Re: Triage Project Update
Hi Nino, That's the beauty of our project, everyone's opinion is respected :) I'll try to avoid adding any work to website team and see what method works best to get these triaged and organized best. As of now, google doc + fdo seems to be doing the trick :) Ultimately might just make a macro to auto sort them once every other week to keep the google doc updated until the project is done (ie. getting all bugs 30 days old triaged so we can try to stick with a goal of triaging withing 30 days for new bugs). Thanks for all the valuable input. Best Regards, Joel On Tue, Sep 4, 2012 at 3:07 PM, Nino Novak nn.l...@kflog.org wrote: Am 04.09.2012 23:05 schrieb Joel Madero: I agree that FDO has some benefits but the limitation is really that each user is needed to query every time, the possibility of overlap is great, and no one is really responsible for an individual bug until the query is made and someone takes the time to look into it. I'm not sure if others would agree but it seems like having a group of 50 or so and being able to just do those at your convenience makes people more likely to help and feel like their is an end in sight for their portion. This is vs. just seeing a never ending list from FDO or even having to teach new users (or even not new users) exactly what to search for every time with FDO. As for me (a rather unexperienced QA Newbie), I've chosen a somewhat different approach: I've first created two custom searches, 1) all recent bugs (reported within the last two days) for curiosity (just to see what people report recently) 2) all UNCONFIRMED bugs from the last 14 days From query 2 I picked a couple of bugs every couple of days to reproduce/confirm/assign/close/whatever seemed appropriate. That's just to show a slightly different approach, which is rather simple and can be handled perfectly within bugzilla itself without any external tool. Ok, the only problem was, that when a person starts reproducing a bug, it can happen, that another triager just starts with the very same bug at the same time. So some kind of lock signal was the only missing thing to prevent duplication of work. However, this situation did not happen a single time during my self-chosen BugReviewWeek ;-) Another advantage: By the above process nobody (virtually) blocks 50 bugs for a longer time period. Bugzilla queries are very adequate at every time, as all works with live data. Similar to how developers assign themselves bugs and then can just go look at their own bugs (My Bugs) it would be nice to have this ability for QA triagers but have it somewhat automated since it's just triaging, not programming. In the long run (once we're through the back log of 650+ that are really old), it would be amazing if we had a team of QA staff that signed up to have bugs auto assigned to them for triaging. We have the libreoffice-bugs@fdo mailing list, which contains (nearly?) every new bug. Could we use it somehow for this purpose? E.g. by replying to a bug or forwarding it to the qa list or some such? (Just thoughts, nothing concrete) What I imagine: QA triagers sign up for components they are willing to triage and their max load New bug is reported, if the bug has a component listed the bug gets auto assigned for triaging purposes according to some rule(s) Personally, I prefer not to sign up for a special component but to pick a recent bug which kind of attracts me spontanously. But there might be other opinions/preferences/arguments/approaches. For now the google docs works, FDO does not as it is now but I'll discuss this further with Bjoern, Petr Rainer to see if we can come up with something more functional than the chaos that is FDO :) Or maybe I'm just not familiar enough with FDO to really feel comfortable myself with it, this is more likely than not true :) :-) I like your initiative. Please don't feel discouraged by my comments, I just wanted to add a slightly different view. If people like your approach, that's great! It does not contradict to mine (IMHO), as it's rather obvious if a bug has been triaged or not. So we can all work together towards our common goal. Regards, Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Triage Project Update
Hi Nino, That's the beauty of our project, everyone's opinion is respected :) I'll try to avoid adding any work to website team and see what method works best to get these triaged and organized best. As of now, google doc + fdo seems to be doing the trick :) Ultimately might just make a macro to auto sort them once every other week to keep the google doc updated until the project is done (ie. getting all bugs 30 days old triaged so we can try to stick with a goal of triaging withing 30 days for new bugs). Thanks for all the valuable input. Best Regards, Joel On Tue, Sep 4, 2012 at 3:07 PM, Nino Novak nn.l...@kflog.org wrote: Am 04.09.2012 23:05 schrieb Joel Madero: I agree that FDO has some benefits but the limitation is really that each user is needed to query every time, the possibility of overlap is great, and no one is really responsible for an individual bug until the query is made and someone takes the time to look into it. I'm not sure if others would agree but it seems like having a group of 50 or so and being able to just do those at your convenience makes people more likely to help and feel like their is an end in sight for their portion. This is vs. just seeing a never ending list from FDO or even having to teach new users (or even not new users) exactly what to search for every time with FDO. As for me (a rather unexperienced QA Newbie), I've chosen a somewhat different approach: I've first created two custom searches, 1) all recent bugs (reported within the last two days) for curiosity (just to see what people report recently) 2) all UNCONFIRMED bugs from the last 14 days From query 2 I picked a couple of bugs every couple of days to reproduce/confirm/assign/close/whatever seemed appropriate. That's just to show a slightly different approach, which is rather simple and can be handled perfectly within bugzilla itself without any external tool. Ok, the only problem was, that when a person starts reproducing a bug, it can happen, that another triager just starts with the very same bug at the same time. So some kind of lock signal was the only missing thing to prevent duplication of work. However, this situation did not happen a single time during my self-chosen BugReviewWeek ;-) Another advantage: By the above process nobody (virtually) blocks 50 bugs for a longer time period. Bugzilla queries are very adequate at every time, as all works with live data. Similar to how developers assign themselves bugs and then can just go look at their own bugs (My Bugs) it would be nice to have this ability for QA triagers but have it somewhat automated since it's just triaging, not programming. In the long run (once we're through the back log of 650+ that are really old), it would be amazing if we had a team of QA staff that signed up to have bugs auto assigned to them for triaging. We have the libreoffice-bugs@fdo mailing list, which contains (nearly?) every new bug. Could we use it somehow for this purpose? E.g. by replying to a bug or forwarding it to the qa list or some such? (Just thoughts, nothing concrete) What I imagine: QA triagers sign up for components they are willing to triage and their max load New bug is reported, if the bug has a component listed the bug gets auto assigned for triaging purposes according to some rule(s) Personally, I prefer not to sign up for a special component but to pick a recent bug which kind of attracts me spontanously. But there might be other opinions/preferences/arguments/approaches. For now the google docs works, FDO does not as it is now but I'll discuss this further with Bjoern, Petr Rainer to see if we can come up with something more functional than the chaos that is FDO :) Or maybe I'm just not familiar enough with FDO to really feel comfortable myself with it, this is more likely than not true :) :-) I like your initiative. Please don't feel discouraged by my comments, I just wanted to add a slightly different view. If people like your approach, that's great! It does not contradict to mine (IMHO), as it's rather obvious if a bug has been triaged or not. So we can all work together towards our common goal. Regards, Nino ___ 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: Triage Project Update
Hi All, I have done a complete update of the google document, this being said, if you named a sheet to your name, it's gone. Noel pointed out that a lot of the bugs on the sheet were already triaged so I just started from scratch. I'm still hoping the web team can help us move this away from google docs and get it automated a bit but for now, it is what it is. Please go back to the link: https://docs.google.com/spreadsheet/ccc?key=0ApS-XtOUGGH5dDIwaXN1YnNsM0h4RXFKdVhvb2RRb0E#gid=75 Choose a sheet, and continue doing the great work. Here are the #'s as they stand now: *We are down to 893 bugs that are = 30 days in unconfirmed status. If we can get just a few more people to dedicate a bit of time we can be caught up for our back log and hopefully set a goal (I think all bugs should be triaged in 30 days, but if that's not possible most should be 60).* * * Thanks Noel for pointing out that they were really out of date, just shows how much time people are spending getting this project done. I'll update every 1-2 weeks, during which time I will set the sheet as private so it'll boot you out if you're working on it (sorry, no other way really). Lastly, there are certain sections which only have a few bugs, if someone(s) can take these and just get them off the list that would be great. These sections are: Chart Contrib Documentation Extensions Filters Storage Formula Editor Framework Graphics Stack Linguistics Localization Printing PDF Export SDK WWW Some of these only have 1-5 bugs to triage. It'll make my job easier in a couple weeks if these are dealt with -- otherwise I have to filter out and create the sheets and what not. Thanks again everyone, great work Best Regards, Joel On Wed, Aug 29, 2012 at 10:10 PM, Joel Madero jmadero@gmail.com wrote: Math was off for averages ;) still doing a good job everyone. On Aug 29, 2012 9:40 PM, Joel Madero jmadero@gmail.com wrote: Well we're 24 days into the project and there is mostly good news (although some bad news is there as well). So bad news first. Overall we're down only about 200 or so bugs in 24 days. This takes into account the new bugs since 8/5 that have been filed which has been a lot. This is also good news as it means our user base is growing and taking an interest in reporting. On to the good news: Start Date: 8/5/2012 Days Since Start: 24 Bugs Triaged: 568! (way to go everyone, I know a lot of these are in NEEDINFO statusbut it's still means we touched the bug which is the goal, letting our users know we care :) ) Some other good news: Average Length of Time Since Last Action: 66 days (prior to project start # was 89) Median Length of Time Since Last Action: 56 days (prior to project start # was 85) These are all incredibly good. Congrats to everyone working on this project, I think we can meet some reasonable goals by the end of the year and work on starting new projects once this back log is finally taken care of. Best Regards, Joel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Triage Project Update
Hi Joel, Am 04.09.2012 19:18 schrieb Joel Madero: I have done a complete update of the google document, this being said, if you named a sheet to your name, it's gone. Noel pointed out that a lot of the bugs on the sheet were already triaged so I just started from scratch. I'm still hoping the web team can help us move this away from google docs and get it automated a bit but for now, it is what it is. I'm not sure to understand what you want to have automated, could you elaborate just a little bit (or - if you have done so already - point me to the archived mail)? Thanks, Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Triage Project Update
Basically it would be really nice to be able to group and assign bugs the way that the document does. I think bugs are much more manageable this way and we've seen a relative spike in QA triaging activity since starting the process this way. Not sure if you looked at the document but it's basically manual everything, I download FDO bugs to Calc, group them based on Component, then manually copy and paste into groupings of no more than 50. It would be incredibly nice to have the list updated automatically based on FDO, group the bugs based on component and then group each of those to a max of 50 bugs per group. If each group of 50 could then be assigned to a user it would be easy for members of QA to get involved with this project and get this back log taken care of. I'm not sure if this is possible or incredibly time consuming (if it is, probably not worth it). It would be even better if we, as the QA team could do a custom group and then it could assign us bugs based on that. For instance, I'm a QA member and I want to do 20 bugs that are either Writer, Calc or Presentation, and I want the oldest bugs (in terms of those that have been left UNCONFIRMED for the longest period of time). It could then give me the list and allow me to assign myself to the group, and thus prevent other QA members from getting those bugs in their list when they do a custom search. Sorry I felt like that was a bit of rambling, let me know if you need it clarified, I can hardly understand it myself ;) Best Regards, Joel On Tue, Sep 4, 2012 at 12:34 PM, Nino Novak nn.l...@kflog.org wrote: Hi Joel, Am 04.09.2012 19:18 schrieb Joel Madero: I have done a complete update of the google document, this being said, if you named a sheet to your name, it's gone. Noel pointed out that a lot of the bugs on the sheet were already triaged so I just started from scratch. I'm still hoping the web team can help us move this away from google docs and get it automated a bit but for now, it is what it is. I'm not sure to understand what you want to have automated, could you elaborate just a little bit (or - if you have done so already - point me to the archived mail)? Thanks, Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Triage Project Update
Am 04.09.2012 21:52 schrieb Joel Madero: Basically it would be really nice to be able to group and assign bugs the way that the document does. I think bugs are much more manageable this way and we've seen a relative spike in QA triaging activity since starting the process this way. Ok, I see: it makes the process a bit more transparent/obvious. And thus is more pleasant and possibly invites more contributors. Not sure if you looked at the document but it's basically manual everything, I looked at it but could not see what is so special with it... I'll try to compare (please comment if you find this inadequate): I download FDO bugs to Calc, group them based on Component, can be done by a bugzilla query then manually copy and paste into groupings of no more than 50. (is this really that important? for crowdsourcing, it might suffice to do coordination by e-mail) It would be incredibly nice to have the list updated automatically based on FDO, group the bugs based on component and then group each of those to a max of 50 bugs per group. if it's a live query, it's current every time you run it If each group of 50 could then be assigned to a user it would be easy for members of QA to get involved with this project and get this back log taken care of. Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it so important? Couldn't we use e.g. time periods (weeks or months) to group the bugs? Then the number would not be constant but who cares? I'm not sure if this is possible or incredibly time consuming (if it is, probably not worth it). I don't know either but wanted to understand what exactly is needed and if it's possible to find (slightly) different solutions which can be implemented more quickly (or are already existing but not thought of) It would be even better if we, as the QA team could do a custom group and then it could assign us bugs based on that. For instance, I'm a QA member and I want to do 20 bugs that are either Writer, Calc or Presentation, and I want the oldest bugs (in terms of those that have been left UNCONFIRMED for the longest period of time). It could then give me the list and allow me to assign myself to the group, and thus prevent other QA members from getting those bugs in their list when they do a custom search. There is a QA Contact field which has not been used extensively (at least according to my recent search). Could it be used for this purpose? (Rainer? Björn?) Sorry I felt like that was a bit of rambling, let me know if you need it clarified, I can hardly understand it myself ;) So let me be a bit of a devil's advocate, aka clarification helper :-) (I've been working in a project as QA helper years ago for several months, they used excel sheets, so I think I understand the need to master the bugs, and to make the processes transparent and obvious. And thus lower the entry barrier for noobs, too btw.) So my present guess would be: - asking for a web tool is ok but - if there's no better tools ATM, let's stay with google docs for the time coming - but let's also try to use bugzilla itself as much as possible - we have also the wiki, but I do not see much advantage of using it compared to a google spreadsheet as it does not support storing/handling structured data. But it's a web, so we can document all processes nicely and link the documents in the wiki. Regards, Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Triage Project Update
I agree that FDO has some benefits but the limitation is really that each user is needed to query every time, the possibility of overlap is great, and no one is really responsible for an individual bug until the query is made and someone takes the time to look into it. I'm not sure if others would agree but it seems like having a group of 50 or so and being able to just do those at your convenience makes people more likely to help and feel like their is an end in sight for their portion. This is vs. just seeing a never ending list from FDO or even having to teach new users (or even not new users) exactly what to search for every time with FDO. Similar to how developers assign themselves bugs and then can just go look at their own bugs (My Bugs) it would be nice to have this ability for QA triagers but have it somewhat automated since it's just triaging, not programming. In the long run (once we're through the back log of 650+ that are really old), it would be amazing if we had a team of QA staff that signed up to have bugs auto assigned to them for triaging. What I imagine: QA triagers sign up for components they are willing to triage and their max load New bug is reported, if the bug has a component listed the bug gets auto assigned for triaging purposes according to some rule(s) For now the google docs works, FDO does not as it is now but I'll discuss this further with Bjoern, Petr Rainer to see if we can come up with something more functional than the chaos that is FDO :) Or maybe I'm just not familiar enough with FDO to really feel comfortable myself with it, this is more likely than not true :) Best Regards, Joel On 09/04/2012 01:53 PM, Nino Novak wrote: Am 04.09.2012 21:52 schrieb Joel Madero: Basically it would be really nice to be able to group and assign bugs the way that the document does. I think bugs are much more manageable this way and we've seen a relative spike in QA triaging activity since starting the process this way. Ok, I see: it makes the process a bit more transparent/obvious. And thus is more pleasant and possibly invites more contributors. Not sure if you looked at the document but it's basically manual everything, I looked at it but could not see what is so special with it... I'll try to compare (please comment if you find this inadequate): I download FDO bugs to Calc, group them based on Component, can be done by a bugzilla query then manually copy and paste into groupings of no more than 50. (is this really that important? for crowdsourcing, it might suffice to do coordination by e-mail) It would be incredibly nice to have the list updated automatically based on FDO, group the bugs based on component and then group each of those to a max of 50 bugs per group. if it's a live query, it's current every time you run it If each group of 50 could then be assigned to a user it would be easy for members of QA to get involved with this project and get this back log taken care of. Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it so important? Couldn't we use e.g. time periods (weeks or months) to group the bugs? Then the number would not be constant but who cares? I'm not sure if this is possible or incredibly time consuming (if it is, probably not worth it). I don't know either but wanted to understand what exactly is needed and if it's possible to find (slightly) different solutions which can be implemented more quickly (or are already existing but not thought of) It would be even better if we, as the QA team could do a custom group and then it could assign us bugs based on that. For instance, I'm a QA member and I want to do 20 bugs that are either Writer, Calc or Presentation, and I want the oldest bugs (in terms of those that have been left UNCONFIRMED for the longest period of time). It could then give me the list and allow me to assign myself to the group, and thus prevent other QA members from getting those bugs in their list when they do a custom search. There is a QA Contact field which has not been used extensively (at least according to my recent search). Could it be used for this purpose? (Rainer? Björn?) Sorry I felt like that was a bit of rambling, let me know if you need it clarified, I can hardly understand it myself ;) So let me be a bit of a devil's advocate, aka clarification helper :-) (I've been working in a project as QA helper years ago for several months, they used excel sheets, so I think I understand the need to master the bugs, and to make the processes transparent and obvious. And thus lower the entry barrier for noobs, too btw.) So my present guess would be: - asking for a web tool is ok but - if there's no better tools ATM, let's stay with google docs for the time coming - but let's also try to use bugzilla itself as much as possible - we have also the wiki, but I do not see much advantage of using it compared to a google spreadsheet as it
Re: Triage Project Update
Am 04.09.2012 23:05 schrieb Joel Madero: I agree that FDO has some benefits but the limitation is really that each user is needed to query every time, the possibility of overlap is great, and no one is really responsible for an individual bug until the query is made and someone takes the time to look into it. I'm not sure if others would agree but it seems like having a group of 50 or so and being able to just do those at your convenience makes people more likely to help and feel like their is an end in sight for their portion. This is vs. just seeing a never ending list from FDO or even having to teach new users (or even not new users) exactly what to search for every time with FDO. As for me (a rather unexperienced QA Newbie), I've chosen a somewhat different approach: I've first created two custom searches, 1) all recent bugs (reported within the last two days) for curiosity (just to see what people report recently) 2) all UNCONFIRMED bugs from the last 14 days From query 2 I picked a couple of bugs every couple of days to reproduce/confirm/assign/close/whatever seemed appropriate. That's just to show a slightly different approach, which is rather simple and can be handled perfectly within bugzilla itself without any external tool. Ok, the only problem was, that when a person starts reproducing a bug, it can happen, that another triager just starts with the very same bug at the same time. So some kind of lock signal was the only missing thing to prevent duplication of work. However, this situation did not happen a single time during my self-chosen BugReviewWeek ;-) Another advantage: By the above process nobody (virtually) blocks 50 bugs for a longer time period. Bugzilla queries are very adequate at every time, as all works with live data. Similar to how developers assign themselves bugs and then can just go look at their own bugs (My Bugs) it would be nice to have this ability for QA triagers but have it somewhat automated since it's just triaging, not programming. In the long run (once we're through the back log of 650+ that are really old), it would be amazing if we had a team of QA staff that signed up to have bugs auto assigned to them for triaging. We have the libreoffice-bugs@fdo mailing list, which contains (nearly?) every new bug. Could we use it somehow for this purpose? E.g. by replying to a bug or forwarding it to the qa list or some such? (Just thoughts, nothing concrete) What I imagine: QA triagers sign up for components they are willing to triage and their max load New bug is reported, if the bug has a component listed the bug gets auto assigned for triaging purposes according to some rule(s) Personally, I prefer not to sign up for a special component but to pick a recent bug which kind of attracts me spontanously. But there might be other opinions/preferences/arguments/approaches. For now the google docs works, FDO does not as it is now but I'll discuss this further with Bjoern, Petr Rainer to see if we can come up with something more functional than the chaos that is FDO :) Or maybe I'm just not familiar enough with FDO to really feel comfortable myself with it, this is more likely than not true :) :-) I like your initiative. Please don't feel discouraged by my comments, I just wanted to add a slightly different view. If people like your approach, that's great! It does not contradict to mine (IMHO), as it's rather obvious if a bug has been triaged or not. So we can all work together towards our common goal. Regards, Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Triage Project Update
Hi Joel, Am 04.09.2012 19:18 schrieb Joel Madero: I have done a complete update of the google document, this being said, if you named a sheet to your name, it's gone. Noel pointed out that a lot of the bugs on the sheet were already triaged so I just started from scratch. I'm still hoping the web team can help us move this away from google docs and get it automated a bit but for now, it is what it is. I'm not sure to understand what you want to have automated, could you elaborate just a little bit (or - if you have done so already - point me to the archived mail)? Thanks, Nino ___ 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] Triage Project Update
Am 04.09.2012 21:52 schrieb Joel Madero: Basically it would be really nice to be able to group and assign bugs the way that the document does. I think bugs are much more manageable this way and we've seen a relative spike in QA triaging activity since starting the process this way. Ok, I see: it makes the process a bit more transparent/obvious. And thus is more pleasant and possibly invites more contributors. Not sure if you looked at the document but it's basically manual everything, I looked at it but could not see what is so special with it... I'll try to compare (please comment if you find this inadequate): I download FDO bugs to Calc, group them based on Component, can be done by a bugzilla query then manually copy and paste into groupings of no more than 50. (is this really that important? for crowdsourcing, it might suffice to do coordination by e-mail) It would be incredibly nice to have the list updated automatically based on FDO, group the bugs based on component and then group each of those to a max of 50 bugs per group. if it's a live query, it's current every time you run it If each group of 50 could then be assigned to a user it would be easy for members of QA to get involved with this project and get this back log taken care of. Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it so important? Couldn't we use e.g. time periods (weeks or months) to group the bugs? Then the number would not be constant but who cares? I'm not sure if this is possible or incredibly time consuming (if it is, probably not worth it). I don't know either but wanted to understand what exactly is needed and if it's possible to find (slightly) different solutions which can be implemented more quickly (or are already existing but not thought of) It would be even better if we, as the QA team could do a custom group and then it could assign us bugs based on that. For instance, I'm a QA member and I want to do 20 bugs that are either Writer, Calc or Presentation, and I want the oldest bugs (in terms of those that have been left UNCONFIRMED for the longest period of time). It could then give me the list and allow me to assign myself to the group, and thus prevent other QA members from getting those bugs in their list when they do a custom search. There is a QA Contact field which has not been used extensively (at least according to my recent search). Could it be used for this purpose? (Rainer? Björn?) Sorry I felt like that was a bit of rambling, let me know if you need it clarified, I can hardly understand it myself ;) So let me be a bit of a devil's advocate, aka clarification helper :-) (I've been working in a project as QA helper years ago for several months, they used excel sheets, so I think I understand the need to master the bugs, and to make the processes transparent and obvious. And thus lower the entry barrier for noobs, too btw.) So my present guess would be: - asking for a web tool is ok but - if there's no better tools ATM, let's stay with google docs for the time coming - but let's also try to use bugzilla itself as much as possible - we have also the wiki, but I do not see much advantage of using it compared to a google spreadsheet as it does not support storing/handling structured data. But it's a web, so we can document all processes nicely and link the documents in the wiki. Regards, Nino ___ 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] Triage Project Update
I agree that FDO has some benefits but the limitation is really that each user is needed to query every time, the possibility of overlap is great, and no one is really responsible for an individual bug until the query is made and someone takes the time to look into it. I'm not sure if others would agree but it seems like having a group of 50 or so and being able to just do those at your convenience makes people more likely to help and feel like their is an end in sight for their portion. This is vs. just seeing a never ending list from FDO or even having to teach new users (or even not new users) exactly what to search for every time with FDO. Similar to how developers assign themselves bugs and then can just go look at their own bugs (My Bugs) it would be nice to have this ability for QA triagers but have it somewhat automated since it's just triaging, not programming. In the long run (once we're through the back log of 650+ that are really old), it would be amazing if we had a team of QA staff that signed up to have bugs auto assigned to them for triaging. What I imagine: QA triagers sign up for components they are willing to triage and their max load New bug is reported, if the bug has a component listed the bug gets auto assigned for triaging purposes according to some rule(s) For now the google docs works, FDO does not as it is now but I'll discuss this further with Bjoern, Petr Rainer to see if we can come up with something more functional than the chaos that is FDO :) Or maybe I'm just not familiar enough with FDO to really feel comfortable myself with it, this is more likely than not true :) Best Regards, Joel On 09/04/2012 01:53 PM, Nino Novak wrote: Am 04.09.2012 21:52 schrieb Joel Madero: Basically it would be really nice to be able to group and assign bugs the way that the document does. I think bugs are much more manageable this way and we've seen a relative spike in QA triaging activity since starting the process this way. Ok, I see: it makes the process a bit more transparent/obvious. And thus is more pleasant and possibly invites more contributors. Not sure if you looked at the document but it's basically manual everything, I looked at it but could not see what is so special with it... I'll try to compare (please comment if you find this inadequate): I download FDO bugs to Calc, group them based on Component, can be done by a bugzilla query then manually copy and paste into groupings of no more than 50. (is this really that important? for crowdsourcing, it might suffice to do coordination by e-mail) It would be incredibly nice to have the list updated automatically based on FDO, group the bugs based on component and then group each of those to a max of 50 bugs per group. if it's a live query, it's current every time you run it If each group of 50 could then be assigned to a user it would be easy for members of QA to get involved with this project and get this back log taken care of. Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it so important? Couldn't we use e.g. time periods (weeks or months) to group the bugs? Then the number would not be constant but who cares? I'm not sure if this is possible or incredibly time consuming (if it is, probably not worth it). I don't know either but wanted to understand what exactly is needed and if it's possible to find (slightly) different solutions which can be implemented more quickly (or are already existing but not thought of) It would be even better if we, as the QA team could do a custom group and then it could assign us bugs based on that. For instance, I'm a QA member and I want to do 20 bugs that are either Writer, Calc or Presentation, and I want the oldest bugs (in terms of those that have been left UNCONFIRMED for the longest period of time). It could then give me the list and allow me to assign myself to the group, and thus prevent other QA members from getting those bugs in their list when they do a custom search. There is a QA Contact field which has not been used extensively (at least according to my recent search). Could it be used for this purpose? (Rainer? Björn?) Sorry I felt like that was a bit of rambling, let me know if you need it clarified, I can hardly understand it myself ;) So let me be a bit of a devil's advocate, aka clarification helper :-) (I've been working in a project as QA helper years ago for several months, they used excel sheets, so I think I understand the need to master the bugs, and to make the processes transparent and obvious. And thus lower the entry barrier for noobs, too btw.) So my present guess would be: - asking for a web tool is ok but - if there's no better tools ATM, let's stay with google docs for the time coming - but let's also try to use bugzilla itself as much as possible - we have also the wiki, but I do not see much advantage of using it compared to a google spreadsheet as it
Triage Project Update
Well we're 24 days into the project and there is mostly good news (although some bad news is there as well). So bad news first. Overall we're down only about 200 or so bugs in 24 days. This takes into account the new bugs since 8/5 that have been filed which has been a lot. This is also good news as it means our user base is growing and taking an interest in reporting. On to the good news: Start Date: 8/5/2012 Days Since Start: 24 Bugs Triaged: 568! (way to go everyone, I know a lot of these are in NEEDINFO statusbut it's still means we touched the bug which is the goal, letting our users know we care :) ) Some other good news: Average Length of Time Since Last Action: 66 days (prior to project start # was 89) Median Length of Time Since Last Action: 56 days (prior to project start # was 85) These are all incredibly good. Congrats to everyone working on this project, I think we can meet some reasonable goals by the end of the year and work on starting new projects once this back log is finally taken care of. Best Regards, Joel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Triage Project Update
Math was off for averages ;) still doing a good job everyone. On Aug 29, 2012 9:40 PM, Joel Madero jmadero@gmail.com wrote: Well we're 24 days into the project and there is mostly good news (although some bad news is there as well). So bad news first. Overall we're down only about 200 or so bugs in 24 days. This takes into account the new bugs since 8/5 that have been filed which has been a lot. This is also good news as it means our user base is growing and taking an interest in reporting. On to the good news: Start Date: 8/5/2012 Days Since Start: 24 Bugs Triaged: 568! (way to go everyone, I know a lot of these are in NEEDINFO statusbut it's still means we touched the bug which is the goal, letting our users know we care :) ) Some other good news: Average Length of Time Since Last Action: 66 days (prior to project start # was 89) Median Length of Time Since Last Action: 56 days (prior to project start # was 85) These are all incredibly good. Congrats to everyone working on this project, I think we can meet some reasonable goals by the end of the year and work on starting new projects once this back log is finally taken care of. Best Regards, Joel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-qa] Triage Project Update
Well we're 24 days into the project and there is mostly good news (although some bad news is there as well). So bad news first. Overall we're down only about 200 or so bugs in 24 days. This takes into account the new bugs since 8/5 that have been filed which has been a lot. This is also good news as it means our user base is growing and taking an interest in reporting. On to the good news: Start Date: 8/5/2012 Days Since Start: 24 Bugs Triaged: 568! (way to go everyone, I know a lot of these are in NEEDINFO statusbut it's still means we touched the bug which is the goal, letting our users know we care :) ) Some other good news: Average Length of Time Since Last Action: 66 days (prior to project start # was 89) Median Length of Time Since Last Action: 56 days (prior to project start # was 85) These are all incredibly good. Congrats to everyone working on this project, I think we can meet some reasonable goals by the end of the year and work on starting new projects once this back log is finally taken care of. Best Regards, Joel ___ 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/
