Cleaning bug list

[Joel Madero]

One more thing to add to this. Last night when I did some (I think I did
about 25-50 so it wasn't too many) I was doing the following:

If someone asked "is this reproducible in the latest release", but didn't
say anything else as to if they themselves had tried to reproduce it. I
would mark as NEEDINFO. I think that this is a bad policy as we can't
expect users to constantly come back when a new release is done and update
their bug saying "still an issue".

For these ones I'm going to leave them as UNKNOWN for now, I'll come back
to them once some policy is decided on to handle them. Maybe what I'll do
is at least with the Linux ones I'll try to confirm that the bug still
exists and change status to CONFIRMED, if I am unable to confirm them I'll
post a comment and change them to NEEDINFO.


Joel

On Fri, Jun 8, 2012 at 3:27 AM, Jan Holesovsky <kendy at suse.cz> wrote:

> Hi Joel,
>
> On 2012-06-07 at 23:49 -0700, Joel Madero wrote:
>
> > 1. If there has been a request for information and there has been no
> > response for 30+ days I'm putting NEEDINFO
> >
> > 2. If two or more people have said that they do not have the bug I'm
> > doing the following if there hasn't been action for 30+ days:
> > a. If it's stated that the bug was fixed in a recent release, I'm
> > putting RESOLVED with a comment that if it's not for the author or
> > someone else to open it back up
> > b. If it's stated that it's not our bug I'm changing status to
> > NOTOURBUG
> > c. If it's stated that it never was a bug I'm putting NOTABUG with a
> > comment saying to open it back up with more information if it is a bug
> >
> > 3. If it's confirmed by other people I'm changing it to confirmed
> >
> > 4. Of course I'm taking a glance at them to see if I can take them on,
> > I've assigned two to myself.
> >
> > 5. If someone appears to be working on the bug and has implicitly or
> > explicitly said they are doing it (ie. it's in progress, almost done,
> > "I'll take this one", etc..) I'm changing to assigned and adding a
> > name
>
> Thanks so much for this - this is greatly appreciated!  I like this
> approach, and I'd like to ask you for some additional points that would
> help a lot (if that fits your workflow):
>
> 6. If the bug talks about a misbehavior in a document, but the document
> is missing, NEEDINFO the reporter to provide the document.  Similarly,
> if the bug says something like "create document, do this, do that, do
> another thing, and then when you choose XY, it does AB instead of CD",
> NEEDINFO the reporter to create such a document, so that the developer
> can focus only on "when you choose XY, it does AB instead of CD".
>
> 7. If the bug is a crash on Linux, ask the reporter for a backtrace, if
> it is not provided yet (unfortunately it is still way too hard to get
> the backtrace on Windows now) - ideally by pointing to:
>
>
> http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29
>
> 8. If the bug is a crash, it is a probable candidate to become one of
> the Most Annoying Bugs; depending on the impact, consider making it
> dependant on
>
> https://bugs.freedesktop.org/show_bug.cgi?id=44446
>
> > I hope I'm not overstepping, just trying to help as much as possible
> > as it seems like there is a bit of a back log. If this isn't wanted
> > just let me know and I'll cease immediately.
>
> The opposite - the more people join this effort, the better! :-)  For
> more co-ordination, I am sure people on libreoffice-qa@ mailing list
> (CC'd) will help you.
>
> Thank you a lot,
> Kendy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120608/d9676427/attachment.htm>