It doesnât ?
Â
How can we state that each TC operates under the IPR policy (at any stage) and then the statement that it only applies when you get to a CS?
Â
This makes no sense whatsoever.
Â
Either all the work in a TC is covered by the IPR policy or it invalidates a lot of collaboration.
Â
Â
From: Chet Ensign <chet.ensign@oasis-open.org>
Date: Tuesday, May 26, 2020 at 6:58 AM
To: Stefan Hagen <pantherleon@web.de>
Cc: Bret Jordan <bret.jordan@broadcom.com>, "chairs@lists.oasis-open.org" <chairs@lists.oasis-open.org>, OASIS Board Process Committee <board-process@lists.oasis-open.org>
Subject: Re: [chairs] Seeking your feedback on proposed workflow changesÂ
THIS EMAIL ORIGINATES FROM OUTSIDE OF LOOKINGGLASS
Hey Stefan,Â
Â
The issue around CS is that the Committee Specification is where the IPR protections kick in. So the distinction between CSD and CS is important - anything in the CSD stage still doesn't have the patent commitments attached to it.Â
Â
/chet
Â
On Fri, May 22, 2020 at 7:46 AM Stefan Hagen <pantherleon@web.de> wrote:
I second removal of every name that is neither CS nor OS on standards track, and CN else.
Â
Why not semantically version the CSs to get rid of the CSD.Â
Â
A committee Would start with a 0.x document version of standard version 42.0 and deliver the first public CS as document version 1.0.0
Instead of Errata archives, we could issue real errata (like every other publisher/author) per reference lists placed somewhere obvious or already noted in the 1.0 doc version of Standard Âversion 42.0.
Â
Subsequent issues of the documents with bug fixes, security advisories etc. could go as doc version 1.0.1 of that standard version 42.0 or As doc version 1.1.y when more severe indicating a standard version 42.1.
Â
Oasis as emitter of OSs could do similarly with technical document versions separate from the standard version.
Â
But, to me any reduction of labelled things not clearly traceable backwards from an OS or CS is a good move to ease creation and consumption of our work products.
Â
All the best,
Stefan
Am 22.05.2020 um 08:26 schrieb Bret Jordan <bret.jordan@broadcom.com>:
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ÂÂ
Â
--
/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Â