Cleaning bug list

classic Classic list List threaded Threaded
35 messages Options
Next » 12
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Cleaning bug list

Just a heads up to everyone. I'm doing a serious cleaning of bug reports. Changing a lot to NEEDINFO, RESOLVED, etc...We have way too many bugs listed as unknown that haven't been touched in months and have been confirmed to not be an issue or needs updated without updates from original authors of the bugs. Hope no one minds.

Joel

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Rainer Bielefeld-2 Rainer Bielefeld-2
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

Joel Madero schrieb:
> Just a heads up to everyone. I'm doing a serious cleaning of bug
> reports. Changing a lot to NEEDINFO, RESOLVED, etc...We have way too
> many bugs listed as unknown that haven't been touched in months and have
> been confirmed to not be an issue or needs updated without updates from
> original authors of the bugs. Hope no one minds.

Hi Joel,

thank you for your initiative. Can you please present your ideas with
some more details on <[hidden email]>?

Best regards

Rainer Bielefeld

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

Sure thing, I'll include it here and add a link as soon as I post over at freedesktop bugs

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

With thousands of unknown bugs I think that this will help us divvy up the work and prioritize a bit. After I do this phase I'll try to get consensus on how to prioritize. Obviously security bugs and resource leaks get highest, next I'm not sure but we can discuss this after.

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.

Thanks to everyone contributing to this great project.


Joel

On Thu, Jun 7, 2012 at 10:49 PM, Rainer Bielefeld <[hidden email]> wrote:
Joel Madero schrieb:

Just a heads up to everyone. I'm doing a serious cleaning of bug
reports. Changing a lot to NEEDINFO, RESOLVED, etc...We have way too
many bugs listed as unknown that haven't been touched in months and have
been confirmed to not be an issue or needs updated without updates from
original authors of the bugs. Hope no one minds.

Hi Joel,

thank you for your initiative. Can you please present your ideas with some more details on <[hidden email]>?

Best regards

Rainer Bielefeld



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

Hi Joel,

On Thu, 2012-06-07 at 23:49 -0700, Joel Madero wrote:
> Sure thing, I'll include it here and add a link as soon as I post over
> at freedesktop bugs

        This is prolly best on the libreoffice-qa list (I just CC'd it) - but
it's interesting on the hackers list too. Your cleanup sounds most
welcome [ to a non QA expert such as myself at least ] :-)

> With thousands of unknown bugs I think that this will help us divvy up
> the work and prioritize a bit. After I do this phase I'll try to get
> consensus on how to prioritize. Obviously security bugs and resource
> leaks get highest, next I'm not sure but we can discuss this after.

        Wonderful :-)

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

        It's good to have more people getting stuck into the bug cleanup - of
course, worth getting advice / input from Rainer & the -qa list, but it
sounds like you're on a good track to me :-)

> Thanks to everyone contributing to this great project.

        And thank-you ! it's really helpful to have more QA people scanning the
bug lists, confirming bugs & closing old duplicates.

        Having said that, there are thousands of open bugs - my report shows:
2.5k in the 'NEW' state, and 1.5k in the UNCONFIRMED state.

        Fixing 6bugs per day on average, that's a good pipeline of a couple of
years work of fixing ;-) so the prioritisation work is really very
greatly appreciated to ensure we fix the right bugs.

        Thanks !

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
Hi Joel,

On Thu, Jun 07, 2012 at 11:49:52PM -0700, Joel Madero wrote:
> Sure thing, I'll include it here and add a link as soon as I post over at
> freedesktop bugs
> [...]
> 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.
>
> Thanks to everyone contributing to this great project.

/me is overfilled with joy hearing this great news!

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by Jan Holesovsky
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 <[hidden email]> 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



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] Cleaning bug list

On Fri, Jun 08, 2012 at 07:17:51AM -0700, Joel Madero wrote:
> 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".

Given the current workload of both QA and development, I think it is
unavoidable though. That being said it makes little sense to do that for every
minor release -- but asking a reporter to try to reproduce the issue on the
most recent major, if a) there is a chance that is has been fixed, because
there has been work in that area b) or the bug is not trivially reproducable is
reasonable IMHO. After all, new majors only appear once every 6 months, so we
wont spam/frustrate reporters too much.

The alternative would be lots and lots of old bugs piling up, which is also not
a Good Thing(tm).

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
julien2412 julien2412
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
Joel Madero-2 wrote
...
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".
...
Joel
First thank you for your help on bug triaging !

About NEEDINFO, it depends on several things :
- if the bug has been reported on 3.5.0 whereas we're on 3.5.4 it can be justified
- if the bug has been reported on 3.5.3 and you know that some work have been done on 3.5.4 on this area, it can be useful to ask.
In both cases, it depends too if the bug is reproductible easily/quicky.
If a doc is attached and the bug is just :
- open the doc
- click on preview => fails
OK
if you have to :
- recreate a DB with tables
- queries,
- reports
- ...
it's on Mysql or Postgres so you must configure
and that the file can't be attached because data are confidential and can't be purged, it's not the same.

In brief, I understand what you mean on this specific point but it depends on the case.

About cleaning, I noticed 2 or 3 things (at least for crashes/freezes) which help quite often :
- some LO specific extensions (I mean not out of the box extensions)
- a brand new LO profile (of course, they must retrieve in a backup the custom settings) (any env)
- uninstall lo-menubar (Ubuntu, other ?)
- accessibility to disable (MacOs)
I think I already mentioned it but it seems to be still true.
So it could be useful to propose to check these points at the first step of bug submitting (perhaps it already exists and I missed it)

For Windows bugs (crashes/freezes), I propose the "raw method" and sometimes it worked :
- uninstall, clean registry with free tool, remove/backup LO profile, install again.
Of course, it doesn't solve the root cause and I won't propose to quote this on bug submitting. But when we can't reproduce the problem, I keep on proposing it sometimes.

Anyway, really great to have some very useful help on this area :-)

Julien.
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Cleaning bug list

In reply to this post by jmadero
I guess my next question is, if I'm not an "experienced user", can I really be messing with this at all? I think the flow isn't great and it would be much better to have a CONFIRMED status and then for the developers to assign themselves to projects, preferably tackling higher priority bugs first and leaving minor issues (like labels, etc..) to novice programmers to assign to themselves. At best I think that having a "Suggestion" for Assigned to would make sense as it would send an email to the developer who might be willing to handle the bug.

Ultimately I think that developers are capable of going to FDO and assigning bugs to themselves without having to add a middle man to CC them, and them for them to reject the CC, and the process just restart. 

I'm going to continue until someone tells me to stop (I don't believe I'm an experienced user but I do think that I'm more than capable of cleaning this list a lot). 

Joel


On Fri, Jun 8, 2012 at 8:42 AM, Rainer Bielefeld <[hidden email]> wrote:
Joel Madero schrieb:

It would be nice to be able to differentiate for definitely confirmed
bugs even if they haven't been assigned. What does everyone think
about marking as ASSIGNED and leaving the Assigned To as
libreoffice-bugs.


Hi Joel,

I also am not absolutely happy with the current proceeding. In the early times we had it other way round: Experienced users adds a "Friendly Expert" <http://wiki.documentfoundation.org/FindTheExpert> to "Assigned to", and if the developer accepts the Bug be changing Status to ASSIGNED or rejects it by reassigning to list. For me that was fine because it was easy to distinguish Bugs with default "Assigned to" and a developer in that field.

But there has been a decision (2011-September or so)
<https://wiki.documentfoundation.org/RBd/TSC_Call_Minutes#Bug_assignition_by_QA>
to change to the current proceeding: "Friendly Expert" addition to CC.
<https://wiki.documentfoundation.org/QA-FAQ#How_to_assign_a_bug_.28QA_team_only.29>

Best regards

Rainer



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Korrawit Pruegsanusak Korrawit Pruegsanusak
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] Cleaning bug list

Hello Joel, all,

First, a big thank you from me! :-)

On Fri, Jun 8, 2012 at 1:49 PM, Joel Madero <[hidden email]> wrote:
> 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

If there is an explicit fix linked / posted, it's good to use FIXED.
If not, that is the bug is just not reproducible with recent release,
we prefer WORKSFORME instead.

> 3. If it's confirmed by other people I'm changing it to confirmed

Could you please give some details about this "confirmed"? Because we
don't have an explicit "confirmed", we just change UNCONFIRMED to NEW.

Anyway, these process / rules / ... could be changed if / when
appropriate, of course.

And yes, the "we" here is now including you, Joel. :-)

Best Regards,
--
Korrawit Pruegsanusak
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] Cleaning bug list

I just realized that there is no CONFIRMED, I think this would be a helpful classification but if it can't/won't be added then I still feel like we should differentiate confirmed from non confirmed in some manner.

This could be as simple as making it ASSIGNED TO and have it blank or just default libreoffice or some other method. I just think Devs shouldn't be wasting their time going through UNCONFIRMED bugs that more probable than not either a. require more info or b. has already been solved or c. isn't a bug to begin with. 

If one of our team can corroborate that a bug is in fact confirmed I think we should do something to notate it. 

Just my thoughts, as it's really confusing having thousands of UNCONFIRMED bugs when in fact many of them are confirmed, just not assigned.

On Fri, Jun 8, 2012 at 9:14 AM, Korrawit Pruegsanusak <[hidden email]> wrote:
Hello Joel, all,

First, a big thank you from me! :-)

On Fri, Jun 8, 2012 at 1:49 PM, Joel Madero <[hidden email]> wrote:
> 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

If there is an explicit fix linked / posted, it's good to use FIXED.
If not, that is the bug is just not reproducible with recent release,
we prefer WORKSFORME instead.

> 3. If it's confirmed by other people I'm changing it to confirmed

Could you please give some details about this "confirmed"? Because we
don't have an explicit "confirmed", we just change UNCONFIRMED to NEW.

Anyway, these process / rules / ... could be changed if / when
appropriate, of course.

And yes, the "we" here is now including you, Joel. :-)

Best Regards,
--
Korrawit Pruegsanusak


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] Cleaning bug list

In reply to this post by Korrawit Pruegsanusak
Hi,

On Fri, Jun 08, 2012 at 11:14:05PM +0700, Korrawit Pruegsanusak wrote:
> And yes, the "we" here is now including you, Joel. :-)

Apropos: If you are able, it would be great if you could join the next QA call
- it will be on 2012-06-12 14:00 UTC. Some things are easier to coordinate on the
phone ;)

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Petr Mladek Petr Mladek
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
Hi Joel,

your plans are great.

On Thu, 2012-06-07 at 23:49 -0700, Joel Madero wrote:
> With thousands of unknown bugs I think that this will help us divvy up
> the work and prioritize a bit. After I do this phase I'll try to get
> consensus on how to prioritize. Obviously security bugs and resource
> leaks get highest, next I'm not sure but we can discuss this after.

Just a side note. Some proposals of bug priorities were discussed in
another thread, see:

http://lists.freedesktop.org/archives/libreoffice/2012-June/032776.html
http://lists.freedesktop.org/archives/libreoffice/2012-June/033011.html


My opinion is that some prioritization would be highly appreciated.

In each case, we should not fight about each bug. The severity and
priority is just a helper information. It could motivate but it can't
force volunteers to work on the bugs. Too many comments that does not
bring any new information makes bugs less readable and worse to
handle :-)

Thanks for helping with sorting the bugs.


Best Regards,
Petr

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

Sure thing. As soon as I do what I'm considering "Phase 1" (just changing from UNCONFIRMED to NEEDINFO or NOTOURBUG) I'll be moving to the second phase which is to prioritize. I'll bookmark those links, appreciate the heads up. It would be nice if we could get 2-3 people to just pound through them and focus on nothing else until they are done but I know that's wishful thinking. My goal is to do 200 a week, that's still 5 months worth of sorting just for phase 1 :( But, progress is progress and once it's done we'll all be able to tackle these bugs a bit easier.


Joel

P.S. I still really think we need a CONFIRMED status so that devs don't have to look at UNCONFIRMED bugs or at least don't have to always look at them. I've voiced this a few times but I think I may be the only one

On Wed, Jun 13, 2012 at 8:42 AM, Petr Mladek <[hidden email]> wrote:
Hi Joel,

your plans are great.

On Thu, 2012-06-07 at 23:49 -0700, Joel Madero wrote:
> With thousands of unknown bugs I think that this will help us divvy up
> the work and prioritize a bit. After I do this phase I'll try to get
> consensus on how to prioritize. Obviously security bugs and resource
> leaks get highest, next I'm not sure but we can discuss this after.

Just a side note. Some proposals of bug priorities were discussed in
another thread, see:

http://lists.freedesktop.org/archives/libreoffice/2012-June/032776.html
http://lists.freedesktop.org/archives/libreoffice/2012-June/033011.html


My opinion is that some prioritization would be highly appreciated.

In each case, we should not fight about each bug. The severity and
priority is just a helper information. It could motivate but it can't
force volunteers to work on the bugs. Too many comments that does not
bring any new information makes bugs less readable and worse to
handle :-)

Thanks for helping with sorting the bugs.


Best Regards,
Petr



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

I brainstormed a bit today and I came up with this flowchart. Looking
for input. I read through email threads and see that prioritizing bugs
has been an interesting discussion but as of now looks to be pretty
unsettled. I'm going to make a similar chart for myself for setting
bugs status. These kinds of things help me, not sure if they help
others, but if they do, feel free to comment :)

This is meant as a general guideline, possibly to put up on the wiki
for future and current QA/Devs to have a bit of focus. It's NOT meant
to be me forcing everyone to conform as I know that QA requires quite
a bit of discretion.

Thanks to all of you for your continued hard work on this project :)
Joel

On Wed, Jun 13, 2012 at 9:11 AM, Joel Madero <[hidden email]> wrote:

> Sure thing. As soon as I do what I'm considering "Phase 1" (just changing
> from UNCONFIRMED to NEEDINFO or NOTOURBUG) I'll be moving to the second
> phase which is to prioritize. I'll bookmark those links, appreciate the
> heads up. It would be nice if we could get 2-3 people to just pound through
> them and focus on nothing else until they are done but I know that's wishful
> thinking. My goal is to do 200 a week, that's still 5 months worth of
> sorting just for phase 1 :( But, progress is progress and once it's done
> we'll all be able to tackle these bugs a bit easier.
>
>
> Joel
>
> P.S. I still really think we need a CONFIRMED status so that devs don't have
> to look at UNCONFIRMED bugs or at least don't have to always look at them.
> I've voiced this a few times but I think I may be the only one
>
>
> On Wed, Jun 13, 2012 at 8:42 AM, Petr Mladek <[hidden email]> wrote:
>>
>> Hi Joel,
>>
>> your plans are great.
>>
>> On Thu, 2012-06-07 at 23:49 -0700, Joel Madero wrote:
>> > With thousands of unknown bugs I think that this will help us divvy up
>> > the work and prioritize a bit. After I do this phase I'll try to get
>> > consensus on how to prioritize. Obviously security bugs and resource
>> > leaks get highest, next I'm not sure but we can discuss this after.
>>
>> Just a side note. Some proposals of bug priorities were discussed in
>> another thread, see:
>>
>> http://lists.freedesktop.org/archives/libreoffice/2012-June/032776.html
>> http://lists.freedesktop.org/archives/libreoffice/2012-June/033011.html
>>
>>
>> My opinion is that some prioritization would be highly appreciated.
>>
>> In each case, we should not fight about each bug. The severity and
>> priority is just a helper information. It could motivate but it can't
>> force volunteers to work on the bugs. Too many comments that does not
>> bring any new information makes bugs less readable and worse to
>> handle :-)
>>
>> Thanks for helping with sorting the bugs.
>>
>>
>> Best Regards,
>> Petr
>>
>

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Prioritizing Bugs FlowChart.pdf (98K) Download Attachment
Prioritizing Bugs FlowChart.odg (24K) Download Attachment
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

Hi Joel,

On 2012-06-15 at 23:09 -0700, Joel Madero wrote:

> I brainstormed a bit today and I came up with this flowchart. Looking
> for input. I read through email threads and see that prioritizing bugs
> has been an interesting discussion but as of now looks to be pretty
> unsettled. I'm going to make a similar chart for myself for setting
> bugs status. These kinds of things help me, not sure if they help
> others, but if they do, feel free to comment :)

I like it - thanks for that! :-)

> This is meant as a general guideline, possibly to put up on the wiki
> for future and current QA/Devs to have a bit of focus. It's NOT meant
> to be me forcing everyone to conform as I know that QA requires quite
> a bit of discretion.

Yes, it would be great to have that in the Wiki.

Regards,
Kendy

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Petr Mladek Petr Mladek
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
Joel Madero píše v Pá 15. 06. 2012 v 23:09 -0700:
> I brainstormed a bit today and I came up with this flowchart. Looking
> for input. I read through email threads and see that prioritizing bugs
> has been an interesting discussion but as of now looks to be pretty
> unsettled. I'm going to make a similar chart for myself for setting
> bugs status. These kinds of things help me, not sure if they help
> others, but if they do, feel free to comment :)

Cool! I like the logic. Also the flowchart is easier to understand than
any text.

I only miss regressions handling. There were long discussions that
regressions should have higher priority than other bugs. Also we add the
"regression" flag into Whiteboard.

I think how to best handle it in the flow chart. I would add a
subprocess at the end of each way. The question is what to do in this
subprocess. We need to set "regression" in whiteboard. We also would
want to increase the priority or even severity by one level.

> This is meant as a general guideline, possibly to put up on the wiki
> for future and current QA/Devs to have a bit of focus. It's NOT meant
> to be me forcing everyone to conform as I know that QA requires quite
> a bit of discretion.

Sounds great! It is even impossible to use it as a strict rule because
different people might have different opinion about how each function is
important and how many users are affected. We need to add there a text
that people should not fight about the severities and priorities. They
are just helper tools for developers. Each volunteer developers has its
own opinion anyway ;-)

By the way. I wonder how complicated would be to rotate the chart to
have the main questions from top to bottom. You know, it is much easier
to scroll the page up and down using the mouse wheel.

I am looking forward to see it on the wiki.

Thanks a lot for working on this.


Best Regards,
Petr

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Rainer Bielefeld-2 Rainer Bielefeld-2
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

In reply to this post by jmadero
Joel Madero schrieb:
> I brainstormed a bit today and I came up with this flowchart.


Hi Joel,

great to see that all in a chart, your conclusions and definitions seem
plausible.

But the chart also shows the limitations of that concept: It's really
sophisticated, and no developer will sit at his's desk to decide whether
he should fix a Bug with Severity=major and Priority=normal before or
after a bug with  Severity=normal and Priority=high  ;-)

But as you stated, such a chart can give some orientation, and so I
think it should be shown in the Wiki. Not on one of the current existing
Pages like BugTriage or similar, but on a page where should gather
detailed background information what would blow up those pages too much,
but nevertheless are interesting or important to know for all who want
to gain more knowledge concerning th bugfixing, QA or whatever else process.

The question is whether the Priority entry is evaluated by anyone, IMHO
most here see that as a personal statement (of reporter?) concerning
importance of the bug - and ignore it.

Best regards


Rainer
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning bug list

I'll modify the orientation today or tomorrow and try to see where
regression should fit. I think that it has to go in Priority and not in
Severity. As for how devs use it, I agree completely that right now it's
almost useless but maybe if it becomes more uniform and it actually
provides some information as to what the bug is doing....who knows. For
instance for me, at this point my abilities are pretty low so trivial
bugs seem to be the go to...hopefully in the future this changes. As for
users prioritizing themselves, I've (mentioned/suggested/got irritated
with) in comments a couple users setting Severity to Critical for
something as minor as Conditional Formatting, it's almost to the point
that it is useless to "let" the end user categorize their own bugs like
this.

Maybe regression should automatically set Priority to "Highest"
regardless of how many people are affected.

Ok off to work. Glad it at least seems a little useful. I have such
limited experience in programming/programming projects that I just felt
a bit overwhelmed so this helped me quite a bit last night when I was
going through bugs.


Joel

On 06/18/2012 04:21 AM, Rainer Bielefeld wrote:

> Joel Madero schrieb:
>> I brainstormed a bit today and I came up with this flowchart.
>
>
> Hi Joel,
>
> great to see that all in a chart, your conclusions and definitions
> seem plausible.
>
> But the chart also shows the limitations of that concept: It's really
> sophisticated, and no developer will sit at his's desk to decide
> whether he should fix a Bug with Severity=major and Priority=normal
> before or after a bug with  Severity=normal and Priority=high  ;-)
>
> But as you stated, such a chart can give some orientation, and so I
> think it should be shown in the Wiki. Not on one of the current
> existing Pages like BugTriage or similar, but on a page where should
> gather detailed background information what would blow up those pages
> too much, but nevertheless are interesting or important to know for
> all who want to gain more knowledge concerning th bugfixing, QA or
> whatever else process.
>
> The question is whether the Priority entry is evaluated by anyone,
> IMHO most here see that as a personal statement (of reporter?)
> concerning importance of the bug - and ignore it.
>
> Best regards
>
>
> Rainer

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12