[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] RE: Outline of proposed 2.0 language specification development process
Okay. I think I understand a little better now. Let me take a stab at further clarifying intent.
I think the answer for intended approach is twofold.
First, Step 3.3 "Based on priority, focus on 1-3 issues at a time discussing on list, iterating on potential refinements/changes and capturing specifics into trackers” is
intended to avoid the "email storm of all of these issues being discussed” problem. We should be deliberatively going through issues in a coordinated fashion and not be throwing things out
willy nilly or discussing issues that are not on the table at the time.
Second, it is the responsibility of the co-chairs and work product editors to “lead” discussion on the issues, elicit input as needed, help to clarify and consolidate, raise cross-dependency
issues, call for informal consensus “votes’ or formal votes as necessary, declare initial consensus and manage which 1-3 issues are on the plate at any given time (based on consensus prioritization). If needed or appropriate the co-chairs and work product
editors could seek out and request others to “lead” discussion of particular issues but that would be ad-hoc based on circumstances and the base responsibility falls with the co-chairs and work product editors.
Does that make things clearer or are there still open questions that we need to resolve?
Sean
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Bush, Jonathan" <jbush@dtcc.com>
Date: Monday, August 24, 2015 at 10:06 AM To: "Barnum, Sean D." <sbarnum@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] RE: Outline of proposed 2.0 language specification development process Thank you Sean, let me attempt to elaborate on my last question. I assume that once we have a list of issues we are trying to tackle, we will all want to know if anyone in particular is “leading” the discussions on a particular
issue. If we don’t have that, I fear we will be left with an email storm of all of these issues being discussed, but it will get tough to get to resolution without a
person that is responsible for bringing them there. From: Barnum, Sean D. [mailto:sbarnum@mitre.org]
Thanks Jonathan. Comments inline below From:
"Bush, Jonathan" <jbush@dtcc.com> Great process here! A couple random thoughts: ·
I really like the idea of the use-cases. As someone new to STIX and the industry, this is something that would extremely helpful. ·
I think that the issues worked on in step 2 below should reference back to the use-case in step 1 (or propose a new use-case). This will let us
focus on the issues that have the most meaning, and steer us away from ‘busy work’.
o
I know you have that in step 3 below, but I think it can start earlier, with the items that are already open issues, and after we have identified
the base use-cases. [sean]I agree that Step 2 can also benefit from aligning to use cases. I did not list it as a required activity in Step 2 as I think it will take a bit
of time to flesh out the use cases and it would be good to have people reviewing and thinking about issues even before the use cases are completely done. I kind of think Step 1 and Step 2 will overlap and occur somewhat in parallel. I originally had a substep
within Step 2 about aligning to use cases but removed it as I did not want to imply that people shouldn’t be reviewing issues now. Good catch though. ·
To prioritize the issues we tackle, I would suggest a simple vote where each member of the TC puts a weight on each issue in the list (numbered from
N to 1). Combining the votes, we will have a group priority order. [sean]Yeah, this might be an effective way to “Assert your prioritization based on importance” and to "Identify consensus prioritization of in-scope issues based on importance”. We will
need to discuss as an SC which approach is the most appropriate. We will also need to remember that this prioritization is a first step of prioritizing but not the last step. After this, we will need to also consider dependence between issues. ·
How do we propose settling issues that we as a group can’t come to a consensus on? We should certainly strive for consensus, but my experience with
groups of over 3 or 4 people is that it is tough to always accomplish. Do we need a majority vote to move a proposal forward into the 2.0 spec? [sean]We need to remember that consensus does not mean unanimous. As long as there is broad general agreement on issues and nobody that strong and persistent objections we can move forward under consensus. For issues where there is
not broad general agreement or there is strong and persistent objections we will either need to keep discussing or at some point potentially call for a formal vote (we want to try hard to avoid this). We should also always remember that one potential option
is also to remove the issue for consideration at this time rather than pushing towards immediate conclusion over the objections of others. ·
My biggest question on all of this is “who is doing what?”. Do we have a way of tracking this sort of thing? I would fear that multiple people
would be working on the same item or worse yet, items get missed. [sean]I am not sure what you mean by “who is doing what?” If you mean reviewing, discussing, formally commenting on, prioritizing,
modeling options on various issues then I think the answer is everyone. We should all be doing all of these things all the time. Which particular issues we are focused on at a given time should be governed by our prioritization. If you mean coordinating votes,
drafting results into documents, etc. then this would be the responsibility of the co-chairs and the assigned work product document editors. Does that answer your question or am I misunderstanding? From:cti-stix@lists.oasis-open.org
[mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Barnum, Sean D. 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
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
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]