Hi,
The subject pretty much explains it.
I have a couple theories why there's so many duplicates: - SourceForge.net is kind of hard to use, especially searching - No login required makes it "too easy" for people to quickly post bug reports without thinking too much as soon as they experience a bug
Anyway, I just wanted to see if anybody had any ideas for how we could minimize duplicate bug reports since it's a quite a pain to keep up with the all the report as it is, especially with things like GTK+ bugs where a distro upgrades their GTK+ and we get a pile of duplicate bugs about the same non-Geany bugs.
Two recent examples come to mind: - GTK+ file chooser dialog bug causes Geany to crash - DBus menu bug causes console spam and non-functioning menus
Both of these had more than 3 or 4 duplicate bugs reported already, even when some of the other duplicate reports were already on the first screen you see before you post a bug. Both have been fixed in Git, but bug reporters won't know this unless they first check for duplicates and see that we've fixed it.
Ideas would be appreciated.
Cheers, Matthew Brush
I propose the "human" solution: ask if there are any candidates for the job of volunteer-duplicate-remover? [sorry, can't do it myself :/ ]
Cheers, Paul
On 02/01/2012 07:27 PM, Matthew Brush wrote:
Hi,
The subject pretty much explains it.
I have a couple theories why there's so many duplicates:
- SourceForge.net is kind of hard to use, especially searching
- No login required makes it "too easy" for people to quickly post bug
reports without thinking too much as soon as they experience a bug
Anyway, I just wanted to see if anybody had any ideas for how we could minimize duplicate bug reports since it's a quite a pain to keep up with the all the report as it is, especially with things like GTK+ bugs where a distro upgrades their GTK+ and we get a pile of duplicate bugs about the same non-Geany bugs.
Two recent examples come to mind:
- GTK+ file chooser dialog bug causes Geany to crash
- DBus menu bug causes console spam and non-functioning menus
Both of these had more than 3 or 4 duplicate bugs reported already, even when some of the other duplicate reports were already on the first screen you see before you post a bug. Both have been fixed in Git, but bug reporters won't know this unless they first check for duplicates and see that we've fixed it.
Ideas would be appreciated.
Cheers, Matthew Brush _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
I'm a co-adniminstrator of a SourceForge host project and agree completely about the bug system, or tracker as they call it. We encourage bug reports to be sent to our mailing list, however, that requires the reporter join the list or one of us has to approve the message upon moderation and then remember to CC the reporter unless we get a mail that the reporter joined the list.
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Perhaps the most difficult thing is using the search properly. What I had happen recently was to search the Debian BTS for some key words on an issue I was having. Almost immediately the maintainer merged my report with an older one that described the same problem but used different terminology. Of course the maintainer recognized the similarity and acted on it. Does the SF.net tracker allow merging of reports? I've not checked as it's not something I've had to try and do as we get so few reports in the SF.net tracker.
- Nate >>
Am 02.02.2012 01:32, schrieb Nate Bargmann:
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Flyspray isn't that bad. We use it in Rockbox.
Best regards.
Has Github a simple and straight foward solution to bug tracking?
2012/2/2 Thomas Martitz thomas.martitz@student.htw-berlin.de
Am 02.02.2012 01:32, schrieb Nate Bargmann:
I don't have an answer but would steal any good ideas. :-) Is there a
BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Flyspray isn't that bad. We use it in Rockbox.
Best regards.
______________________________**_________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-**bin/mailman/listinfo/geanyhttps://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, Feb 2, 2012 at 3:48 PM, Cássio Nandi Citadin cassionandi@gmail.comwrote:
Has Github a simple and straight foward solution to bug tracking?
0.02 Euros: for small, non-distributed dev teams: reporting bugs to the mailing list seems to work well in my experience. The sqlite3 team takes reports from the mailing list and one of the devs enters (or not) the report into the bug tracker. In the fossil project (run by sqlite3's author) we do the same (anonymous bug reports were disabled due to the very high noise:info ratio). Since those particular dev teams are relatively small (not sure how many actively work on sqlite3, but on fossil fewer than 10 people regularly commit), this method seems to cut the bug-noise and duplicate entries to essentially 0.
For large and/or truly distributed projects i'm hoping that someone following this thread can make some good suggestions.
On Thu, 2012-02-02 at 12:48 -0200, Cássio Nandi Citadin wrote:
Has Github a simple and straight foward solution to bug tracking?
GitHub provides a feature for issue tracking, yes. My suggestion would be to just use that one, as it would just be consequent with the code-hosting and users will not have to search stuff in different places.
Regards, Dominic
On 02/02/2012 12:37 PM, Dominic Hopf wrote:
On Thu, 2012-02-02 at 12:48 -0200, Cássio Nandi Citadin wrote:
Has Github a simple and straight foward solution to bug tracking?
GitHub provides a feature for issue tracking, yes. My suggestion would be to just use that one, as it would just be consequent with the code-hosting and users will not have to search stuff in different places.
I think we talked about it before, but the two big problems are getting all our bugs transferred to Github's tracker and also that you need to register an account on Github in order to report a bug.
Moving the bugs would be tricky, though there's lots of really old bugs that probably would never get closed anyway, so not sure how important it is to keep all of the noise ones no one knows what to do about.
For the registration thing, I personally don't see it as a problem, since if someone didn't want to register with Github, they could simply report the bug on the mailing list and someone from the community could open an ticket for them.
That being said, I can't say I've used Github Issues enough to know if it's suitable for our use.
Cheers, Matthew Brush
On Thu, 02 Feb 2012 16:20:59 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
For the registration thing, I personally don't see it as a problem, since if someone didn't want to register with Github, they could simply report the bug on the mailing list and someone from the community could open an ticket for them.
Here I disagree: Its the main point I'm sad on most bugzilla, trac etc. installation: you cannot submit a bug as unregistered user. Shall we really bother people to register and confirmation mail and and and just to tell use an issue? I don't think so. Its hard enough to get good bug reports at all. Most people just ignore bugs and move on without reporting....
Cheers, Frank
On 02/02/2012 11:48 PM, Frank Lanitz wrote:
On Thu, 02 Feb 2012 16:20:59 -0800 Matthew Brushmbrush@codebrainz.ca wrote:
For the registration thing, I personally don't see it as a problem, since if someone didn't want to register with Github, they could simply report the bug on the mailing list and someone from the community could open an ticket for them.
Here I disagree: Its the main point I'm sad on most bugzilla, trac etc. installation: you cannot submit a bug as unregistered user. Shall we really bother people to register and confirmation mail and and and just to tell use an issue? I don't think so. Its hard enough to get good bug reports at all. Most people just ignore bugs and move on without reporting....
I feel split on the issue TBH. At least with something like Github, it might not be "yet another thing to sign up for" like all the separate Bugzilla/Trac installations. There's some chance that the user will have a Github account, though it's probably not *that* likely, it's still useful for other things (same as SF.net account).
I can understand wanting to make it easy to report bugs, but at the same time I can understand the argument that requiring registration will likely lead to better bug reports, ex. from people who are helping with testing. Many of the current "Nobody"/Anonymous bug reports are quite vague, quickly written, and even sometimes having a strange "attitude" in them. What's more since it's so easy, the reporters are probably more likely to quickly fill in the form and submit it before even bothering to search for duplicates or to know the bug reporting procedure outlined on the website (at least that's my theory).
My personal opinion is that it's better to get less really good reports from testers in the community than to get many vague/duplicate bug reports from random anonymous people who are just pissed off because a bug is annoying them.
But anyway, I don't feel to strongly either way, mostly this thread was meant for ideas on how to better manage bugs, especially duplicates, not necessarily to discuss changing bug trackers, though that could possibly help.
Cheers, Matthew Brush
Matthew Brush wrote:
I feel split on the issue TBH. At least with something like Github, it might not be "yet another thing to sign up for" like all the separate Bugzilla/Trac installations. There's some chance that the user will have a Github account, though it's probably not *that* likely, it's still useful for other things (same as SF.net account).
I can understand wanting to make it easy to report bugs, but at the same time I can understand the argument that requiring registration will likely lead to better bug reports, ex. from people who are helping with testing. Many of the current "Nobody"/Anonymous bug reports are quite vague, quickly written, and even sometimes having a strange "attitude" in them. What's more since it's so easy, the reporters are probably more likely to quickly fill in the form and submit it before even bothering to search for duplicates or to know the bug reporting procedure outlined on the website (at least that's my theory).
My personal opinion is that it's better to get less really good reports from testers in the community than to get many vague/duplicate bug reports from random anonymous people who are just pissed off because a bug is annoying them. [...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
On Fri, 03 Feb 2012 19:54:26 +1100 Ross McKay rosko@zeta.org.au wrote:
Matthew Brush wrote:
I feel split on the issue TBH. At least with something like Github, it might not be "yet another thing to sign up for" like all the separate Bugzilla/Trac installations. There's some chance that the user will have a Github account, though it's probably not *that* likely, it's still useful for other things (same as SF.net account).
I can understand wanting to make it easy to report bugs, but at the same time I can understand the argument that requiring registration will likely lead to better bug reports, ex. from people who are helping with testing. Many of the current "Nobody"/Anonymous bug reports are quite vague, quickly written, and even sometimes having a strange "attitude" in them. What's more since it's so easy, the reporters are probably more likely to quickly fill in the form and submit it before even bothering to search for duplicates or to know the bug reporting procedure outlined on the website (at least that's my theory).
My personal opinion is that it's better to get less really good reports from testers in the community than to get many vague/duplicate bug reports from random anonymous people who are just pissed off because a bug is annoying them. [...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
Cheers, Frank
[...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
I agree with Frank, registration tends to stop casual reporters, who are not involved with the particular program but have found a problem.
Certainly I will not bother to report a bug in software I am just using, but not involved with, if I have to jump through hoops. And there is no way I remember what I used as a password last time I registered to report a bug for [insert project here] so to report again I have to go through the whole forgoten password fiasco. Bah, too much trouble.
Admittedly casual reports are varying quality, from ones where you want to shout "RTFM", to completely professional. Just because the reporter didn't register does not imply any lack of intelligence or knowledge.
Perhaps we just need to be a little more proactive in closing them, after all they don't actually go away and it shows an actuve bug processing culture.
Cheers Lex
Cheers, Frank -- http://frank.uvena.de/en/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, Feb 3, 2012 at 12:57 PM, Lex Trotman elextr@gmail.com wrote:
Perhaps we just need to be a little more proactive in closing them, after all they don't actually go away and it shows an actuve bug processing culture.
On a related note: there have been a couple cases where i've filed bugs in Launchpad and the bug reports go untouched for 2-3 _years_ before someone sets a priority. In such cases, the admin always says, "please check on the latest version." (Fair enough -the report was against a much older version.) But if they are taking several years to answer then i honestly can't be bothered to go back and verify the bug on a newer system. Waiting too long to prioritize new bugs leaves a bad taste in user's mouths (at last it does mine).
Examples: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/119097
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/122919 (this one "only" took them 9 months to prioritize and 3 years to mark as "will not fix")
On 02/03/2012 03:57 AM, Lex Trotman wrote:
[...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
I agree with Frank, registration tends to stop casual reporters, who are not involved with the particular program but have found a problem.
Certainly I will not bother to report a bug in software I am just using, but not involved with, if I have to jump through hoops. And there is no way I remember what I used as a password last time I registered to report a bug for [insert project here] so to report again I have to go through the whole forgoten password fiasco. Bah, too much trouble.
I'd agree somewhat for random Bugzilla/Trac installations where each one has a different login, but for something like SF.net or Github.com where there's only one login, it's much less of a problem. What's more, it takes like 1-3 minutes to reset a password, if you can't be bothered to spend a few minutes entering details for the bug report (in this case your contact info), what are the chances your report is going to be sufficiently detailed? And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc?
Admittedly casual reports are varying quality, from ones where you want to shout "RTFM", to completely professional. Just because the reporter didn't register does not imply any lack of intelligence or knowledge.
But it often implies lack of care or follow through, or in the case of SF.net that you might've forgotten to login because it's not required :)
Perhaps we just need to be a little more proactive in closing them, after all they don't actually go away and it shows an actuve bug processing culture.
I see lots of active bug processing on Launchpad.net and various Bugzillas despite them requiring a login. They have a certain minimum amount of information needed to start working on a bug, and that includes the reporters contact information.
Cheers, Matthew Brush
In fact, make a user to register in a new platform to report a bug make it lost it focus on the bug itself with all registration and new passwords. Its not fair said that someone who dont want to register doesn't have valueable info about a issue.
2012/2/3 Matthew Brush mbrush@codebrainz.ca
On 02/03/2012 03:57 AM, Lex Trotman wrote:
[...]
+1 to everything above. I reckon that many of those anonymous bug
reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
I agree with Frank, registration tends to stop casual reporters, who are not involved with the particular program but have found a problem.
Certainly I will not bother to report a bug in software I am just using, but not involved with, if I have to jump through hoops. And there is no way I remember what I used as a password last time I registered to report a bug for [insert project here] so to report again I have to go through the whole forgoten password fiasco. Bah, too much trouble.
I'd agree somewhat for random Bugzilla/Trac installations where each one has a different login, but for something like SF.net or Github.com where there's only one login, it's much less of a problem. What's more, it takes like 1-3 minutes to reset a password, if you can't be bothered to spend a few minutes entering details for the bug report (in this case your contact info), what are the chances your report is going to be sufficiently detailed? And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc?
Admittedly casual reports are varying quality, from ones where you
want to shout "RTFM", to completely professional. Just because the reporter didn't register does not imply any lack of intelligence or knowledge.
But it often implies lack of care or follow through, or in the case of SF.net that you might've forgotten to login because it's not required :)
Perhaps we just need to be a little more proactive in closing them,
after all they don't actually go away and it shows an actuve bug processing culture.
I see lots of active bug processing on Launchpad.net and various Bugzillas despite them requiring a login. They have a certain minimum amount of information needed to start working on a bug, and that includes the reporters contact information.
Cheers, Matthew Brush
______________________________**_________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-**bin/mailman/listinfo/geanyhttps://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Le 03/02/2012 17:07, Matthew Brush a écrit :
On 02/03/2012 03:57 AM, Lex Trotman wrote:
[...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
I agree with Frank, registration tends to stop casual reporters, who are not involved with the particular program but have found a problem.
Certainly I will not bother to report a bug in software I am just using, but not involved with, if I have to jump through hoops. And there is no way I remember what I used as a password last time I registered to report a bug for [insert project here] so to report again I have to go through the whole forgoten password fiasco. Bah, too much trouble.
I'd agree somewhat for random Bugzilla/Trac installations where each one has a different login, but for something like SF.net or Github.com where there's only one login, it's much less of a problem. What's more, it takes like 1-3 minutes to reset a password, if you can't be bothered to spend a few minutes entering details for the bug report (in this case your contact info), what are the chances your report is going to be sufficiently detailed?
I agree with Frank and Lex: I do already have given up reporting a bug just because the procedure to do it was "too complex". What "too complex" means probably depends a lot on the bug's annoyance, the commitment to the project and the basic feeling about the software's developers (e.g. what you think they'll do with the bug, or "do I want to give them mail/pwd?"), but the fact is that there is something to do beside reporting the bug.
And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc?
Good point though. Without contact info, follow up is nearly impossible and the bug is likely to be useless unless it's particularly good straight from the start. That's a valid point towards required registration.
Admittedly casual reports are varying quality, from ones where you want to shout "RTFM", to completely professional. Just because the reporter didn't register does not imply any lack of intelligence or knowledge.
But it often implies lack of care or follow through, or in the case of SF.net that you might've forgotten to login because it's not required :)
Perhaps we just need to be a little more proactive in closing them, after all they don't actually go away and it shows an actuve bug processing culture.
I see lots of active bug processing on Launchpad.net and various Bugzillas despite them requiring a login. They have a certain minimum amount of information needed to start working on a bug, and that includes the reporters contact information.
Cheers, Matthew Brush _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
* On 2012 03 Feb 11:45 -0600, Colomban Wendling wrote:
I agree with Frank and Lex: I do already have given up reporting a bug just because the procedure to do it was "too complex". What "too complex" means probably depends a lot on the bug's annoyance, the commitment to the project and the basic feeling about the software's developers (e.g. what you think they'll do with the bug, or "do I want to give them mail/pwd?"), but the fact is that there is something to do beside reporting the bug.
I've been on this side of the fence numerous times and am a bit sympathetic to this line of thought.
And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc?
Good point though. Without contact info, follow up is nearly impossible and the bug is likely to be useless unless it's particularly good straight from the start. That's a valid point towards required registration.
And now being on the developer side of the fence, a hit and run bug report may deserve about as much attention. I can see both sides of the argument. Knowing what I now know from being on the dev side of things, I am much more willing to do whatever registration is required to submit a bug report and follow up with the maintainer/developer. Admittedly, even doing so doesn't always resolve things on my schedule. Still, the tools and responses out here in free software land far exceed any of my experiences with proprietary software years ago.
If I were in a position to choose, I would choose user registration as I think the benefits for all concerned outweigh any inconvenience. OTOH, "registration" can be as simple as the Debian BTS where all is required is a "from" email address to submit the report using reportbug. I suppose a fake address has been used, but I suspect most reporters use a valid address to remain in the response loop.
- Nate
On 02/03/2012 10:13 AM, Nate Bargmann wrote:
- On 2012 03 Feb 11:45 -0600, Colomban Wendling wrote:
I agree with Frank and Lex: I do already have given up reporting a bug just because the procedure to do it was "too complex". What "too complex" means probably depends a lot on the bug's annoyance, the commitment to the project and the basic feeling about the software's developers (e.g. what you think they'll do with the bug, or "do I want to give them mail/pwd?"), but the fact is that there is something to do beside reporting the bug.
I've been on this side of the fence numerous times and am a bit sympathetic to this line of thought.
And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc?
Good point though. Without contact info, follow up is nearly impossible and the bug is likely to be useless unless it's particularly good straight from the start. That's a valid point towards required registration.
And now being on the developer side of the fence, a hit and run bug report may deserve about as much attention. I can see both sides of the argument. Knowing what I now know from being on the dev side of things, I am much more willing to do whatever registration is required to submit a bug report and follow up with the maintainer/developer. Admittedly, even doing so doesn't always resolve things on my schedule. Still, the tools and responses out here in free software land far exceed any of my experiences with proprietary software years ago.
If I were in a position to choose, I would choose user registration as I think the benefits for all concerned outweigh any inconvenience. OTOH, "registration" can be as simple as the Debian BTS where all is required is a "from" email address to submit the report using reportbug. I suppose a fake address has been used, but I suspect most reporters use a valid address to remain in the response loop.
You pretty much summed up my feelings. I've been through Bugzilla hell as a user and been on the developer side trying to understand random bug reports with little information and no contact information.
I also would choose registration over not requiring registration, but only by a small margin. I agree that just even name and/or email address, without "creating another account somewhere" would be the best option, like you said.
Cheers, Matthew Brush
Matthew Brush wrote:
I'd agree somewhat for random Bugzilla/Trac installations where each one has a different login, but for something like SF.net or Github.com where there's only one login, it's much less of a problem. What's more, it takes like 1-3 minutes to reset a password, if you can't be bothered to spend a few minutes entering details for the bug report (in this case your contact info), what are the chances your report is going to be sufficiently detailed? And what are the chances that you're going to go back to the bug report, which doesn't know your email address to tell you of new comments, and follow up with additional testing, etc? [...]
+1 again. What's the point in making it easy for someone to commit 1 minute to writing a content-free bug report? If the bug is that simple to describe, the chances are a committed user with a login will also hit it. If it takes more than a minute to describe, then the hassle of logging in to describe it isn't much on top of the actual bug report.
I like the idea of pushing the bug tracking on to Github. It seems to be much more social, and given that Geany is a developer's tool the chances are that many users will either already have a login there or will not feel too inconvenienced getting one (like, "been meaning to do that sometime anyway").
[...]
+1 again. What's the point in making it easy for someone to commit 1 minute to writing a content-free bug report?
Because it also makes it easy to commit one minute to writing a concise, useful, insightful bug report, don't punish the innocent just because you can't catch the guilty.
If the bug is that simple
to describe, the chances are a committed user with a login will also hit it. If it takes more than a minute to describe, then the hassle of logging in to describe it isn't much on top of the actual bug report.
Committed users tend to stick to well known, well worn tracks, its the users who try the stupid, "why the [blank] would you do that", things that find the bugs, and new use cases that make the software more useful.
I like the idea of pushing the bug tracking on to Github. It seems to be much more social, and given that Geany is a developer's tool the chances are that many users will either already have a login there or will not feel too inconvenienced getting one (like, "been meaning to do that sometime anyway").
That is likely partly true, but its still one more thing to do. And it probably doesn't apply to many who use Geany in a web centric environment.
The idea from a previous post that you must be logged in or provide a contact email is good, but what bts works that way? And who hosts it?
In the end the bts has to be available on a suitable host for free, and we need to be able to convert at least the last year of bugs to it. Don't know anything that does both.
Cheers Lex
Lex Trotman wrote:
[...] Committed users tend to stick to well known, well worn tracks, its the users who try the stupid, "why the [blank] would you do that", things that find the bugs, and new use cases that make the software more useful. [...]
This is very true. That's why I get SWMBO to do testing for me :)
* On 2012 03 Feb 20:37 -0600, Lex Trotman wrote:
The idea from a previous post that you must be logged in or provide a contact email is good, but what bts works that way? And who hosts it?
My memory may be getting hazy but it seems as though every Bugzilla I've encountered required registration to do anything useful.
- Nate
On 02/03/2012 02:32 AM, Frank Lanitz wrote:
On Fri, 03 Feb 2012 19:54:26 +1100 Ross McKayrosko@zeta.org.au wrote:
Matthew Brush wrote:
I feel split on the issue TBH. At least with something like Github, it might not be "yet another thing to sign up for" like all the separate Bugzilla/Trac installations. There's some chance that the user will have a Github account, though it's probably not *that* likely, it's still useful for other things (same as SF.net account).
I can understand wanting to make it easy to report bugs, but at the same time I can understand the argument that requiring registration will likely lead to better bug reports, ex. from people who are helping with testing. Many of the current "Nobody"/Anonymous bug reports are quite vague, quickly written, and even sometimes having a strange "attitude" in them. What's more since it's so easy, the reporters are probably more likely to quickly fill in the form and submit it before even bothering to search for duplicates or to know the bug reporting procedure outlined on the website (at least that's my theory).
My personal opinion is that it's better to get less really good reports from testers in the community than to get many vague/duplicate bug reports from random anonymous people who are just pissed off because a bug is annoying them. [...]
+1 to everything above. I reckon that many of those anonymous bug reports are next to worthless for their minimal detail and that means they end up reducing the signal to noise ratio. If someone isn't already a member of either SF or GH and won't join up in order to submit a bug report, what are the chances that the bug report is both sufficiently detailed and not a duplicate?
I can tell only for myself: I found a couple of bugs on wordpress, and some misbehaviors und firefox and a couple others more. As the I'm forced to register a new account on their plattforms the mood to report went against 0 so a couple of them I just fixed locally and didn't report upstream. Shame on me. But I don't want to do a 10min register marathon just for reporting one line is suboptimal. I'm fine with a bigger number of noise, if there are a bunch of maybe new reports which we wouldn't get else wise.
But you already have a SF.net and Github.com login :)
And if you didn't, IIRC at least for Github it takes maybe 30 sec. to 1 minute to register. Name, email, password, confirm, done. If you can't be bothered to spend a minute to enter a little detail, what are the chances your report is going to be sufficiently detailed? And then, having no way to contact you besides comments on the report, what are the chances you're going to follow up, possibly testing some new commit/version/dependency?
Just sayin...
Cheers, Matthew Brush
On 02/01/2012 04:32 PM, Nate Bargmann wrote:
I'm a co-adniminstrator of a SourceForge host project and agree completely about the bug system, or tracker as they call it. We encourage bug reports to be sent to our mailing list, however, that requires the reporter join the list or one of us has to approve the message upon moderation and then remember to CC the reporter unless we get a mail that the reporter joined the list.
-1 to mailing list reporting for the reasons you mentioned, at least not for *all* bugs.
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Having used Bugzilla only as a user, I can say it's easily as bad as Source Forge if not worse. I've seen Trac but never used it.
Perhaps the most difficult thing is using the search properly. What I had happen recently was to search the Debian BTS for some key words on an issue I was having. Almost immediately the maintainer merged my report with an older one that described the same problem but used different terminology. Of course the maintainer recognized the similarity and acted on it. Does the SF.net tracker allow merging of reports? I've not checked as it's not something I've had to try and do as we get so few reports in the SF.net tracker.
Agree about searching. Two users experiencing the same issue usually have a completely different description, and so searching is often quite hard.
I don't think SF.net does allow merging dupes, and this partially the reason I started this thread, because duplicate tracking is stupid on Source Forge (unless I just don't know how to use it).
In a perfect world, each report that was marked as a dupe would contribute to keywords for the whole bug and before the user submits a new report, it would search all the items and duplicates and suggest that the user checks a handful of similar reports before/during submitting to see if they are duplicates.
Cheers, Matthew Brush
On Fri, Feb 3, 2012 at 11:31 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 02/01/2012 04:32 PM, Nate Bargmann wrote:
I'm a co-adniminstrator of a SourceForge host project and agree completely about the bug system, or tracker as they call it. We encourage bug reports to be sent to our mailing list, however, that requires the reporter join the list or one of us has to approve the message upon moderation and then remember to CC the reporter unless we get a mail that the reporter joined the list.
-1 to mailing list reporting for the reasons you mentioned, at least not for *all* bugs.
Mailing list for all bugs just adds unnecessary clerical effort on the Geany team.
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Having used Bugzilla only as a user, I can say it's easily as bad as Source Forge if not worse. I've seen Trac but never used it.
Used Trac a few times, it seems much the same. ie bad
Perhaps the most difficult thing is using the search properly. What I had happen recently was to search the Debian BTS for some key words on an issue I was having. Almost immediately the maintainer merged my report with an older one that described the same problem but used different terminology. Of course the maintainer recognized the similarity and acted on it. Does the SF.net tracker allow merging of reports? I've not checked as it's not something I've had to try and do as we get so few reports in the SF.net tracker.
Agree about searching. Two users experiencing the same issue usually have a completely different description, and so searching is often quite hard.
I don't think SF.net does allow merging dupes, and this partially the reason I started this thread, because duplicate tracking is stupid on Source Forge (unless I just don't know how to use it).
On most of them AFAICT
In a perfect world, each report that was marked as a dupe would contribute to keywords for the whole bug
Thats a good idea, now how do we get it implemented?
and before the user submits a new report, it
would search all the items and duplicates and suggest that the user checks a handful of similar reports before/during submitting to see if they are duplicates.
Thats more likely to be annoying rather than useful
The issue with a bug tracker is only what software to run, but who to host it. Nobody I know of allows you to run your own tracker software, each free host has its own.
Cheers Lex
Cheers, Matthew Brush
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 3 February 2012 11:12, Lex Trotman elextr@gmail.com wrote:
On Fri, Feb 3, 2012 at 11:31 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 02/01/2012 04:32 PM, Nate Bargmann wrote:
I'm a co-adniminstrator of a SourceForge host project and agree completely about the bug system, or tracker as they call it. We encourage bug reports to be sent to our mailing list, however, that requires the reporter join the list or one of us has to approve the message upon moderation and then remember to CC the reporter unless we get a mail that the reporter joined the list.
-1 to mailing list reporting for the reasons you mentioned, at least not for *all* bugs.
Mailing list for all bugs just adds unnecessary clerical effort on the Geany team.
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it to be so-so. Trac is another.
Having used Bugzilla only as a user, I can say it's easily as bad as Source Forge if not worse. I've seen Trac but never used it.
Used Trac a few times, it seems much the same. ie bad
Perhaps the most difficult thing is using the search properly. What I had happen recently was to search the Debian BTS for some key words on an issue I was having. Almost immediately the maintainer merged my report with an older one that described the same problem but used different terminology. Of course the maintainer recognized the similarity and acted on it. Does the SF.net tracker allow merging of reports? I've not checked as it's not something I've had to try and do as we get so few reports in the SF.net tracker.
Agree about searching. Two users experiencing the same issue usually have a completely different description, and so searching is often quite hard.
I don't think SF.net does allow merging dupes, and this partially the reason I started this thread, because duplicate tracking is stupid on Source Forge (unless I just don't know how to use it).
On most of them AFAICT
In a perfect world, each report that was marked as a dupe would contribute to keywords for the whole bug
Thats a good idea, now how do we get it implemented?
and before the user submits a new report, it
would search all the items and duplicates and suggest that the user checks a handful of similar reports before/during submitting to see if they are duplicates.
Thats more likely to be annoying rather than useful
The issue with a bug tracker is only what software to run, but who to host it. Nobody I know of allows you to run your own tracker software, each free host has its own.
Cheers Lex
Cheers, Matthew Brush
You might consider JIRA, a commercial product of Atlassian. Of course Geany is an open source project and may prefer not to be tied in any way to a company. Atlassian provide hosted instances of JIRA for open source projects, including JBoss. I use it almost daily in my work and find it's a very capable product.
The Frugalware Linux distribution recently changed from using Flyspray to Trac because Flyspray was no longer maintained. Trac seems OK to me as an end user of the product.
Mantis - http://www.mantisbt.org/ - looks good and is seemingly actively developed. According to the blog, it has a phone-optimized interface available which could be a big advantage. The development team could keep their phones by their beds and track bugs as they are reported and respond instantly and easily. :P
Regards,
Russell Dickenson
Having used JIRA on my job, and it is a really complete e rebust software. Its very flexible and tends to take form over the culture of the local business where it is used. Dont know how geany is developed (sprints, single features and different teams, anyone can contribute), but JIRA is certainly recommended if you need some specificity on your track systems. In other words, if you track system can do, JIRA can, but may need some patience to put it to work.
Have some months of experience with Mantis. Its straight forward as a bug track system, may need some tweaks to take the form expected for the dev team.
Github has it simple track system, but shows powerful in teams and projects with many issues and little/medium teams. But, i think the most appeal point in GitHub is the "social coding". The way the communication flows in to the network, with another developers and it seems more "open" them other plataforms out there, maybe its only impression of a frustrated open source developer, but since I started to use geany (two months) and saw that it is worth, I prayed for it to be hosted on Github. I think it will facilite the new users and developers to get this project to be the best lightweight text editor in the universe (it is almost there)
2012/2/2 Russell Dickenson russelldickenson@gmail.com
On 3 February 2012 11:12, Lex Trotman elextr@gmail.com wrote:
On Fri, Feb 3, 2012 at 11:31 AM, Matthew Brush mbrush@codebrainz.ca
wrote:
On 02/01/2012 04:32 PM, Nate Bargmann wrote:
I'm a co-adniminstrator of a SourceForge host project and agree completely about the bug system, or tracker as they call it. We encourage bug reports to be sent to our mailing list, however, that requires the reporter join the list or one of us has to approve the message upon moderation and then remember to CC the reporter unless we get a mail that the reporter joined the list.
-1 to mailing list reporting for the reasons you mentioned, at least
not for
*all* bugs.
Mailing list for all bugs just adds unnecessary clerical effort on the Geany team.
I don't have an answer but would steal any good ideas. :-) Is there a BTS that is easy to use? Debian's system is mostly done via email, at least that has been the extent of my involvement with it as a reporter and on followups. Bugzilla is used by various projects and I find it
to
be so-so. Trac is another.
Having used Bugzilla only as a user, I can say it's easily as bad as
Source
Forge if not worse. I've seen Trac but never used it.
Used Trac a few times, it seems much the same. ie bad
Perhaps the most difficult thing is using the search properly. What I had happen recently was to search the Debian BTS for some key words on an issue I was having. Almost immediately the maintainer merged my report with an older one that described the same problem but used different terminology. Of course the maintainer recognized the similarity and acted on it. Does the SF.net tracker allow merging of reports? I've not checked as it's not something I've had to try and do as we get so few reports in the SF.net tracker.
Agree about searching. Two users experiencing the same issue usually
have a
completely different description, and so searching is often quite hard.
I don't think SF.net does allow merging dupes, and this partially the
reason
I started this thread, because duplicate tracking is stupid on Source
Forge
(unless I just don't know how to use it).
On most of them AFAICT
In a perfect world, each report that was marked as a dupe would
contribute
to keywords for the whole bug
Thats a good idea, now how do we get it implemented?
and before the user submits a new report, it
would search all the items and duplicates and suggest that the user
checks a
handful of similar reports before/during submitting to see if they are duplicates.
Thats more likely to be annoying rather than useful
The issue with a bug tracker is only what software to run, but who to host it. Nobody I know of allows you to run your own tracker software, each free host has its own.
Cheers Lex
Cheers, Matthew Brush
You might consider JIRA, a commercial product of Atlassian. Of course Geany is an open source project and may prefer not to be tied in any way to a company. Atlassian provide hosted instances of JIRA for open source projects, including JBoss. I use it almost daily in my work and find it's a very capable product.
The Frugalware Linux distribution recently changed from using Flyspray to Trac because Flyspray was no longer maintained. Trac seems OK to me as an end user of the product.
Mantis - http://www.mantisbt.org/ - looks good and is seemingly actively developed. According to the blog, it has a phone-optimized interface available which could be a big advantage. The development team could keep their phones by their beds and track bugs as they are reported and respond instantly and easily. :P
Regards,
Russell Dickenson _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Russell Dickenson wrote:
[...] Mantis - http://www.mantisbt.org/ - looks good and is seemingly actively developed. [...]
I don't know how "active" that really is, but it's good old basic PHP on top of MySQL and thus will run pretty much anywhere -- I have it set up on some really cheap hosting for some projects and it basically just works. It doesn't let you merge duplicates, but it's very easy to mark a bug as a duplicate (as well as add relationships to other bugs, and links are as simple as writing #123 in a field to link to bug number 123).
It's ugly, and probably not as flexible as some, but it doesn't ask for much (i.e. hosting support) and is easy to set up.