New solution for bug reporting and feature requests

[Mij]

From a users viewpoint it would be nice if the prefix showed a clear promotion of the status of the report or request. I think it is better for the posting to slip off the bottom of the list unpromoted than to be rejected by an Administrator unless it is clearly contrary to the rules of the forum. It will only disappear off the bottom if nobody is discussing it.

In the case of bug reports I would propose
1. Reported ( by OP)
2. Supported (by Administrator)
3. Forwarded (to Irfan)

and for Feature requests
1. Requested (by OP)
2. Supported (by Administrator)
3. Forwarded (to Irfan)

IMHO administrators should normally wait a day or two before promoting a post to allow forum members (including themselves) to discuss it first.

I would hope that if the post is forwarded to Irfan and got a response, either positive or negative, from him then the administrator concerned would post information on the thread to provide feedback to those who have contributed. Similarly if it is fixed. It does not really need a new status. We can just read the message.

Administrators must decide between themselves how a report or request is going to be promoted from Supported to Forwarded.

[Bhikkhu Pesala]

It is not for any moderator to reject a feature request, but if it has been rejected by Irfan it is better to record that fact so that users know there's little point in submitting it again. The status needs to be changed from Forwarded to show that it has received a response from Irfan.

[Bhikkhu Pesala]

This needs to be resolved quickly. Iit is now worse than before. There is no Confirmed category, and Not a Bug category is still there.

[Skippybox]

• I think for consistency all threads should have a prefix for status.
  
• The Supported prefix is unnecessary since if it is forwarded it is pretty obvious that it was.
  
• I don't like Confirmed or Supported for users and moderators, since that should be for Irfan to decide.
  
• There should be a provision for a rejected concern, in case Irfan is against it.
  
• There should be a notice that it is either going to be available or is already, so no reading is required to know when.
  
• If something clearly is found to not be a bug, then it should be moved to Support. Feature request should be left in their forum however.

Bug Reports:
1. Reported (by OP; default prefix)
2. Forwarded (by Administrator)
3. Confirmed (by Irfan)
4. Rejected (by Irfan)
5. Upcoming (fix available in next release)
6. Fixed (a fixed version is available now)

Feature Requests:
1. Requested (by OP; default prefix)
2. Forwarded (by Administrator)
3. Supported (by Irfan)
4. Rejected (by Irfan)
5. Upcoming (feature available in next release)
6. Added (this feature is available now)

There are some problems with this system though.

It does not matter how many or who supports a fix/feature, since it is ultimately up to Irfan (besides, he does not know how many did anyway).

As for discussion, I support many ideas, but I don't voice my opinion necessarily. Likewise, if something isn't discussed at all, that doesn't mean it is unimportant. Additionally, if a workaround is presented for a problem, that doesn't mean a bug/feature shouldn't be corrected or added. I think there needs to be a better way, maybe polling on all fixes/features. This may be the most important.

[Bhikkhu Pesala]

I think for consistency all threads should have a prefix for status.

Agreed. Reported is fine for a default prefix.

The Supported prefix is unnecessary since if it is forwarded it is pretty obvious that it was.

Agreed for bugs. Feature Requests should not be forwarded unless supported by other users.

I don't like Confirmed or Supported for users and moderators, since that should be for Irfan to decide.

I think it is pretty obvious to experienced users if something is a bug or not, so I see no harm in moderators confirming a bug report. It tells the reporter that it has been checked and is repeatable. It is up to Irfan to reject it as Not a bug in IrfanView if the behaviour is caused by something beyond his control. If a bug is trivial it can be left as confirmed, without forwarding.

There should be a provision for a rejected concern, in case Irfan is against it.

I think "Rejected" is not suitable for bugs. A bug is either a bug or it is not a bug. If Irfan replies negatively, saying he cannot fix it or it takes too much work, or its too trivial as there is an easy workaround, then just leave it as "Pending." That is why I prefer something non-commital like "Pending" rather than "In Progress," which implies that something is actively being worked on and will be fixed in the next build or soon after, not just in Irfan's todo list.

There should be a notice that it is either going to be available or is already, so no reading is required to know when.

It is unwise to say that a bug will be fixed until it is fixed. "Pending" tells us that it will be fixed when its ready. "Fixed" tells us it will be available in the next release.

If something clearly is found to not be a bug, then it should be moved to Support. Feature request should be left in their forum however.

Agreed, except that Feature Requests that already exist in the program should also be moved to support.

I think six categories is too many. Four or five should be enough:

Bug Reports:
1. Reported (by OP; default prefix)
2. Confirmed (by user or moderator)
3. Forwarded (by anyone. Some users send a bug report then report it on the forum)
4. Pending (fix available when its ready)
5. Fixed (fix available in next release or in our downloads)

Feature Requests:
1. Requested (by OP; default prefix)
2. Supported (by other users)
3. Forwarded (by anyone)
4. Rejected (by Irfan)
5. Fixed (feature available in next release or in our downloads)

In the case of Feature Requests it is better to know if it is being considered, or has already been rejected. If it has been forwarded, we can assume that it is being considered.

[Skippybox]

Feature Requests should not be forwarded unless supported by other users.

Except, not all users use the forum and would be unrepresented. If user support is required, I truly think a voting should be held, in addition to any discussion. I do not want to post my support for every topic/idea.

I think it is pretty obvious to experienced users if something is a bug or not, so I see no harm in moderators confirming a bug report. It tells the reporter that it has been checked and is repeatable. It is up to Irfan to reject it as Not a bug in IrfanView if the behaviour is caused by something beyond his control. If a bug is trivial it can be left as confirmed, without forwarding.

This is why I don't like Confirmed for us, because why confirm it if it really turns out to be Not a Bug? Doesn't it give the wrong connotation, like Irfan has Confirmed it? It would appear as if it was already Forwarded.

I think "Rejected" is not suitable for bugs. A bug is either a bug or it is not a bug. If Irfan replies negatively, saying he cannot fix it or it takes too much work, or its too trivial as there is an easy workaround, then just leave it as "Pending." That is why I prefer something non-commital like "Pending" rather than "In Progress," which implies that something is actively being worked on and will be fixed in the next build or soon after, not just in Irfan's todo list.

I agree. However, why give false hope if the decision has already been made? Rejected may be unsuitable, but it is clear. That is why I thought both would be better. Either no, it's not going to happen, or yes, it's in the works. No fuzziness.

It is unwise to say that a bug will be fixed until it is fixed. "Pending" tells us that it will be fixed when its ready. "Fixed" tells us it will be available in the next release.

I do see your point, but many times Irfan already has fixed the problem with a patch or in his code. It is only a matter of time before everyone has it. I don't think the status should raise more questions than answers. What would be its point then?

Agreed, except that Feature Requests that already exist in the program should also be moved to support.

Yes, that is true.

I think six categories is too many. Four or five should be enough:

Simplicity is key, but accuracy is important, too. I don't know.

Bug Reports:
3. Forwarded (by anyone. Some users send a bug report then report it on the forum)

You're right.

Feature Requests:
5. Fixed (feature available in next release or in our downloads)

Why Fixed?

[Bhikkhu Pesala]

Except, not all users use the forum and would be unrepresented.

We can only represent users who actually post on these forums.

If user support is required, I truly think a voting should be held, in addition to any discussion. I do not want to post my support for every topic/idea.

Voting is too complicated. If a request is not worthy of a supporting post, then its not worthy of Irfan's time either. If we forward every request, even a request with at least some support, Irfan will be overwhelmed with emails. He might as well subscribe to the forum and read them himself. We need to discuss, refine, and clarify what is being requested before forwarding it to Irfan.

This is why I don't like Confirmed for us, because why confirm it if it really turns out to be Not a Bug? Doesn't it give the wrong connotation, like Irfan has Confirmed it? It would appear as if it was already Forwarded.

The meaning of each status can be clarified in a sticky post in the Bug Reports forum. If another user confirms a bug on Vista, as a moderator I can still change the status to confirmed, although I'm not using Vista. What is being confirmed is the unexpected behaviour reported by the user, not the cause of it. Consider a case like this Resize Bug. It might possibly turn out that Irfan designed it to behave like that for some reason that I don't know about, so its not a bug strictly speaking, but the reported behaviour does occur on my system as well as on the reporter's, so it is confirmed. Then, if Irfan reports back that it is "By Design" I would report that result with his explanation and move the thread to the support forum.

Why give false hope if the decision has already been made?

Never say never. Decisions can and do change, for example if plugin authors undertake to do the work that Irfan was unwilling or unable to undertake.

Why Fixed?

Either a bug is fixed or it is not. Even if it is not available to everyone yet, we know that the issue is closed. We should perhaps give a version number too when changing the thread's status, e.g. Fixed in version 4.24.

[Skippybox]

Voting is too complicated. If a request is not worthy of a supporting post, then its not worthy of Irfan's time either. If we forward every request, even a request with at least some support, Irfan will be overwhelmed with emails. He might as well subscribe to the forum and read them himself. We need to discuss, refine, and clarify what is being requested before forwarding it to Irfan.

Absolutely, that is why voting makes sense, because there are too many threads to post to. Features with the most votes or some minimum would only get approved. Too many good threads get ignored, because there really aren't enough experienced users active on the forum.

The meaning of each status can be clarified in a sticky post in the Bug Reports forum.

That will probably be the best you can do.

What is being confirmed is the unexpected behaviour reported by the user, not the cause of it.

Except, you yourself wrote:

2. If the program doesn't behave as you think it should, that is not a bug.

in the famous thread, When is a Bug not a Bug

But, if you want to confirm them anyway, fine by me. If it is "By Design", sure, why not put it in Support with an explanation.

Either a bug is fixed or it is not. Even if it is not available to everyone yet, we know that the issue is closed. We should perhaps give a version number too when changing the thread's status, e.g. Fixed in version 4.24.

No, no, I referred to feature requests. Why would you use Fixed for feature requests? I like your idea about bug reports though, detailing the version. That definitely works.

I think we have made some progress.

[Mij]

Who is it for?

Will you make use of these prefixes, Skippybox? I don't think I will. I will still read the posts whatever the label and expect that to tell me more about the status than the label does.
Are all these different categories going to be useful to you Bhikkhu, or are they just ones you think will be helpful to others?
Neither Skippybox or I are typical of the users. It would be nice to know if any of them will actually find some benefit.
Only Steve can tell us how he intends to use it. If his possible actions turn out to be just "Do something about it" or "Do nothing about it" then only 2 categories are needed surely.

[Bhikkhu Pesala]

Too many good threads get ignored, because there really aren't enough experienced users active on the forum.

Some threads would still get ignored if we had a voting system. In fact, we do have a voting system. You can rate a thread. The problem is that the OP can also rate it, and those are often the only votes that a thread gets, so a five star rating is not indicative of being well supported. There are currently 604 threads in Feature Requests. I am sure many are duplicates, but that is still far too many to consider seriously.

If it is "By Design", sure, why not put it in Support with an explanation.

Even experienced users get it wrong sometimes, and only Irfan can really know what his intention was. If he says it was "By Design" then the thread would get moved. If I think it was "By Design" it will also get moved. If others disagree with me, it can be moved back into Bug Reports and reconsidered.

No, no, I referred to feature requests. Why would you use Fixed for feature requests?

Well a Feature Request could also be considered as fixed if it is implemented, but "Added" or "Implemented" would be more accurate.

I think we have made some progress.

That's why we need to have this discussion in the public forum, so that users as well as moderators can have a say in how it should be implemented.

[Bhikkhu Pesala]

Are all these different categories going to be useful to you Bhikkhu, or are they just ones you think will be helpful to others?

Yes, they remind me that a thread has been dealt with, and tell other users what has been done about it.

So what we have so far is:

Bug Reports:
1. Reported (by OP; default prefix)
2. Confirmed (by another user and a moderator)
3. Forwarded (by anyone. Some users send a bug report then report it on the forum)
4. Pending (under consideration by Irfan. A fix will be available when its ready)
5. Fixed (A fix will available in the next release or is already in our downloads)

Feature Requests:
1. Requested (by OP; default prefix)
2. Supported (by other users)
3. Forwarded (by anyone)
4. Rejected (by Irfan)
5. Implemented (feature available in next release or in our downloads)

Is this good enough yet? For now we only need to decide on the prefixes to be used — not on voting or other issues.

[Skippybox]

Will you make use of these prefixes, Skippybox? I don't think I will.

I think these prefixes started with the best of intentions, but I don't know how it will turn out. You're right, I probably won't use them and just read the threads. I was trying to make it as clear for typical and unregistered users as possible, but there is only so much we can do. I suppose this system will provide some information for us all. I will try and see it as an improvement.

Some threads would still get ignored if we had a voting system. In fact, we do have a voting system. You can rate a thread. The problem is that the OP can also rate it, and those are often the only votes that a thread gets, so a five star rating is not indicative of being well supported. There are currently 604 threads in Feature Requests. I am sure many are duplicates, but that is still far too many to consider seriously.

That is true, but that is because the system is rather meaningless, and has no prominence. The election would have to far more visible and organized, but I know it is a lot of work. The problem with the current method of supporting features is that this is a small community, meaning little to no discussion. Without the diversity of users who use the program in so many ways, how can we ever expect much progress. I mean, some ideas require months to get any head wind, because of the infrequency of visitors who want the feature. I'm sure users would enjoy other features than their own, but don't devote the time to support them or notice.

The other problem is should good features require any support? Look at the attention Irfan has given to command line options, yet how much support would adding some get?

Well a Feature Request could also be considered as fixed if it is implemented, but "Added" or "Implemented" would be more accurate.

I do like Implemented.

Is this good enough yet? For now we only need to decide on the prefixes to be used — not on voting or other issues.

Well, they are intertwined aren't they? But, yes, I'm reasonably satisfied.

[stefan]

Hi,

a short another idea from me:

I did turn off the project tools, because of the double postings.

But why don´t we use the project tools instead of the forum postings?

Just have a look at the vbulletin forum and their project tools:

http://www.vbulletin.com/forum/project.php?issueid=27342

Please look on the right side of the thread:

Issue Type Bug
Project vBulletin
Category Infractions
Status Working as Designed
Priority 5 - Medium
Affected Version 3.8.1
Fixed Version (none)
Users able to reproduce bug 1
Users unable to reproduce bug 0
Attachments 0
Assigned Users (none)
Tags (none)

Here we find some details, which has already been discussed:

"Users able to reproduce bug" and "Users unable to reproduce bug" would solve the voting/poll problem. Affected version/fixed version provides a better overview.

The prefixes, discussed here, can easily be set as the "status" in the project tools.

I see only "one" problem: I must import all bugreports to the project tools. But that´s OK it only takes time... What do you think?

Greetings,

steve

[Skippybox]

That does look like a good idea, steve.

[stefan]

Hi,

i just installed project tools v2: In a response to a bug report normal users can "vote" for a change of the status (prefix). If an administrator will do that the status will be changed automatically, but not if normal user do that! Great function.

What i can do for a re- organisation of the bugreports:

Move all posts into a category called "archive". Then i import the bugreports with the most amount of views/replies first.

Bugreports, older that one year with no reply will be stored in the archive forum (should we delete them?).

So the most discussed bugreports will appear in the project tools very soon!

Greetings,

steve