[Pharo-project] Google Code labels/templates
Someone had suggested to remove the "Pharo 1.4 Enhancement" template, since we're not accepting any. That makes sense. Also, the Nautilus template labels the issue "Nautilus", but the label in the list is "Type-Nautilus". Which brings me to my next question... The other Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and Jenkins [2] really don't fit into this framework. Maybe because there will be many fewer issues, we don't need the level of granularity of [1] for [2]. But when we get close to a release, it'd be nice to know that there is 1 Nautilus bug and 10 Enhancements pending (i.e. probably only one critical thing) vs. 11 Type-Nautilus. So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus. What do you think? Sean -- View this message in context: http://forum.world.st/Google-Code-labels-templates-tp4636767.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Yes, I think also that the Type (bug, enh, feature, cleanup) of the issue must be orthogonal to the tool/app/subsystem in question :) On Tue, Jun 26, 2012 at 8:48 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Someone had suggested to remove the "Pharo 1.4 Enhancement" template, since we're not accepting any. That makes sense.
Also, the Nautilus template labels the issue "Nautilus", but the label in the list is "Type-Nautilus". Which brings me to my next question...
The other Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and Jenkins [2] really don't fit into this framework. Maybe because there will be many fewer issues, we don't need the level of granularity of [1] for [2]. But when we get close to a release, it'd be nice to know that there is 1 Nautilus bug and 10 Enhancements pending (i.e. probably only one critical thing) vs. 11 Type-Nautilus.
So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus.
What do you think?
Sean
-- View this message in context: http://forum.world.st/Google-Code-labels-templates-tp4636767.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Jun 26, 2012, at 8:49 PM, Sean P. DeNigris wrote:
Someone had suggested to remove the "Pharo 1.4 Enhancement" template, since we're not accepting any. That makes sense.
Also, the Nautilus template labels the issue "Nautilus", but the label in the list is "Type-Nautilus". Which brings me to my next question...
The other Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and Jenkins [2] really don't fit into this framework. Maybe because there will be many fewer issues, we don't need the level of granularity of [1] for [2]. But when we get close to a release, it'd be nice to know that there is 1 Nautilus bug and 10 Enhancements pending (i.e. probably only one critical thing) vs. 11 Type-Nautilus.
So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus.
What do you think?
honestly I don't care... there is so much to do that I can't even think about details like this. Marcus -- Marcus Denker -- http://marcusdenker.de
Marcus Denker-4 wrote
So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus.
What do you think?
honestly I don't care... there is so much to do that I can't even think about details like this.
If you give me access, I will take care of it. These clarifications will avoid more, possibly invalid, issues from cluttering up our minds. -- View this message in context: http://forum.world.st/Google-Code-labels-templates-tp4636767p4638879.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Jul 6, 2012, at 7:35 PM, Sean P. DeNigris wrote:
Marcus Denker-4 wrote
So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus.
What do you think?
honestly I don't care... there is so much to do that I can't even think about details like this.
If you give me access, I will take care of it. These clarifications will avoid more, possibly invalid, issues from cluttering up our minds.
That is a great idea! I will add you as and admin. Marcus -- Marcus Denker -- http://marcusdenker.de
Sean P. DeNigris wrote
The... Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and Jenkins [2] really don't fit into this framework. Maybe because there will be many fewer issues, we don't need the level of granularity of [1] for [2]. But when we get close to a release, it'd be nice to know that there is 1 Nautilus bug and 10 Enhancements pending (i.e. probably only one critical thing) vs. 11 Type-Nautilus.
So, now that I said all that, it seems the most powerful/flexible approach would be to leave the "nautilus" tag, remove the leading "Type-" from "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed like the one for Nautilus.
I moved Types that are really sub-tools/topics to Targets (you can pick one Target per issue): Target-Seed = Bootstrap oriented Target-Filesystem Target-Spec Target-Jenkins = CI related stuff Target-Nautilus We now have the following types (you can pick one Type per issue): Type-Bug = Report/fix of a software defect Type-Cleanup = Change that does not functionally modify existing Type-Feature = New Feature Type-HighLevelTask = Work item that doesn't change the code or docs Type-Enh = Little Enhancement Type-FailingTest = There is a test for this bug that fails I updated all existing issues/templates that seemed relevant to use the new labels. Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-labels-templates-tp4636767p4641868.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (3)
-
Guillermo Polito -
Marcus Denker -
Sean P. DeNigris