LilyPond Contributor's Guide: 13.5.3 Policy decisions

### 13.5.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:

>     https://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: Rietveld 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 gerrit? https://sourceforge.net/p/testlilyissues/issues/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)

#### LilyPond — Contributor’s Guide v2.22.2 (stable-branch).