launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Apr 14, 2011 at 5:49 PM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Thu, Apr 7, 2011 at 10:30 PM, Robert Collins
> <robertc@xxxxxxxxxxxxxxxxx> wrote:
>> On Fri, Apr 8, 2011 at 12:30 AM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>>> On Thu, Apr 7, 2011 at 5:29 AM, Robert Collins
>>> <robertc@xxxxxxxxxxxxxxxxx> wrote:
>>>> I'd like to cleanup our tags a little - we have 151 official tags. I
>>>> don't mean to stop folk using arbitrary tags, just make the set we're
>>>> /working with/ a little clearer and crisper: I don't think there is a
>>>> lot of value making every single thing have a blessed tags. We should
>>>> have tags for broad areas and for current LEPs.
>>>>
>
> Sorry for the delay in response.
>
> I want to re-iterate that I think it's a good idea to revisit our tags.
>
>>> ...
>>>> I'd like to delete the following tags as seeming not carrying enough
>>>> use to be *official tags* in the project - they would stay on the
>>>> relevant bugs, but not be always shown in the portlet, nor be offered
>>>> in typeahead in the bug tags widget.
>>>>
>>>
>>> A lot of these are cleanups which are obviously good ideas. I don't
>>> know what criteria you are using to decide that one tag is worthy of
>>> being official and another is not. Why is 'canonical-losa-lp' to stay
>>> official but 'oem-services' not? Why is 'patch-tracking' not worthy of
>>> being official when 'codehosting' is? You say "broad area" above, but
>>> I would have thought that "bug tags" were a broad area.
>>
>> Hunch, guesswork. For your specific examples:
>> canonical-losa-lp is important because we use it to mark things we
>> want to do for operational efficiency/robustness, and we need to know
>> how many things are affecting that.
>> oem-services isn't because while we care about things affecting
>> stakeholders (which is why I proposed a new stakeholder official tag),
>> the specific stakeholder isn't something we need to report on &
>> trivially show. patch-tracking I folded into code review, because
>> patch tracking was intended as a form of code review. codehosting is a
>> broad area (as is code review).
>>
>
> Sure, patch-tracking is a form of code review, but bugs in the way the
> bug tracker handles patches rarely have anything to do with bugs in
> the code-review system. This makes me think that we have a difference
> over what tags are or what they should be used for or something.
>
>> Are you happy with me actioning what I listed (modified by Julian and
>> Curtis' suggestions)?
>>
>
> Not really, because I still don't have a good idea of what official
> tags we'd end up with.
>
> My main hesitation over this proposal is I'm afraid the outcome will
> be an official breakdown of Launchpad into components, while the
> discussion has been about what tags we'll change. Maybe I don't need
> to worry about that. Having a list of the proposed new set of official
> tags would help with that, I think.
>

I still think that this is the case, but reckon that if you go ahead
and just do the changes that you are proposing we'll be in a better
position to see what those components are.

jml