Re: we now have "lilypond" organization on GitHub

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> Forget big-picture pontification -- I never intended to engage in
> that.  What it comes down to is this.
>
> I've contributed code and documentation to a variety of different free
> software projects.  Lilypond stands out among them in being
> _astonishingly_ difficult to contribute to, and this difficulty is
> almost entirely down to the choice of tools and the way in which
> certain procedures are managed.

You can post a patch to the developer and bug list if you want to, and
the bug squad will likely pick it up.

The instructions state things like

    Small additions
    ---------------

    For additions to the documentation,

      1. Tell us where the addition should be placed.  Please include both
         the section number and title (i.e. "LM 2.13 Printing lyrics").

      2. Please write exact changes to the text.

      3. A formal patch to the source code is _not_ required; we can take
         care of the technical details.

      4. Send the suggestions to the `bug-lilypond' mailing list as
         discussed in *note Contact: (lilypond-web)Contact.

What's so hard about that?

    Larger contributions
    --------------------

    To replace large sections of the documentation, the guidelines are
    stricter.  We cannot remove parts of the current documentation unless
    we are certain that the new version is an improvement.

      1. Ask on the lilypond-devel mailing list if such a rewrite is
         necessary; somebody else might already be working on this issue!

      2. Split your work into small sections; this makes it much easier to
         compare the new and old documentation.

      3. Please prepare a formal git patch.

It does not state "please use git-cl"

Then it follows up with

    Announcing your snippet
    -----------------------

    Once you have followed these guidelines, please send a message to
    lilypond-devel with your documentation submissions.  Unfortunately
    there is a strict `no top-posting' check on the mailing list; to avoid
    this, add:

       `> I'm not top posting'

       (you must include the > ) to the top of your documentation addition.

       We may edit your suggestion for spelling, grammar, or style, and we
    may not place the material exactly where you suggested, but if you give
    us some material to work with, we can improve the manual much faster.

       Thanks for your interest!

> In every case, whether it's git-cl, whether it's the way the bug squad
> duties are to be carried out, or whether it's how pull requests are
> managed, it almost always seems to come down to involving unnecessary
> mental and manual and custom-built work where for years there have
> been standard automated tools that would handle those problems.

The point is that we _have_ a bug squad that would take the work off
your hand that you complain of.

> That makes me very, very sad because I love so many aspects of
> Lilypond and I want very much to contribute.  But -- I'm sorry -- I
> don't want to tolerate unnecessary obstacles to contribution.  I want
> the time I spend on contributions to be spend on writing code or
> documentation, not on working around finnicky tool problems.

So why would you not spend time on writing code or documentation and
leave it to the bug squad to work around finnicky tool problems?  What's
keeping you from it?

> I'd be much more willing to temporarily put in that effort to work
> around those issues, if I felt that at least there was recognition of
> the usability issues I (and others) have raised.  But every time there
> is this reaction: "Why don't you do it, then, since you know so well
> how it ought to be."
>
> Whatever is meant by those saying it, at the end of the day it comes
> across as: "Hey, we don't care about your usability issues, we don't
> care that it's difficult and finnicky to contribute to us, we only
> care about solving that problem if you solve it for us."

> And ultimately, that's very demotivating and makes everything about
> contribution feel bad.

How about not worrying about the tools then and just doing your
contribution any old way you prefer to work?  We have procedures in
place for picking up from there.

Once those responsible for picking up get overwhelmed in work, we can
think about how to make it easier for them.

But so far, in spite of the Contributor's Guide clearly spelling out
that documentation contributions don't require you to juggle the tools
and review procedures yourself, there is not a lot of contributions to
manage.

-- 
David Kastrup