Re: branching

[Mike Solomon]

On Dec 11, 2013, at 12:03 AM, David Nalesnik <address@hidden> wrote:

Hi,

On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson <address@hidden> wrote:

On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon <address@hidden> wrote:

The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating.  I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has peaced out because of this.  I am looking for ways for this to no longer be an issue.  I was hoping that branches would go a way towards making this happen for myself and hopefully other developers, but it’s clear that this is not a good idea.

In my two day jobs, director of the ensemble 101 and developer for the Guido project, I work with two (very different) teams of people on projects that require creativity, consistency, and tons of communication.  Neither of them has any of this friction resulting from communication issues, both of them enjoy a diversity in major contributions, and both are evolving rapidly and stably in several interesting ways at the same time.  I truly hope that LilyPond can be like that.

I don't know how you communicate with your other two teams,

Face-to-face communication for one, e-mail for another.

I always feel a bit silly writing emoticons and exclamation points, but they are nice to see(!)

 

It is regrettable that you would let such things interfere with your contributions to LilyPond.

Exactly.  Both you and David are invaluable to this project.  I watched the paralysis set in, the deadlock, and wondered a bit about the future of the project.  I think there has to be some compromise in this Apollonian/Dionysian test of wills (to throw in a little pretentiousness).

See:

http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870

as one of several examples.  There is truth in anything David says, meaning that I (like him (and most of us on this list)) have caused bugs that I did not find or fix before someone else.  How, does this warrant this communication style?  This chain of e-mails was the single determinant that ruled LilyPond out of a government funded, multi-national European typesetting project I’m organizing in which the team will need to extend aspects of the software.  I imagined the score of man hours that goes into all the projects I do and how important team morale is over the long term.  I don’t want anyone on my team to lose time feeling bad from e-mail confrontations - it’s not worth it for many reasons.

 

Ultimately, it is about the project, not the people. Perhaps counter-intuitively, the answer to the problem you perceive is not to reduce participation, but to increase participation. In my own case, my interactions with David had the effect of getting me more involved in the "behind the scenes" workings of the code. Why? So that eventually, David won't be able to criticize me for not being willing to "get my hands dirty."

Well, I ordinarily have a bit of a thin skin, and I remember reading somewhere on the lists that you have to have some nerve to contribute.  My personal response to the possibility of brutally honest criticism--which is a necessary thing if this project isn't going to go to hell--is to make sure I've got everything as polished as I can make it before I make it public.  And accepting that I've got a lot to learn,  (This is about me, and is in no way directed at you, Mike.)

Of course I have a lot to learn, too.

I release things in various states of polished-ness to the list, often because its their unpolished-ness that I need comments or opinions on.  This in and of itself is valuable information.  Imagining a hypothetical scenario where I sent a patch that someone wants to see restructured into several commits before they can review it.  One developer responds:

It’s difficult for me to understand what you’re doing - please split it up.

and another responds:

Please act like a member of the community, start taking other people into consideration and split up your patches.

The information is the same, but (A) makes me want to stay in the project a lot more than (B).  A lot of (B) causes me to lose interest.  How does one proceed?  Should one gloss over the way (B) is written and get (A) out of it?  Should one respond to (B) on its own terms?  How does one let these things not interfere with one’s contributions?

I currently have a boss who is an industry-expert in typesetting that decided not to get involved with LilyPond development 3 or 4 years ago because of feuds he saw on the devel list.  This is not good.  By old developers not contributing as much and new ones not wanting to join, our community has dwindled down to one where 40% of commits are made by one person, and this is including documentation, meaning that when it touches the folders ly/, scm/, and lily/ it is a lot higher.  Compare http://www.ohloh.net/p/lilypond/contributors/summary to http://www.ohloh.net/p/musescore/contributors/summary and http://www.ohloh.net/p/supercollider/contributors/summary.  LilyPond is not in good shape.

David’s argument, which I agree with, is that LilyPond needs to get more modular.  This will make contributing easier while avoiding confrontation once the barriers to entry are lower.  Is it our desire as a community, then, to give David stewardship over the bulk of developing the program until he gets it to this point of modularity?

However, when the standstill happens, something has to be done.  I'm sorry that I don't have any solution to offer, other than to try to work together for the sake of LilyPond,  (Emoticons!  Kidding.)

I had coffee with a developer a year or so ago who told me that he dropped out of the project because of commutation problems with David.  Last night I wrote to him to share some of these frustrations and he wrote back: “as long as David is leading up the team, it’s a lost cause, nothing has changed and his way of acting is too problematic, independently of his technical excellence.”  I tend to conceive of problems in terms of one, two, or many.  The problem here has reached the “many" level and I think we need to find a solution that goes beyond the individual.  List-etiquette policies, branching policies - I’m open to trying anything.

One thing that is important to restate is that I realize that, unlike my bad-but-getting-better commenting style, _all_ of this is out of David’s control in that it stems from a medical issue.  Which means that the communication problems won’t go away - they’re going to be a fixture of LilyPond development so long as he’s involved.  As a group of humans, it is _everyone’s_ responsibility to find creative ways to get past handicaps because _no one_ wants to have them.  What I’d like to see is a situation where David can blow off steam however he needs to, he doesn’t feel like people are ignoring him, and LilyPond can be a dynamic, multiplayer environment without people getting offended and leaving the project.

Cheers,

MS