Re: development process

[Graham Percival]

On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote:
> Han-Wen Nienhuys <address@hidden> writes:
> > For context, I have a busy daytime job. I work 80% so I can set aside
> > a couple of hours of concentrated hacking time on Friday.

Yes.  I expect that most people knowledgeable about lilypond code
are in this situation, or have even less time available.  The
whole idea behind the "countdown" system introduced in the early
2010s (which I believe is still in effect) is to make maximum use
out of LilyPond experts who only have a few free hours per week.

Suppose that an expert has 2 hours of time on Friday, and maybe 10
minutes per day to skim emails for the rest of the week.  The idea
is that you can quickly see the patches that are nearing
acceptance, review them, and warn if they make any bad changes.

That's why the "countdown" system has multiple stages -- it was
designed to take at least 72 hours (IIRC) from submission to git
master, precisely to allow infrequent-but-expert developers a
chance to spot mistakes before they got into git.


> >    We use “we’ll push if there are no complaints” for contributions. I
> >    think this is harmful to contributors, because it doesn’t give 
> > contributors
> >    a clear feedback mechanism if they should continue down a path.
> 
> They get feedback when the code is getting reviewed.  If code does not
> get reviewed, having their changes dropped on the floor is not going to
> increase their enthusiasm.

Yes.  And unfortunately, LilyPond has had a lot of patches get
dropped because nobody feels comfortable reviewing / shepherding
them.

That could be avoided if the community demanded that expert
developers spend more time reviewing patches and mentoring
beginners... but that would be horribly insulting to those
developers.  If somebody has volunteered x hundred hours, then
wishes to follow other persuits, the community should thank them
for their effort and wish them well.

> >    It is harmful to the project, because we can end up adopting code
> >    that we don’t understand.  -

That's true.

It's not an easy place to be in:
- there's not enough experienced developers who want to mentor
  newcomers [1].
- if it's too easy to get code in, stuff will break.
- if it's too hard to get code in, few people will want to
  contribute.

I'm not claiming that the current situation is the ideal balancing
point, but we were aware that it was a compromise solution.

[1] there's good reason for that -- my experience from the grand
documentation project is that approximately 25% of contributors
reached the "break-even" point (compared to me simply writing all
the docs myself) [2].  Based on my investigation into similar
projects (GNOME, google summer of code, etc., around 2012), that
figure is normal.

[2] of course, some of those 25% have gone on to do an incredible
amount of work, so I consider the project to have been a great
success.  Still, I can see how it can be demoralizing for a
developer to put hours into mentoring a newcomer who ends up
contributing only one or two small patches.

> The current scripts were designed to work with Google Code,

Yes.  I wish that github was FSF or GNU approved, or that there
were other tools of the same quality.

Cheers,
- Graham