[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#830344: How should the TC help with a project roadmap?


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:


  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

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

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

Reply to: