Remy Blank wrote: > I would add one additional nuance: > > - The ticket is an interesting enhancement idea, but provides value > only to a minority of users => close as wontfix and suggest creating a > plugin >
Well, we could certainly do that when it's perfectly reasonable to implement as a plugin. Believe it or not, I did this myself a couple of times ;-) > I know the plugin vs. core issue is sensitive, but it's probably no use > keeping tickets around that will most probably never be included in core. > When it's clear that something could be done as a plugin given the existing interfaces, I think it's OK to suggest to create a plugin (closed as "externalplugin"?). But when there's a lack of adequate interfaces or there's the need for adaptations in Trac itself (be it simple refactorings), I think it's best to keep the ticket opened for tracking the prerequisite changes needed in Trac. That ticket serves then as a communication medium between the core developers and plugin developers. > Alternatively, we could create a "plugin" milestone to track plugin > ideas. Or did you intend 2.0 to fulfill this function? > > No, not really. 2.0 is more or less for gathering potential enhancements for which nobody could plan an earlier milestone, or for defects that are rooted deep in the design of Trac and are not likely to get fixed soon. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
