[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Feature voting and tracking system
The intent was not that this “voting” would be the sole arbiter of prioritized ordering.
If you look at the
proposed development process for 2.0 that we discussed, agreed to and published a couple of months ago you will see that the intent is that each member review tracker items and then offer their opinion on prioritization “based on importance” using a TBD
mechanism (what we are discussing now). These individual opinions would then be considered in aggregation and then factor in other criteria such as cross-dependencies and impacts in order to reach an actual prioritization.
This aggregate prioritization is characterized as:
"
Review set of issues suggested as in scope for 2.0
“
This “voting” and prioritization technical capability would be used to serve item “a.” in the list above.
I spoke with Aharon and we are both fine if the SC decides that they are okay with Aharon and I doing the above aggregation and prioritization analysis ourselves and then presenting it as a roadmap. Our concern is that all voices are heard and that there
is no appearance of bias or favoritism on our part. That is why we have proposed using a mechanism to capture everyone’s opinions in an explicit way. As discussed on the call, one option for the solution is to not have a technical “voting” capability and have
the co-chairs establish the roadmap. It should be up to the SC members whether or not they prefer this option over the others.
I certainly agree with "less talk about how to do things, more actually doing things.” That is why I would like to move past talking about capabilities like this and actually decide on which capability to use.
sean
From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Thursday, October 22, 2015 at 11:19 AM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Feature voting and tracking system So I have to admit that I still don’t really understand the whole voting thing. What are we using the votes for, prioritization? Or will issues that get a lot of “downvotes” not get addressed?
I think I said this on the call yesterday, but my preferred approach would be for someone (the co-chairs) to lay out a rough roadmap of the issues that we need to address. They can take into account list preferences, dependencies between issues,
etc. In particular, they could identify some fundamental issues to talk through first before hitting the specifics. Then they send that roadmap to the list and if anyone wants to add to it or disagrees with it we talk about it.
I worry that if we just rely on upvotes we’re going to tackle things randomly rather than strategically and we’ll end up spinning our wheels. For example, if you look at our previous conversations on relationships we ended up with short diversions
to versioning, IDs, markings, and other topics that we probably should tackle separately, first, so that they don’t keep coming up in other discussions.
I do like the idea of threaded conversations. The mailing list is difficult if you miss even one day of a quick discussion. Though it seems like the mailing list + Github is working *OK* (not great, but OK) and I wouldn’t want to spend months
figuring out how to switch to Stack Exchange when we could be actually working on STIX issues during that time.
To sum up: less talk about how to do things, more actually doing things.
John
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]