On Mon, 11 Jul 2016 12:39:33 +0200, Margarita Manterola wrote:
(cc'ing leader@, withstanding the temptation to cc -project in order
not to hijack the TC specific bug)
> 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.
I think this proposal has quite some merits.
IMO it boils down to what this roadmap and the goals are supposed to
be, and I have the impression that this is not very clear and/or that
there's no real consensus about this question.
My idea is that a roadmap is a document laying out the global
direction of the project, and act as somewhat binding guidelines for
all Debian contributors ("something we want to achieve together");
and not just a collection of random detailed technical changes.
> 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.
I agree on this reasoning. If the roadmap should be more than a list
of "private" projects that can just be ignored, than it needs "buy
in"/legitimacy by the project members; and even if GRs are quite
heavy-handed they're the only tool we have to take decisions as a
project and to produce this legitimacy.
> 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.
I think that the framing of potential goals as "bugs" with severities
might be narrowing down our collective imagination of what we might
want to achieve together.
> 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.
That was my impression too :)
> 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.
IMO the TC is the wrong body for a roadmap, as I see it as an arbiter
in cases of technical disputes, and the goals covered by the roadmap
neither need to be technical nor controversial per se.
In the end, I think that a roadmap for the project lies in the
responsibility of the DPL, i.e. that it's a genuine leadership task
(and indeed it was proposed by our DPL already in his platform); of
course it seems reasonable for Mehdi to seek support in the actual
implementation of the process, e.g. from a group of people called
"Roadmap Team".
I suppose that Mehdi will drive this further, I just wanted to write
down my thoughts before they fall prey to amnesia ...
Cheers,
gregor
--
.''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Sweet Transvestite
Attachment:
signature.asc
Description: Digital Signature