Bug#830344: How should the TC help with a project roadmap?
Hi marga,
On 11/07/2016 12:39, Margarita Manterola wrote:
> For documentation purposes, I list below my summary of the points that were
> raised during the Roadmap BOF. These items are separate and may not necessarily
> all (or even any) need to be true in the implementation adopted. During the BOF
> there were disagreements on almost all of them.
>
> a. Proposals could be made using the DEP process
> (http://dep.debian.net/deps/dep0/)
>
> b. Goals should have owners.
>
I don't remember any disagreement over a. and b. The main remark about DEPs was
that it could be the tool to implement the roadmap, but it lacks a few things:
1. it is not obvious to measure progress of each DEP
2. the whole process looks abandoned, and nobody is taking care of it. It really
needs to be managed. Some DEP drivers feel a bit lost because they don't know
when a DEP should become "ACCEPTED".
3. a roadmap should show a list of subjects people are actively working on. It
is not clear how to do that with dep.d.n
4. communication about new DEPs (and evolution of the list of DEPs in general)
If 1. and 3. are fixed, DEP could be a perfect _tool_ to implement a roadmap.
Still, we need people to look over ongoing DEPs/goals and fix 2. and 4.
> c. Goals should not be announced unless there's already work going on.
>
> d. There could be a list of goals (with owners and work under way) and a
> wishlist (things that we consider a good idea, but haven't been started).
>
IMHO, c. and d. are the same points. The consensus during the BoF was that
there could be very relevant and important ideas, but if there no drivers for
it then it should appear on a different list, which could be something else
than the roadmap.
> e. There should be clear tracking of what's going on with each goal.
>
My feeling is that there was no disagreement over this specific point. At least,
I don't recall any. Can you refresh my memory? (I may have missed it).
The proposal was to work on S.M.A.R.T goals [1], like we did for Release Goals
in the past.
[1] https://en.wikipedia.org/wiki/SMART_criteria
> Additionally, I suggested that a team (be it the TC or some other team) could
> gather the list of goals and once a year let the project vote on it through a
> GR, so that all goals that beat NOTA get approved. This proposal was rejected as
> being too heavy handed.
>
> My reason for proposing this was that I feel developers will be more engaged
> with the goals if they have voted for them than if they come from an external
> team. However, as long as we are not forcing people to work on specific things
> (i.e. if the bugs related to the goal are not RC), I'm fine with the goals
> coming from whoever the roadmap team is.
>
We share the same goal: We want developers to feel more engaged with the goals
and encourage others to work on them. The disagreement was only about the way
to reach it. As you say, the goal of a roadmap is *not* to turn down individual
initiatives. I fear that a vote will be counter-productive if some goals are
voted against.
Additionally, I am not sure how to interpret the results of a vote. What should
happen if the project votes aginst a roadmap with a dozen of goals? Should we
play this game over and over until some list gets through? Similarly, the
outcome will not be very clear if we vote for individual roadmap items (and
when some of them do not receive enough votes). We are not looking for ways to
block initiatives, but to foster innovation and collaborative work.
I guess the idea behind the vote is to give goals some momentum, increase
engagement, gather more supporters, etc.... And I agree that those points
are very important if we want to publish a project roadmap. I think that votes
are a poor way to achieve that. People will not be convinced about an idea just
because another set of people voted for it. Additionally, votes are not a way
to reach consensus, and that's really what we need for roadmap items (IMHO).
Votes tend to force a win/lose dichotomy and ignores the possibility of building
a compromise. I expect project members to discuss proposed goals and reach
consensus, and not simply block it with a vote because of a disagreement. A vote
may also isolate a minority, which is really not what we are trying to achieve
with the roadmap.
About RC-ness of bugs, it is the Release Team territory. I don't see a reason
to change that... especially, since roadmap goals are not necessarily bound to
a release. The RT is free to block a release waiting for some goal, but it is
their decision.
Saying all that and we forget an important historical data point : Release
Goals were proposed by project members and decided by a team. None of them
required a vote. It was required that a Release Goal should be generally
consensual, and it will be required for Project Goals (as noted in the gobby
"roadmap" document that was drafted during the BoF). Otherwise, it would be
difficult to call them "Project Goals" or a "Project Roadmap". We do not need
everyone to agree on each individual item, we are not looking for a formal
binding on each item of a roadmap... We want project members to agree on a
sensible list of ideas or plans to implement.
> During the BOF, a bunch of people volunteered to be part of the Roadmap team,
> even though it was unclear what the Roadmap team should do and how it should do
> that.
>
> Initally, Mehdi wanted the TC to be the Roadmap team, but given the intent of
> forming this other Roadmap team during the BOF, I don't know what is currently
> expected of the TC.
>
The goal of the BoF was to gather comments from project members on the idea of
the roadmap, its content, how to implement it, etc... And I think we already
have made great progress towards that goal during the BoF.
I initially thought that TC would be a perfect match for the roadmap team and
that we didn't need a new team for that. I can understand very well that the
idea is quite new and that the TC didn't act on this sort of things in the
past. So a thinking about it might be a necessary step before deciding that it
belongs to another body/team.
Here are the points that plead for the TC on this subject:
- §6.1.2 Decide any technical matter where Developers' jurisdictions overlap.
- §6.1.3 Make a decision when asked to do so.
- §6.1.5 Offer advice.
- §6.2.7 Membership is limited in time, by constitution
The last item ensures that the roadmap is not taken over by a subset of people
over time. The others are useful tools to work on a roadmap. Additionally, I
believe that criteria that make some person a good fit for the TC match with
the ones for the roadmap team.
The list of folks who volunteered for the roadmap team will help, if the TC
decides to _not_ step up for this task, to think about the process, organize
the proposals, communicate about the dates, etc...
As a courtesy to the TC, I didn't start working with the aforementioned group
and I am waiting for the conclusion of this bug. Of course, I will respect the
decision of the team and will not question it.
Kind Regards,
--
Mehdi
Reply to: