| [ << Administrative policies ] | [Top][Contents][Index][ ? ] | [ LilyPond grammar >> ] | ||
| [ < Ongoing jobs ] | [ Up : Grand Organization Project (GOP) ] | [ Policy decisions (finished) > ] | ||
14.6.3 Policy decisions
There are a number of policy decisions – some of them fairly important – which we have been postponing for a few years. We are now discussing them slowly and thoroughly; agenda and exact proposals are online:
http://lilypond.org/~graham/gop/index.html
Below is a list of policies which are not “on the agenda” yet.
Note that the presence of an item on this list does not mean that everybody thinks that something needs to be done. Inclusion in this simply means that one developer thinks that we should discuss it. We are not going to filter this list; if any developer thinks we should discuss something, just add it to the bottom of the list. (the list is unsorted)
As GOP progresses, items from this list will be put on the agenda and removed from this list. I generally try to have one month’s discussion planned in advance, but I may shuffle things around to respond to any immediate problems in the developer community.
There are some item(s) not displayed here; these are questions that were posed to me privately, and I do not feel justified in discussing them publicly without the consent of the person(s) that brought them up. They will initially be discussed privately on the lilypond-hackers mailing list – but the first question will be "do we absolutely need to do this privately", and if not, the discussion will take place on lilypond-devel like the other items.
In most policy discussions in lilypond over the past few years, the first half (or more) is wasted arguing on the basis of incorrect or incomplete data; once all the relevant facts are brought to light, the argument is generally resolved fairly quickly. In order to keep the GOP discussions focused, each topic will be introduced with a collection of relevant facts and/or proposals. It is, of course, impossible to predict exactly which facts will be relevant to the discussion – but spending an hour or two collecting information could still save hours of discussion.
Note: The estimated time required for "prep work", and the following discussion, has been added to each item. At the moment, there is an estimated 30 hours of prep work and 140 hours of discussion.
- Patch reviewing:
At the time of this writing, we have 23 (known) patches waiting
for review. Some from main developers; some from new developers.
We desperately need more people helping with lilypond, but
ignoring patches is the best way to drive potential contributors
away. This is not good.
(prep: 2 hours. discuss: 10 hours)
- Official links to other organizations?:
There’s something called the "software freedom conservancy", and
in general, there’s a bunch of "umbrella organizations". Joining
some of these might give us more visibility, possibly leading to
more users, more developers, maybe even financial grants or use in
schools, etc.
(prep: 2 hours. discuss: 5 hours)
- Issue tracking with google code:
We use the google issue tracker, but this means that we are
relying on a commercial entity for a large part of our
development. Would it be better (safer in the long run) to use the
savannah bug tracker?
(prep: 1 hour. discuss: 5 hours)
- Patch review tool:
Reitveld is inconvenient in some respects: it requires a google
account, and there’s no way to see all patches relating to
lilypond. Should we switch to something like gerritt?
http://code.google.com/p/lilypond/issues/detail?id=1184
(prep: 5 hours. discuss: 15 hours)
- Clarity for sponsorships:
We currently do not advertize bounties and sponsorships on the
webpage. How much advertising do we want, and what type?
Should we change the "structure" / "framework" for bounties?
(prep: 2 hours. discuss: 10 hours)
- code readability:
"Our aim when producing source code for Lilypond in whatever
language is that it should be totally comprehensible to a
relatively inexperienced developer at the second reading."
Rationale: - aids maintainability of code base - "second reading" so newer developers can look up unfamiliar stuff - will help to keep things simple, even if the code is doing complex stuff discourages "secret squirrel" coding, e.g. "how much functionality can I squeeze into as few characters as possible" "comments are for wimps" - will aid not *discouraging* new developers to join the project
(prep: 2 hours. discuss: 10 hours)
- C++ vs. scheme:
what should be in scheme, what should be in C++, what can/should
be ported from one to the other, etc. Questions of
maintainability, speed (especially considering guile 2.0), and the
amount of current material in either form, are important.
(prep: 5 hours. discuss: 15 hours)
- always make an issue number for patches:
there is a proposal that we should always have a google code issue
number for every patch. This proposal is closely tied to our
choice of patch review tool; if we switch to a different tool (as
suggested in a different proposal), this proposal may become moot.
(prep: 1 hour. discuss: 5 hours)
- initalizer lists:
shoudl we use initalizer lists for C++? AFAIK they make no
difference for built-in types, but there’s some weird case where
it’s more efficient for objects, or something.
Probably not worth making this a weekly thing on its own, but we can probably wrap it up with some other code-related questions.
(prep: 15 minutes. discuss: 3 hours)
| [ << Administrative policies ] | [Top][Contents][Index][ ? ] | [ LilyPond grammar >> ] | ||
| [ < Ongoing jobs ] | [ Up : Grand Organization Project (GOP) ] | [ Policy decisions (finished) > ] | ||