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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
