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] Re: [tab] Invitation to comment on revisions to OASIS policy documents


There is a delicate balance between âefficiencyâ and Participation & consensus. One must always remember that creating standards is a social activity as much or more as it is a technical activity.

 

My experience has been that there is no better way to limit participation than to breeze past things in pursuit of âefficiencyâ. Doing so is also a challenge to the âStandards in a Fishbowlâ that OASIS has long boasted about.

 

On a pure meeting-by-meeting basis, many only attend regular meetings to maintain voting status. They are not planning to and will not provide regular feedback on the TC, for reasons I will touch on below. The TC that started this conversation has a half dozen active participants and many regular attendees. Anything that communicates that votes donât really matter will reduce meeting attendance.

 

Having working drafts in advance of a meeting becomes essential as the specification comes closer to fruition. Some companies may not have permission to make an utterance without running it by corporate counsel (for IP), or by technical leadership (for alignment with strategy). There has never been any meeting overhead to create working drafts. It greatly increases participation to say âWe will discuss WD36 at the meeting, and it will be available 48 hours in advance.â Several TCs I have been involved with have adopted a 24-hour or 48-hour window as a working rule. One used a standard of a week. These restrictions increased participationâand as working rules, they can be changed by the TC as the stage of work changes.

 

In any case, the working process and comment tracking do not matter much until the first CS arrives. This conversation started around the first CS.

 

The issue around voting fatigue and PR creation never really existed either. Many TCs have used standard templates for OASIS Motions. (https://www.oasis-open.org/resources/tcadmin/tc-motion-language-templates). The template motion for a CS

 

I move to approve the Chair requesting that TC Administration hold a Special Majority Ballot to approve <Committee Specification Draft title and version number> contained in <URL to Committee Specification Draft> as a Committee Specification.

 

Has often been modified to

 

I move to approve the Chair requesting that TC Administration hold a Special Majority Ballot to approve <Committee Specification Draft title and version number> contained in <URL to Committee Specification Draft> as a Committee Specification, and to direct the TC Administration to issue this Committee Specification for Public Reviewâ.

 

Or something similar. There has never been a need for that to require a separate vote, or to thereby create âVoting Fatigueâ except through lack of planning.

 

As we get into public review. Longer often is needed to engage a wider audience. Many companies will not write any code around a spec until and unless it is so frozen. In OpenC2 last week, we created a CS explicitly for the purpose of locking things down until two weeks after an upcoming plug-fest, to encourage wide participation and comment, especially from non-OASIS members.

 

Two TCs that I have worked on included membership by a national trade association whose architects met once a month. We would get no comments from them until two meetings had passed. At the first, the TC member would present the CS to the Architects Committee. Those members would return to their various companies discuss, and decide on their position. At their next monthly meeting, they would vote on their comments. At the next TC meeting after that, we would receive their comments.

 

In those TCs, we would *always* request that the public review process was 60 days. We requested 90 days for the initial public review. These delays were to *expand* participation to include national wholesale markets. I am not recommending a universal standard 90 and 60 daysâmerely providing a counter-example.

 

For a long time, one of the most inviolate rules was that no changes be made to a document during public review. The reason for this rule was, again, to expand participation. Nothing causes people to walk away faster than when the code they spent a week developing, and the comment based on that that they got approved after three days with corporate receives the response âOh, we already changed that sectionâ.

 

Comment tracking should be as open as the document. Lack of transparency and reporting on comments can doom a standard, as potential adopters walk away from what appears to be a closed process. In the TC in question, it appears that comments already submitted have been dropped. Itâs OK, as noted above, pre-CS01 I feel pretty much anything goes. I personally feel reluctant to spend the time again without a commitment to transparent tracking. Note that this is not a demand that my comment one. A response that we laughed at this proposal and rejected it quickly on a voice vote is always a legitimate response, and as much as many comments deserve. Dropping them entirely is something else.

 

And as before, when comments are just dropped, the message received loud and clear, is why should I submit a comment to someone who appears to be using OASIS to write an internal document for their company.

 

Tc

 

 

From: Vasileios Mavroeidis <vasileim@ifi.uio.no>
Sent: Friday, September 18, 2020 2:33 AM
To: Bret Jordan <bret.jordan@broadcom.com>
Cc: Stefan Hagen <stefan@dilettant.eu>; Chet Ensign <chet.ensign@oasis-open.org>; chairs@lists.oasis-open.org; OASIS TAB <tab@lists.oasis-open.org>
Subject: Re: [chairs] Re: [tab] Invitation to comment on revisions to OASIS policy documents

 

I understand your point Bret, but something else to consider is that eliminating this process at the CSD-level may decrease the quality of the specifications, and add extra overhead to the OASIS administration team since we as TCs will have to go through the same ballot process multiple times at the committee specification-level for addressing issues. Isn't the point of having those ballots at CSD-level a way to iteratively reach consensus that we are in the right track ?

 

 

-Vasileios

 

 

On Sep 18, 2020 1:14 AM, Bret Jordan <bret.jordan@broadcom.com> wrote:

I really feel like this is something we should do. It would make things more agile and reduce so much unneeded complexity and burnout that takes place in TCs.

 

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 Thu, Sep 17, 2020 at 4:57 PM Stefan Hagen <stefan@dilettant.eu> wrote:

I would really appreciate that speed up.

 

Never, I encountered a TC playing back and forth via CSDs. If a group can simply decide in a meeting via motion to publish a CSD and have it than published without further ritual time burning is what the world has been waiting for ;-)

 

Only keeping  CS and OS as Balloted outputs from TC and OASIS respectively seems to be the 21st century way of standardization. This matches the Way we produce music, books, and software these days and I am sure, this will reduce fatigue and unleash TC superpowers.

 

I once expressed âHereâ the hope to witness such a way of operating before I go and it makes me very happy to imagine this could be the case even while I am actively supporting OASIS at large in producing standardized specifications from words and deeds of Open and accessible groups of experts.

 

Go, OASIS, go!

 

All the best,

Stefan.

 

Am 17.09.2020 um 18:39 schrieb Bret Jordan <bret.jordan@broadcom.com>:

ï

Chet,

 

Given that the proposal removes the concept of a "working draft", we really should remove the requirement to have a ballot on a CSD. Since the CSDs are really just internal TC documents and not for external consumption, we should get rid of this extra layer of un-needed busywork process. Larger TCs that are very active tend to suffer from Ballot fatigue from ballots that are really not even necessary. 

 

So I would propose that a TC can release the CSDs whenever they want and as frequently as they want. Then the ballot to approve it is done at the CS level. If you look at a TC that produces say 6 CSDs for a single CS and given that ballots need to be open really for 2 weeks, then for a standard release there is about 12 weeks or 3 months of dead time in a TC due to ballots. This is just a waste. 

 

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 Wed, Sep 2, 2020 at 3:57 PM Chet Ensign <chet.ensign@oasis-open.org> wrote:

Dear OASIS members,

Over the past two and a half years, the OASIS Board has considered changes to our project policy documents based on feedback from you, the members, the people who actively do the work.

At its meeting on July 22, 2020, the Board approved a set consolidated changes to the Committee Operations Process, the TC Process, the Defined Terms, and the Naming Directives. Because these changes include some significant changes to current practice, the Board would like to hear your comments.

This email starts a 30-day member comment period. When the review is completed, our Board will review any comments and then propose a final set of approved documents as well as determining their effective date.

As a member-centric and member-run organization, your opinions matter. The attached ZIP file contains redlined copies of each policy document. A brief summary of the changes is included below. Please take some time to review the documents and share your thoughts with us. You can share your comments by sending them to our archived discussion list at oasis-member-discuss@lists.oasis-open.org or, if you prefer, share them directly with me or with any OASIS board member or staff.

Thank you in advance for your time & feedback!

---

Summary of changes to Committee Operations Process, TC Process, Defined Terms and Naming Directives.

The major changes:

* We changed pronouns to be gender-neutral throughout.

* We simplified the work product workflow. (A separate communication will be forthcoming describing these changes.)

Going forward, we have eliminated the confusing and duplicative Committee Specification Public Review Drafts and the Candidate OASIS Standards. Your group will now produce Committee Specification Drafts. Public reviews will be done on the CSDs and, after you have approved Committee or Project Specifications, the CS or PS will be put forward for the 60-day public review preceding the Call for Consent as OASIS Standard. We hope this will address long-standing confusion over the conflicting numbering schemes as well as eliminate unnecessary duplication of publications.

A substantial number of the changes you'll see are simply eliminations of references to the eliminated artifacts.

* We modified the rules on handling content post-approval to allow TC Administration to work with the editors to correct problems discovered during publishing process. We agree that it is to everyone's advantage to put forward the highest quality work from our projects. We hope you will take advantage of this to fix those niggling glitches that we come across during preparation of your work.

* We added a new section 1.10 to the TC Process titled "TC Vitality." TCs will now be asked to review and confirm (or modify) their charter once every four years.

* We added a requirement to Committee Process section 1.4 Chairs that every two years, a committee must reappoint its chairs. Sitting chairs are allowed to stand but must be reconfirmed by committee vote.

The minor changes:

* We clarified the requirement that meeting minutes must be posted to the TC's general email list. We hope this will help eliminate the hiccups when TC Admin has to postpone working on a support request until the minutes are sent to the mail list.

* We removed a discrepancy between the definitions of Material and Non-Material changes.

* We clarified an ambiguity about how a Member gains voting rights during a 60 day period if less than 2 meetings are held.

* We shortened and simplified the Leave of Absence policy. Now, a first LoA request is considered automatically approved.

* We clarified that changing employers does not change a member's voting rights or other status within a committee.

* We clarified that a TC can use the electronic ballot tool to record votes during a TC meeting.

* We changed references from normative / non-normative to normative and informative to be more in line with other SDO practice.

Again, thank you for your time & feedback.

 

--


/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 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 



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