[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [EXT] [openc2] RE: Workflow change
OpenC2 Technical Committee,
Do you agree with the following procedure?
· A subcommittee or tiger team will execute the day-to-day business of drafting, soliciting, and resolving comments to documents, specifications etc.
· The subcommittee will provide updates to us throughout the process and may ask the TC for feedback and help
· When the subcommittee reaches general consensus, it will notify us and provide a draft and any recommendation(s)
· Based upon TC review, the TC will accept the subcommittees submission, send it back to the subcommittee for further deliberation or (I suspect this will be rare) outright reject the submission
If you agree with this in principle, would you like to leave some of the mechanics to the discretion of the subcommittee chairs, or do prefer that the TC spells out the number of comment periods, the length of the comment periods, how the comments are to be provided to the subcommittee?
I would like to put the ‘pushing concepts far too quickly’ opinion in context:
· This TC imported a document of approximately 150 pages from a forum [which has since been decommissioned].
· Prior to June of 2017, that document had general consensus and running code [from the legacy forum].
· This TC has been in operation for four months and its SC has reviewed and resolved numerous comments.
· The Language SC presented 13 pages of the 150 page document and asked the TC for its agreement on the scope and meaning of the 31 actions and the general form of the frame.
It is my opinion that asking the TC to agree on the 13 pages is not particularly hasty.
I was in fact present at the TC meeting that took place at 21:00 and I will remind you of the gist of the comments; One of the members present at the 11:00 meeting was not comfortable with proceeding on the vote on the 13 pages, so a motion was passed to create an electronic ballot and the matter regarding the language spec would be settled two weeks hence. This is a case where a single member was uncomfortable with holding the vote at that time and the matter was essentially postponed to provide more time.
Regarding version 0.2.0 of the language spec; Version 0.2.0 may be presented to the TC at the Language SC’s discretion. If presented, the TC will be asked to accept, reject or send it back to the SC for further deliberation. It is my understanding that the Language SC is asking the TC for agreement on the scope and the meaning of the targets. The baseline for these targets are from the 150 page document that was imported last June.
If you could provide specifics of what you think the difference is, that would help. I read your proposal and immediately thought “+1 -- that is what I understand the charter already calls for”. There are unspecified details that need to be put down in writing, but there are no conflicts or inconsistencies.
B: 1) The SC works on content or a document until they think it is done and ready for prime time
2) At this point the SC would inform the broader TC that they have a document that they would like the broader TC to review.
J: * When the subcommittee reaches general consensus, the entire TC is notified and provided the draft.
D: These look identical – the work of developing a document happens at the SC level, and the SC decides when it is ready for prime time.
B: 3) A two to three comment period would be opened up for the whole TC to review and comment.
4) The SC will take the comments and feedback and rework the document. This process would then rinse and repeat until there is no more substantive comments in the document.
5) Once all substantive comments are resolved, then an electronic ballot would be opened to give people one last two week period to review before they vote.
J: * The TC is asked to review the document. At this point, the TC is asked to either accept, reject or send it back to the subcommittee for further work and deliberations.
D: These are consistent. I believe Duncan gave one week notice on LS v0.1, but the review period can certainly be codified as two or three weeks. There is no difference between Bret’s 4 and 5 – every time the SC submits a document to the TC, all substantive comments have been resolved and the document is ready to be accepted. So an electronic ballot is opened every time, and if the document doesn’t pass, then the rinse and repeat cycle continues. The “last two week period” is the one preceding a successful vote – if the vote failed then it wasn’t the last.
TC DECISION: “How does the TC accept a document or send it back for rework?”
1) TC accepts a document from the SC and opens a two week electronic ballot
2) TC accepts a document from the SC and announces a voice vote at the TC meeting following the two week review period
If a voice ballot were held at a TC meeting, a majority of *voting* members would need to pass it, so the results should be the same as an electronic ballot with respect to TC-wide consensus. But to avoid any perception of “ramrodding”, I fully support requiring all TC votes to be held electronically, at least until the TC decides that that perception is unwarranted and changes the rules back to re-enable meeting votes.
The manner in which you are defending the existing process which I now believe is not what I am suggesting is illustrative that the concerns we have are not being heard.
I feel like this group is trying to push concepts through far to quickly. The fact that last night you mentioned that Allan’s motion is now going to delay us, is further evident of that.
5-8 people in a working call does not constitute TC wide consensus. Your statements last night that we would resume the up/down vote at the next full TC meeting, in my belief is yet further proof.