kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Marco,

Am 06.05.20 um 11:59 schrieb Marco Ciampa:
> This issue:
>
> https://gitlab.com/kicad/services/kicad-doc/-/issues/773
>
> is directly related to our lack of manpower or really to our lack of courage?
>
> Lets fork the docs and purge the 5.* docs from 6.* new features info.
>
> For what I see docs are already frozen and that can be a reason.
>
> Making cherry-picks here and there between the two branches should not be
> a big deal...
>
> What do you think?

having just one branch for all the development directions can't be the 
right way.

Uses branches within git is easy and costs quite nothing.

Drop all non relevant branches within the Gitlab instance for kicad-doc. 
I see e.g. branches like dynamic_version_info, zh_po_hack, 
github/fork/*. I've no idea waht they are for, other users for sure also 
don't know why they are here.

Specify the branch structure so contributors see were they are. E.g. use 
master' for the documentation of the current upstream behaviour, use 
'release-5.1' for the current stable release tree, once KiCad 6.0 got 
the final release create a new branch 'release-6.0' on top of the 
'master' branch.

All contributions need to be done by direct commits of people who have 
commit access or by *fast-forward* merge requests.

Keep the structure clean and simple and document this.

I've lost finally the interest to work on the documentation due the 
above reasons. But the main reason in my eyes for the outdated 
documentation is the lack of people who are willing to write some 
bleeding edge documentation. I'm not a native English speaker, I'd be 
the wrong person for doing anything on this.

--
Regards
Carsten