say, is there any kind of "method" we should follow when going over people's bug reports, patches, etc? I didn't find anything in the Wiki about it.
1. Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing - someone may come up with a better report in comments.
2. Clarify. If it took you some time to guess what it's about, take another second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it) .
3. Document your solution. When closing a bug as fixed, add a comment about how you did it (especially what files changed and what to look for in these files).
_________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
Could you place this procedure on the wiki...
Jon
On Tue, 2004-04-13 at 19:42, bulia byak wrote:
say, is there any kind of "method" we should follow when going over people's bug reports, patches, etc? I didn't find anything in the Wiki about it.
- Do not close an unreproducible bug unless a reasonable amount of effort
is put into reproducing it, and let it rot for some time before closing - someone may come up with a better report in comments.
- Clarify. If it took you some time to guess what it's about, take another
second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it) .
- Document your solution. When closing a bug as fixed, add a comment about
how you did it (especially what files changed and what to look for in these files).
MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Apr 13, 2004 at 08:03:27PM -0700, Jonathan Phillips wrote:
Could you place this procedure on the wiki...
I've put it here:
http://www.inkscape.org/cgi-bin/wiki.pl?UpdatingTrackerItems
(and now I have to go back and "fix" some of the tracker items I updated...)
On Wed, 14 Apr 2004, bulia byak wrote:
say, is there any kind of "method" we should follow when going over people's bug reports, patches, etc? I didn't find anything in the Wiki about it.
- Do not close an unreproducible bug unless a reasonable amount of effort
is put into reproducing it, and let it rot for some time before closing - someone may come up with a better report in comments.
I think in a few situations we've not been able to recreate the bug, but due to the involved assistance of the user have been able to narrow down and fix the problem, and the user's been able to do the validation.
- Clarify. If it took you some time to guess what it's about, take another
second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it) .
- Document your solution. When closing a bug as fixed, add a comment about
how you did it (especially what files changed and what to look for in these files).
4. Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.
Bryce
participants (4)
-
Bryce Harrington -
bulia byak -
Jonathan Phillips -
Kees Cook