[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 1463 in lilypond: Writing metadata to the PDF file
From: |
Colin Campbell |
Subject: |
Re: Issue 1463 in lilypond: Writing metadata to the PDF file |
Date: |
Sun, 06 Feb 2011 18:47:56 -0700 |
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)