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


I echo Vasileios comment. Great to see the effort to simplify the process!

Regards,


Omar Santos
PSIRT
Security Research and Operations
cisco Systems
Email: os@cisco.com
PGP: https://keybase.io/santosomar


From: Vasileios Mavroeidis <vasileim@ifi.uio.no>
Sent: Friday, May 22, 2020 3:23:50 AM
To: Bret Jordan <bret.jordan@broadcom.com>
Cc: Chet Ensign <chet.ensign@oasis-open.org>; Hal Lockhart <harold.w.lochhart@gmail.com>; chairs@lists.oasis-open.org <chairs@lists.oasis-open.org>; OASIS Board Process Committee <board-process@lists.oasis-open.org>; William Parducci <bill@parducci.net>
Subject: Re: [chairs] Seeking your feedback on proposed workflow changes
 
The simpler the process the better.

The changes seem reasonable. 3 years now engaged with oasis tcs and the process for coming out with specifications was still confusing. Nothing better than a cleaner way of doing it.

Thanks.

-Vasileios


On May 22, 2020 8:26 AM, Bret Jordan <bret.jordan@broadcom.com> wrote:
With the proposed changes, we will only be publishing two types of documents out of a TC now, not three. So a TC will only publish CSDs and CSs.  They will no longer publish CSPRDs. All public reviews will just be announcements of a CSD. Similarly, a candidate OASIS standard will not be a republishing of a document, but rather an announcement of a CS. This will get rid of a lot of the weird numbering situations that can occur. 
  
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 21, 2020, at 4:14 PM, Chet Ensign <chet.ensign@oasis-open.org> wrote:

Thanks Hal. Yes, merging the CSD and the PRD into one document is something we started last year. Before that, we were publishing duplicate copies. A lot of extra work!

On Thu, May 21, 2020 at 5:18 PM Hal Lockhart <harold.w.lochhart@gmail.com> wrote:

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 


--

/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 




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