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.schoen...@t-online.de > <mailto:c.schoen...@t-online.de>>: > > 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@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp