Ticket triage discussion
Matt Good
not in the tickets themselves. We're getting some of these tickets way
too cluttered with discussions that aren't relevant to the actual
ticket itself, which makes it difficult for users to follow the actual
progress of the ticket. Also, I think that discussions about adding
new resolutions or making other changes to the workflow used on t.e.o
should be started on the mailing list, and not opened directly as
tickets.
In #4359 and #4260 there's some discussion of how to resolve tickets
where there's a known plugin to solve the problem. I disagree that
these should be closed as "worksforme", and rather we should use
"wontfix" since we're stating that while there's a plugin available, we
will not be adding the functionality to the core. This will be more
consistent with when we close tickets as "wontfix" and suggest that the
feature *could* be implemented as a plugin, but hasn't been yet.
I also don't see a reason to add a special "plugin" resolution as
suggested in #4260. This is really just a subset of "wontfix" since
it's used for enhancements we're saying don't belong in the core
system. If there's a reason to "tag" tickets that have a plugin
avaible to solve that could be done with a keyword instead. That way
the keyword could be added to tickets that were implemented as a plugin
after being closed instead of changing the resolution.
-- Matt Good
Ilias Lazaridis
> Let's keep the discussion of ticket triage rules on the mailing list,
> not in the tickets themselves. We're getting some of these tickets way
> too cluttered with discussions that aren't relevant to the actual
> ticket itself, which makes it difficult for users to follow the actual
> progress of the ticket.
That's right, such discussions should be spinned-off as separate
tickets, which should point back to the causing ticket.
> Also, I think that discussions about adding
> new resolutions or making other changes to the workflow used on t.e.o
> should be started on the mailing list, and not opened directly as
> tickets.
personally, I spinned-off tickets directly out of the usage-context,
using trac's exceptional abilities to interlink everything (including
the TracTicketTriage document).
Such enhancements tickets, subject the Component "Project" help to keep
the (very complex) topic transparent, granular and focused.
The document TracTicketTriage was a very good start.
> In #4359 and #4260 there's some discussion of how to resolve tickets
> where there's a known plugin to solve the problem. I disagree that
> these should be closed as "worksforme", and rather we should use
> "wontfix" since we're stating that while there's a plugin available, we
> will not be adding the functionality to the core. This will be more
> consistent with when we close tickets as "wontfix" and suggest that the
> feature *could* be implemented as a plugin, but hasn't been yet.
my rationales for a "external/plugin" resolution are within:
http://trac.edgewall.org/ticket/4260
> I also don't see a reason to add a special "plugin" resolution as
> suggested in #4260. This is really just a subset of "wontfix" since
> it's used for enhancements we're saying don't belong in the core
> system. If there's a reason to "tag" tickets that have a plugin
> avaible to solve that could be done with a keyword instead. That way
> the keyword could be added to tickets that were implemented as a plugin
> after being closed instead of changing the resolution.
have you looked at the keywords list?
http://trac.edgewall.org/wiki/TracTicketTriage#Keywords
This list is 'screaming':
"please, reduce me! Please, don't you see that you've overloaded me?
Please move all this classification away from me where it belong's too"
.
Emmanuel Blot
> not in the tickets themselves.
Yeah, sorry about that, I should not have started the discussion in
one of these tickets.
> I also don't see a reason to add a special "plugin" resolution as
> suggested in #4260. This is really just a subset of "wontfix" since
> it's used for enhancements we're saying don't belong in the core
> system. If there's a reason to "tag" tickets that have a plugin
> avaible to solve that could be done with a keyword instead.
The 'plugin' keyword is already listed in TracTicketTriage, however
its meaning is not explained yet. I've used this keyword twice to tag
tickets for which a plugin was the proposed solution.
So, "wontfix" status + "plugin" keyword would be the most common case.
What about the "plugin but an API extension is required" case as cboos
refered to ?
--
Manu
Sid Wiesner
> In #4359 and #4260 there's some discussion of how to resolve tickets
> where there's a known plugin to solve the problem. I disagree that
> these should be closed as "worksforme", and rather we should use
> "wontfix" since we're stating that while there's a plugin available, we
> will not be adding the functionality to the core. This will be more
> consistent with when we close tickets as "wontfix" and suggest that the
> feature *could* be implemented as a plugin, but hasn't been yet.
Agreed. "worksforme" resolution is used when the problem can be
resolved by a configuration change, upgrade, etc or there is a good
workaround.
"wontfix" could (should?) be used only when this is a requested
enhancement / bugfix that (1) will not be merged into Trac core
because it is not in line with the project goals, (2) will not be
merged into Trac core, and a plugin is available, or (3) is not really
Trac's problem (perhaps when there is a bug in one of Trac's
dependencies).
Sid
Matt Good
resolved by some action by the end user instead of the developers
needing to fix something in the code. I think these issues should fall
under the current "worksforme" or "wontfix". The issue which prompted
this was the request in #4039 for a new branch in SVN, which was
denied, so it should have been closed as "wontfix". The fact that
Ilias solved this problem for himself by working in a separate
repository doesn't really affect the resolution from Trac's side. The
other issues I see this applying to are when the user has configured
something incorrectly. These should be resolved as "worksforme" since
the problem was a user error, and not something done wrong by Trac.
-- Matt Good
Matt Good
> What about the "plugin but an API extension is required" case as cboos
> refered to ?
I suppose the originally requested feature can still be closed as
"wontfix" but a ticket should be opened for the necessary API changes
(if it doesn't exist).
-- Matt Good
Emmanuel Blot
> "wontfix" but a ticket should be opened for the necessary API changes
> (if it doesn't exist).
Sounds fine.
Cheers,
Manu
Ilias Lazaridis
If a team starts to place itself above the english language, then it's
time to rethink and to take some feedback of people in account, which
are not 'trapped' by the long-time operation within the projects domain
knowledge.
People, "wontfix", "worksforme", "defect", "task" etc. is english - not
tracish !
http://trac.edgewall.org/ticket/4212#comment:6
.
Christian Boos
No, I don't agree. Closing the original ticket describing what needs to
be done and then creating another one for implementing an interface is a
waste of effort. Plus, that second ticket would necessarily have to
contain a discussion about the requirements which would basically be a
rewrite of the original request, so that would be redundant.
Like I've written in #4259:
> Now, I also like to keep open the tickets that are clearly candidates
for plugins '''if''' the interfaces they would need are not yet in
place. Once the necessary interfaces are implemented, the ticket can be
closed as a normal ticket would (milestone set and ''fixed'').
> Typical example is #1947 (see also
[googlegroups:trac-dev:cad8978f68b65cb8 this mail] on trac-dev).
So let's keep it simple: close requests for enhancements as
"wontfix/plugin" only if they can actually be written as plugins.
-- Christian
Ilias Lazaridis
> Matt Good wrote:
> > Emmanuel Blot wrote:
> >
> >> What about the "plugin but an API extension is required" case as cboos
> >> refered to ?
> >
> > I suppose the originally requested feature can still be closed as
> > "wontfix" but a ticket should be opened for the necessary API changes
> > (if it doesn't exist).
>
> No, I don't agree. Closing the original ticket describing what needs to
> be done and then creating another one for implementing an interface is a
> waste of effort. Plus, that second ticket would necessarily have to
> contain a discussion about the requirements which would basically be a
> rewrite of the original request, so that would be redundant.
you are both wrong.
The original ticket remains open
An 2nd ticket is opend, affecting the API change/addition etc.
The 2nd ticket points back to the original ticket (block-relation)
The original ticket points to the 2nd ticket (depends-relation)
(ideally, this would be done by an automated dependency relation, but
doing it manually is ok, too)
> Like I've written in #4259:
> > Now, I also like to keep open the tickets that are clearly candidates
> for plugins '''if''' the interfaces they would need are not yet in
> place. Once the necessary interfaces are implemented, the ticket can be
> closed as a normal ticket would (milestone set and ''fixed'').
> > Typical example is #1947 (see also
> [googlegroups:trac-dev:cad8978f68b65cb8 this mail] on trac-dev).
>
> So let's keep it simple: close requests for enhancements as
> "wontfix/plugin" only if they can actually be written as plugins.
correct.
.