Bug#830344: How should the TC help with a project roadmap?
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.
--
Regards,
Marga
Reply to: