mtrack: roadmap RFC
I wanted to share some of my thoughts on future development in mtrack, and solicit some feedback. Some of these are driven directly from user requests, and others are things that I've been thinking about on-and-off for a little while.
I really want to hear your thoughts, whether they relate to ideas and feature suggestions, or whether you have some experience or anecdotes on these topics.
Custom Fields
I was hoping to avoid having to enable this as a feature, as I find the implementation approach taken in the original Trac to be sub-optimal, both in terms of run time efficiency and in terms of user experience when it comes to reporting on the custom fields.
The approach taken in trac is to define custom fields in an auxillary table containing ticket, name, and value information, and then joining that back to the main information in the right places. It makes it painful to write reports.
It is an unavoidable feature; I've already had to bite the bullet and cook up a plugin for this at work, but I'm holding off putting it into the main branch at the moment. My reasoning is that I really don't like the established way to implement this, and the plugin that I have at work actually changes the schema of the database to make this less sucky, but I'm still not happy with this, as allowing arbitrary schema changes reduces the flexibility we have for future development.
One possibile course of action here is to ride the new wave of "document databases", like CouchDB to partially side-step the schema issue, but the trade-off there is that writing reports becomes harder.
Managing Information Flow
One of the pain points that we're feeling at work is the volume of notifications being generated by our development team. As we continue to grow, the amount of information flying around grows also, and it is reaching very high levels. We are not alone; just the other day I was fielding some questions about managing the flow of information from mtrack.
What I think we should move to is allowing each user a level of granularity; allowing them to opt-in to wiki, ticket updates and commits respectively across different project areas (areas of the wiki tree, areas of the source trees, components, milestones) and at the individual ticket level.
We should also provide RSS feeds with similar granularity controls, so that the user can choose their update mechanism. This should also have an API so that other services can be wired in to receive these updates.
Avoiding data overload
One of the drawbacks of having a single application to aggregate all your various projects and teams is that you end up with a lot of users, milestones and components in the drop-downs as you navigate the application.
We should definitely make these use some kind of livesearch feature, and possibly intelligently adapt to the user preferences; based on their notification preferences, we can boost their followed items to the top of the list so that they have less searching for their commonly used items.
Related to this, we have a couple of tickets with very long comments or descriptions (big patches or transcripts pasted in from elsewhere). It would be nice to intelligently limit the size of those if they pass some threshold.
Better Documentation
A goal for all projects!
Code Reviewing
I have a couple of scenarios in mind for this; ranging from an ad-hoc peer review where you spot something in a commit that you comment on, to workflow enforced where you want to have someone review commits made by new or junior staff members.
Better Diff Reviewing
I'd like to have mtrack give you the option of viewing diffs in context, or at the very least, doing a better job of telling you which lines are affected.
Pastebin
Useful for sharing snippets. Should also use the same reviewing framework to allow code or configuration to be commented on.
Repo creation and cloning
In discussing possible future directions for our source control, we've been evaluating tools such as Git and Mercurial. The killer feature of Git is Github, with its social and collaborative coding interface. Bitbucket is the Mercurial equivalent.
Why can't we have a our own tools like this internally? Well, let's make it so that we can.
The major coolness here is twofold:
- I can set up a repo of my own to track a small project that I'm working on, without having to login to the backend and run some obscure commands
- I can clone an existing project so that I can hack in partial isolation from the main tree, but have a location that can be shared and collaborated on with others
By making it easy to set up and collaborate in the application we will remove some physical and psychological barriers to making forward progress, and by having a share point on the central server, you can also make backups of the various ad-hoc repos that your developers might already have been working with across their various machines (I can't count how many of these I have, or how many I have started and forgotten about).
User and Group Management Improvements
I also would like to improve both the interface for setting up users and their rights (it doesn't exist right now!), as well as defining access controls for the per-user repos. This should also allow for group entities, so that an organization can have product/project repos distinct from an individuals development repo.
Along with this, improving OpenID support is important also.
Distributed mtrack
This is something of an aspiration; I don't really have a strong need for this feature, but I like the concept of being able to be completely disconnected from the office and having a sync'd mtrack + set of code repos so that I can file tickets, edit the wiki and make code changes and commit them while I am out of contact, and then have those sync back to the main system when I get back.
A side effect of enabling this use case is that you gain most of what you would need for scaling out a "cloud" mtrack service.
I'm strongly considering CouchDB to enable both this and the custom fields capabilities.
Document Database
One thing that's clear to me from my experience with CouchDB so far is that it is moderately difficult to install. I like the fact that mtrack today take moments to get running in a basic fashion, and I don't want to move away from that.
I have some plans for building a document store with similar storage and search/indexing functionality as CouchDB that will not require external dependencies; just what ships with PHP 5.
More Caching
Right now, mtrack shells out to the underlying SCM toolset when it needs to query information from the repos. We've noticed that mtrack can be a litle clunky if a couple of people are looking at bit commits at the same time.
I'd like to remove this bottleneck by adjusting that access pattern. My plan for this is to break that data apart so that portions of it are cacheable by the browser, and use AJAX to integrate that into the individual pages.
With this in place, it should make it more feasible to support remote repos (where the repo is not local to the mtrack box), although I expect that will still be a less enjoyable experience than with a local repo.
REST API
Providing the ability to enumerate, search, create, update, delete the various objects that comprise an mtrack install, including repos and users.
Anything else?
If you'd like to share ideas, thoughts and/or feature requests, feel free to either comment below, on the mtrack mailing list or in the #mtrack IRC channel on freenode.