intrigeri wrote:
> after more than a year of using Redmine, it's probably time to refine
> things a little bit. Here are notifications about changes I've already
> made, and proposals to do more. I'd be happy to read more issues
> identified, and more proposals!
>
> 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.
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.
> 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.
> 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...
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'm not sure that creating boolean fields is a good solution because we
might need one per "field of expertise".
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...
> c. As discussed previously here, I've created two new categories:
> "Email Client" and "Instant messaging", and moved a bunch of
> tickets in it. Once we've finished migrating to Icedove, we might
> want to rename the former to "Icedove", so that RSS feed support
> can fit into it too, if we also replace Liferea with Icedove for
> this use case as well.
Thanks.
--
sajolida
