openmw.org

Regarding the no version state: My opinion is that this should be used for issues that are not actionable, not because of external issues (need prerequisites done, needs 1.0 first etc.), but because of issues with the issue itself: insufficient information to categorise it, triage not happened yet or still in progress and so on.
Every other issue should have a version number assigned to it, because that means it will appear somewhere on the roadmap and given the right circumstances a developer can pick it up.

Technically, anything is actionable - the action can be to do research, have a discussion, set it to Feedback needed, reject the issue due to lack of feedback or because we think it can't reasonably be done.

I'm not opposed to having a list of 'ready to code' issues somewhere, but I don't think versions/milestones are the right way to do it. It would be nice if we had tags.

I'm not opposed to having a list of 'ready to code' issues somewhere, but I don't think versions/milestones are the right way to do it. It would be nice if we had tags.

We have to agree to disagree then.

so many ways to skin a cat...

However many ways there are to do it, and regardless of what may be "best", should we pick one way to do it and document that so all devs can follow the same process?

It sounds like you all have a bunch to figure out on the developer end. My only input is that you can't change human behavior, you can only guide it into the outcome that you want. This makes the decision to remove adding a version to the bug reports good. Bug reporters should only have control over things that aid them in giving the devs more info on fixing the bug, everything else is a distraction. However, people are still going to be confused as to why certain things are being overlooked (in their eyes). Clarifying the way decisions are made on the wiki will help, so will giving the devs a united way of approaching triage and bug squashing. I'm sure most users won't care one way or the other as long as overall progress is being made, but whatever solution you find it might be helpful to think of the whole thing as a PR process. My approach is that everything visible to general users is essentially a PR problem. Less confused users will be less annoying!

@raevol I don't like spending a large amount of time on this stuff and (as I have mentioned before) we have to do it again after 1.0 anyway, I prefer to do as little as possible right now. Unless there is something else scrawl absolutely wants to be changed, I suggest to just go ahead with the changes we made and see how it works out.

If we've made a decision about how version numbers should work, can we get that added to the wiki so that the information is easier to find once this thread has been buried in the forums?

Zini wrote: ↑12 Sep 2017, 09:10go ahead with the changes we made

What are the changes we made though? I think that's the point of confusion. And I totally get not retroactively changing all the issues when they're all going to get changed again anyway, but for new issues what should we do?

We made two changes:
- Version numbers can only be set by devs
- Inactive tasks have been removed from the current milestone (mostly into openmw-1.0(-cs) or elsewhere when appropriate).

Relevant wiki page at https://wiki.openmw.org/index.php?title ... Guidelines

Basically it says fill in the following: and leave the rest to the devs.

That's probably close enough - though it does raise the question whether priority, category and severity should be left in their current intermediate status, or should be moved either into "submitter encouraged to fill them in" or "submitter locked out".

Loriel