arbit roadmap
This is a basic draft for a roadmap for arbit. Here you can find the roadmap generated by the issue tracker.
Version 0.1
A first running (and maybe release ready) version of arbit should fulfill the following goals:
General
-
Data backend
-
Extensibility
We should keep in mind, that we might want to add support for other backends (like the more popular MySQL RDBMS) later, and keep a high abstraction of data access.
-
CouchDB
The document-based approach is particularly well for issue tracking and managing wikis and forums. We use this as initial backend.
-
-
Support for multiple projects
We want to support multiple projects managed by one instance, because the usual developer always has a number of small projects in his pipe, for which it may not seem usefull to setup a complete new instance of the project tracker.
Since projects won't ever share data, we may just use different databases for the differents projects data, which has several benefits:
-
It is easy to move a project to a own / custom arbit instance later.
-
It keeps the databases small, which is generally faster to access.
For each preoject it should be possible to specify a list of sub components, with custom versioning for each. A common simple project may, for example, have different bug categories and release schedules for its website, documentation and the actual source. In other cases the software may be devided in multiple autarchic parts, which should be handled seperately.
-
-
User management
We defenitely need the possibility to maintain different project responsibilities and access rights to the different projects from the very beginning. For this we need a "full featured" user management, authorization and authentication system.
-
Modularized
Each tool for a project should be integrated as a module, starting with the issue tracker, but also wikis, forums and similar, so that they are replaceable later.
We will start with the following modules in version 0.1:
-
Simple issue tracker
Perhaps even without support for complex workflows, but just a very simple plain issue tracker with some statistics.
-
Simple wiki
As a base for documentation and collaborative development we want to provide a very simple wiki with the first release.
-
Simple project statistics
Graphs are always nice to have, but this might a bit more complicate to integrate and perhaps only the modules itself should have graphs.
-
Notification
The system must be able to notify developers about new tickets, commits and other system events.
-
Version 1.0
After the first running version fulfilling the basic requirements for project management there are some more important modules to come with the next versions. Those should be released in several iterations before we finally reach version 1.0.
General
-
User friendly installer
For a general pupose tool we will need a tool (pyrus, pear) for really easy installation of arbit.
-
Bug fixing / stabilization
This is obvious, isn't it?
-
RDBMS backend
To make the tool available for a broader installation base we should support usual RDBMSs as a backend.
Modules
-
build system integration
There are several build systems out there, like ant and phing, which should / could be integrated to provide nightly builds of the projects or similar.
-
VCS browser
We should provide access to the projects code through the several available VCS.
-
Roadmap support for tracker
It should be possible to assign bugs to a release and create roadmaps for releases.
-
VCS integration
Modularized signal handling for tight VCS integration to automatically close bugs, rebuild projects, restart tests, etc.
-
Automatic project configuration creation
It should be possible to create new projects either from the shell or (preferably) from the webinterface.