Re: development process

[Joram Noeck]

Dear developers,

tl;dr:
 * please continue those discussions to a constructive end
 * my experience as a non successful contributor


after more than a year of (relative) abstinence from LilyPond, I enjoy
reading the current drive in both commits and discussions in the
aftermath of the Salzburg conference. (I wished I could have been there.)

I am not a LilyPond developer, so the following is more an outside
perspective. I decided to share it, because "potential new contributors"
are mentioned several times. While sometimes there are no two ways about
it, there is room for improvements and compromise, I guess. Neither the
current dev process and tools are optimal nor is it advisable to change
everything. Because I can feel some tension in the recent discussions,
I’d like to emphasize that the following is to be read in a very
friendly tone.


Experience with trying to contribute
------------------------------------

I am working with software development every day. I wanted to contribute
to LilyPond since about 2005. It never happened and there are some reasons:

- Even after reading the CG and getting some helpful answers to
questions, I never understood how the process works.

- tools:
  - I am used to github+travisCI and to Atlassian/Bitbucket/Jira/Jenkins
and I enjoy working with those setups. But I never understood the
LilyPond toolchain and especially the path from a commit/issue to the
final change in a LilyPond version.
  - I don’t understand why
     · there are so many tools involved, lily-git, git-cl and so many
       accounts required
     · it seems so hard to compile LilyPond on an ordinary Linux machine
       i.e. why I need LilyDev
     · dependencies on clang-format or (for a long time) python3 are
       frowned upon while the dependencies on guile and GUB look much
       more complicated to me.
  - I guess (because I haven’t worked my way through the current tools),
several of the already listed tools with better integration of review
and/or issue tracking would be an improvement over the current tools.
  - At some point I needed a Google account which I didn’t want and
could not get without a cell phone.

- I experienced quite some amount of misunderstandings and in a few
cases insinuations which made it very unpleasant to invest the work to
get over the technical hurdles. I felt a bit scared away.

- According to what I read on lilypond-devel, quite frequently
suggestions end up in an undecided state where some are for and some are
against a proposal. But that is probably much less the case for patches.

That’s my very personal experience. I have some minor local patches,
some are made obsolete by recent development. In some months from now, I
might make a new attempt to understand how contributing works.


Braking things down
-------------------

I have the impression that what is currently discussed might be too big
to be decided upon at once. There could be some merit in splitting
things into smaller decisions. I see at least these points:

1. code style conventions
   a) checking tools (astyle, clang-format), for scm or python?
   b) changes only for new code?
   c) and their level of enforcement (hooks, review process, …)
2. tools for git, review, issue tracking, release management
   pros and cons have been mentioned for several options, but even
   if there is nothing new, a systematic assessment could help
3. development process / code of conduct
   a) number of stages from a proposed patch to a final change
   b) decision process and who decides what
   c) formal rules vs. consensus

I am sure I missed some important points here.


Even if it doesn’t matter at all, my personal choices would be:
- tools: github+jenkins, but very open to gitlab and others
         definitely clang-format over astyle (just my experience)
         I moved once from trac to github.
- less manual work in cherry-picking, testing, linking commits to issues
- much more openness towards change
- a clearer description how decisions are made and who decides while
still preferring to keep a community mindset over a strict rule set.

Many thanks to all developers for making LilyPond what it is and I wish
that you can see those discussions as a fruitful way to improve things.
In my opinion it matters for potential new developers.

Cheers,
Joram