Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.