We have talked a few times now about the desire to move forward as quickly as possible on STIX 2.0 but also of the need to balance this with the requirement of nailing down STIX 1.2.1 first as an initial OASIS version. We have also talked about the need for a coordinated and deliberative process once we do actually get working officially on 2.0.
Unfortunately, we haven’t really given you much detail in what that means beyond the simple principle.
In an effort to provide a little more clarity, reduce uncertainty and level set our expectations we have put together an outline of the proposed specification development process for STIX 2.0 (In reality, this basic process would be the same one followed for pretty much any SC work products). It highlights the important central role of both use cases and the issue trackers to help scope, frame, focus, coordinate, collaborate, track and record our efforts.
There are obviously many other details not represented here but this outline should give a solid feel for the key milestones and dependencies in the process.
Outline of proposed 2.0 language specification development process
Performed by the SC as a whole and its various members ( this set of activity could occur pre-official 2.0 kickoff and in parallel with work on 1.2.1 )
Codify relevant use cases for STIX (these will be captured on the STIX wikis)
Identify potential use cases Codify rough initial outline for each use case Evaluate and coordinate use case discussion at the TC level Identify initial consensus scoping of use cases Iteratively discuss and refine use cases while codifying their evolutionary detail Confirm consensus scoping of use cases
Performed by each contributor ( this set of activities could occur pre-official 2.0 kickoff and in parallel with work on 1.2.1 )
Review current content of trackers ( STIXProject/schemas STIXProject/specifications ) (NOTE: the language specification relevant issues will likely eventually be merged into the STIXProject/specification tracker)
Add new entries for issues you want to raise that are not currently present
Identify issues that you think should be in scope for consideration for 2.0 (NOTE: This does not mean assigning a STIX 2.0 label to the issue within the tracker. That will need to be done at the SC level as described below)
We will need to work on a technical mechanism for supporting centralized coordination of this but for now feel free to capture it yourself in whatever form is most convenient
Assert your prioritization of issues based on importance
We will need to work on a technical mechanism for supporting centralized coordination of this but for now feel free to capture it yourself in whatever form is most convenient
Contribute initial thoughts on issues into trackers
Performed by the SC as a whole ( this set of activities would be post-official 2.0 kickoff and the basis of the formal 2.0 work )
Select work product editors Review set of issues suggested as in scope for 2.0
Identify consensus scoping of issues for consideration Identify and eliminate unnecessary duplication between issues (merge/consolidate where appropriate)
Identify cross-dependencies and impacts between in-scope issues Identify use cases relevant to each issue Identify consensus prioritization of in-scope issues based on importance Prioritize in-scope issues based on dependence (which issues should be resolved before others as their resolution impacts the others) and importance
Based on priority, focus on 1-3 issues at a time discussing on list, iterating on potential refinements/changes and capturing specifics into trackers
For proposed refinements/changes identify use case justification as well as use cases negatively affected As each issue settles, assert initial consensus and move on to other issues
As later issues settle towards consensus their discussion and proposed refinements/changes may effect previously settled issues and may require they be revisited. One potential consensus may be to remove the issue from 2.0 scope consideration
Once all in-scope issues have settled
STIX 2.0 specification work product editors capture totality of refinements/changes into specification documents All SC members review STIX 2.0 specification documents containing totality of proposed refinements/changes and offer comments STIX 2.0 specification work product editors discuss and iterate on comments until documents settle
One key takeaway to highlight is the fact that the set of activities listed under numbers 1 & 2 (the first two blocks in the outline) can be pursued immediately by the SC members and in parallel with ongoing STIX 1.2.1 activities. In fact, getting this set of activities well along should set us up solidly for the actual formal work on 2.0 including giving us some focus on how we talk about issues rather than bouncing willy-nilly from issue to issue like pachinko balls.
In that light, we encourage everyone to start tackling these steps as soon as you can.
The outline will be posted up on the wikis and will be maintained on an ongoing basis.
We hope that the outline presented here is clear and helpful in understanding the proposed process going forward.
If anyone has any questions or concerns with the process outlined please let us know.
Thank you,
Sean Barnum
CTI STIX SC Co-chair
