Prioritizing and labeling issues

Developers
1

I’m flipping through our issues and one obvious thing we don’t have is prioritization of issues. I think it’s time we added labels for it.

Anyone have any suggestions? My suggestions would be “high”, “medium”, “low”.

One other thing I think we could add for people to start contributing is labeling issues with a sense of how difficult the fix is. I’m thinking something like “simple”, “complicated”, and “complex”, but open to any suggestions. The difference is simple is really simple, complicated might be a lot of steps but straightforward, and complex requires some critical thinking before a solution can be found.

2

How about for urgency: “results are wrong”, “next release”, “bug”, “project”

For difficulty I like “simple”, “multi-step”, and “design issues” or some other words that touch on those points.

3

Nice topic! I like the overall form of the suggest, because
it gets us away from tying urgency to releases.

At some point, we should sit down and decide to do a release
and only then tag the things that need to be done for the next
release. Right now, we do a lot of shuffling and issues for
the next release pile up.

I think urgency needs clear levels, which "results are wrong"
indicates, but it’s not the only critical issue that has to be
fixed (breaking in a compiler everyone uses is another).
This extreme urgency level to me is synonymous with “next release” (which
is not how we currently use “next release”).

Then, behind the results-are-wrong, we have the as-soon-as-possible
issues. I put most bugs into that boat if they don’t cross the
is-it-a-bug-or-a-feature line.

So how about for urgency something more temporal (the names are
bad, but I hope the idea’s clear):

URGENCY: NOW << ASAP << EVENTUALLY

I think difficulty is a trickier issue, with something like

DIFFICULTY: NOVICE << BEGINNER << INTERMEDIATE << EXPERT

but even that is an issue because some things are expert comp sci
and others are expert stats and other things are expert dev ops
or sys admin or whatever. So somehow the difficulty really needs
to be something like kinds of pre-reqs. But even then, if you have
the pre-reqs, some things are harder than others. So difficulty is
only going to give a rough flavor of project complexity.

Then Krzysztof’s idea of “project” is related in my mind to size,

SIZE: X-SMALL << SMALL << MEDIUM << LARGE << X-LARGE << XX-LARGE

We can go with the vente/grande scale, or the medium/big-gulp scale
if you don’t like the t-shirt scale.

Of course, size and difficulty are not unrelated as the more expert
you are, the smaller projects look.

I like this idea because it takes us away from putting the
milestones in ahead of time. —hopefully we’ll
be able to get to all of the NOW issues. But that’s my main
fear for project stability—that we’ll get overwhelmed on
multiple fronts (compilers, platforms, algorithms, etc.) and won’t
be able to keep up with all the NOW issues.

  • Bob