[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] MVP Discussion
There are three distinct topics for the CTI TC to discuss in this thread but want to focus on the MVP discussion with my perspectives and suggestions for consideration by the community at large.
Please note full support of the core objectives here of clearly defining our near term road map for our initial MVP release ASAP. This is an argument for a alternative approach to the MVP process to meet this shared community objective.
(1) We should simply vote up/down (Yes/No/Abstain) the Items (aka "Features") for inclusion in the initial release MVP.
(2) Some Items are not well described, are highly subjective in interpretation, or have an obvious bias in their descriptions. We should allow for iteration through this process. If one is not certain of the implications to their Use Cases and Requirements,
they can Abstain in this round and make comments on these Items.
(2.1) Using this process we should clearly identify those broad consensus Must
Items for inclusion in the MVP in the first round. The subcommittees and working groups can immediately continue/begin work on these
Items.
(2.2) We will also identify those Items requiring further definition for a reasoned CTI TC decision for inclusion in the initial MVP (or deferred to subsequent rounds).
(2.3) There may also be some complexities and inter-relations that impact other
Items. We will prioritize those deferred Items where they intersect with CTI TC consensus
Items view identified (2.1). This also helps us triage and select items for deferred discourse in subsequent rounds.
(3) I do not agree at all with ruling anything out for future consideration. These are long term decisions for the CTI TC and we should not in anyway arbitrarily constrain our vision/options now.
(4) An approach that requires discourse on future features/functions now will only delay our progress. By leaving all options on the tables for future consideration we can desensitize our current discourse, collectively and narrowly focus on "what" an
MVP Item is for the next release of the CTI TC standards. We can then iteratively apply our Lessons Learned, community outreach/engagement, consensus building on what will be included in the next release.
We all move forward together.
Patrick Maroney
President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org I think the purpose of a survey is to get a more nuanced answer to each feature.
The final binding vote should indicate in/out for each feature, but the vote should be for the list as a whole.
From: Mark Davidson [mailto:mdavidson@soltra.com]
Since we are talking in/out list primarily, perhaps we could just have a checkbox for each option? Checking yes means “In for 2.0” and leaving the checkbox empty means “out for 2.0” with no additional clarity about abstain/2.x/never.
Personally I think the important decision in front of the group is the in/out list; the rest of the detail is IMO a nice to have and not necessary to proceed on 2.0 work. This list is something that people will point to for a while, so I’d like to do our best to get it into the OASIS ballot facility.
Thank you. -Mark
From:
<cti@lists.oasis-open.org> on behalf of Chet Ensign <chet.ensign@oasis-open.org>
All,
Bret and I talked about what sort of information he'd be looking to collect. Something along the lines of...
Option 1: Yes, No, Maybe, Abstain, 2.0, 2.1, 2.x, Never Option 2: Yes, No, Maybe, Abstain, 2.0, 2.1, 2.x, Never ...
It is indeed difficult to see how that could be done with the OASIS ballot facility. My two concerns are (a) that whatever ballot mode is used must be available to all members and (b) that there must be some way to ensure the results of such a ballot are available for the long haul in the TC's archives.
I doubt that anyone would be blocked from using SM so no problem there. So I'm ok with doing it this way:
- Bret (or whoever) posts an email to the TC mailing list pointing to the survey and giving an end date when it will be closed. - When the survey is closed, the detailed results are downloaded and loaded to the TC's or Subcommittee's document repository. The email that is generated when a document is loaded can be annotated to state that these are the results of the survey mentioned over there.
That way, 3 or 4 years from now, if someone asks 'how did you come up with that list' there is an audit trail to point to.
We also discussed an approach to making the issues being debated in Slack easier for those outside the discussion group to track. More to follow on that but one key thing I suggested was a disciplined use of an issue tracking system. While we are in discussions to migrate the existing open source projects to OASIS, I told Bret that you should all feel free to request that we start projects for you now if it would be useful (and not redundant I suppose). The steps for doing that are explained in https://www.oasis-open.org/resources/open-repositories/faq
Best,
/chet
On Tue, Apr 5, 2016 at 1:14 PM, Piazza, Rich <rpiazza@mitre.org> wrote:
--
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]