Bug Triage
Locked
Bug Triage
 
|
I would like to get started on the Bug Triage work. I've never worked on an Open-Source project before, so the protocols of communication are new to me. Your understanding is appreciated.
I have a few questions:
1. What are the goals for the Bug Triage? What would you like to see accomplished?
2. What is the expected timeline to have the Bug Triage completed?
3. Do you want me to update the Bugs directly? Should I post my thoughts to the list first, then follow through with updating the Bugs?
4. Who should I direct my questions to? The developers list or particular individual(s) off the list?
5. Do I need special credentials to update the Bugs in the Bug Tracking system? If so, who can give me that access?
FYI - there are 1040 bugs with a Hide Status of Resolved (and above) as of today. The oldest is from 11-01-06.
Cheers,
Matt ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Bug Triage
|
2010/9/10 Combs, Matthew Christopher <[hidden email]>
* Reduction of open tickets, removal of stale/out of date tickets, grouping of feature requests.
What is the timeschedule of the assignment? Obviously you are allowed to spend as much time with as you want from our point of view.
Direct updating of the bugs. Send me your account, and I upgrade it so you can update bugs.
Developer list is best. You can also send reminders from the bug tracker. I am bmcage on the tracker. From interaction on the devel list it will become clear who to contact directly for certain type of problems (eg translation for romjerome (Jerome), gramplet problems for dsblank (Doug), ...
I can.
Yes. Note that resolved is good enough, little people take the time to close a bug that is resolved. The best path forward is: 0. make sure you have Gramps installed so you can test bugs and problems. Create a family tree and import the example.gramps file. It would be nice if you can also run the trunk version of gramps so as to test bugs that are in trunk only. 1. read a bit the documentation of mantis so you know what is possible, http://www.mantisbt.org/documentation.php Eg, you can ask me to add a category if you think that would give a better workflow, ... 2. Take a screenshot of the summary info on the tracker with open bugs, ... before you start. Like that you can proof what you did afterwards. 3. At the moment only project gramps 3.2 and gramps trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other: * resolved in the meantime * does not apply anymore * version no longer supported, try with new version * bug/problem still present, move the bug to the correct project (eg it is a feature request * too little information given * several issues in one bug, close it asking users to submit a ticket per issue (or rename the bug for one issue, and ask to create new ones for the other) * ... ALWAYS be polite when doing something to a bug ticket. 4. for the supported projects, the bugs must be triaged: Duplicate bugs closed, set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the example.gramps file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often fast. 5. then there is the feature request project. That must be organised somehow. I think it is best you look at some of those tickets and do a suggestion on how to organize it so that the feature requests remain usefull. Also giving better titles is imporant here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!). Perhaps we can combine this with a wiki page? That should get you started :-) Benny
------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Bug Triage
|
Hello Matt,
>4. for the supported projects, the bugs must be triaged: Duplicate bugs closed, >set a better bug title so it is more clear for a developer what the bug is >about, add extra information. Most important here is to try to duplicate the bug > >with the example.gramps file, as that is what the developer will spend a lot of >time trying to do. Fixing a bug always starts with reproducing it, and many >times the developer does not succeed in that. Making that possible is the aim of > >triage. Once a developer sees a bug in front of him, fixing it is often fast. Just to add to what Benny wrote about bug triage, please read: http://www.gramps-project.org/wiki/index.php?title=How_to_create_a_good_bug_report In an ideal world users would create bug reports with a test case demonstrating exactly how to re-create a bug but often we get bug reports with only basic information which leads to the developer having to spend much time trying to reproduce the issue. A bug cannot be fixed until it can be reproduced on demand. Gramps is a data driven application with the complication that a user's data is usually private and not available to us developers, so we have an example database which comes with every Gramps installation which we use to prepare test cases. If a user can reproduce their issue with the test case then we stand a chance of reproducing it too. When triaging an issue, many times you will find that the real cause of the problem is not actually in the Gramps feature that the user was running. For example a user might report that Gramps crashed when they ran Report X. In fact, the real bug might be somewhere else buried in the code that inserted the data into the database which lead to some data corruption manifesting itself as a crash in Report X. Bye Gary (gburto01 on the bug tracker, though I haven't had enough time to be active in the project for a while) ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
«
Return to GRAMPS - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |