[Debian-roadmap] Roadmap -- kick-off

[Mehdi Dogguy]

On 30/01/2017 04:51, martin f krafft wrote:
> also sprach Mehdi Dogguy <mehdi at dogguy.org> [2017-01-30 15:28 +1300]:
>> - a project goal should be:
>>
>>   * SMART (Specific, measurable, assignable, realistic, timely)
>>   * Have an 'advocate', who can track and keep status of progress.
>>   * Be generally consensual
> 
> What's the process if said advocate becomes unresponsive/inactive?
> Would it maybe make sense to pre-define periods after which the
> roadmap team can be at liberty to transfer ownership, e.g. after
> 3 pings that must be at least 2 weeks apart, or so?
> 

I think this is a good idea. If we decide that it is important enough
to put it on the roadmap, we should ensure that each idea doesn't get
abandoned because last driver went MIA.

>> - The DEP process /could/ be the process to manage the roadmap,
>> but it is up to this team to decide. It could be left to specific
>> goals which match with the spirit of DEPs and not enforce it for
>> each goal.
> 
> Sounds like project-management to me. Kanban or a more specific
> tool?
> 

Could be.

> Do we know why DEPs seem abandoned? Could it be the antiquated wiki
> workflow?
> 

DEPs are not abandoned but rather in a poor state. This state can be
explained by several factors:
1) Nobody is working with the drivers to ensure that they remain active
   or to mark the DEP as abandoned if every involved person goes MIA.
2) Proposals go the "Candidate" state when there is a consensus, but it
   is not always easy to see if we reached one.
3) No regular communication on DEPs and its progress. Some people forget
   about it.
4) No incentives to push some idea as a DEP. It is not clear for everyone
   what is the benefit of a DEP.

IMHO, DEPs and Release Goals serve similar goals. The latter has a deadline
bound to a release. Issues listed above could happen with the roadmap as
well if there is no active team behind it. A way to implement the roadmap
could be to use DEPs and make the roadmap team responsible on the decisions
on DEPs.

>> - The roadmap is not a tool to tell people what to work on, but rather
>>   a tool to help attracting more visibility on their work. If a goal
>>   has been declined to be part of the roadmap, it doesn't mean that it
>>   should be stopped, but it has not been judged sufficiently significant
>>   to be shown in the roadmap.
> 
> We're of course still dealing with volunteers, but I feel this is
> a bit weak. If the roadmap is simply a PR stunt, i.e. a collection
> of wanna-haves and would-be-nices, then we're over-engineering.
> 

Agreed.

> At the least, roadmap projects should be regarded favourably wrt bug
> reports, similar like release goals make for RC bugs. I'm not saying
> RC, but if e.g. my roadmap item were complete MIME coverage — just
> a silly, yet overarching example — then wishlist bugs like #723696
> should become automatically NMUable, or disagreement resolved in
> favour of the roadmap. Look at the reproducible builds effort… we
> could be a lot further already if people like Chris could just
> upload the tiny patches to the archive, rather than having to pester
> people like myself for months (#777364).
> 

NMU policy is way more open that it used to be. And, globally, people
are accepting NMUs much better than ten years ago. But, still, as you
noted, there is some margin of progress to make it completely smooth.

Severity of bugs are of the domain of the Release Team. But it is not
easy to propose all roadmap items as release blockers. My approach
would be to try to come up with a first version of a roadmap, and then
convince the Release Team that some items deserve being pushed more
than others in next release. Besides, Stretch's freeze policy [1]
already allows to upload fixes for "important" bugs. So I am fairly
optimistic we could make bugs for some roadmap items of severity
important.

[1] https://release.debian.org/stretch/freeze_policy.html

> Furthermore, I'd be interested in discussing an idea along the lines
> of roadmap projects becoming primary candidates to receive funding
> for e.g. yearly sprints. This could IMHO provide a driving force to
> projects and their advocates/managers, while also possibly making it
> easier for us to spend all our money… ;)
> 

In fact, I think I mentioned this idea during the BoF but failed to put
it in the summary. Thanks for bringing it up! and yes, I'd approve this
of course.

> Maybe there are some other ideas around about how to make roadmap
> projects stand out more?
> 

- a talk at DebConf (and sponsoring the speakers)?

We will find more ideas, but I need to sleep right now :-)

-- 
Mehdi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-roadmap/attachments/20170130/f10981a5/attachment.sig>