[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
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 > >     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 > > > > > > > > -- > > > > /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]