This is going to be a long post, but I'm trying to express my main concepts for Bit Vizier itself, and how I can leverage TurboGears to make Bit Vizier happen.
I am not limiting Bit Vizier to be used for F/OSS projects. I want it to be capable of being used for something as small as a one man project, up to as large as a medium sized corporate help desk. This changes some of the assumptions that would normally be made.
Bit Vizier will be built around three core concepts: Entities, Tags, and Views.
An Entity is, simply put, a thing to be stored and retrieved from the system. It can be anything at all. In my white board notes, I used three examples: Tasks, Documentation, and Assets. Allow me to break these down a bit more.
Tasks represent work to be done. These can take on numerous forms, such as scheduled tasks, development tasks, call logs, and trouble tickets. Each of these task types has their own requirements, their own way to be displayed, and their own work flow types.
As an added bit of complexity, a user might not have permission to view a specific task until it enters a given state. For example, a development task might have to go through an approval process before it can be viewed by the development team.
Finally, tasks can spawn other tasks, and even be dependent on them before they can be closed. A classic example of this would be a trouble ticket spawning a development task, and unable to be closed until development is complete.
Documentation actually comes in two flavors: Static and User-Generated.
Static documentation will include such things as doc strings and any other documentation that comes with Bit Vizier. This is intended to allow an installation of Bit Vizier to be complete and stand alone from any other installation.
User-Generated documentation is likely to take the form of a wiki, allowing the users of a given installation of Bit Vizier to enter their own documentation about the topic at hand. For instance, if Bit Vizier is deployed in a F/OSS project, I would expect to see pages about getting the latest development version, a FAQ, how to get involved, and the like. Whereas for a corporate help desk, I would expect to see pages about policies and procedures.
As a possible side note: It would be worth the time investment to ensure the ability to store sensitive data in the wiki, including passwords. With sufficient protections, it could make a very viable way of distributing sensitive data only to those who need it (such as passwords, account numbers, etc).
Assets can be most anything, but are generally going to represent some physical item such as a computer or a cell phone. This would provide a way of tracking who has been given what specific item. This is almost exclusively useful for corporate deployments, and should likely be an entirely separate (and optional) extension.
As a final note, all entity types will support the concept of a changelog, recording the data about who changed what values and when. This is important for accountability purposes.
Tags are arbitrary names that can be assigned to Entities using an M:N relationship (any tag can be on any number of entities, and any entity can have any number of tags).
Some specific choices about tags here that make them slightly different than what you might be used to elsewhere have been made. For instance, it should be possible to place tags into tag groups, and make it so that a given entity type must choose one (and only one) from a given tag group. This would replicate the idea of a ticket going to specific department, and only being in that department, even though it may well have other tags that could be interesting.
In addition, entities should be able to specify requirements regarding tags and tag groups. For instance, no tags allowed, one (or multiple) from specific tag groups, or a free for all. And it should also be controllable by the installation administrator.
Tags should also be able to be defined by the installation administrator for system wide tags, or by the user for private tags.
Finally, tags should also have a "shared" attribute, which will serve a dual purpose: On system wide tags, this will indicate that other systems can receive this tag/entity. On user defined tags, this will indicate that other users can see this user defined tag.
The last significant piece of work (for now) for the system will be views. A view is a collection of tags and tasks displayed to the user.
Similar to tags, views can be defined by the installation administrator, or they can be defined by the user. Also similar to tags, views will have a "shared" attribute, which will perform the same function as the same attribute on tags.
Views will also be the result of a search, which means a simple search will produce a new user defined view that the user then will have the option of saving.
Finally, views will come in three types: Condensed, Expanded, and Detailed.
Condensed Views are meant to provide single row display of summary information about the entity.
Expanded Views are meant to provide the equivalent of Google search results, where you will get a couple of lines of output regarding the entity.
Detailed Views are meant to provide a full screen view of an entity, and will (as a result) show everything: change logs, comment logs, patches, everything.
Where To From Here?
There's a lot of information up there to digest, and that's all from just one white board's worth of notes (and, considering my handwriting, that's pretty impressive).
TurboGears, with Sprox and the tgext.admin extension, are going to provide me with much of the backbone for this. In fact, now that I have this much, I can foresee getting a basic issue tracking system that meets these requirements out the door quite quickly thanks to TurboGears. Since it's now the end of October, I'd expect to see the equivalent of a 0.4 release by the end of December which fulfills all of these basics.
And The Shared Issue Tracking?
After that, it's going to be time to consider getting the shared issue tracking working. I think I have ideas for this now that are worth considering.
Right now, I'm looking at having the installations of Bit Vizier use self-signed SSL certs for validation. Provided I do this carefully, it will be possible to build up a web of trust, much like GnuPG/PGP. This would allow authenticated connections between Bit Vizier installations.
When those options are not available, it will also be possible to use plugins capable of talking to other systems, so that I will have (for example) a BugzillaAutomator that will upload and download from Bugzilla trackers, a similar one for Trac trackers, etc.
In conclusion, I'd like to toss a few words of thanks to the TurboGears team. They're being hugely supportive of these ideas, and their work is making mine much easier.
Thanks guys. I do appreciate it.