I've been following Lilypond mailing lists since 2016 or so. I'd describe my most common role as "entry-level tech support," answering the most basic mailing list questions so better-skilled people don't have to deal with them.
I can point to the exact thread(s) that drew me into the Lilypond community. (keywords: mclaren prime tuplets) The outstanding feature to me was its handling of conflict. <https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00409.html> In that thread, it was as if someone had read the Dale Carnegie "How To Win Friends and Influence People" book and then behaved the exact opposite of everything the book teaches. David Kastrup has often been criticized for lacking "soft skills" with people. But there I noticed he kept offering help (well-wrapped in sarcastic rebukes, I grant) after many "nicer" people had lost their tempers and were calling for the offending user's head. <https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00403.html> I could easily spill 800 words on the Code of Conduct proposal. But Carl Sorensen's posts already pretty much captured what I'd have to say. The only thing I'll add is that according to this article on SourceForge, a lack of project contributors is not in any way unique to LilyPond, or likely to be much solved by adopting a Code of Conduct: " Open Source Is Growing, But Not How It Should ...According to a recent survey from Stack Overflow only a mere 12.4% of respondents said they contribute to open source at least once a month or more often, and 23.1% said they contribute more than once a year but not monthly. The rest of the respondents, which constitute more than half, said they contribute less than even once a year or not at all... " <https://sourceforge.net/blog/open-source-growing-not/> I agree with Mike Solomon's conclusion that the Contributor Covenant Code of Conduct is not a good fit for the Lilypond project, in the state they are each currently found. I don't disagree in principle with the effort to have something like that, though. I just came across the one on GitLab's forum today and was favorably impressed. <https://forum.gitlab.com/faq> If a project reform effort is desired, I think the code contribution workflow is a much better choice. Pretty much everyone agrees that what we have isn't good. I'd really like to see the issue tracker, code review, and repository all together in one place. GitLab looked good in a previous thread researching it, but I have no emotional investment in anything here. My personal story of contributor experience: I have done one patch, ever. It wasn't easy. But that's not really anyone's fault. In fact, the lilypond-devel list was outstanding in support efforts; I consider it my collective mentor. Lilypond is just a HARD project. Converting plain text to beautiful sheet music, what else to expect? It needs music theory, music engraving, computer science, C++, Guile, Python, Bison, PostScript, fonts, MetaFont, Texinfo... the list just goes on. Following the Lilypond mailing lists has taught me more about music than most anything else, but I simply don't currently have the skills for being a big contributor. My formal education stopped at 8th grade. I had lots of computer time in late teen years, but it was Windows 98, Microsoft Office, and Visual Basic for Applications. A Knoppix Live CD entered the picture eventually, and I've enjoyed Linux ever since. But usage habits had already been formed. I find Unix-world text editors and Git interesting, but intimidating. I'd probably do well to learn them, but as stratechery.com Ben Thompson says, once something's getting the job done for someone, it needs a 10X improvement to get them to switch to something else. For most any Lilypond code I want to work on, it seems I need to research a fair list of foundational concepts first. I actually enjoy doing that, but a self-employed father of five (oldest age 11) can only do so much for hobby projects. At my state in life, it's hard to study up on something before the need arises for it. For me, another big barrier to contributing is simply not knowing what's a good area to work on. The single biggest thing I've seen working to get people contributing is inviting them into a definite effort with clear instructions. Example: Knut Petersen's "Please Test GUB" thread from a year ago, which got about 16 people helping on one of the thorniest parts of the entire project. <https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html> Another thing: I don't see any substitute for having full-time developers. I was following the list for a long time before I realized that David Kastrup's position depends on financial support from the community, or how people could contribute that way. Currently, the Lilypond website's "Sponsoring" page says nothing about this. <http://lilypond.org/sponsoring.html> I'd like to see that changed so that anyone with Git commit privileges and a flexible schedule (allowing doing more Lilypond work if getting more Lilypond pay) could get their name and brief bio on that page with a paypal.me link or similar. Changes to the page would go through normal code review, hardly any new processes would be needed. -- Karlin High Missouri, USA
