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