Developers' Corner

A blackboard for ideas related to future directions _{(or: How do we bribe the aliens so that we can reach milestone:2.0?)}

More seriously, this page is for drafting long term ideas and share the vision the Trac developers have.

• for the actual coordination of on-going tasks, see TracDev/ToDo.
• have an sneak preview of cboos' next steps

Development Process Issues

Regarding ../:

1. Core development has stagnated
   Probably true, we need more people to actively care about the project. How?

   Comment: Just look at the history of #2456. People cared, wrote patches, discussed the issue. But in the end nothing changed despite the fact that trac doesnt adhere to its design principles in that area (Users not managed via pluggable Components/Relations) The ticket is 4 years old. There are few comments from team members and virtually no information what problems prevent this to move forward. People got frustrated, wrote competing implementations/plugins or gave up and moved on. I think it's worth analyzing what went wrong here.

   Comment: ActiveState now use trac commercially (​http://firefly.activestate.com) maybe the core developers could get active state to pitch in?

1. lowering the barrier to entry
   We could achieve this by providing better docs, API docs, cleaner and simpler code
2. motivating people to jump over the barrier
   
   • the great new feature!
   • nice stuff that really makes Trac stand out of the competition
   • cookies!
3. Some ideas which may be completely off the mark…
   • ?? Use more standard libraries. Templating has moved to Genshi, but maybe SQLAlchemy for DB backend?
   • ?? Highlight issues that should be easy for new people to fix
   • ?? Google summer of code mentoring (requires time though)

2. Core developers do not or cannot commit a lot of time to the project
   Whip them? Otherwise, see 1.

   Comment: In theory they don't need to, if the community can write patches and test them, then all the core developers need to do is commit to svn.

3. Frequently requested features do not get implemented
   Big features (e.g. MultipleProjectSupport) first need to have a developer really needing the feature, as it can't be done without some kind of deep involvement. See 1.2.
4. Release cycle is way too slow
   (need a picture showing Release History)
   I proposed something with intermediate point releases, see ​googlegroups:trac-dev:7f875005134cd355. We should actually do it.
5. Zero chance of a plugin getting into the core
   Well, WebAdmin was integrated. There was some attempt to do the same for ​AccountManagerPlugin (see also WhatUsersWant), but see 3. Note that some plugins will never be integrated or even bundled, due to licensing issues (TracMercurial and ​GitPlugin).
6. Features that users think should be "core" are not
   Since 0.12, there's a new tracopt. package hierarchy, for bundling components that are not enabled by default. This makes it possible to have some room between strictly necessary for almost anyone using Trac (trac.) and optional, must be 3^rd party.