On Mon, 2011-02-07 at 00:26 +0100, Reinhold Kainhofer wrote: > Am Sonntag, 6. Februar 2011, um 23:58:20 schrieb Graham Percival: > > There's five questions in my mind. > > > > 1) should we reject a patch which does not have complete > > documention? (IMNSHO: no) > > I would word it differently: > We encourage (although not absolutely require) each developer to write basic > documentation for a new feature. > > > 3) once a code patch has been accepted, should we reject any doc > > patch written by the programmer? (no, of course not! If a > > programmers *wants* to write docs, then of course that's great! > > Okay, then expect some patches for my new features in the 2.13 release. > > > 4) once a code patch has been accepted, should we immediately add > > a doc-issue to the tracker for missing docs? (this one is > > arguable; at the moment I don't see the point of doing this, but > > if somebody is very excited about some particular piece of missing > > docs and enjoys playing with the google tracker, I'm not going to > > stop them) > > I would prefer a new issue so that no new features are missed. >
As a sort-of doc polisher cum bug squadder, I welcome the idea of a class of issues based on a "rough cut" by the developer describing a new feature, which would be the documentation equivalent of a frog task to polish. Colin -- In seeking wisdom, the first step is silence, the second listening, the third remembering, the fourth practicing, the fifth -- teaching others. - Ibn Gabirol, poet and philosopher (c. 1022-1058) _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
