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.  Just to clarify, the COS would not be eliminated nor would the statements of use be removed. Everything would work as it does today, except, the COS would be a cover page to a CS just like the PRD would be a cover page you a CSD.


Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On May 27, 2020, at 6:16 AM, David Filip <david.filip@adaptcentre.ie> wrote:

All, I think it means less red tape and less confusion if we get rid of csprds and going to have a public reviews simply as a flag on csds.

However, I wouldn't do away with COS so easily. Albeit there is not supposed to be any material difference between a cs and a COS, the condition for progressing from cs to COS is currently a given number of statements of use (SoUs). I think that proving implementability by a number of SoUs is significant enough a milestone to warrant reprint of the cs deliverable as COS.

I do understand how my life as editor/secretary/chair will become easier getting rid of csprds especially as my committees did use to send all csds for public review.. so we had to create two sets of artifacts all the time..  and I still remember how confusing that was back in 2012 when I had to go through that for the first time ;-)

I believe that the progression cs -> COS -> OS is different and I'd like to see more detail on how this progression is handled with COS eliminated. I assume/hope that OS is not eliminated..

Cheers and thanks

Dr. David Filip
ISO/IEC JTC 1 PAS Mentor | Convenor, ISO/IEC JTC 1/AG 3 Open Source Software, Convenor, ISO/IEC JTC 1/SC 42/WG 3 Trustworthiness of AI | National mirror chair, NSAI TC 02/SC 18 AI | Head of the Irish national delegation, ISO/IEC JTC 1/SC 42 AI | Chair & Editor, OASIS XLIFF OMOS TC  | Secretary & Lead Editor, OASIS XLIFF TC | NSAI expert to ISO/IEC JTC 1/SC 38 Cloud Computing, ISO TC 37/SC 3 Terminology management, SC 4 Language resources, SC 5 Language technology | GALA TAPICC Steering Committee Member
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122

On Tue, May 26, 2020 at 6:13 PM Bret Jordan <bret.jordan@broadcom.com> wrote:
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.

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.


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

Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open source & open standards for the information society

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]