[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] Re: [members] Re: [chairs] Re: [tab] Invitation to comment on revisions to OASIS policy documents
My response on serialisation was with respect to a combined
CSD/PR vote.
On Mon, Sep 21, 2020 at 04:18:40PM +0100, martin.chapman@oracle.com wrote:Bret, I though we covered this issue when we worked on this within the Board. " So I would propose that a TC can release the CSDs whenever they want and as frequently as they want." How does a TC decide to "release" a CSD? It takes a vote. This can be a vote during a meeting or by electronic ballot - we even added that electronic ballots during meetings are allowed (e.g. across multiple sessions). The fact that a TC chooses to have two week electronic ballots (minimum is 7 days in TC process) is not a TC Process issue in my opinion. Personally, I think it is good practice to iterate a baseline (CSD) via TC votes on the whole document rather than wait until the end to decide its fate. To address Vasileios comment: "So I missed a step in the process. Two ballots. One for accepting a CSD and another to decide if it will be released for public review. Then I concur with Bret." There is no requirement to serialise andÃÂ can all be done in a single vote/ ballot. Martin.Our TC votes on 3 changes to the spec. Normally once vote finishes editors make the change and push to github. Assume 2 votes pass, 1 fails. Editors should be able to push passed changes to github and have that be a CSD. As it is we can not include a vote to approve a CSD with one of the votes for the changes if they run in parallel since we don't know how will the full CSD look like ahead of the time. This looks like serialization to me.On 18/09/2020 17:48, Bret Jordan wrote: I agree.ÃÂ Long-term I would love to see us get to an automated workflow with git and document publication. 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 Fri, Sep 18, 2020 at 8:49 AM Michael S. Tsirkin <mst@redhat.com> wrote: There is actually something I would like to add.ÃÂ If that takes place, really whenever something is comitted in the TC SVN/git, it should be possible to regard that as a draft deliverable for IPR purposes (e.g. the limited patent covenant). A step of generating a number for a CSD changes nothing IMHO. On Fri, Sep 18, 2020 at 10:17:28AM -0400, Chet Ensign wrote: > Bret, thanks again. I have started a comment log to collect all feedback and > loaded your comment there so that the Board can discuss it.ÃÂ > > One quick note on the process:ÃÂ even if votes on CSDs are eliminated, TCs will > still have to vote to approve releasing CSDs for public review. It will not be > just the CS level. > > Again, thanks for the feedback.ÃÂ > > /chet > > On Thu, Sep 17, 2020 at 11:43 AM Bret Jordan < bret.jordan@broadcom.com> wrote: > >ÃÂ ÃÂ ÃÂ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 >ÃÂ ÃÂ ÃÂ ÃÂ ÃÂhttps://urldefense.com/v3/__http://www.oasis-open.org__;!!GqivPVa7Brio!JHZBnxXMIJKI0Wav4H3ZznCnMc_I6YEpIZxRhDhnaIrw6tx3yKq9-ujeEOQ_2uFfhkc$ > >ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ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://urldefense.com/v3/__https://www.oasis-open.org/apps/org/workgroup/portal/__;!!GqivPVa7Brio!JHZBnxXMIJKI0Wav4H3ZznCnMc_I6YEpIZxRhDhnaIrw6tx3yKq9-ujeEOQ_GLdoqqs$ my_workgroups.php > > > > -- > > /chetÃÂ > ---------------- > Chet Ensign > Chief Technical Community Steward > OASIS: Advancing open source & open standards for the information society > https://urldefense.com/v3/__http://www.oasis-open.org__;!!GqivPVa7Brio!JHZBnxXMIJKI0Wav4H3ZznCnMc_I6YEpIZxRhDhnaIrw6tx3yKq9-ujeEOQ_2uFfhkc$ > > Mobile: +1 201-341-1393ÃÂ
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]