Re: sustainable development in LilyPond
On Mon, Aug 23, 2010 at 11:06:02AM +0200, Jan Nieuwenhuizen wrote: > As I read it, your mentoring efforts did not get you what > you wanted (doc writers), but it got you something else > (possibly more valuable/hard to get?): developers. Is > that correct? What I wanted, most of all, was to have a doc team to replace me. In late 2006 or early 2007, I realized that I was completely "burnt out" with respect to doc stuff, and I really wanted to start doing programming. In particular, I wanted to fix all the old collision bugs that nobody else seemed to care about. So I launched the biggest "resignation period" ever: a 12-month project to train anybody who wanted to do doc stuff. 4 months into the public, I publicly announced that I would be leaving at the end of it. And when that day came, I officially left for 4 months. When I returned, there was nobody working on docs. Some people were programming; some people wanted to do docs but had health problems; some people had drastically changed circumstances in real life. Everybody had good reasons for not doing doc work any more, but the sum was still 0 people on the docs, out of 21 people who participated in GDP. So, in early 2009, with considerable reluctance and a general sense of failure, I started doing doc work again, and abandoned my hopes of fixing collision bugs. > If so, mentoring may very well not get you what you set > out for, but in a wider context could get you "more > project resources". > > Do you have an idea of how much time you put into this > mentoring, and how much overall project development time > you got (or may/will probably get) out of it? As I said on the page on GDP in the slides: I spent 700-800 hours on GDP. Yes, that's 20 weeks of full-time work . Almost half a year (or maybe more in Europe, with fewer hours per week and more holiday time :) During the course of GDP, the project completed 600-900 hours of doc work. In other words, there was no clear benefit or loss to having me teaching instead of doing doc work myself during that period. It's harder to estimate the amount that we've gotten back since then... anywhere from 500 - 1200 hours of doc work, with potentially much more work from programmers. I mean, if we claim that GDP provided the "spark" for Patrick and Carl to get involved... and if we claim that Carl was the "spark" for all the Frogs... then we're probably looking at a total of 2000 - 3000 hours of work "because of" GDP. But I think some of those steps are a bit of a stretch. Now, the most important question (to me) is not "was it worth 800 hours of my time", but rather "was that the *best* use of 800 hours of my time [towards lilypond]". I mean, there's a lot I could do in that time. - settle the C+scheme indentation debate and provide an automatic tool: 10 hours. (which I'm planning on doing in Sep anyway) - exhaustively learn scheme and our lilpond scheme stuff: 50 hours? 100 hours? - learn enough about programming so I can start reviewing some of those 8-week old patches that nobody is working on: 10 hours? 50 hours? 90 hours? - switch to the waf build system: 200-300 hours - add braille output to lilypond: 200? 400? 600 hours? - run GLISS, standardize output: 100-200 hours - write new website: 50 hours estimated, about 300 hours actual, and now complete - get the Bug Squad organized so that users and developers no longer complain about losing their bug reports: 50 hours so far - fixing those 4-year-old collision bugs: 400 hours should make a serious dent in them, if not finish them all. Now, each of these items will do different things for future developers. Braille output would attract huge attention from the accessiblility community (and their developers), but probably wouldn't be a blip on anybody else's radar. Code indentation is a low-level annoyance that probably won't do anything directly, but reducing annoyance isn't a bad thing. Reviewing people's patches is probably the #1 thing to do to retain developers -- ignoring patches is a great way to drive people away. So maybe I should prioritize learning more about programming stuff... oh, but if I drop all my release work now, lots of people will be pissed off. At the very least I should wait until 2.14.0 is out. etc. With all that in mind, I am confident in stating that GDP was *not* an effective way of gathering more project resources. I don't mind doing it as an experiment, but the results show that unlimited mentoring is *not* effective. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Op maandag 02-08-2010 om 19:31 uur [tijdzone -0700], schreef Graham Percival: Hi Graham, Great talk. How do you reach your conclusion that spending unlimited mentoring is not effective? As I read it, your mentoring efforts did not get you what you wanted (doc writers), but it got you something else (possibly more valuable/hard to get?): developers. Is that correct? If so, mentoring may very well not get you what you set out for, but in a wider context could get you "more project resources". Do you have an idea of how much time you put into this mentoring, and how much overall project development time you got (or may/will probably get) out of it? Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch-reviewing and the i-ching (was Re: sustainable development in LilyPond)
On Wed, Aug 04, 2010 at 02:33:30PM +0200, Mike Solomon wrote: > I am a bit lost with respect to what has to be done and who's working on > what, but I've been chipping away as best I can on issues that, to me, seem > under-commented-upon. In theory, the Status:Started, Owner:foo indicates that. In some cases, it only indicates that foo is responsible for shepherding it. Exceptions: we don't always keep those updated, and anything marked with percival.music.ca or Valentin is likely to be a historical inaccuracy. > I think that Graham's sustainable development presentation is excellent, > especially the part about swag, btw, adapted from http://www.daemonology.net/blog/2009-07-14-a-call-for-schwag.html > In parallel to what he says, I feel that another way to get things > done on a more short-term basis (i.e. before 2.14 and before Graham puts a > sustainable plan into place) is to randomly assign issues to willing > participants via a lottery. I don't think we need any policy change to deal with 15 issues (expected: 30 Criticals before 2.14). In fact, any change is likely to result in mythical-man-month problems. On an individual basis, it would be great if you chose a few Critical issues to investigate, make comments, and maybe even produce a patch. The balance of "investigate new Critical issues vs. review a patch for a low-priority enhancement" is a tricky one, but I'd like to encourage people to do more patch-reviewing and *less* work on new (or un-investigated) issues. Yes, this delays 2.14, but I think that having better discussion of post-initial-patch development effort will pay off more in the long run. My hope is that Marek (the guy who adds ignored patches to the tracker) job is supposed to be a failsafe -- he should have nothing to do. Once a patch is sent to lilypond-devel, we should have a discussion starting within 3 days, and continue discussing it until the patch is committeed or withdrawn. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch-reviewing and the i-ching (was Re: sustainable development in LilyPond)
On 8/4/10 1:25 PM, "Trevor Daniels" wrote: > > David Kastrup wrote Wednesday, August 04, 2010 11:27 AM > > >> "Trevor Daniels" writes: >> >>> 1) There is no architectural overview and no program logic manual >>> to >>> guide new developers through the early stages. >>> This has the advantage that only experienced and expert >>> coders able to deduce the design from the source code are >>> able to contribute significantly, ensuring high quality. >> >> I consider that reverse logic. The problem is that you are likely >> to >> have people reinventing the wheel, leading to a loosely connected >> garden >> of code written by x, code written by y where everybody has >> his own >> ways and subroutines for solving particular subtasks. > > Yes; I worded it badly. I meant, "The only advantage this has > is that ...". You correctly point out the outweighing > disadvantages. > > It was clear, I hope, that I am advocating better documentation, > not less. > > Trevor I am a bit lost with respect to what has to be done and who's working on what, but I've been chipping away as best I can on issues that, to me, seem under-commented-upon. I think that Graham's sustainable development presentation is excellent, especially the part about swag, as I am moving from a wine-drinking country to a beer-drinking country in two weeks and could use a lilypond bottle opener. In parallel to what he says, I feel that another way to get things done on a more short-term basis (i.e. before 2.14 and before Graham puts a sustainable plan into place) is to randomly assign issues to willing participants via a lottery. Said participant would then be responsible for stewarding the issue until resolution, which could involve anything from coordinating efforts on an untouched problem to simply running a test on a patch that is quite evolved and signaling to one of the developers that it is ready to be pushed. It would also be a great way for new folks (like me) to learn - I chose to work on issue 1173 at pseudo-random (Python's random library) and learned a great deal in doing so. If there is sufficient interest in this idea, I think it would be a good way for newcomers and experienced lilyponders alike to move forward with outstanding issues. ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
David Kastrup wrote Wednesday, August 04, 2010 11:27 AM "Trevor Daniels" writes: 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that only experienced and expert coders able to deduce the design from the source code are able to contribute significantly, ensuring high quality. I consider that reverse logic. The problem is that you are likely to have people reinventing the wheel, leading to a loosely connected garden of code written by x, code written by y where everybody has his own ways and subroutines for solving particular subtasks. Yes; I worded it badly. I meant, "The only advantage this has is that ...". You correctly point out the outweighing disadvantages. It was clear, I hope, that I am advocating better documentation, not less. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
"Trevor Daniels" writes: > 1) There is no architectural overview and no program logic manual to > guide new developers through the early stages. > This has the advantage that only experienced and expert > coders able to deduce the design from the source code are > able to contribute significantly, ensuring high quality. I consider that reverse logic. The problem is that you are likely to have people reinventing the wheel, leading to a loosely connected garden of code written by x, code written by y where everybody has his own ways and subroutines for solving particular subtasks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Graham Percival wrote Wednesday, August 04, 2010 9:41 AM On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote: 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that No; there's no advantage to this. It's simply due to an imbalance of high skill, available time/interest, and an overwhelming number of other concerns. I'm quite aware of the problems that this causes for new developers, but as long as we have over 10 patches waiting for review for the past few months, the current bottleneck is *not* in the initial "getting started" stages. The current bottleneck is reviewing patches. That's true; but I didn't say this was a current bottleneck, I said it was a danger to sustainability, the topic we were discussing. The CG section on programming has been improving slowly but surely, as have the Frogs. I wish that we had more Frogs submitting doc patches to the CG explaining the stuff they've learned instead of leaving that task to the already over-burdened Carl, but I didn't think it was worth raising this point directly. I think it is worth pushing. Most of LM 3 was written as I learned how to use the IR. It doesn't matter if a doc patch is incorrect - it would almost certainly illicit a rapid response from a core developer and we would all learn. 2) There is no overall design plan to guide future development. New features are added in an ad hoc fashion at the whim of individual developers. The danger is that the overall structure will lose coherence, properties will increasingly behave in inconsistent ways, and the complexity of the user interface and the barriers to new developers will increase. At present we rely on Neil and other core developers to maintain the integrity of the design by reviewing patches, but that is not guided development. This part and parcel with the general way that volunteer open-source projects work, though. I know. It is probably the greatest defect of OSP. Projects with large commercial backing (like mozilla and openoffice.org) can give a roadmap with the knowledge that they have 20/50/100 developers to assign as they wish. True and of course we can't do this. But we could set out some desirable directions and goals. Consistently thought-out ones, rather than individual feature requests. If such a roadmap existed it might prompt contributors, frogs even, to work on those items. We have an opportunity within GLISS and GOP to tackle these dangers, although their terms of reference would need to be widened to embrace them. GLISS would need also to consider future needs and how they would be accommodated in the input syntax, and GOP would have to break down the barriers which new developers currently have to overcome themselves. This is possible, but I don't think it's realistic. In particular, it would need: 1. a large amount of developer time being placed under the control of a benevolent dictator (or council of dictators), and Yes. All the most successful OSP have this. 2. the "mundane" development tasks to be sustainable, and to have enough effort to cover those tasks without needing to distract any minions working on #1. I'd say that we're at least a year away from having sustainable mundane tasks... the Bug Squad will probably be sustainable in 2-4 months, but GDP utterly failed at creating a sustainable doc team, Don't run this down. The docs were immeasurably improved by GDP. This was beneficial dictatorship in action. It was and still is unrealistic to expect people to work several hours a day on LP for more than a year or so (with one or two dedicated exceptions). So the goal should be to accommodate a flow of people coming in, working a while, and then leaving. So we have to make it as easy as possible for newcomers to contribute easily and quickly, to both docs and development. The concept of permanent teams is fine, but not teams with permanent members - there will always be a flow. However, IMO we shouldn't be fussing too much about these long-term issues until 2.14 is out. We need a stable foundation. (it's a bit unfortunate that the talk was when it was) OK, agreed. I've made my comments while they were in my mind. I'll back off now. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote: > > 1) There is no architectural overview and no program logic manual to > guide new developers through the early stages. > This has the advantage that No; there's no advantage to this. It's simply due to an imbalance of high skill, available time/interest, and an overwhelming number of other concerns. I'm quite aware of the problems that this causes for new developers, but as long as we have over 10 patches waiting for review for the past few months, the current bottleneck is *not* in the initial "getting started" stages. The current bottleneck is reviewing patches. The CG section on programming has been improving slowly but surely, as have the Frogs. I wish that we had more Frogs submitting doc patches to the CG explaining the stuff they've learned instead of leaving that task to the already over-burdened Carl, but I didn't think it was worth raising this point directly. > 2) There is no overall design plan to guide future development. > New features are added in an ad hoc fashion at the whim of individual > developers. The danger is that the overall structure will lose > coherence, properties will increasingly behave in inconsistent ways, and > the complexity of the user interface and the barriers to new developers > will increase. > At present we rely on Neil and other core developers to > maintain the integrity of the design by reviewing patches, > but that is not guided development. This part and parcel with the general way that volunteer open-source projects work, though. Projects with large commercial backing (like mozilla and openoffice.org) can give a roadmap with the knowledge that they have 20/50/100 developers to assign as they wish. Even something as "simple" as documentation writing was a huge challenge to manage for the guided development in GDP. I can't imagine any such system working in lilypond [1]. [1] the single exception would be if we got a 50,000+ research grant to do some notation project. But that's not at all likely, and I can't see this working with individual donations. I'm comfortable with the "herding cats" style. Most of the time, we let people wander around at will; once in a while, we'll have a Grand Project that attempts to capture people's imagination and make them all move in (approximately) the same direction. > We have an opportunity within GLISS and GOP to tackle these > dangers, although their terms of reference would need to be > widened to embrace them. GLISS would need also to consider > future needs and how they would be accommodated in the > input syntax, and GOP would have to break down the barriers which new > developers currently have to overcome themselves. This is possible, but I don't think it's realistic. In particular, it would need: 1. a large amount of developer time being placed under the control of a benevolent dictator (or council of dictators), and 2. the "mundane" development tasks to be sustainable, and to have enough effort to cover those tasks without needing to distract any minions working on #1. I'd say that we're at least a year away from having sustainable mundane tasks... the Bug Squad will probably be sustainable in 2-4 months, but GDP utterly failed at creating a sustainable doc team, and I'm not certain if anybody in the world other than Jan and me can build releases. (I know that Patrick's been working on some stuff, but I don't know if he can build everything) However, IMO we shouldn't be fussing too much about these long-term issues until 2.14 is out. We need a stable foundation. (it's a bit unfortunate that the talk was when it was) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Graham Percival wrote Tuesday, August 03, 2010 3:31 AM As you might recall, I gave a talk at RMLL 2010 about sustainable development in F/OSS. Nice talk. It prompted me to think about my own involvement with LilyPond. I volunteered for doc development due to the guilt pressure at the start of GDP, IIRC. I continued because I enjoyed it, spending around a year working several hours most days on the LM. Eventually pressure of other things which I'd been neglecting caused me to back off, and recurring RSI prevents long sessions at the keyboard, so now I do little more than keep in touch :( On the main point I can see two dangers to sustainability. 1) There is no architectural overview and no program logic manual to guide new developers through the early stages. This has the advantage that only experienced and expert coders able to deduce the design from the source code are able to contribute significantly, ensuring high quality. But there are very few such people, and it is conceivable the number might decline to zero at some point. 2) There is no overall design plan to guide future development. New features are added in an ad hoc fashion at the whim of individual developers. The danger is that the overall structure will lose coherence, properties will increasingly behave in inconsistent ways, and the complexity of the user interface and the barriers to new developers will increase. At present we rely on Neil and other core developers to maintain the integrity of the design by reviewing patches, but that is not guided development. We have an opportunity within GLISS and GOP to tackle these dangers, although their terms of reference would need to be widened to embrace them. GLISS would need also to consider future needs and how they would be accommodated in the input syntax, and GOP would have to break down the barriers which new developers currently have to overcome themselves. Trevor Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Graham: ... > http://percival-music.ca/blog/2010-08-01-sustainable-development.html ... Thank you for the slides, I liked them. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
sustainable development in LilyPond
(sorry if this is a resend; I seem to be having problems with email) Hi guys, As you might recall, I gave a talk at RMLL 2010 about sustainable development in F/OSS. I took most of my examples from lilypond, so it may be of interest to you: http://percival-music.ca/blog/2010-08-01-sustainable-development.html Also, if you ever wonder about the thought process behind some of my policies (or at least interests), this is it -- I'm trying to make the lilypond project sustainable. I highly recommend skimming through the slides. Cheers, - Graham PS my flight is in 1 hour + 4 minutes, and I expect to be waking up in Glasgow in about 24 hours. Barring any compilation problems, 2.13.29 should be in about 30 hours from now. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
