[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How about a roadmap?
How about a roadmap?
Fri, 18 Feb 2022 06:05:58 -0800
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
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 (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)?
- How do we prioritize initiatives? First come, first serve? Or should
there be some kind of karma system in effect? Or something less
formal but still authoritative, like a visible summary of who's been
filing (and reviewing/triaging) what?
 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.
 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.
 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.
|[Prev in Thread]
||[Next in Thread]|
- How about a roadmap?,