Re: Add Code of Conduct (issue 575620043 by address@hidden)

[Karlin High]

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