First off, we know the following:
1. Sensor data collection is inherently unreliable. We can't guarantee 'perfect' data collection.
2. Telemetry should degrade gracefully; we shouldn't require complete data to do useful analyses.
3. In the domain of issue management, the number of current open issues is probably the number one most useful telemetry stream.
Unfortunately, the current design of the Issue sensor makes (3) problematic:
- we won't have all of the Issue events available to us;
- we would have to search through all our records and 'reconstruct' which are open;
- we will need to have a complete history of the issues from the start of the issue management system
An alternative approach to getting (3) is a kind of 'snapshot' mechanism, in which the Jira sensor wakes up once a day, queries Jira for the set of open issues, and emits a set of specially indicated Issue events that comprise a 'snapshot' of the open issues on that day. We could 'specially indicate' these issues by including a key-value pair in the data field such as OpenIssueSnapshot=<timestamp>, where all of the open issues in this list would share the same timestamp value. (That would enable the sensor to send it twice in one day and allow the telemetry stream to use only the last received set).
This would not replace the current mechanism, it would simply supplement it.
Finally, we would need to indicate which account should receive this data. I suggest an extension to the usermapping system to enable us to indicate, for example, that hackystat-l should get this data.
Cheers, Philip
