CRAVEX-integration: Integration with Issue trackers: generic

[pombredanne]

The goal is to design a framework to integrate with issue trackers.
And create some proof of concept.

[DennisClark]

The integration framework should address:

• User mapping
• User group (permissions) mapping (to be determined if this is necessary)
• Issue status mapping
• Issue subject (title) mapping
• Issue description mapping
• Issue comment mapping
• links to attachments

[DennisClark]

User mapping: Most issue tracking applications identify users via email address, directly or indirectly (an application-specific user-id with an associated email address in its profile). This maps nicely with DejaCode (indirect), but can be complicated with an AboutCode application such as SCIO where user-ids are not required. A few possible approaches to resolve this:

1. Enhance the AboutCode application to require a user-id (with an email address), and/or
2. Identify an AboutCode application level user-id, with email address, to use as a default when a specific user-id is not available or has no clear mapping to the issue tracking application.

[DennisClark]

Issue status mapping: Most issue tracking applications have a basic set of issue status values (e.g. GitHub has simply Open and Closed). DejaCode has 3: Draft, Open, Closed (a Draft status DejaCode issue should probably not be integrated), so that is a simple and obvious mapping. For issue tracking applications with more flexible and nuanced issue status values, we should provide a means to identify the ones that correspond to Open and the ones that correspond to Closed (rather than expand the scope of this to provide AboutCode applications with multiple user-definable issue status values).

[DennisClark]

It should probably not be necessary to create a standalone "mapping application" for AboutCode integration with issue tracking applications for the various corresponding informational fields, especially since the mapping should be reasonably obvious for fields such as title, description, comments, etc. A configuration file should be sufficient, or in the case of DejaCode by simple additions of new fields as necessary on the Dataspace definition.

[DennisClark]

Integration triggering: As described in issue #354 integration triggering from DejaCode is based on the creation of a Request in Open status, modifications to that Request, or a change to the status of that Request; integration to DejaCode should be triggered whenever there is a change in content or status in the issue tracking application. In the case of other AboutCode applications, an integration triggering event may possibly be the result of the detection of compliance warnings/errors; that will need further analysis and possibly require a configuration setting.

2-way activity: Ideally, issue tracking applications should trigger updates to DejaCode Requests when there is activity on an issue. In the case of other DejaCode applications (those with a UI, such as SCIO) it may be best to display the URL and Status of the issue from the tracking system so that a user can easily navigate to it.

[mjherzog]

This integration needs to be focused on DejaCode only where we have a framework for request processing. This framework does not exist in any other AboutCode application at this time (e.g. SCIO) and is not planned for the foreseeable future. We are planning to added user access controls and permissions to SCIO but that does not provide any request processing functionality.