[Debian-roadmap] Roadmap -- kick-off

[martin f krafft]

Dear Mehdi,

Thanks for the e-mail and the reference to the TC thread, which
I skimmed.

Here are some thoughts to your e-mail, as per your request:

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?

> - 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?

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

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

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

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… ;)

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

> - Publicity period and communication workflow: When should we
>   communicate about the roadmap? How should we make a call for ideas?
>   etc...

I think as soon as we have a reasonably shared understanding of what
comprises a "roadmap project". The actual process can be left
"agile" for a start, I think.

-- 
 .''`.   martin f. krafft <madduck at debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
      DebConf18 in your city? https://wiki.debconf.org/wiki/DebConf18
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.alioth.debian.org/pipermail/debian-roadmap/attachments/20170130/781863b8/attachment.sig>