Re: [IAEP] [Sugar-devel] triage meeting
Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.org around for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
+1 to one less account +1 to a nicer workflow +1 to automatically keeping us updated by the github email bot On Apr 19, 2014 10:03 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.org around for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Sat, Apr 19, 2014 at 01:03:37AM +0100, Daniel Narvaez wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. For your interest, spam has gone away entirely on the OLPC trac http://dev.laptop.org/ after the accounts were purged and an additional special question added to the register page. I can supply that if anybody needs it. Speculation: the attack robots are familiar with trac instances, but not customised instances. -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
I tried to do a migration using trac2github. Here is what it looks like https://github.com/dnarvaez/test/issues/258 It's missing the reporter and it's not filtering by component but these should be easy to add (it's php sigh, but still...). On 19 April 2014 01:03, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.org around for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
By the way, if we decide to do it I think we should do it *before* the meeting, so that we triage using github already and we don't risk to lose information (or to have a really hard time fixing the script to preserve it). On 19 April 2014 02:03, Daniel Narvaez dwnarv...@gmail.com wrote: I tried to do a migration using trac2github. Here is what it looks like https://github.com/dnarvaez/test/issues/258 It's missing the reporter and it's not filtering by component but these should be easy to add (it's php sigh, but still...). On 19 April 2014 01:03, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.orgaround for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Looks more than comments than tickets, right? Or I am missing something? For our way of work, I think we need at least component and priority, and if is a bug or a enhancement. Or there are another way to categorize them? I see labels here https://github.com/dnarvaez/test/issues Gonzalo On Fri, Apr 18, 2014 at 6:07 PM, Daniel Narvaez dwnarv...@gmail.com wrote: By the way, if we decide to do it I think we should do it *before* the meeting, so that we triage using github already and we don't risk to lose information (or to have a really hard time fixing the script to preserve it). On 19 April 2014 02:03, Daniel Narvaez dwnarv...@gmail.com wrote: I tried to do a migration using trac2github. Here is what it looks like https://github.com/dnarvaez/test/issues/258 It's missing the reporter and it's not filtering by component but these should be easy to add (it's php sigh, but still...). On 19 April 2014 01:03, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.orgaround for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Gonzalo Odiard SugarLabs - Software for children learning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Yes! I agree. On Thursday, 10 April 2014, Walter Bender walter.ben...@gmail.com wrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:; wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:; wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Thu, Apr 10, 2014 at 6:52 AM, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Maybe it is as simple as that: (1) need_to_fix (2) want_to_fix (3) nice_to_fix I cannot imagine we need more granularity than that. -walter Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.com wrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. IMO it's really really important to aggressively close stuff we are not realistically going to fix soon. Otherwise either we waste more time triaging than fixing or we don't triage enough and the bug tracker becomes useless. Just my two cents. We could also keep low for now and see if it really grows too much to be worth retriaging over time. In my experience it's always does but it would be nice to be proven wrong. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a w -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
I disagree. While is true manage the tickets have cost, is good have a record of things we want to do, even when we don't have the resources today to do it. More in the context of a project where we have volunteers some times more, some times less. Just my two cents ...of pesos :) Gonzalo On Thu, Apr 10, 2014 at 9:27 AM, Daniel Narvaez dwnarv...@gmail.com wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. IMO it's really really important to aggressively close stuff we are not realistically going to fix soon. Otherwise either we waste more time triaging than fixing or we don't triage enough and the bug tracker becomes useless. Just my two cents. We could also keep low for now and see if it really grows too much to be worth retriaging over time. In my experience it's always does but it would be nice to be proven wrong. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a w -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Yes, things we *want* to do are normal priority, my issue is with things that would be nice to do :) Terminology aside, I'm not saying it's bad, just expensive and IMO lower priority then a lot of other awesome things we could do... But if there are people interested in keeping records, all the power to them! On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: I disagree. While is true manage the tickets have cost, is good have a record of things we want to do, even when we don't have the resources today to do it. More in the context of a project where we have volunteers some times more, some times less. Just my two cents ...of pesos :) Gonzalo On Thu, Apr 10, 2014 at 9:27 AM, Daniel Narvaez dwnarv...@gmail.comwrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. IMO it's really really important to aggressively close stuff we are not realistically going to fix soon. Otherwise either we waste more time triaging than fixing or we don't triage enough and the bug tracker becomes useless. Just my two cents. We could also keep low for now and see if it really grows too much to be worth retriaging over time. In my experience it's always does but it would be nice to be proven wrong. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Thu, Apr 10, 2014 at 01:27:09PM +0100, Daniel Narvaez wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. I agree, if there's nobody going to work on a ticket, then close it wontfix. The bug tracking system is useful as a list of non-features. Also, it is common in triage to not process already triaged would be nice tickets, so you shouldn't be wasting triage time on them over and over. If you are, fix your triage process. -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On 10 April 2014 21:18, James Cameron qu...@laptop.org wrote: On Thu, Apr 10, 2014 at 01:27:09PM +0100, Daniel Narvaez wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. I agree, if there's nobody going to work on a ticket, then close it wontfix. The bug tracking system is useful as a list of non-features. Not what I said. And not even funny. Also, it is common in triage to not process already triaged would be nice tickets, so you shouldn't be wasting triage time on them over and over. If you are, fix your triage process. And how do you avoid the issues getting obsolete (no more relevant, already fixed etc) if not by re-triaging them? That approach has been certainly common in sugar triage until recently. The result was that we couldn't really point any new contributor to the bug tracker because most of the bugs was obsolete. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On 10 April 2014 22:08, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 April 2014 21:18, James Cameron qu...@laptop.org wrote: On Thu, Apr 10, 2014 at 01:27:09PM +0100, Daniel Narvaez wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. I agree, if there's nobody going to work on a ticket, then close it wontfix. The bug tracking system is useful as a list of non-features. Not what I said. And not even funny. My sarcasm detector was inaccurate here. Further explanation in irc, which I agree with. 21:30 Quozl` dnarvaez_: the existence of a ticket is a report of feature mismatch between human and software. wontfix is a policy decision of the project. policy can be set by resource constraint. it's fine, close 'em. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, On Wednesday, 9 April 2014, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Then we can use the triage meeting to finish the confirmation and to set the priorities. What you think? Gonzalo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
I added a Needs Design field to the status. -walter On Wed, Apr 9, 2014 at 6:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? -- Gonzalo Odiard SugarLabs - Software for children learning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:_e(%7B%7D,'cvml','godi...@sugarlabs.org'); wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:_e(%7B%7D,'cvml','godi...@sugarlabs.org'); wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Finally, something I think is important is to set enhancement vs defect. It doesn't take much effort and it's very useful when we are feature frozen. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
