Hi gregor,
On 14/07/2016 04:12, gregor herrmann wrote:
> 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)
>
FWIW, I am subscribed to -ctte mailing list.
>> 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.
>
I believe I replied to this point in my reply to marga in this bug (and also
partly later in this mail). Please let me know if there are other points I
didn't clarify.
>> 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.
>
Historically, we mainly used the TC that way indeed. I believe this was due
to a lack of a vision in our project, and the TC could engage in such higher
value tasks and set a direction to the project.
Working (openly) on a list of project goals has also the merits of describing
a context and a direction which helps to avoid some conflicts. So, it is a
pro-active way of solving potential problems.
> 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".
>
Yes, I agree. My reasoning led me to think that the TC is the best body to
handle this in Debian. We obviously disagree on this specific point, but I
am only explaining my reasoning. So I asked the current TC Chair to engage
a discussion with TC members and see if they share this thought. If not, it
will be done elsewhere, a "Roadmap Team". Since we are discussing setting a
direction for the project, I agree that the DPL should be actively working
on it. But there is some administrative and communication work to not
underestimate and I believe a delegated team or a roadmap helpers team would
be of a great help to drive this forward. This is not required if the TC
handles the roadmap though as they already have the constitutional powers to
decide on technical matters.
It is also quite common (elsewhere) to see a Technical Committee deciding on
a program or a roadmap. For conferences, the Technical Committee usually
reviews proposed papers, selects accepts papers, set the conference program,
etc... In companies, a Technical Committee also usually decides on the general
direction that should be implemented.
In my understanding, having the powers the overrule individuals in a project
or decide on technical matters where jurisdictions overlap are only tools to
be able to set a direction, and not the other way around.
It is true that we focused our attention on disputes and how to solve them,
which is a very valuable goal, but IMHO we lost sight on the bigger picture:
what we want to achieve in our project. We are not looking for expertise in
mediation and social problem solving. We want the project to stay relevant,
innovate and spread free software. (Yes, we have many implicit goals and
this is not an exhaustive list of course). Pursuing that goal, we should not
rely on individual project members to shine and share their vision on what
Debian should look like. We should tool ourselves with the right bodies to
ensure that we have a shared direction, that things get done and that we do
so in a cooperative (and welcoming) way. Solving issues between developers is
_not_ the goal. Giving advice to developers is moot when you do not set a
direction. Why would people ask you for an advice otherwise?
Additionally, we are also living a nice period of our project where we have
very little number of issues to solve between developers. Why should not we
take this as an opportunity to raise our focus on other tasks? (w/o loosing
sight on the historic ones).
> I suppose that Mehdi will drive this further, I just wanted to write down my
> thoughts before they fall prey to amnesia ...
>
and thanks for sharing! :-)
--
Mehdi
