Suggest new Status and Issue Type for JIRA

[BrentNewland]

Open JIRA bugs

As a user and occasional bug tester/filer, the state of the bugs in JIRA has gotten me down for a while. Lots of open bugs, some not commented on in years.

According to the JIRA manual, the status and issue type can both be expanded.

I would suggest two new statuses: Verified (for bugs that have been verified as valid but for which work has not started) as well as Approved (for improvements and new features which have been accepted, but for which work has not started), and a new Issue Type: Crash (to separate blue screens and hard locks from general bugs).

This little bit of organization should make it easier for testers and developers to see which bugs need more focus. It would also make any future bug drive more effective.

*edit* A third status, "METABUG", would help differentiate the metabugs from other bugs. Leaving them as just "Open" makes them kind of buried in the other bugs.

[Black_Fox]

I agree we should go through JIRA, but first sweep doesn't even need developer attention, we can do it by ourselves. Any issue can attract attention just because someone touched it after a long time (as seen at CORE-7344). As a small notice, you could also include "Reopened" tickets. I'll have a look at the list whenever I have time, we could indeed help to close a lot of issues.

I don't agree with adding the "Verified" and "Approved" statuses, they are redundant and already implicitly used. If the issue is invalid, it can be closed as invalid, worksforme or some other status. If it's valid, it's either kept as it is or assignee changed. That applies for both bugs and enhancements. The proposed addition would only put load on somebody's shoulders without much benefit. It won't stop some tickets from rotting in JIRA anyway. As for the metabugs, I agree they need to be fixed, but there are existing solutions to the problem that can be used - either a label or adding it into a summary (summary metabugs, label metabugs). The best may be to apply both label and summary. The same approach is also available for regressions.

[BrentNewland]

If the issue is invalid, it can be closed as invalid, worksforme or some other status. If it's valid, it's either kept as it is or assignee changed.

That's the problem. Out of 1,550+ bugs that I linked, only 8 are "in progress", the rest are just open. And there's no way to tell which ones have been verified by a developer and which ones haven't even been commented on.

[Webunny]

If the issue is invalid, it can be closed as invalid, worksforme or some other status. If it's valid, it's either kept as it is or assignee changed.

That's the problem. Out of 1,550+ bugs that I linked, only 8 are "in progress", the rest are just open. And there's no way to tell which ones have been verified by a developer and which ones haven't even been commented on.

I think you have a point. But I also think the underlying problem is that most of those bugs aren't really looked at (in the sense of: being verified, or at least commented on).

That underlying problem will not go away by introducing a 'verified' tag, since, if one doesn't bother, they STILL will remain as 'open'.

[Black_Fox]

My point is, some tickets WILL stay here for years, even if "assigned to" or "verified" or whatever. They aren't touched even if there is an army of testers. What do you expect of the few developers, to do our job?

[EmuandCo]

We don't need any new tags. Black_Fox is right. We try to fix bugs as fast as possible, but the manpower is a slight problem here from time to time. Many are invalid in theory because theres no needed information, just App xyz does not work! No information about the hardware, no in formation about the used version etcetc.

[Webunny]

My point is, some tickets WILL stay here for years, even if "assigned to" or "verified" or whatever. They aren't touched even if there is an army of testers. What do you expect of the few developers, to do our job?

I'm not sure if the last part is meant to be ironic or not, but it sounds funny. Comes over as: "What, you expect us to do our job?"

ermm...




PS. For the humorous-challenged: I know the devs are volunteers, no point in pointing that out. Just saying it came off as funny, when reading it. I guess it's implied that 'touching it' is our (testers?) job, not the job of the devs. But, I think the parents posters' point was, that with 'touching it' he meant: fixing the bugs. And fixing the bugs is, generally speaking, the devs job, not the testers' job. In as far as anyone can consider it a job, since we're all volunteers, of course. (Though, those who accepted an official function in ROS still have the duty to perform according to that function, obviously.)

We don't need any new tags. Black_Fox is right. We try to fix bugs as fast as possible, but the manpower is a slight problem here from time to time. Many are invalid in theory because theres no needed information, just App xyz does not work! No information about the hardware, no in formation about the used version etcetc.

With all due respect, and I'm sure the devs do their best in looking at the bugreports, it DOES sometimes seem little to no attention is given to (some) bugs. Even when this is, in effect, not the case, it still gives that impression, when you see a whole buckload of bugs, some of which are years old, to stand there as 'open' without anything happening to it. I think this is what the parent poster was alluding at. Even if you were correct, it would still be better to give some response to those bugreports, like 'not enough info, please provide more' or, indeed, just a tag indicating it has been (re)viewed, but can't be solved. If they are invalid, it should be indicated as such, not remain 'open' indefinately.

[Black_Fox]

I'm not sure if the last part is meant to be ironic or not

It was originally meant to be ironic, but now I see it only as a highly inappropriate way of saying the truth Developers are supposed to fix bugs, but we testers have to give them some information first. No developer will touch any of the hundreds of bugs that are last touched years ago, when there are also hundreds of recent bugs, it wouldn't make sense. I'm not saying it's flawless approach, but it's probably the best approach.

Any additional effort would just take more time off the devs' hands, so it would appear that the team is more active, but less work would actually get done. The very basic triage "yes, can be still reproduced" can be done by anyone. Caemyr and Amine used to handle tickets, but Caemyr is not very active these days and Amine has since increased his "dev" skills to contribute in more direct ways. If I keep having an hour or two in the evening a few days a week, I'll try to "refresh" as many of the old bugs as possible till the end of the year. I already saw that middings was taking care of it as well (there may be more people, but I was watching this ticket already and got a notification).

EDIT: small wording improvements

[Webunny]

I'm not sure if the last part is meant to be ironic or not

It was originally meant to be ironic, but now I see it only as a highly inappropriate way of saying the truth Developers are supposed to fix bugs, but we testers have to give them some information first. No developer will touch any of the hundreds of years-old bugs, when there are also hundreds of recent bugs, it wouldn't make sense. I'm not saying it's flawless approach, but it's probably the best approach.

Any additional effort would just take more time off the devs' hands, so it would appear that the team is more active, but less work would actually get done. The very basic triage "yes, can be still reproduced" can be done by anyone. Caemyr and Amine used to handle tickets, but Caemyr is not very active these days and Amine has since increased his "dev" skills to contribute in more direct ways. If I keep having an hour or two in the evening a few days a week, I'll try to "refresh" as many of the old bugs as possible till the end of the year. I already saw that middings was taking care of it as well (there may be more people, but I was watching this ticket already and got a notification).

Yes, well...with the understanding that those hundreds-of-years-old bugs were also, at one time, with the 'hundreds of recent bugs', when they were first reported.

Being shorthanded is the eternal problem, it seems. But that said, even towards testers - not all are seasoned, after all - it would be better if they got a 'please provide more info' than nothing at all. There are, after all, also people who are not as IT-minded as us, have less experience (to some point, this goes for all of us) in these things, and think they've done a good job...and then wait and wait, and nothing happens, and they get frustrated, and don't test any more.

It's true that direct coding is more important, but one has to search for a balance somewhere, or one risks losing a potential base of testers/funders/fans/etc. when one gives the impression of neglect. I've said this before, but I think one gives a TOO low priority on establishing such a 'relationship' between devs and userbase. In the long run, this is pretty important, however, since it let's you grow, and ultimately makes it possible to have a larger chance of getting more funds or devs (even paid ones), and thus, in the long run speed ROS-development up more than it would have otherwise. So one loses a bit in the short run, to gain more in the long run.

Anyway, if you and middings take up the job a bit, that's great to hear.

[middings]

As a user and occasional bug tester/filer, the state of the bugs in JIRA has gotten me down for a while. Lots of open bugs, some not commented on in years.

You're describing JIRA Entropy Dysphoria, a state of unease or discomfort because JIRA issues tend to be quicker and easier to file than to resolve.

Take a look at this list. It's the project's good news.

WINE resolves bug reports as "Abandoned" if the reporter is asked to retest with a new revision but is never heard from again. (WINE defines "never" as a wait of more than six months.) This is most appropriate for reports of bugs encountered in commercial or specialized software that the reporter can use but the project team members cannot. Among the objections to this practice is that it only cosmetically reduces the bug count, nothing actually gets fixed. ReactOS team members with JIRA super powers can do something similar without an explicit "Abandoned" label. They can eventually close the issue as Cannot Reproduce or Incomplete but I think there is a tendency to simply leave it in JIRA as unresolved.

I... suggest two new statuses: Verified (for bugs that have been verified as valid but for which work has not started) as well as Approved (for improvements and new features which have been accepted, but for which work has not started), and a new Issue Type: Crash (to separate blue screens and hard locks from general bugs).

Your suggestions of Verified and Approved as statuses fit JIRA's scheme of tracking an issue as it moves through the issue resolution workflow toward resolution. Something like your suggestion of Approved already exists in the ReactOS project in two places: (1) there are JIRA issues that are a list of blockers for the next (or future) release, and (2) the features listed in the Planned Releases listed in the [https://www.reactos.org/wiki/Roadmap#Re ... on_History]ReactOS Version History[/url] on the Roadmap page in the ReactOS wiki. When a ReactOS developer team member adds an issue to one of those lists, that is roughly equivalent to your suggested status of Approved.

For a status of Verified to be useful in practice, a reliable group of people who regularly and frequently review newly filed JIRA issues is required. Reviewing JIRA issues is not the best use of the developers' time. To verify a bug report probably takes patience (uh, oh!), the ability to make and understand ReactOS test logs, and a test target machine along with a debugger host machine, or a machine that can run ReactOS in a virtual machine (VM). At present, one can make screen capture images more easily in a VM than when running ReactOS in real hardware. (The ReactOS implementation of the clipboard and the print screen function is still too primitive to do the job for me on my test rig.)

A status of "Crashes" doesn't fit the JIRA status model because it describes a program behavior not a point in the workflow as an issue is moved toward resolution. However, JIRA does allow issues to have a Label. It is something like a tag or search keyword.

This little bit of organization should make it easier for testers and developers to see which bugs need more focus. It would also make any future bug drive more effective.

The JIRA heat death of the universe is frightful to contemplate.

Organized bug triage always helps. Perhaps JIRA's existing Issue Type: Story (a user story) could be used more often to mark JIRA issues that may be interesting to think about but do not clearly describe a clear, specific, and reproducible Bug or a defined Task. Also, some issues are marked as Issue Type: Bug that might be better marked as Issue Type: Task. Example CORE-3552, Migrate keyboard layouts to .klc (Microsoft Keyboard Layout Creator) format. (CORE-3552 is mentioned here as an example only; resolving it might no longer be useful.)

CORE-3552 looks like a task that a programmer could resolve without specialized knowledge of Windows's internal behavior. Triaging such issues as Tasks could make it easier for someone with moderate programming skills to identify something useful to contribute to the project. The most likely benefit of culling Tasks from Bugs is moving issues that are not really Bugs out of the depressingly long list of bugs.

Of course, however your ideas for giving better organization to ReactOS's collection of JIRA issues might be applied, they require someone to take the time to accomplish them--a significant commitment of time.