Edit wiki page
You do not have sufficant permissions to edit or create the wiki page.
=============
arbit roadmap
=============
This is a basic draft for a roadmap for arbit. `Here`_ you can find the roadmap generated by the issue tracker.
.. _`Here`:
http://tracker.arbitracker.org/arbit/issue_tracker/roadmap
Version 0.1
===========
A first running (and maybe release ready) version of arbit should fulfill the
following goals:
General
-------
- Data backend
- CouchDB
The document-based approach is particularly well for issue tracking and
managing wikis and forums. We use this as initial 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.
- 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.