hi,
emmapeel wrote (09 Mar 2016 11:47:41 GMT) :
> Muri and I are working on the documentation for our Redmine bug
> tracker[1],
Woo! \o/
Sorry for the delay…
> and would benefit for some more insight on
> - Categories
Perhaps we could state what a "Category" is in our Redmine-speak? (See
the discussion, on this mailing list, that lead to introducing the
"Type of work" field: IIRC back then we came up with a definition of
what Category vs. Type of work meant.)
Also, in passing and FWIW, I see little value in listing the
categories we have, and trying to keep the list up-to-date. If an item
or three require an explanation (and can't be renamed to not need any
explanation), then let's write it, but I would say let's not list
possible values. What do you think?
> - Type of work
Here it feels worth defining some of the possible values, and I'm glad
you did it! Same as categories, let's not list those that don't
need any explanation, and IMO let's not try to keep the list
up-to-date.
What insight do you need about those?
Regarding "Debian": the current description makes it sound anything
that has to be done upstream should have Type of work = Debian, which
is not the case. Some work has to be done upstream _elsewhere_, and
then we generally use Communicate (e.g. when the action is to report
a bug upstream), or Code (e.g. when the action is to do the needed
tech work upstream), or Wait (when we're waiting for upstream to do
it themselves).
> - Affected tool
Same as Category I think.
> and also a review of the descriptions we are giving to the
> rest of the fields of course.
First of all: excellent work, I like it!
* Description: I think that the "preferred style" instructions are
good for bug reports, but I don't think it works too well for
features. Perhaps just clarify the scope of applicability of these
instructions? (We don't really need to decide what the preferred
style is for features, do we?)
* "Frontdesk team is in charge [...]" → link to the team role's
description, that is more precise?
* We have no "experimental" branch anymore.
* In Progress: perhaps the description is a bit too restrictive.
E.g. I personally set a code ticket "In Progress" as soon as I have
pushed an initial draft, possibly far before it's ready for QA.
* Generally: s/git/Git/, unless you mean the command. Sorry :)
* Dev Needed: "Choose this when you think a developer will have enough
information to start working on this ticket" ← I'm not aware of such
usage; do we really use it this way?
* Generally: in a few places it's written "code", while the text is
valid for any kind of contribution that lives in Git; I would love
to see the language be a bit more inclusive wrt. these other kinds
of contributions. If you don't feel like working on this yourself,
I'll be happy to give it a try once you see the branch as ready
for QA.
* Feature Branch: when "repositoryname" is not specified, implicitly
we mean "the official Tails Git repository".
* "If you create a ticket you become automatically
a watcher" ← really?
* I say we can just ignore the fields we basically never use, e.g.
Start date and Due date. Or, state that their usage is reserved to
whoever works on the ticket, and they can use them in any way
they want.
Cheers,
--
intrigeri
