kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

No one is going to argue that our documentation could be improved.  I'm
not really sure what the best approach would be to do that.  I would
prefer that we work with the tools and infrastructure we already have in
place rather than create a new dependency if at all possible.  What
about creating a documentation todo list asciidoc file in the
documentation repo.  The list would be broken down into two sections,
undocumented features and out of date/obsolete features.  Each section
can be broken down by application.  This would give folks looking to
help an idea of what needs to be done.

On 11/2/2017 3:24 AM, Nick Østergaard wrote:
> We used to have an ether pad on pads.kicad-pcb.org
> <http://pads.kicad-pcb.org> where I collected notes on new features and
> changes for 5.0.0. But this is down, and Ajo who runs it has been
> unresponsive for quite some time. I was intending to start a news post
> on the website to collect it, but I didn't manage to do this in time.
> 
> 2017-11-02 7:56 GMT+01:00 Carsten Schoenert <c.schoenert@xxxxxxxxxxx
> <mailto:c.schoenert@xxxxxxxxxxx>>:
> 
>     Am 01.11.2017 um 16:20 schrieb Marco Ciampa:
> 
>     > This is my suggestion:
>     >
>     > Dev programmers whose group of patches were made accepted in the
>     master
>     > tree should at least write a line in the (now inexistent) NEWS file.
> 
>     That's the way it's typically working. And looking at workflows and
>     methods of other long term projects can really help to not reinvent
>     wheels again.
> 
>     Git itself can produce some of the entries if commit are made wisely.
> 
>       git log --online [foo-options]
>       git whatchanged
> 
>     are the things I mostly use to get an overview whats happen in the past.
>     And that's why git commits should strictly follow some rules, otherwise
>     I need an expensive amount of time to get the needed overview what has
>     changed.
> 
>     > That should be made during or immediately afterwards the git merge.
>     > Now tracing the new features of KiCad could be very difficult.
> 
>     Can be but shouldn't. I guess every developer who has contributed
>     specific parts knows best what his work has changed, improved or added.
>     So maybe it should be started here, just write down what comes in mind
>     to be worth referenced in a Changelog. Based on this there needs to be
>     decided what has to be done on the documentation part.
> 
>     A Etherpad site could be a starting scratch notepad, someone can pick up
>     the notes then into a KiCad wiki site on GitHub?
> 
>     --
>     Regards
>     Carsten Schoenert
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>