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
but…
* 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!
--
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.