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


Martin,

 

Let me run an example, to make sure I understand:  the OpenC2 TC holds two sessions for our monthly meeting, at 11:00am and 9:00pm. I saw the provision for electronic ballot during meetings in the proposed revisions, so are any of the following approaches unacceptable:

 

1)     Announce a ballot on the TC email list just prior to the morning session, ending at the end of the evening session, votes to be recorded by responding to the TC mail list with your vote.

2)     Open a ballot in Kavi covering the same time period as examples #1 (does Kavi permit a ballot period that starts and ends w/in the same day?)

3)     Use the motion / voting mechanism w/in the meeting platform (Lucid Meetings in this case) at each session to record votes, and then tally them up after the second session ends.

 

Thanks.

 

Dave

 

David Lemire

HII Mission Driven Innovated Solutions (HII-MDIS)

Technical Solutions Division

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190 | Mobile (443) 535-1182

 

From: martin.chapman@oracle.com [mailto:martin.chapman@oracle.com]
Sent: Monday, September 21, 2020 11:19 AM
To: Bret Jordan <bret.jordan@broadcom.com>; Michael S. Tsirkin <mst@redhat.com>
Cc: Chet Ensign <chet.ensign@oasis-open.org>; tc-announce@lists.oasis-open.org; Members <members@lists.oasis-open.org>; chairs@lists.oasis-open.org; OASIS Board Process Committee <board-process@lists.oasis-open.org>; Board Plus <board-plus@lists.oasis-open.org>; OASIS TAB <tab@lists.oasis-open.org>
Subject: EXT :[chairs] Re: [members] Re: [chairs] Re: [tab] Invitation to comment on revisions to OASIS policy documents

 

CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

 

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.

 

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 [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 [oasis-open.org]
>
>
>
> --
>
> /chet 
> ----------------
> Chet Ensign
> Chief Technical Community Steward
> OASIS: Advancing open source & open standards for the information society
> http://www.oasis-open.org [oasis-open.org]
>
> Mobile: +1 201-341-1393 



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