Hi, I managed to make time to watch the video of the roadmap BoF, so hopefully I'm now able to respond to more than the name "roadmap*. Some notes regarding the BoF: Consensus: It strikes me that where there is consensus, the process of getting it on the roadmap is not really needed, so then it's just a question of raising awareness across the project. I think the TC has very little to contribute in such cases. Conflicting goals: Unless it's clear that both goals will be done unless one of them is stopped, and they are going to be in conflict from the start, I think it's normally best to let them compete. As long as each effort is aware of the other, then they can decide amongst themselves which is going to fail in the end. It's completely possible that of the two efforts, one is clearly technically superior, but the other has more enthusiastic people involved -- how does one choose which to stop? GR for the roadmap: If we need a centrally agreed list, then this seems like the best way to do it, since it makes sure that a) all developers will be made aware of the goals, and b) the ones that succeed have enough support that even those that might be tempted to resist a goal should be persuaded that many people want it to happen. Late conflict: This is a very important point. If we can come up with a way of avoiding this happening it would clearly be a benefit. The "Let me help you do what you want team": That encapsulates what I think might be worthwhile out of this idea. It emphasises letting people do things if they happen to feel the urge. So, the problem I see with getting the TC involved with this is process is that it emphasises the aspect of somehow seeking permission before proceeding. We don't really have a shortage of ideas in Debian, but we do have a shortage of effort to implement them. If we can make it easier for people to go ahead and explore their idea for improving Debian, that's great. If we can also help them avoid pitfalls, and help them promote their effort to get more people to help them, even better. Of course, that doesn't really advance the idea of a centralised and coherent roadmap. I'm not too upset about that, since I think that lurking in the foundations of the idea of a coherent roadmap is the assumption that we can somehow predict which ideas are likely to succeed, and that we can somehow tell people to work on them. I don't think either assumption is true, and that some good ideas will be lost if we set up any sort of filter. For example, If a Roadmap Team (that acted as gatekeepers to a centralised roadmap) had been around in 2000, when the idea of reproducible builds was mentioned on the lists, I'd guess that idea would not have made it onto the roadmap (judging from the list response). If by the time 2013 came round, we had had a decade of failed attempts to get Reproducible Builds onto the Roadmap, perhaps Lunar would have assumed that the idea was a non-starter. Perhaps the Roadmap Team would remember past rejections, and respond on the basis of precedent. Perhaps if a roadmep had been in existence for a decade or more, people would now consider getting on the roadmap as a necessary first step for any ambitious idea. This all strikes me as counter-productive. So, let's not build a discriminating filter, but rather a full-band amplifier. We can expect unworkable ideas to fall by the wayside, but even then they might prompt someone to come up with a workable replacement idea, so are not automatically a waste of time. In fact, if someone wants to do something obviously stupid, perhaps the only way for them to be persuaded to give up is to let them try. Having the TC (or anyone else) decide that the idea has no merit might well lead to endless bickering about how there's a conspiracy to suppress their genius. The TC seems like it is far too likely to act as a brake on development if people are encouraged to seek its approval. I don't think we should be involved (except of course as individuals on the other team, as we wish). Cheers, Phil. P.S. Sure, if two ideas are going to cause a conflict, then they can be referred to the TC in the normal manner, and then we'd get involved, but I would expect that to be a very rare event. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature