:For one of our several major projects we created a new Hackystat project that included the workspaces of the 4 components we used.
What advantages do we get by defining a telemetry stream that shows each toplevel project? To me it seemed that Hackystat projects were best defined for software components and that "business level projects" were best defined by composing themselves from other hackystat projects -- we just had to simulate it by defining it using the same workspaces.
That makes sense to me. Hackystat does not currently have any facility for to compose projects together into super-projects (and performing analyses at that level). We could do it, of course, but I think it's a long way off since we have so much work to do just figuring out how to deal with the simple project level.
For us, several software modules are shared across several projects. Business projects have a shorter lifespan than software projects. Consequently a software module may be improved several different times, each as a result of different business projects. So we may want to see the entire timeline when looking at a software module, but when looking at the effort for a business project we may only want to see the timeline during the begin/end period for that business project. I guess that's why using the Hackystat projects the way I described earlier makes sense to me. How could we use the projects differently, and what benefit would this new templating setup bring to us?
If I understand you correctly, you're using projects correctly, in the sense that you use projects to:
(a) define a short-term increment of work over a set of workspaces. (a "business" project).
(b) represent the long-term history of one or more workspaces (the 'lifespan' of a functional unit)
And, of course, these projects can overlap, both in terms of the time interval and the set of workspaces involved in them.
In answer to your question regarding the utility of the templating setup, the first thing to note is that all telemetry occurs at the level of an individual project; there are no facilities to support, for example, a telemetry report consisting of three charts, each reporting the size of a different project. In other words, in any given telemetry report, all of the charts are going to provide values regarding a single project.
In our case, the hackystat project consists of a couple dozen workspaces and a dozen developers. Let's say that we are interested in, for example, the active time by each developer on each workspace. Right away, that's 288 distinct telemetry streams. Templating allows us to avoid having to manually define and name all 288 streams. It would seem to me that you will soon hit a similar point with your current setup, where you find that the number of streams you want becomes a multiplicative relationship between components, developers, and an analysis. As soon as you start thinking, "This is going to be a ridiculous number of telemetry streams to define", templating will hopefully come to your rescue.
Cheers, Philip
