[neomutt-devel] Issue labels / Waffle Board

[guyzmo]

And now, let's discuss the following:

> > I have a few questions / suggestions...
> > * What's the difference between:
> > 	type:enhancement
> > 	type:feature request
> The type:enhancement is just an historical relict IMHO - before we had
> rewritten the labels, nearly *every* issue or pull request had the
> label type:enhancement - therefore I wanted to split that up in
> several things (e.g. the topic: labels).

in terms of ontology, you have three main types of issues:

- bug: when someone report an unexpected behaviour (usually expected
  behaviour is defined by the documentation… a crash being a special
  case of unexpected behaviour ☺) ;
- enhancement: a way to extend the behaviour of the software
- question: a general question that's not covered in the documentation
  but that's unlikely to end up with more code

a "feature request" is just a special kind of enhancement, that is an
enhancement being asked/begged for by an user, contrasted by you (or us)
deciding that enhancement X is a must have and will be there in release Y.

As the project moves on, it's likely that all enhancements will be
feature requests, so the name does not really matter.

> In my view, the label type:feature request should be used in the
> future and type:enhancement should be deleted. (But also, not every
> type:enhancement should be type:feature request)

My personal take on this is that "enhancement" is a default label provided
by github, so it'll make sense to anybody used to github but new to the
project. It's also shorter by 4 letters ☺ (or for the label golf, simply
type:feature, even shorter).

> > I'd like to rename:
> > 	backlog -> planned
> > I keep having to look up the meaning of "backlog", so I'd like to change
> > it to "planned" (meaning: wanted for the next release, but not yet being
> > worked on).
> +1 I also forget the meaning of "backlog" a lot. 

Well, you should get used to it sooner than later, as the traditional
columns on a kanban are:

| (pool) | backlog | in progress | ready | (closed) |

Pool and closed are not really a thing, just a reminder of what's
outside of the current sprint.

The backlog is the restricted set of issues we're selecting to work on
over the next sprint, which is the time length between two releases. In
SCRUM, a sprint is of a fixed time duration. 

The process is that the scrum master selects issues from the pool to 
define the scope of the next release, and pushes it in the backlog. Then
developers take issues from the backlog, and while working on it, move
it into progress. When over it's moved to ready.

On the last day of the sprint, all the issues that are ready shall be
merged and a new release be made. Those that are not, get back to the
pool (then the scrum master measure how much overestimation he's made
for that sprint to better adjust the next one).

That's for the traditional meaning of it.

For our case, and because we should never force people in doing what
they don't like — we're doing this for the fun, not for having an extra
unpaid after hours job! — we've got to give it our own meaning, to
better reflect our "best effort" approach.

So what I'm suggesting is the following:

→ the column "discussion" is only there to get rid of those issues that
are cluttering the view (they're not likely to become development in the
foreseeable future). Basically, it's not a bad idea to keep that column
shrunk, to leave more room for the others.

→ the column "bugs" is just a way to split the "pool" in order to avoid
having over 30 issues in a single column, with the added value that bugs
are higher priority than mere enhancements.

→ the column "backlog", is the minimal set of issues you want to see
implemented before deciding to merge all and push a new release.

→ progress: self explicit

→ ready: stuff is ready to merge for the next release

→ closed: packed and shipped, it's all in the master (or devel) branch.

> > 	ready -> review
> > [...]
> > The "ready" category will become "review".  When someone finishes some
> > code it will get moved here until it has two approvals.

I would rather suggest to actually add a new column: review. The process
becoming:

→ status:progress → status:review → [approved] → status:ready → [merged] → status:closed
             ↑            ↓
             ↑ ← ← ← [rejected]

> Maybe "needs:review" instead of just "review" ? I like the
> explicitness. But generally i like this idea.

For homogeneity, I suggest it should be status:review.

Because if you want the semantics of X in the "X:Y" labels scheme to
really have a powerful meaning, you shall have as few of them as
possible.

→ status:   is to define the lifetime of a *CODING* issue
→ type:     is to define the category of an issue (bug, enhancement, question)
  • bug or enhancement will lead to code, and will receive a status: label and lifecycle
  • question will have the "more info from user" or "need action from us" lifecycle
→ priority: self explicit: either put high:p on top of the column, and
  low:priority at the bottom of the column
→ topic:    is just a qualification so we can easily filter issues by topic,
  I don't see it being really useful, but it's harmless.
→ docs:     is about the same as topic, imho, but slightly more useful, so
  non-coders know they can take those, and contribute. It could be
  merged with topic, though.
→ distro:   same as above, could be yet another topic
→ closed:   are not really useful, but can help documenting past
  decisions, and also make statistics on closing our issues.

Of course there's always an exception:

→ status:discussion, the rationale is covering everything that won't
  take immediate action. So it's covering all type:question, or
  type:enhancement that are moonshots, and need a lot of discussion to
  get done. The only thing is that type:enhancement+status:discussion
  is likely to get out of the discussion column. Eventually. Whenever.

> > * Blue Sky category (in waffle)
> > There are quite a lot of issues in the "pool" category.  Many of the
> > requests are unlikely to be fulfilled.  I think I'd like a blue-sky
> > status category (as well as, or instead of) the blue-sky milestone.
> > That way I don't have to close the issues, but I can ignore them.
> +1

Ideally, I'd love that waffle would support filtering issues, so that we
could exclude all type:question (and maybe even status:discussion) from
the kanban, as well as milestone:blue-sky.

BTW, I'd rather call it moonshot, or even better just with a moon emoji,
so that it's taking very little space: 🌝 or 🌙 or 🌛.

On Sun, Jan 29, 2017 at 10:16:26AM +0100, toogley at mailbox.org wrote:
> I have also a suggestion:
> Can we replace the "needs:help" tag with the habit of assigning people
> to issues if they work on that? (and remove that also if they don't
> anymore)
> I mean when nobody has been assigned to the issue, that means kind of
> that we don't know how to solve that one or are lacking time to work
> on it. Therefore, IMHO the lack of an issue assignation automatically
> tells that we need help on that.

a better one would be a "help wanted" tag, a bit like the "easy" one, so
it's not used for our own process, but for advertising the issue. That
way, we could consider having a list of issues to be featured on the
neomutt.org website filtered by either tag.

Cheers,

-- 
Z