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
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"
.
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
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
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
Sounds fine.
Cheers,
Manu
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
.
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
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.
.