Bug#830344: How should the TC help with a project roadmap?

[Keith Packard]

Package: tech-ctte
User: tech-***@packages.debian.org

Mehdi has proposed that the TC be involved in some fashion with a
"project roadmap". Some of the TC members met in person at debconf 16 to
talk about how that might work. I will attempt to (badly) summarize some
of the ideas brought out in that meeting with the goal of encouraging a
more complete discussion here.

I think we had general agreement on a couple of notions:

1) Work in Debian is done by developers at their own discretion.
2) We do not want to stop people working on anything

I think that Sam suggested that the TC could help encourage work on
goals which were well specified and already in progress

Keith suggested that the TC could help identify useful goals which were
less well specified and less active.

The end goal of this bug should be a response to the DPL's request.

[Margarita Manterola]

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.

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).

e. There should be clear tracking of what's going on with each goal.

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.

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.

[Keith Packard]

Post by Margarita Manterola
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.
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).
e. There should be clear tracking of what's going on with each goal.
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 like this idea -- it lets every developer have a voice in broad
project goals, which seems better than some small committee. I wonder if
this would let us add a 'not for next release' item in the list, such
that goals above that could be RC?

Post by Margarita Manterola
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.

Curating the list of goals still needs a committed team to write up a
good description of each goal, and keep things updated as the world
changes. Each goal also needs a discussion on the technical feasibility
of the proposal, a list of dependencies and potential conflicts so that
people can judge the costs and benefits.

Post by Margarita Manterola
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.

I think that the work involved in this should be seen as largely
clerical -- collecting goal ideas and writing up coherent
documentation. Some of that requires technical expertise, but I'm not
sure I would like to see such a group actually responsible for choosing
which goals people should be encouraged to work towards.

[Sam Hartman]

Here are my thoughts on the road map and TC involvement.

There is value in two levels of thing:

* Goals that we've committed totrying as a community. For these, RC bugs or
NMUing a package are valuable.

At this level it's desirable to have review of the plan to achieve a
goal. It's frustring to make a bunch of stuff RC buggy only to later
realize that even if you had fixed those bugs you never would have
gotten to the goal.

I think that review needs to be positive--some people need to say yes,
not simply no one raises objections. Also, it needs to be reviewed to
make sure all the stakeholders are involved.

* Second level: wishlist. Things people think would be valuable. Easy
to add to. May not represent project-level commitment to try for the
goal. You may not want people NMUing at this level. As an example,
removing build information from a binary package does sometimes make
debugging harder. If we're not actually going to achieve reproducible
builds, it's not clear that making those changes is valuable. (In the
specific case of reproducible builds, we've met the bar already, but
the point stands as a generalization)

----------------------------------------

TC skills that may help here:

1) Across the entire TC we have a moderately good coverage of things in
the project. There are probably gaps. Across the TC we have fairly
good coverage of who to go to for more depth about a given issue.

2) We're builting a TC that's good at working with people and helping
facilitate communication.

3) We can do technical review for completeness of a proposal.

----------------------------------------

One area where I'd like to the see the TC help is to try and avoid late
stakeholders appearing. That is, you put together a plan, start working
on it, and then discover late in the process that you missed some key
player, and they disagree with your goal. So you invest a bunch of time
and run up against a stone wall.

I think if we worked on it we could be fairly good at making sure people
have talked to a lot of the stakeholders they need.
I really hope the process supports that sort of review because I believe
it could significantly help with burnout avoidance.

[gregor herrmann]

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)

Post by Margarita Manterola
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.

Post by Margarita Manterola
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.

Post by Margarita Manterola
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.

Post by Margarita Manterola
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 :)

Post by Margarita Manterola
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

[Philip Hands]

Hi,

I managed to make time to watch the video of the roadmap BoF, so
hopefully I'm now able to respond to more than the name "roadmap*.

Some notes regarding the BoF:

Consensus:

It strikes me that where there is consensus, the process of getting it
on the roadmap is not really needed, so then it's just a question of
raising awareness across the project. I think the TC has very little
to contribute in such cases.

Conflicting goals:

Unless it's clear that both goals will be done unless one of them is
stopped, and they are going to be in conflict from the start, I think
it's normally best to let them compete. As long as each effort is
aware of the other, then they can decide amongst themselves which is
going to fail in the end. It's completely possible that of the two
efforts, one is clearly technically superior, but the other has more
enthusiastic people involved -- how does one choose which to stop?

GR for the roadmap:

If we need a centrally agreed list, then this seems like the best way
to do it, since it makes sure that a) all developers will be made
aware of the goals, and b) the ones that succeed have enough support
that even those that might be tempted to resist a goal should be
persuaded that many people want it to happen.

Late conflict:

This is a very important point. If we can come up with a way of
avoiding this happening it would clearly be a benefit.

The "Let me help you do what you want team":

That encapsulates what I think might be worthwhile out of this idea.
It emphasises letting people do things if they happen to feel the urge.

So, the problem I see with getting the TC involved with this is process
is that it emphasises the aspect of somehow seeking permission before
proceeding.

We don't really have a shortage of ideas in Debian, but we do have a
shortage of effort to implement them. If we can make it easier for
people to go ahead and explore their idea for improving Debian, that's
great. If we can also help them avoid pitfalls, and help them promote
their effort to get more people to help them, even better.

Of course, that doesn't really advance the idea of a centralised and
coherent roadmap. I'm not too upset about that, since I think that
lurking in the foundations of the idea of a coherent roadmap is the
assumption that we can somehow predict which ideas are likely to
succeed, and that we can somehow tell people to work on them. I don't
think either assumption is true, and that some good ideas will be lost
if we set up any sort of filter.

For example, If a Roadmap Team (that acted as gatekeepers to a
centralised roadmap) had been around in 2000, when the idea of
reproducible builds was mentioned on the lists, I'd guess that idea
would not have made it onto the roadmap (judging from the list
response).

If by the time 2013 came round, we had had a decade of failed attempts
to get Reproducible Builds onto the Roadmap, perhaps Lunar would have
assumed that the idea was a non-starter. Perhaps the Roadmap Team would
remember past rejections, and respond on the basis of precedent.
Perhaps if a roadmep had been in existence for a decade or more, people
would now consider getting on the roadmap as a necessary first step for
any ambitious idea. This all strikes me as counter-productive.

So, let's not build a discriminating filter, but rather a full-band
amplifier. We can expect unworkable ideas to fall by the wayside, but
even then they might prompt someone to come up with a workable
replacement idea, so are not automatically a waste of time.

In fact, if someone wants to do something obviously stupid, perhaps the
only way for them to be persuaded to give up is to let them try. Having
the TC (or anyone else) decide that the idea has no merit might well
lead to endless bickering about how there's a conspiracy to suppress
their genius.

The TC seems like it is far too likely to act as a brake on development
if people are encouraged to seek its approval. I don't think we should be
involved (except of course as individuals on the other team, as we wish).

Cheers, Phil.

P.S. Sure, if two ideas are going to cause a conflict, then they can be
referred to the TC in the normal manner, and then we'd get involved, but
I would expect that to be a very rare event.

[Ian Jackson]

Post by Philip Hands
I managed to make time to watch the video of the roadmap BoF, so
hopefully I'm now able to respond to more than the name "roadmap*.

Thanks, Philip, for this penetrating analysis.

I complete agree with your conclusions.

Post by Philip Hands
That encapsulates what I think might be worthwhile out of this idea.
It emphasises letting people do things if they happen to feel the urge.

I think this would be an awesome idea. Let me try to run with it.

What would such a team need ?

* To be accessible and approachable, and not judgemental.

* To have the communication and technical skills to help someone with
an idea produce clear and cogent explanations.

* To have high status and high visibility, so that when they
introduce someone driving a project to stakeholders, they get
airtime.

* Ideally to contain people with few enemies.

* To be dynamic and novelty-oriented.

Looking at that wishlist in the round, it doesn't look like the TC.

Perhaps we could have the larger core teams send a representative each
to this new liason team. But we do have difficulties with some of the
important stakeholders in the project having a shortage of people.


There is also a question about archive-wide changes. We have a
recurrent conflict about a questions of the following form:

Should the maintainers of a package P be required to carry a patch to
provide for P a feature F, that P's maintainers don't care about, but
the feature F team do ? (By a feature I mean not the abstract
requirement, but the concrete approach - maybe a specification,
technical policy or particular implementation.)

These discussions are sometimes in the context of a feature F which
the F team is trying to introduce; and sometimes in the context of one
which a subset of maintainers in Debian are trying to remove.

One of the biggest impediments to archive-wide features is that the
feature team may expect resistance from maintainers. This is
particularly true for features which compete with (or seem to compete
with) ones that maintainers care about (or are politically aligned
with).

I have a very firm view that it is a primary responsibility of the
maintainers to enable other people's work. The amount of effort to
carry a patch is normally low.

But the TC in particular has in the past had a low regard for features
of this kind which in the TC's view `duplicate' other functionality.
In these circumstances the medium- to long-term coexistence of
competing approaches is not possible, because maintainers can block
the one they don't like.

As a result the healthy competition between ideas, which you describe,
cannot always occur in Debian.


Ian.

[Sam Hartman]

I'm not really advocating that the TC would be a very good help promote
your ideas team.
However, I'm struck by the following even if I don't entirely know what
to make of it.
Ian> * To be accessible and approachable, and not judgemental.

Ian> * To have the communication and technical skills to help
Ian> someone with an idea produce clear and cogent explanations.

Ian> * To have high status and high visibility, so that when they
Ian> introduce someone driving a project to stakeholders, they get
Ian> airtime.

Ian> * Ideally to contain people with few enemies.

Ian> * To be dynamic and novelty-oriented.

I'll note that with the exception of the last bullet point, that's
fairly close to what I'd hope to see out of a TC.
The last bullet point may well be important in this context.

Yes, sometimes the TC will need to make judgments, but I think that to
do its job and actually collect information, it needs to be perceived as
non-judgmental in the sense you mean above.

[Ian Jackson]

Post by Sam Hartman
However, I'm struck by the following even if I don't entirely know what
to make of it.
Ian> * To be accessible and approachable, and not judgemental.
Ian> * To have the communication and technical skills to help
Ian> someone with an idea produce clear and cogent explanations.
Ian> * To have high status and high visibility, so that when they
Ian> introduce someone driving a project to stakeholders, they get
Ian> airtime.
Ian> * Ideally to contain people with few enemies.
Ian> * To be dynamic and novelty-oriented.
I'll note that with the exception of the last bullet point, that's
fairly close to what I'd hope to see out of a TC.
The last bullet point may well be important in this context.

Well, not _all_ of the bullet points above are things that the TC is
(or could be) bad at.

But, in increasing order of likely controversy:

* By my comments about "judgemental" I meant that a "helping people
get their ideas done" team ought to try to avoid making technical
judgements, especially adverse ones, about those ideas.

However, making technical judgements is the key function of the TC,
and making them early, tentatively and informally is very valuable
in the TC context. In the context of a "new ideas enabling" team,
early technical judgement (even if tentative and informal) risks
sapping energy.

* It is inevitable that people are often unhappy with TC decisions.
It is natural that TC members will tend to accumulate, if not
actual "enemies", people who have serious qualms about their
judgement.

We can hope that usually people who are pleased by TC decisions are
more numerous, but in the context of an "idea enablement" team, it
is much more important that stakeholders don't have an initially
negative view of the team members.

* I think that the TC should have a bias towards being conservative,
when resolving disputes (which is its primary function).

Thanks,
Ian.

[Mehdi Dogguy]

Post by Ian Jackson
Well, not _all_ of the bullet points above are things that the TC is
(or could be) bad at.
* By my comments about "judgemental" I meant that a "helping people
get their ideas done" team ought to try to avoid making technical
judgements, especially adverse ones, about those ideas.
However, making technical judgements is the key function of the TC,
and making them early, tentatively and informally is very valuable
in the TC context. In the context of a "new ideas enabling" team,
early technical judgement (even if tentative and informal) risks
sapping energy.

Note that working on a roadmap does not necessarily call for making
judgments on ideas. Also, we should not be afraid of asking questions
about the proposed ideas/goals and not consider questions to be judgments.

Besides, as Debian Developers, we like to think about technical details
of implementation. So this risk is in fact general and not specifically
linked to the TC.

Post by Ian Jackson
* It is inevitable that people are often unhappy with TC decisions.
It is natural that TC members will tend to accumulate, if not
actual "enemies", people who have serious qualms about their
judgement.

I am a little bothered with this specific point above. I do not expect TC
members to accumulate enemies over time. If people do not respect TC
decisions then we will have hard time explaining to them that they should
implement the decision. On the contrary, I really believe the TC is very
well respected in our project. People recognize the usefulness of their
work and respect their decisions once made public.

If some TC members accumulate "enemies" with time, then maybe some members
do not agree with a fundamental part of our constitution where the TC can
be called to overrule a developer. I believe people in that case are a real
minority (if they exist) and that we should not focus our attention on them.

Post by Ian Jackson
We can hope that usually people who are pleased by TC decisions are
more numerous, but in the context of an "idea enablement" team, it
is much more important that stakeholders don't have an initially
negative view of the team members.

I truly believe project members to not have an initial negative view of
the TC.

Regards,

[Mehdi Dogguy]

Hi Philip,

Post by Philip Hands
Unless it's clear that both goals will be done unless one of them is
stopped, and they are going to be in conflict from the start, I think
it's normally best to let them compete. As long as each effort is
aware of the other, then they can decide amongst themselves which is
going to fail in the end. It's completely possible that of the two
efforts, one is clearly technically superior, but the other has more
enthusiastic people involved -- how does one choose which to stop?

From a TC member, I find your question funny :-) I'd reply to your question
by: in the same way the TC used to do. Besides, it is not about which one
to stop, but which one to promote as a project goal.

Post by Philip Hands
If we need a centrally agreed list, then this seems like the best way
to do it, since it makes sure that a) all developers will be made
aware of the goals, and b) the ones that succeed have enough support
that even those that might be tempted to resist a goal should be
persuaded that many people want it to happen.

I think I have replied to this in my reply to marga.

Post by Philip Hands
This is a very important point. If we can come up with a way of
avoiding this happening it would clearly be a benefit.
That encapsulates what I think might be worthwhile out of this idea.
It emphasises letting people do things if they happen to feel the urge.
So, the problem I see with getting the TC involved with this process
is that it emphasises the aspect of somehow seeking permission before
proceeding.

It is not about seeking permission since we are not looking for new ways
to stop people doing things. We are trying to promote their work, find
ways to enhance their ideas or put them in touch with other people that
might help them, (through the roadmap) communicate about what project
members are working on, and communicate on what we think is important to
achieve for the upcoming year(s). Having your idea on the roadmap also
helps to gather more supporters and organize sprints to develop it and
work on it. While this last point doesn't specifically need the roadmap
to hold true, it is much more convenient to encourage people to work on
specific identified subjects... than to encourage sprints on general
subjects.

Post by Philip Hands
We don't really have a shortage of ideas in Debian, but we do have a
shortage of effort to implement them. If we can make it easier for
people to go ahead and explore their idea for improving Debian, that's
great. If we can also help them avoid pitfalls, and help them promote
their effort to get more people to help them, even better.

I agree that we don't have a shortage of ideas in Debian. The problem
is that we don't necessarily communicate on our ideas. This makes it
even more difficult to find volunteers to work on it. So both points
(number of ideas vs. manpower) are linked, IMHO.

Post by Philip Hands
Of course, that doesn't really advance the idea of a centralised and
coherent roadmap. I'm not too upset about that, since I think that
lurking in the foundations of the idea of a coherent roadmap is the
assumption that we can somehow predict which ideas are likely to
succeed, and that we can somehow tell people to work on them. I don't
think either assumption is true, and that some good ideas will be lost
if we set up any sort of filter.

The assumption of maybe failing to detect successful ideas might be true
but I don't think it would prevent anyone to work on ideas that failed to
be on the roadmap. Your example of the Reproducible Builds is only
speculation and I fail to link it to reality, tbh. Again, the idea of the
roadmap is not to _decide_ which ideas people should _not_ work on, but
rather which ones should be promoted to gather more momentum.

Regards,

[Mehdi Dogguy]

(I noticed that you replied to the list, and not to the bugreport. I
took the liberty to send my reply to the bug as well to have a complete
log of the discussion. Feel free to drop the list in the subsequent replies).

One thing I don't think we're in complete agreement about is which
problem we're trying to solve with the roadmap. Is it to gather
enthusiasm? Is it to steer Debian better? Is it to communicate to
commercial partners like HPE? Something else? I think we need to agree
on that before we try to agree on the mechanism to achieve it.

This is a very good question indeed. The main goal of the roadmap is
none of those. What you listed are desirable (and expected) side
effects. The main goal is to document time-limited technical sub-projects
that might need more promotion and/or more manpower.

As I described it during my talk, a roadmap:
- reveals gaps between what we do and what we should be doing
- provides a strategic view, a vision to the project
- is a communication tool
- can be a recruitment platform.

Having a roadmap published, I expect us to:
- find new contributors by showing that our work doesn't focus solely on
packaging. For example, porting [1] efforts are funny problems for programmers
and I am not sure those easily find how to start in our project.
- give some insights about what we are doing and what we are planning to do
- be able to approach partners and potential sponsors with a concrete work plan
- an easy way to communicate about what we do (and about our progress)

I believe those are valuable goals and a roadmap will help us to achieve them.

[1] By porting, I mean both adapting code to work on new architectures and
migrating some code to new versions of some libraries.

Regards,

[Mehdi Dogguy]

Hi gregor,

Post by gregor herrmann
hijack the TC specific bug)

FWIW, I am subscribed to -ctte mailing list.

Post by gregor herrmann

Post by Margarita Manterola
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.

Post by Margarita Manterola
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.

Post by gregor herrmann

Post by Margarita Manterola
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 :)

Post by Margarita Manterola
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.

Post by gregor herrmann
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).

Post by gregor herrmann
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 Dogguy]

Hi marga,

Post by Margarita Manterola
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.

Post by Margarita Manterola
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.

Post by Margarita Manterola
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

Post by Margarita Manterola
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.

Post by Margarita Manterola
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,