Bug#830344: How should the TC help with a project roadmap?
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
Reply to: