TrackerFederation

Status: Very intial discussion

We see a need to be able to coordinate numerous distinct trackers, which we're considering doing with some kind of federation.

As it stands, there are good reasons for distinguishing collections of issues, according to aspects like traits and relevant supporters (and clients, in dedicated trackers). Additionally, issues represent support history, valuable for later knowledge mining and for capturing support performance. In our implementation, trackers represent the application domain and administrative contexts for the issues.

At Digital Creations, part of our business is support, both of commercial (paying) customers and of open source participants in the development of our wares. This means we provide support for diverse communities, having varying support requirements modulo concerns like privacy levels and topic focus, and, generally, distinct topic domains.

These distinct purposes can call for separate issue collections to provide operation for the specific audiences, which we implement with separate trackers. However, this simplification can complicate the job of support management, who need to coordinate supporter efforts across support efforts, and also can complicate the mining of knowledge from the established issues across these efforts.

We see addressing this with a federation layer over the trackers, enabling consolidation of search, reporting, and supporter assignment while maintaining decoupling of the subject domains. We see a need to be able to coordinate numerous distinct trackers, which we're considering doing with some kind of federation.

While we could reorient trackers to contain numerous separate domain collections, we would simply be pushing the issue of encompassing the separate collections within the context of a single tracker, and we would either be sacrificing the option of having the separate domains handled in separate locations - ie, separate trackers - or we would have to implement a federating layer on top of the encompassing trackers, anyway. Given that it should be no harder to implement a federating layer across several trackers, and would be necessary anyway, the tracker is the right unit of resolution for an application domain.

While it's designs were not initially motivated by federation, the tracker is constructed with a combination of ZClasses, Zope Python Products and External Methods, so the tracker implementation is fairly intensively object-oriented - and thus, it should be quite amenable to federation. Zope's inherent xml-rpc access to its objects may even be easily exploited for inter-site federation.

Owner: KenManheimer Last major modification: May 7, 2000