OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [chairs] Seeking your feedback on proposed workflow changes


Thanks Duncan,

We will be getting final approval from the Board Process committee in the next 2 weeks. Then we can start planning a roll out.  I just wanted to get some feedback from the membership before this change was made. I am glad you and everyone else likes the proposed changes.


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."



On May 26, 2020, at 11:09 AM, duncan sfractal.com <duncan@sfractal.com> wrote:

Going back to the original request for feedback. Like everyone else who has stated preferences, I prefer the new proposal.
I imply from some of the comments that some of these are already in use.
Can I start using this new workflow today on a draft Iâm working on? If not, at what date can I?
 
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
 
 
From: Chet Ensign <chet.ensign@oasis-open.org>
Date: Friday, May 15, 2020 at 11:39 AM
To: "tc-announce@lists.oasis-open.org" <tc-announce@lists.oasis-open.org>, "members@lists.oasis-open.org" <members@lists.oasis-open.org>, "chairs@lists.oasis-open.org" <chairs@lists.oasis-open.org>
Cc: OASIS Board Process Committee <board-process@lists.oasis-open.org>, Bret Jordan <bret.jordan@broadcom.com>
Subject: [chairs] Seeking your feedback on proposed workflow changes
 
Dear OASIS Member,

The OASIS Board of Directors' Process Committee is currently evaluating proposals to simplify the process of creating and maintaining Technical Committee work products. The committee requests feedback on the proposal below from the general OASIS Membership. The plan, if the proposal appears desirable, is to implement this change as part of the July 2020 TC Process updates.

Current Process

Today, the editors in TCs request a Working Draft (WD) template from TC Administration and use this template to collect ideas and write content. These WDs are initially stored in Kavi, SVN, GitHub, Google Docs - where ever the editors are storing drafts. They can iterate and number these WDs as frequently as they want. When the TC decides that the WD has progressed sufficiently, they can approve it as a Committee Specification Draft by a Full Majority Vote, either by a motion in a TC meeting or by electronic ballot.

At this point, they *may* choose to submit the work to TC Admin for publication on the docs.oasis-open.org library (where the numbering will start all over again) or they *may* keep it locally in their doc store.

At some point, the TC will decide to approve submitting the work for public review, again by Full Majority Vote. At this point, the CSD is published online in the docs.oasis-open.org and given a Public Review Draft number that may differ from the CSD number. Per the TC Process statement that "No changes may be made to the public review draft during a review," the editors may also assume that all work on the draft must then stop.

The end result can be a lot of dead-air time for the work product, ballot fatigue if the TC is using electronic ballots to approve every iteration of the draft, and work product numbering across the various iterations that is confusing to the TC members. A TC for example could have specs where...

Spec v1.1 reached WD07 which then became CSD01, followed by 02 and 03 on Kavi, which then became CSD01 all over again when published on docs.oasis-open.org. That, or a subsequently approved and published CSD, then becomes CSD##/PRD01 for its public review. And the beat goes on. The multiple, overlapping naming and numbering schemes can become very confusing for the TC members - not to mention interested parties outside - to follow.  

The Proposal

The proposed idea is simple: editors create and maintain Committee Specification Drafts. A TC work product is a CSD until such time as it holds the Special Majority Vote to approve it as a Committee Specification.

Working drafts would just be individual contributions to the editors and would require no special template.

When the editors begin their work, they will receive a Committee Specification Draft template where some fields (such as the version URLs) are reserved for TC Admin to supply later. The TC can approve iterations of the CSD by Simple Majority Vote in TC meetings until they are ready to request publication by TC Admin. That will require (as it does now) a Full Majority Vote, either by motion in a meeting or by electronic ballot.

Public Reviews will be done on Committee Spec Drafts, not on identical copies labeled Public Review Drafts. The TC can approve that a CSD be released for public review and TC Admin will add a document to the CSD's directory flagging it as released for public review. The content reviewed, however, will be that of the CSD.

The end result will be a simple sequence of CSDs until such time as the TC approves the CS. So, instead of a confusing sequence like the above, just something like...

Spec v1.1 => CSD01 => CSD02 => CSD03 which is submitted for public review and then, no material changes being made, is finally approved as CS01.  

We feel this change can reduce the number of formal ballots, reduce lag-time in the editorial process, and simplify today's confusing number scheme.

Please feel free to send comments and feedback to me and/or to Board-member Bret Jordan (bret.jordan@broadcom.com) and we will share them with the Process Committee. We look forward to hearing from you.

Thanks

Chet Ensign and Bret Jordan on behalf of the Board Process Committee 
 
-- 

/chet 
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open source & open standards for the information society
http://www.oasis-open.org

Mobile: +1 201-341-1393 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]