Hi Philip, On 03/08/2016 10:47, Philip Hands wrote: > 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? >
>From a TC member, I find your question funny :-) I'd reply to your question by: in the same way the TC used to do. Besides, it is not about which one to stop, but which one to promote as a project goal. > 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. > I think I have replied to this in my reply to marga. > 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 process > is that it emphasises the aspect of somehow seeking permission before > proceeding. > It is not about seeking permission since we are not looking for new ways to stop people doing things. We are trying to promote their work, find ways to enhance their ideas or put them in touch with other people that might help them, (through the roadmap) communicate about what project members are working on, and communicate on what we think is important to achieve for the upcoming year(s). Having your idea on the roadmap also helps to gather more supporters and organize sprints to develop it and work on it. While this last point doesn't specifically need the roadmap to hold true, it is much more convenient to encourage people to work on specific identified subjects... than to encourage sprints on general subjects. > 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. > I agree that we don't have a shortage of ideas in Debian. The problem is that we don't necessarily communicate on our ideas. This makes it even more difficult to find volunteers to work on it. So both points (number of ideas vs. manpower) are linked, IMHO. > 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. > The assumption of maybe failing to detect successful ideas might be true but I don't think it would prevent anyone to work on ideas that failed to be on the roadmap. Your example of the Reproducible Builds is only speculation and I fail to link it to reality, tbh. Again, the idea of the roadmap is not to _decide_ which ideas people should _not_ work on, but rather which ones should be promoted to gather more momentum. Regards, -- Mehdi