Define and document issue workflow

[michaelcfanning]

A preliminary proposal for driving issue workflow for spec changes. We should refine, add to and subtract from this content in discussion here.

• All activity that may impact spec content will be tracked as issues, e.g., Define driving principles for SARIF effort #1
• We encourage discussion on the public issues. Editors will ‘curate’ by applying specific tags, ensuring content from other sources (email) is recorded, etc.
• Editors will prepare proposed changes in separate repository branches. A clean document with revisions tracking enabled will be used for driving specific textual proposals.
• Any issues that require time-sensitive discussion will be driven through the mailing list (this should be rare)
• Issues that are ready for final approval or which warrant discussion on the telecon will be tagged in advance of each meeting.
• After telecon approval/rejection, PRs will be merged or closed unmerged as appropriate.
• This process (with additional details) will be driven by an open issue and documented in a file persisted to the repository (and will be approved next TC)

[ghost]

Here are the tags I propose to apply to issues in this repo. They are mostly a subset of the tags in the original spec repo https://github.com/sarif-standard/sarif-spec:

• bug: The issue prevents the file format from correctly and consistently representing the information necessary to support the scenarios for which it is designed.
• enhancement: The proposal adds support to the spec for a new scenario, or provide richer support for a supported scenario.
• domain-result-management: The issue is specific to the domain of result management.
• domain-security: The issue is specific to the security domain.
• impact-breaks-consumers: The proposed change to the format would prevent consumers of the format, such as viewers or result management systems, from consuming some or all valid log files.
• impact-breaks-producers: The proposed change to the format would render invalid log files created by existing producers, such as analysis tools or converters.
• impact-documentation-only: The proposed change clarifies or enhances the documentation, but does not affect the format.
• impact-non-breaking-change: The proposed change to the format is backward compatible with all conforming producers and consumers.
• process: The issue relates to the process of producing the TC's work products, rather than to the content of the work products themselves.
• prototype-needed: The practicality of implementing the proposed change is unclear; the change should be prototyped in code before being considered for adoption.
• question: The issue is a request for information, not a proposal to change the format or the documentation.
• ready-for-approval: The issue has been discussed and a resolution reached, the spec has been edited with change tracking to reflect the change, and the change is ready for approval at the next TC meeting.
• resolved-by-design: If the issue is a bug, this tag means that the existing behavior is as intended and will not be changed.
• resolved-deferred: The issue is deferred for consideration in a future version of the specification.
• resolved-duplicate: The issue is a duplicate of another.
• resolved-fixed: The changes to the spec have been approved at a TC meeting and have been merged into the Working Draft.
• resolved-wont-fix: If the issue is a bug, this tag means that the bug will not be fixed. (This should be rare!) If the issue is an enhancement, this tag means that the TC has decided not to incorporate the proposed change into the spec.

[michaelcfanning]

Workflow reviewed and approved by project editors and others. Checked in at https://github.com/oasis-tcs/sarif-spec/blob/master/Workflow.md