= Developers' Corner =
 '' A blackboard for ideas related to future directions'' 

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 [ChristianBoos#NextSteps cboos' next steps]
 - see the topics currently discussed for the [[TracDev/ReleaseNotes/0.13|next major version 0.13]]


== Development Process Issues ==

Regarding [../#HighLevelObservations High Level Observations] points raised on the SeaChange page:
 1. '''Core development has stagnated''' [[br]]
    Probably true, we need more people to actively care about the project.
    How?
        {{{#!div style="background:#efe"
        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.
        }}}
        {{{#!div style="background:#efe"
        Comment: ActiveState now use trac commercially (http://firefly.activestate.com) maybe the core developers could get active state to pitch in?
        }}}
     a. lowering the barrier to entry [[br]]
        We could achieve this by providing better docs, API docs, 
        cleaner and simpler code
        {{{#!div style="background:#efe"
        Comment: When I started looking into Trac it did feel like development documentation was somewhere between minimal and doesn't exists at all for some areas of the code. However, I did manage to find everything I needed by looking in the source (and I pretty much learned Python while trying to figure Trac out) - its well commented and with some searching skills it providers pretty much everything that a developer could need. That being said, and even tho I'm personally completely fine with looking thru the source code, I think that setting-up API documentation can really help developing for Trac, while it shouldn't take too much effort - there must be plenty of API documentation generators for Python... - shesek
        }}}
     a. motivating people to jump over the barrier [[br]]
         - the great new feature!
         - nice stuff that really makes Trac stand out of the competition
         - cookies!
     a. 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''' [[br]] 
    Whip them? Otherwise, see 1.
        {{{#!div style="background:#efe"
        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.
        }}}
        Aggregating random changes is not going to work. We need a plan, a global vision.
 3. '''Frequently requested features do not get implemented''' [[br]] 
    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.
 4. '''Release cycle is way too slow''' [[br]]
    (need a picture showing Release History) [[br]]
    I proposed something with intermediate point releases, 
    see googlegroups:trac-dev:7f875005134cd355. 
    We should actually do it.
    Current idea is to shorten the development cycle of major 
    releases, see googlegroups:trac-dev:6823a7fa94bb0392. 
    This is still somewhat complementary to first idea exposed above:
    if a big feature doesn't make it for a release, it should simply
    wait for the next one instead of delaying it further.
    This implies merging a feature ''late'', once we're sure it
    can be finished. Late merging has its own drawbacks, which
    could perhaps be mitigated by the use of temporary integration 
    branches.
 5. '''Zero chance of a plugin getting into the core''' [[br]]
    Well, WebAdmin was integrated. There was some attempt to do the same for 
    [TH:AccountManagerPlugin] (see also [../WhatUsersWant]), but see 3.
    Note that some plugins will never be integrated or even bundled, due to 
    licensing issues (TracMercurial and [TH:GitPlugin]).
 6. '''Features that users think should be "core" are not''' [[br]]
    Since 0.12, there's a new [source:trunk/tracopt 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.''