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

Bug#830344: Moving forward with the Project Roadmap question

Dear TC,

I have now found enough brain-time to re-read this bug-log. It's a very 
enlightening and interesting read, I must say.

Now onto moving forward; thanks go to Marga for, as Sam put it, "getting the 
level of specificity that we need now". I agree that we have enough data to 
decide at which level the TC should be involved, even without having refined 
the Roadmap's definition.

My current opinion is as follows: I firmly believe that whichever process put 
in place to get items on the roadmap should be encouraging, straight-forward 
and not too administrative, by default. Bigger administrative setups (such as 
GRs, TC votes overriding people, "escalation" in general) should really be 
reserved for opposing decisions. The "Debian way" of doing this would be to 
have a team decide on the roadmap item definition, minimal conditions (such as 
SMART, ownership, etc), etc.

(None of this implies the TC should not be that body, though).

Now, I realize that having project-wide agreement (aka GR decisions) on 
roadmap items has a potential for a lot of positive energy for agreed-upon 
items; I'm quite skeptical of the associated risks on the motivation of 
stakeholders for items downvoted.

Le jeudi, 11 août 2016, 20.17:22 h CEST Margarita Manterola a écrit :
> One slightly contentious part is how the goals that are actually published
> in the Roadmap get decided. I proposed through a yearly GR (each goal
> individually, not the whole Roadmap as one thing). Mehdi wants the team in
> charge of the Roadmap to decide.

Personally, I currently side with Mehdi on that question. GRs are still 
(probably wrongly so) seen as a heavyweight process. The burden it puts on the 
secretary can also become a showstopper.

That said, I sympathize with using our project-wide decision mechanism (GRs) 
more, I'm mostly unsure we're ready for wider usage yet.

> The other slightly contentious thing is whether the TC should be the Roadmap
> team, have an advisory role towards the Roadmap team or not be involved as
> a body at all (individual members are of course free to do as they want).
> From our last IRC meeting, and the few opinions from TC members on this bug,
> my feeling is that most TC members don't want to have the TC be the Roadmap
> team.

I have found quite hard to separate the two following concerns:
* the TC could constitutionally and socially be the correct body for that work
* adding "required" work on the TC's mandate is rising the barrier of entry 
and possibly hardening the recruitment process too.

The main problem I feel with making the TC the Roadmap Team is this "the TC 
becomes a bottleneck" problem.

> It's now been more than a month since this thread started and we don't seem
> to have much traction. I propose that we take a vote with the following
> options:
> 1) The TC will be the Roadmap Team
> 2) The TC will act as an advisor to the Roadmap Team
> 3) The TC will not be involved as body with the Roadmap Team
> 4) Further Discussion

I'd likely vote 2 > 1 > 4 > 3 with this ballot, FWIW, for the above reasons.

What seems to me the most straightforward is for all TC _members_ to 
constitute the initial Roadmap Team, they'd start ironing the details as the 
Roadmap Team, and we'd evolve from there. Somewhere down the line, we're 
likely to have a much better understanding of what decision need to be made, 
and by whom.

> Given that I'm new in the team, I'm explicitly not calling for the vote, but
> proposing this vote, as I would first like to hear if this makes sense to
> the other members.

It does, thank you!


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: