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

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Philip Hands writes ("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*.

Thanks, Philip, for this penetrating analysis.

I complete agree with your conclusions.


> 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.

I think this would be an awesome idea.  Let me try to run with it.

What would such a team need ?

 * To be accessible and approachable, and not judgemental.

 * To have the communication and technical skills to help someone with
   an idea produce clear and cogent explanations.

 * To have high status and high visibility, so that when they
   introduce someone driving a project to stakeholders, they get
   airtime.

 * Ideally to contain people with few enemies.

 * To be dynamic and novelty-oriented.

Looking at that wishlist in the round, it doesn't look like the TC.

Perhaps we could have the larger core teams send a representative each
to this new liason team.  But we do have difficulties with some of the
important stakeholders in the project having a shortage of people.


There is also a question about archive-wide changes.  We have a
recurrent conflict about a questions of the following form:

Should the maintainers of a package P be required to carry a patch to
provide for P a feature F, that P's maintainers don't care about, but
the feature F team do ?  (By a feature I mean not the abstract
requirement, but the concrete approach - maybe a specification,
technical policy or particular implementation.)

These discussions are sometimes in the context of a feature F which
the F team is trying to introduce; and sometimes in the context of one
which a subset of maintainers in Debian are trying to remove.

One of the biggest impediments to archive-wide features is that the
feature team may expect resistance from maintainers.  This is
particularly true for features which compete with (or seem to compete
with) ones that maintainers care about (or are politically aligned
with).

I have a very firm view that it is a primary responsibility of the
maintainers to enable other people's work.  The amount of effort to
carry a patch is normally low.

But the TC in particular has in the past had a low regard for features
of this kind which in the TC's view `duplicate' other functionality.
In these circumstances the medium- to long-term coexistence of
competing approaches is not possible, because maintainers can block
the one they don't like.

As a result the healthy competition between ideas, which you describe,
cannot always occur in Debian.


Ian.


-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.