> The biggest problem with this kind of documentation is that it always risks > ending up outdated; how do we encourage developers to keep it up to date > once it's done?
My response to this has been to put such documentation in the code itself. As developers, our responsibility is to the code, and so I think on balance developers feel more obligated to maintain docs in the code than docs outside the code. Obviously this doesn't work for docs whose audience includes many people who don't have a mozilla-central checkout. On Fri, Jun 14, 2013 at 8:51 AM, Gabriele Svelto <[email protected]> wrote: > On 06/14/2013 04:10 PM, Eric Shepherd wrote: >> >> We may be contracting out to help get the core B2G docs up to date. By >> that, I mean, things other than Web-facing stuff. Things like core >> libraries, architecture, that kind of thing. > > > Will this documentation be oriented towards developers who might actually > want to work on the B2G core (gecko, gonk, platform stuff, porting, etc...)? > > There's quite a few areas of our code which will appear pretty obscure to > anybody seeing them for the first time without some form of documentation. I > was working myself on a document on our memory management policies which > would cover low-memory detection, memory pressure events, OOM killer policy, > priorities and so on. > > The biggest problem with this kind of documentation is that it always risks > ending up outdated; how do we encourage developers to keep it up to date > once it's done? Outdated documentation can often be worse than no > documentation at all and B2G has been a pretty fast moving target until this > point. > > Gabriele > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
