History for TrackerFederation

??changed:
-
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