On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote: > Han-Wen Nienhuys <[email protected]> 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
