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

[Hal Lockhart <harold.w.lochhart@gmail.com>]

This seems like a good change. My recollection is that the distinct "Public Review Draft" is a (relatively) recent innovation. I don't remember people before that time being confused about type of document was which.

Hal

Virus-free. www.avg.com

On Fri, May 15, 2020 at 11:39 AM Chet Ensign <chet.ensign@oasis-open.org> wrote:

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Â