My responses to developers' responses

[address@hidden]

Hey all,

Thank you very much, Colin, for organizing these responses.

I think GOP2-0 is very important, and as such I'd like to send responses to 
certain excerpts from other people's emails.

DevC

> There's a similar problem with trying to recruit new contributors.
> Person 41 says "hey guys, it's easy to help!  here's a link to get you
> started", then person 15 immediately says "no wait, it's too hard.
> Don't get involved unless somebody will help you".  And then person 15
> and 94 start arguing about something else, so even if somebody still
> wanted to help out, the argument would drive them away anyway.  But
> just like the website problem, it seems that nobody is saying "yes, we
> should have new contributors, so I will help 1 person get involved and
> take responsibility for giving that 1 person a fair chance to
> contribute".

I agree.  I do not believe that saying "it's too hard" is a good solution.  I 
am more than willing to help people this way - I am officially naming myself as 
"New Contributor Czar" and will propose a patch in an hour that advertises this 
on the website.

> The arguments are another problem that lessens the feeling of
> teamwork.  We should be able to "agree to disagree" -- namely,
> politely state our opinions and any evidence to support them, read
> other people's opinions and evidence, and compare the two.  Even if
> there is no consensus, we should still appreciate that the other
> people are trying to make lilypond better.  I don't feel that we've
> had polite disagreements in all cases, such as the recent argument
> about s1*0 vs. <>.

I agree, but I have come to realize in the past year that politeness is more 
linked to someone's capacity to be polite than any inherently good or bad 
aspect of a patch (meaning that there is no such thing as a patch that merits 
more or less politeness, just people who are more or less polite by nature).  I 
used to get hung up on this and hurt by certain comments, but I have since just 
come to say to myself "person X or Y is sometimes impolite", not as a value 
judgement, but simply to remind myself that this is how person X or Y 
communicates.  I believe this type of distance is critical: people often cannot 
control their level of politeness (in the same way they can't control if they 
feel offended or hurt) and I now just accept everyone on this list for who they 
are and have learned to understand what they mean without taking things 
personally.  Everyone on this list wants to make beautifully typeset music - 
for me, that is reason enough to work with them without letting personality 
differences get in the way.

> The last "teamwork" problem is the amount of "monetization" going on.
> I didn't join lilypond to help other people make money off it.  I
> don't have any good suggestions for this, but the question asked if I
> was contributing less and this is one reason.  Having some people
> making money and others not makes it feel like less of a "team".

When I worked a church gig for 3 years, I made money, as did the pastor and 
other members of the community.  There were many other members of the community 
who simply donated their time to the church.  Others couldn't donate time but 
benefited from church events and the Sunday service and were grateful that the 
church was there.  Here, we were able to use the paid roles in order to create 
more, not less, of a sense of teamwork.  I encourage people to ask themselves 
how they can make LilyPond work like this.  I didn't join LilyPond either to 
help other people make money off of it, but I'm thrilled that my contributions 
to it can help people like David work on it full time, which in turn makes 
LilyPond better and therefore easier for me to contribute.

Lastly, monetization often goes hand-in-hand with team building.  I think our 
team can only get stronger because of stuff like LoMuS and GSoC, and I think 
it's important to keep looking for rewards and programs like this.

> The third reason is the patch-handling setup.  There have been a few
> times that some documentation needed a little edit or tweak here or
> there, but I just couldn't be bothered to make a new branch, do the
> edit, upload to rietveld, wait a few days, then push that branch to
> staging.

I do fixes like this all the time w/o the full review (i.e. the pondings 
column).  Everyone trusts you - if it's truly a minor tweak, go for it.

DevG

> Serious involvement with LilyPond, be it as a user,
> developer or doc-writer, requires a serious commitment of time and
> effort.  For me, and probably for most others, that level of
> dedication can be maintained only for so long.

I feel the same way - I had a long burst of energy, and I will still be doing 
the skyline patch, but I'm spending a lot more time composing and performing 
now.  I think that the solution is pedagogy - get people interested in LilyPond 
so that someone can rise out of the crop who, for a year or so, can sustain a 
high level of development performance.  I'll be doing what I can when I go on 
tour w/ my group next year.

DevH

> My motivation goes down when i feel insignificant:
> 
> - when i don't get reviews

I am a culprit of this and I'll try to do a better job.  I've found that, for 
me, I've hit my reviewing stride w/ Janek - not necessarily patch reviews, but 
e-mails back and forth about GSoC.  This is more informal than Rietveld but I'm 
much better at responding to targeted questions rather than looking at the 
totality of the patch.  I used to be on the sending end of these e-mails to 
Neil and Han-Wen.  It's less transparent than the common process but it speeds 
things up and I think we should encourage more stuff like this.

> - when a simple patch takes forever because every word is discussed
> over and over again

Agreed - I think less is more here.  I've lost time on patches going over and 
over things that could have taken way less time.  I think that Keith is a model 
for good patch review - he says what needs to be done, I get it done, and all 
is well.  No confusion, no arguments.  Very efficient.  When I do give 
feedback, I try to model mine on his and I'd like to see everyone do the same.

> - when i spend more time on maintenance (creating issues, searching
> for messages on two trackers+email, closing issues, pushing to
> staging) than actual work

This surprises me - I have often felt that maintenance was annoying (we all do) 
but I never felt like I spent more time on this than actual devel work.  The 
automation tools that Graham has made are excellent and the bug squad is really 
helpful w/ reminders if need be.  I'd encourage everyone to get the most 
up-to-date git-cl.

> 
> - when someone else could in half an hour do what i'm struggling to do
> since two days (but he simply doesn't have time)

Just send an e-mail to the list or to an individual.  Almost every time Werner 
sends an e-mail saying "do thing X" I do it.  I mostly don't work on issues 
because I don't know about them or don't feel they're particularly urgent or 
important.

> Finally, i think we lack a vision and common goal that would give us
> motivation boost.  I find it quite surprising that Janek's articles in
> LilyPond Report #25 and #26 gathered little comments from experienced
> developers.


I completely agree that this work is essential.

DevL

> 1. Friendship and the fun of creating: ... now I realise
> that working together on a project (the how) is possibly more
> important than what you are making (the what).

I enjoy working with the development team and I try to make it as social as 
possible. I'm lucky to live close to several developers.  That said, the one I 
see most (Valentin) and I rarely work on LilyPond development together, though 
we use it and promote it all the time.

> For me, working on
> LilyPond was mostly fun.  Anything was possible, the only limitation
> was myself.

I still feel this way about LilyPond.

> 3. Shared, global responsibility and trust: Breaking things seems
> critical now, you have to be extremely careful.  When things broke,
> anywhere in LilyPond (C++, Scheme, build system, Python, Scheme) often
> another developer would have it fixed before you found out yourself.
> Everyone had almost global understanding of everything, we all made
> mistakes and we all knew that we all made mistakes (incidentally:
> that's how people learn best). 

This is more or less how I approached LilyPond when I started development a 
couple years back.

It'd be great to see others get to the "everyone had an almost global 
understanding of everything" point - I think the GSoC project will be great for 
Janek to get there and I'm always willing to give people a hand understanding 
stuff.  This is especially true for bug-squad members and doc writers: you guys 
have already gone through all the hard stuff.  Understanding the code base is 
easy compared to creating a first score with LilyPond, which all of you have 
assumedly done.

Cheers,
MS