Re: [Gramps-devel] Bug Triage

[Benny M. <ben...@gm...>]

2010/9/10 Combs, Matthew Christopher <mc...@ui...>

>  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
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>