Quantcast

Bug Triage

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug Triage

Combs, Matthew Christopher
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug Triage

Benny Malengier


2010/9/10 Combs, Matthew Christopher <[hidden email]>
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?

* Reduction of open tickets, removal of stale/out of date tickets, grouping of feature requests.

 
2.  What is the expected timeline to have the Bug Triage completed?

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.
 
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?
 

Direct updating of the bugs. Send me your account, and I upgrade it so you can update bugs.

4.  Who should I direct my questions to?  The developers list or particular individual(s) off the list?

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), ...
 
5.  Do I need special credentials to update the Bugs in the Bug Tracking system?  If so, who can give me that access?

I can.
 
FYI - 
there are 1040 bugs with a Hide Status of Resolved (and above) as of today.  The oldest is from 11-01-06.

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
 
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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug Triage

Gary Burton
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
Loading...