Chris wrote: ↑
11 Sep 2017, 02:26
I always figured openmw-future would be for post-1.0 stuff, and openmw-1.0 is for things that need to be done for 1.0. openmw-future makes it sound like it's a far-off (future) consideration, rather than ASAP.
Sorry for the confusion, the list has to be read backwards compared to the one above it, that's why I numbered it 3-2-1 (the 'everything else' part made more sense that way).
Makes sense. But we would have to define more clearly the meaning of the individual priority options. And maybe the severity field, too?
Would that definition be in any way specific to our project? If it's not, do we really need it?
I support this idea.
I'll ping lgro about the permissions change.
First openmw-future is for things that are not required for 1.0. Doesn't always mean that we can't do them (see above, unruly developers).
Is it? From what I've seen things not required for 1.0 have 'no version' (unless we can't or don't want to do them for 1.0, in which case they're openmw-future). That's how the tracker has been used, in my experience. If we decide this usage was wrong, we need to prepare for a lot of reorganisation work.
If we went by your proposed logic, then everything triaged will naturally fit into either openmw-1.0 or openmw-future (which could then just be renamed 'openmw-rest' or 'openmw-undecided'). This holds less information than using openmw-1.0, openmw-future and 'none' separately ('future' only for things that we can't or don't want to do now, and 'none' for undecided).
I'm getting the impression people think using 'no version' delibarately is bad because it would mean 'untriaged'. But that's not what it is. Issues with a version are triaged, but not all issues without a version are untriaged. There are many reasons why one would not be able to decide on a version after triaging an issue. IMO we should use the 'Confirmed' field as meaning 'Triaged'. (Note there isn't a 'Confirmed' status for Features, but that's not really a problem - most features are either openmw-1.0 or openmw-future anyway - and for the rest, I'd argue that there isn't a single way to 'triage' a feature, often it's a continous process with many changes/discussions along the way, even after implementation starts)
If we wanted to use versions for triaging, we have to add another milestone 'openmw-undecided' or 'openmw-triaged' and that is just too confusing and noisy.
I think what we're doing now is perfectly fine, with the only problem being the 'next version' milestone being used as a dumping ground that no ones knows what it means.
But if people really dislike it so much, maybe we should consider a openmw-1.0-optional milestone that would collect all non-essential issues from openmw-1.0.
So yet another version/milestone, that seems confusing. I'd just give them 'no version' to communicate that the issue is not (longer) required for 1.0. Anyway, we don't have to do that now and I agree the growing list is not really an issue (it should shrink eventually).
About the current milestone filling up with more and more tasks that are carried on indefinitely:
Again, I was hoping to address that after 1.0, because I don't like the idea of doing a reorganisation now.
If I offer to do it myself, do you like the idea now?
But what we could do (on the next release) is to move all inactive tasks from current to openmw-1.0 (or openmw-future/openmw-1.0-optional in some cases). That would at least get rid of the bug tracker update spam on each release.
A mass movement without actually looking at the issues would be harmful - then we're dealing with clutter on openmw-1.0, or whereever we move them, that doesn't actually belong there.
I had a quick look. The number is not as bad as I thought (only ~50 now, when it used to be 100-150). Ignoring the in progress/resolved ones, I only found one issue that has anything to do with the next release: 'Task #3776 Linux generic release package is missing OSG plugins' (relevant because it's a trivial fix and should be done, missing files needing to be added to the actual release build / packaging script). The rest are either:
1) untriaged, needing feedback/discussion, can't reproduce etc.
2) Bugs that likely originate from an external dependency (so even if they're fixed, we can't claim them as being fixed in a particular OpenMW release)
3) Issues that should strictly go to 'openmw-1.0', because Morrowind doesn't have this issue/omission (but the issue hasn't been assigned to openmw-1.0 maybe because we deemed it 'unimportant')
1) and 2) can go to no version. 3) probably goes to openmw-1.0 (that doesn't mean we'll actually end up doing them before 1.0, as you said we can do a purge by priority at some point). Sound good?