How about a roadmap?

[J.P.]

I'd like to get a rough schedule going, if at all possible: just
something broad and informal to sketch out the expected time frames for
those initiatives currently underway or being proposed. For now, let's
just assume this will happen here, on the mailing list[1] (though not
necessarily in this thread), and that revisions will be posted in full
as top-level replies.

Some basic questions toward that end:

- How vast or limited a period should this cover? Until the next minor
  Emacs release, perhaps? Or maybe just the end of the calendar year?

- How exacting should we be in budgeting time intervals, and what's a
  reasonable base unit? (A week?) Should we even bother penciling in
  date ranges, or would it be enough to just assign costs as loose
  durations (along with a priority)[2]?

- How do we prioritize initiatives? First come, first serve? Or should
  there be some kind of karma system in effect[3]? Or something less
  formal but still authoritative, like a visible summary of who's been
  filing (and reviewing/triaging) what?

Thanks,
J.P.


[1] Initially, I was thinking about a SaaS tool for scheduling. But even
    the standalone, minimalist ones I looked at tended to lean heavily
    on big forge/tracker integrations. And since we're debbugs- and
    email-based, I don't think we'd reap much benefit from such a thing.
    And all that agile jargon would likely just get in the way. I also
    considered using EmacsWiki or even just a few org-mode (or plain
    text) files hosted somewhere. But since we'd probably want the
    changes echoed to the list anyway, it kind of seemed redundant.

[2] Going with relative costs without some base time unit, while perhaps
    helpful, feels a little too much like punting. I'd rather be bold
    and wrong here, all things being equal.

[3] Meaning the sort where you accumulate "capital" fixing bugs and
    reviewing patches, and then "spend" it down the line on a pet
    feature. The point would be to welcome newer or more reserved voices
    by providing a concrete counterweight to the usual "law of the
    jungle" approach of favoring louder contributors and +1s. IMO, this
    sort of gamification works for large orgs but may risk harming
    morale by imposing a stilted paradigm in the case of smaller teams.