Re: [Libreoffice-qa] Cleaning bug list
Hi Joel, Joel Madero píše v Út 19. 06. 2012 v 13:36 -0700: I moved this to a new thread because the subject here didn't really accurately portray the direction of the conversation The mail includes many good questions and proposals that might move us forward. I'll try to answer it later this week. Just a hint. In the future, I suggest to do NOT solve too many problems in one mail. Too long mails are discouraging. They are hard to read after few replies. I write such mails from time to time as well and I am always told that they are hard to handle ;-) In addition, I suggest to use formatting using spaces and tabs. Some people use text-only mail clients (pine) and they do not see the bold text :-) Finally, we need to add libreoffice-qa mailing list into CC for replies to the other mail. It is affecting the QA job. but I wanted to say I have uploaded the latest flowchard: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg I wasn't sure how or if I needed a wiki page or if I should just link to the jpg in the Useful Links section of the Bug Triage wiki page. Any thoughts? If you could respond on the other thread (more accurate subject) that would be great, if not here is fine. Thanks all for the input, I think that this is at least a decent start. I would add it instead of http://wiki.documentfoundation.org/BugReport_Details#Severity and add extra step for this into the BugTriage process. I hope that Rainer is not against. Thanks for the nice flowchart and working on triaging the bugs. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Thanks for the advice. I thought I had included the qa list, my mistake. As for the length, I agree and I almost didn't include it but that was an email in response to mine so I felt a bit obligated to respond despite the length. I had another side question, the response to the thread was made here: http://nabble.documentfoundation.org/Cleaning-bug-list-td3988836i20.html#a3991106 I never got an email about the response, instead it was only part of the digest. Is this the norm because the response was made through nabble? I was just lucky that I read the digest and saw that there was a response, otherwise that person would have never heard back from me about all of his concerns. Thanks again for the feedback, I think this topic is about exhausted at least for now. I'll get something up on the site where you suggested as well as a little blurb about it unless Rainer suggests otherwise. Joel On Wed, Jun 20, 2012 at 2:17 AM, Petr Mladek pmla...@suse.cz wrote: Hi Joel, Joel Madero píše v Út 19. 06. 2012 v 13:36 -0700: I moved this to a new thread because the subject here didn't really accurately portray the direction of the conversation The mail includes many good questions and proposals that might move us forward. I'll try to answer it later this week. Just a hint. In the future, I suggest to do NOT solve too many problems in one mail. Too long mails are discouraging. They are hard to read after few replies. I write such mails from time to time as well and I am always told that they are hard to handle ;-) In addition, I suggest to use formatting using spaces and tabs. Some people use text-only mail clients (pine) and they do not see the bold text :-) Finally, we need to add libreoffice-qa mailing list into CC for replies to the other mail. It is affecting the QA job. but I wanted to say I have uploaded the latest flowchard: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg I wasn't sure how or if I needed a wiki page or if I should just link to the jpg in the Useful Links section of the Bug Triage wiki page. Any thoughts? If you could respond on the other thread (more accurate subject) that would be great, if not here is fine. Thanks all for the input, I think that this is at least a decent start. I would add it instead of http://wiki.documentfoundation.org/BugReport_Details#Severity and add extra step for this into the BugTriage process. I hope that Rainer is not against. Thanks for the nice flowchart and working on triaging the bugs. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Joel Madero píše v St 20. 06. 2012 v 08:08 -0700: Thanks for the advice. I thought I had included the qa list, my mistake. As for the length, I agree and I almost didn't include it but that was an email in response to mine so I felt a bit obligated to respond despite the length. If only I had more time to react early in this interesting discussion :-) I had another side question, the response to the thread was made here: http://nabble.documentfoundation.org/Cleaning-bug-list-td3988836i20.html#a3991106 I never got an email about the response, instead it was only part of the digest. Is this the norm because the response was made through nabble? I was just lucky that I read the digest and saw that there was a response, otherwise that person would have never heard back from me about all of his concerns. I see, bfo sent the response only to the mailing list. The problem is that different people has different style in handling mailing lists. I prefer to stay in CC because I monitor mailing lists less frequently. Hence, I keep also other people in CC. I know many other guys that do not want to get mails twice (from mailing list and from CC), so they remove themselves and all other people from CC. I am afraid that we can't do much about it. Both approaches have some advantages :-) Thanks again for the feedback, I think this topic is about exhausted at least for now. I'll get something up on the site where you suggested as well as a little blurb about it unless Rainer suggests otherwise. Yup, I need to do some other work as well. I have spent too much time with mails the previous two days ;-) Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] 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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] 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 doingwho 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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Rainer Bielefeld píše v Po 18. 06. 2012 v 13:21 +0200: 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 ;-) You are right, developers will not strictly follow the severity and priority. On the other hand, they care of the usability of the application. They are actively working on the most annoying bugs. They prioritize bugs themselves, so why not help them. Note that MAB is only a workaround because all the other bugs are not prioritized. I think that it is hard job to prioritize all bugs. It will cause some troubles because different people might have different opinions. Though, I think that we should try it. 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. You are right that we need to keep the bugtriage page easy to do not scare people. It would make sense to describe the prioritization on extra page and just link it from the BugTriage page. BTW: Recently someone said that the Bugtriage page was not easy to understand (state CONFIRMED). I think that some people might prefer the graphics flow chart over the text. It would be nice to have similar flow chart also for the overall bugtriage 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. Good question. My opinion is: + severity defines how much a bug affect the functionality + priority defines order in which it should be fixed It means that, some feature might have higher priority because of marketing reasons. Also some less severe bug might have higher priority because it affects many users. Hmm, when I think about it, I would propose another prioritization: 1. Define severity by symptoms. + this is well handled in the flow chart. + alternative proposal is at at http://wiki.documentfoundation.org/BugReport_Details#Severity is reasonable. + I think that they both describe the same things different way. I do not have any strong opinion what formulation is easier to understand. We would need feedback from more people ;-) 2. Define priority more clever way: + the default priority should basically follow the severity; it means that critical bugs should have high priority, ... + the number of affected users and visibility should shift it higher or lower, though + it is already somehow handled in the flowchart. Well, I would, allow to skip even more levels. For example, typo in the main menu is minor bug but it might have even highest priority. Such bug in final release would look amateurish and would bring bad feeling from users. Hmm, I am not sure how to effectively describe it in the flowchart. + with this logic, the bugs with the high and highest priority should be mentioned in MAB. + anyway, developers should have the final word about priorities (for assigned bugs); they might want to organize their daily work by it Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Joel Madero píše v Po 18. 06. 2012 v 09:32 -0700: Version 2, changed orientation and tried to take comments into account. Let me know what you all think. It is much better readable. I finally got a better picture :-) Well, I think that it still need some thinking. You set inability to safe as major. I think that it should be blocker. The application would be almost useless with this bug ;-) I suggest the following changes in the top levels: Q: Does bug cause crash, loss of data[*], inability to install, broken core function, e.g. inability to safe any writer documents, print? + A: yes: = Q: Does it affect almost all users within everyday usage and is it a regression? + A: yes = blocker, highest, MAB + A: no = critical, high, MAB I would leave the + A: no = Q: Does bug involve a serious glitch such as tediously slow, inability to open particular documents, install some extensions, print on some printers? + A: yes: = major, high IMHO, the rest might stay as is. Well, it would be great to create several examples also for the other categories. I do not have power to invent them now, though ;-) [*] Note that data loss might be caused by incomplete import. If it is not a regression, it might be marked by developers as an enhancement. Note that it needs many developer/years to support some file formats. OOXML format is described on several thousands of pages... I am very happy with the progress and the state. Thanks a lot for working on it. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
I agree with the save comment, I'll change that right now. Also realized I didn't put a note in for regressions so I added to the bottom notes: **Regressions** Special attention should be paid to regressions. In most cases a regression calls for an increase in priority but in some cases it will not. If the regression is not elevated to a higher priority, a comment may be useful to explain why this decision was made Joel On Mon, Jun 18, 2012 at 10:54 AM, Petr Mladek pmla...@suse.cz wrote: Joel Madero píše v Po 18. 06. 2012 v 09:32 -0700: Version 2, changed orientation and tried to take comments into account. Let me know what you all think. It is much better readable. I finally got a better picture :-) Well, I think that it still need some thinking. You set inability to safe as major. I think that it should be blocker. The application would be almost useless with this bug ;-) I suggest the following changes in the top levels: Q: Does bug cause crash, loss of data[*], inability to install, broken core function, e.g. inability to safe any writer documents, print? + A: yes: = Q: Does it affect almost all users within everyday usage and is it a regression? + A: yes = blocker, highest, MAB + A: no = critical, high, MAB I would leave the + A: no = Q: Does bug involve a serious glitch such as tediously slow, inability to open particular documents, install some extensions, print on some printers? + A: yes: = major, high IMHO, the rest might stay as is. Well, it would be great to create several examples also for the other categories. I do not have power to invent them now, though ;-) [*] Note that data loss might be caused by incomplete import. If it is not a regression, it might be marked by developers as an enhancement. Note that it needs many developer/years to support some file formats. OOXML format is described on several thousands of pages... I am very happy with the progress and the state. Thanks a lot for working on it. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Hello, may I suggest that this list of eight important points of consideration should be included in this http://wiki.documentfoundation.org/BugTriage page? For me it would be great if I could have an authorative advise about how to deal with open bugs... Greetings, Marc Am 08.06.2012 12:27, schrieb Jan Holesovsky: 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=6 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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] 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. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
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=6 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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
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 ke...@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=6 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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
