Hi,
sajolida@??? wrote (15 Sep 2014 14:32:15 GMT) :
> intrigeri wrote:
>> a. We need to clarify usage of the "Upstream" type of work. It's been
>> used for very different things, and is therefore currently
>> meaningless IMO:
>>
>> 1. Talk to upstream (e.g. report a bug, suggest an improvement):
>> I think we should just use the "Communicate" type of work.
>>
>> 2. Turn custom changes of ours into something that's ready for
>> upstream consumption, and have it merged there. I think we
>> should have a "Push Upstream" type of work.
>>
>> 3. Wait for "someone" to implement something upstream (assuming
>> it's already known upstream that it needs to be done; else, go
>> to #1). I think that the "Wait" type of work is good for
>> these ones.
>>
>> If there's no objection within a week, I'll do that.
> So you are proposing to close the "Upstream" type and create a "Push
> Upstream" type? That's pretty much similar as renaming it and clarifying
> its use, no? But I'm pretty sure that the same confusion that you are
> describing will appear with the new name. I don't think that the
> vocabulary difference between "Upstream" and "Push Upstream" will
> prevent people from using it for case #1 for example. To me, the verb
> "push" describe more of a communication action than a coding action
> actually.
OK, I'm convinced.
> If this multipurpose use of the "Upstream" type of work really disturbs
> you (it doesn't disturb me that much apparently) then why not using
> "Code" for case #2? This is coding work really. And then remove it all
> the way or use it as a category.
Fine with me. I've triaged all "upstream" tickets right away, and
deleted this "type of work".
>> b. What does the "design" category mean? It was empty recently, and
>> then:
>>
>> - tchou added a bunch of UX -related tickets to it; on the other
>> hand, many other similar tickets have other categories (e.g.
>> the one corresponding to the software whose UX should be
>> improved), or not at all; so, it's not clear to me what's the
>> current practical usefulness of using this category for these
>> tickets;
>>
>> - anonym used it for a ticket that's about design doc (I've fixed
>> it since then).
>>
>> So, clearly something is too vague here. I propose to just drop
>> this category unless the problem gets worse, and then let the UX
>> team think their Redmine needs through and come up with something.
>> I'll do that if there's no objection within a week.
> Agreed.
Done, triaged the corresponding tickets.
>> I realize that the axes that we currently use probably don't match
>> their needs: e.g. how do you categorize something that's about the
>> Tor configuration's UX? is it about Tor configuration, or about UX?
>> Maybe an additional "UX" boolean flag is the best we can do, until
>> we have tags.
> We use categories to describe different "axes" as you call them:
> - Tools (eg Whisperback)
> - Fields of expertise (eg Accessibility and Internationalization)
> The "name field of expertise" is not that good but I couldn't find
> better...
In most cases, IMO "type of work" is better suited to reflect the
needed expertise than the category. But I realize that what you're
talking about, when you write "field of expertise", is more about some
type of problem (e.g. Tails Installer can have i18n problems, that
will be solved by modifying its source code) than about
specialized expertise.
> Unless we decide to have only one axe in those categories, they are
> bound to overlaps sometimes. When I have to choose between two things, I
> choose the "tool" over the "field of expertise".
I very well see what you mean, and I've seen BitingBird struggle with
this too when triaging tickets.
> The real solution would be to allow multiple values for Categories.
> That's more like tag system with predefined value. Does this exist in
> Redmine? The notion of "Category" is pretty bad anyway for picky people
> like us...
Nope, this is not possible in Redmine. However, custom fields (e.g.
the one we're using for "Type of work") *can* have multiple values
allowed, so we could possibly create another custom field and entirely
replace our usage of categories with it. However, I couldn't find how
one can fully disable the Category field, so it would be confusing.
With this in mind, and my above note about the "field of expertise"
(sic, IMO), I think the best we can do is to:
1. use the Category field for generic, transversal type of issues
(e.g. accessibility, i18n, hardware support, persistence);
2. create a dedicated custom field called "Subsystem" or "Affected
Tool" or similar.
This also addresss the problem you raised in another email (about e.g.
I2P persistence), as long as we cheat a bit and see persistence as
a transversal matter in Tails, instead of a subsystem of its own.
Cheers,
--
intrigeri
