Sorry for this being such a long post, but with 0.11 just released I
thought this would be the right time to put forward some thoughts on
how we might make it easier for other new users to take advantage of
Trac. I doubt anything I’m about to suggest is really new, but I
wanted to weigh in on the topic.
Getting Trac up and running the first time isn’t too hard, especially
with the changes made in 0.11. (As a side note, the documentation on
the wiki could be cleaned up a bit as there’s a lot of old information
hanging out in there. I’ll help with the Windows part of the install
docs.) But taking that next step from a basic working system to a
customized one taking full advantage of Trac is hard. Much of Trac's
strength comes from it's plugins. Trac's plugin system is very
flexible, but the documentation and project infrastructure make it a
fairly steep learning curve. In short, discovering and installing
plugins is hard for beginners. Handling updates with lots of plugins
is also tough (especially with Trac's historically long update
cycles).
The current Trac development philosophy seems to be to keep the core
lean and provide lots of extension points. I think that’s a great
philosophy and fully agree with it. My thoughts are not about changing
the implementation of Trac, but changing the nomenclature around Trac.
If the developers make everything practical a plugin and only add
changes to the core that support key features needed/desired by plugin
authors, that satisfies both the flexibility and leanness objectives.
My suggestion is to introduce three artificial levels of plugins. By
“artificial” I simply mean that there’s no implementation difference
between the levels, this is just about how they are delivered and
documented. Those levels would be
Core Features
Trac Options
Trac Plugins
“Core Features” would be included in the base Trac installation and
enabled by default. Examples would be the Trac wiki, admin pages,
search, and other such basic building blocks of a Trac installation. A
nice admin page for disabling core features where appropriate would be
great (if you wanted to disable the report module for instance).
“Trac Options” would also be included in the base Trac installation
but disabled by default. Again, a nice admin page for enabling these
optional features would be great. These option plugins would be those
particularly useful/powerful plugins that the development team deems
stable enough and appropriate. The key here is that these option
plugins would be maintained as part of the Trac release process. The
whole point here is to keep the core lean and not weigh the core down
with unnecessary plugins being loaded, but ensure that if you enable
one of these optional features it will continue to work if you upgrade
Trac to a new release. Examples of these would be the existing sample
plugins like Timestamp as well as extremely popular plugins like
AccountManagerPlugin.
“Trac Plugins” would be all the other stuff from trac-hacks.org and
would be handled pretty much as it is now -- a free-for-all that can
include anything, but it’s up to the user to ensure that a plugin is
compatible with a new Trac release.
This would make it easier for people to gain access to features that
are very commonly used but don’t need to be part of the Trac core. It
would also simplify the upgrading process to new Trac releases (since
you’d know that optional pieces you depend on are already compatible).
The space requirements are trivial (it’s not like plugins are very
big). Since the Core Features and Trac Options are constrained lists
known in advance, we could have special admin pages that simplify
enabling/disabling these plugins to customize a Trac installation.
This could really help out new users. Voting on the mailing lists
could handle moving a plugin into the Trac Option category.
I'd like to see a fairly large number of the commonly used plugins
moved into the Trac Option category. In some cases there should
probably be a bit of refactoring of the existing plugins to follow a
more cohesive plan, but that can be worked out as we go.
I hope I didn’t step on any toes here, but I do think this would help
people take advantage of Trac.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
