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