Meetings

Overview

Meetings

1. WGs are encouraged to schedule regular conference calls.
2. The Meetings MUST be announced at least seven (7) days in advance for conference calls, and one (1) month for face-to-face meetings.
3. All the Organization members are contractually bound to the IPR policy under terms of the Membership Application.
4. Meetings SHALL have an antitrust statement and an IPR call where a reminder of the IPR policy and the duties and obligations of members is provided.
5. A meeting attendee list MUST be produced for each meeting. This list is necessary to determine which members can vote in a Supermajority vote if one is needed.

Meeting Best Practices

A group meeting needs a clear agenda. We suggest that Maintainers or Chairs of the Working Group should follow up on these steps:

Before

Before the meeting, the Maintainer should:

• Announce the day and time for the meeting well in advance, e.g. seven days
• Create a meeting agenda using a template, e.g., agenda-template.
• Ask the Group for discussion topics to be added to the Agenda.

At the beginning

At the beginning of the meeting:

• Record in the Meeting Minutes the name, affiliation, or email address of all the meeting attendees.
• Before starting the meeting, draw the attendee's attention to the anti-trust and IPR statements on the Agenda.
• Review with the Working Group the meeting topics prior start the discussion and ask for additions or updates. Amend the Agenda accordingly.
• Ask for the Agenda to be approved before beginning the formal debate.

During

• Give each topic enough discussion time, or postpone the topic for the following meeting.
• Assign clear action items and takeaways at the end of each discussion topic (if needed).

After

• Share the Meeting Minutes with all the attendees and ask for comments or amendments.

Minutes Guidelines

Further details about meeting minutes can be found here

Example of Meeting Minutes

Example detailed discussion

Example summarised discussion

OMA-MWG-CPM-2009-0079R01-CR_TS_Conversation_parameters Nadia from Ericsson introduced this contribution. Comments: Acision: Contribution ID is fine, we should not change anything. NSN: Appendix is normally informative. NSN: namespace for Message ID. New namespace?  Ericsson: yes.  Defined as part of the IMDN.   NSN: Have no problems reusing parameters. NSN: Change 2 (beginning): conversation Thread is undefined. Ericsson: Contribution ID: important to say it is a globally unique ID.   NSN: not sure it needs to be unique, this is not a requirements, may end up unique as a side effect.  Ericsson: delete 1st sentence. NSN: Change 2: does not talk about Message COM Header. Why?   Ericsson: SIP INVITE does not carry, MESSAGE message carries conversation ID. NSN: Appendix C: Need to rephrase heading.   Ericsson. OK “Parameters for conversation & contribution identification”. Ericsson, Acision: C.1.3: remove “SHALL always”. NSN, Acision, Ericsson: advantage of going to IETF asking them to define CPM tags/parameters. IETF will need time write the draft & then the RFC. NSN: I don’t push to go through the IETF way, I just suggest it as an idea. Ericsson: Kyung Tak did online edit, 0079R02 can be put in R&A. Chair:  will upload R02 (online editing done during 0079R01 discussion), and wait until Helsinki to consider alienate proposals.  R02 postponed until Helsinki.

OMA-MWG-CPM-2009-0079R01-CR_TS_Conversation_parameters Nadia from Ericsson introduced this contribution. Comments: Change 1: no comments, proposal agreed. Change 2:  agreed ‘conversation thread’ needs to be defined.    Contribution identity: agreed no need for this to be globally unique, submitters will delete 1st  sentence. Change 3: agreed to rephrase heading to ‘Parameters for conversation & contribution identification’;  C.1.3 agree to remove ‘SHALL always’.   Group discussed possibility of asking IETF to define CPM tags/parameters, but concluded that this would take too much time to write the draft, then RFC. Conclusion: Ericsson will upload R02, and wait until Helsinkito consider alternative proposals.  R02 postponed untilHelsinki.

Decision-Making

As part of their responsibilities defined in Chairs, Chairs need to ensure efficient and effective decision-making:

1. The decision-making process in WGs is intended to be as inclusive as possible.
2. WGs SHALL attempt to use consensus to make decisions.
3. If consensus cannot be reached, voting mechanisms MAY be used.
4. Formal notice SHALL be given for decision making, e.g.:
   • Inclusion of a document on the agenda, proposing a specific decision to be taken (e.g., Pull Request).
   • Inclusion of an item directly in the agenda (e.g., proposed next meeting date).
   • Items proposed for approval via the group mailing list (e.g., agreement a document revision).
   • Inclusion of a document for decision in an electronic Review and Approval event
   • Inclusion of a document for decision in an e-vote (Supermajority) vote.
5. There SHALL be no distinction in the decision-making merit of real-time or non-real-time meetings.
   • In real-time meetings, consensus can be determined by receiving no sustained objections to a proposal.
   • In non-real-time meetings, consensus SHOULD be developed using Review and Agreement periods, e.g., using Review and Approval
6. Proposals SHALL be available for review for a given period, agreed by the Working Group

Seeking Consensus

1. Groups SHALL endeavour to reach a consensus on all decisions.
2. Informal methods of reaching consensus are encouraged (e.g., a show of hands).
3. Groups SHOULD attempt to ensure contributions relating to the same subject matter are considered together before being reviewed.
4. However the Maintainer SHALL ensure that progress is not delayed by unavailable contributions or participants.
5. Agreement SHALL be sought in all forms of meeting.

Handling Objections When Seeking Consensus

1. Objections from a small minority SHOULD be minuted, and the objecting delegates SHOULD be questioned if having their objections minuted is sufficient, and they agree not to sustain their objections.
   • If such agreements are secured, there is a consensus for approving the proposal.
   • If such agreements are not secured, then the proposal is not agreed upon, and further action SHALL be taken (e.g., the proposal is withdrawn, updated, or voted on).
   • Members are discouraged from sustaining their objections when it is clear that a vote will override them.
2. In real-time meetings, consensus can be determined by receiving no sustained objections to a proposal.
   • Efforts to immediately resolve or record objections can be taken to attempt to achieve consensus.
3. Where attendance is sparse when viewed from normal participation levels, potentially controversial proposals SHOULD be made available to the broader membership.
4. The Maintainer is responsible for ensuring such opportunity for participation in the decision-making process.
5. Sparsely attended meetings SHOULD NOT be used to drive through proposals that would not have broad support.
6. Following a decision-making meeting, a summary of decisions and document dispositions SHALL be published as soon as is practical.
   • This will be addressed if the meeting minutes are available in a timely fashion.
7. When there is insufficient time for review in a real-time meeting, non-real-time consensus approaches SHOULD be considered.
8. In non-real-time meetings, consensus SHOULD be developed by using Review and Approval periods.
   • Using the group mailing list
   • Using GitHub "Review and Approval" label
   • Proposals SHALL be available for a given period.

Voting

This section describes how to use Supermajority Vote to Achieve Agreement

Phrasing of Voting Questions

1. The Maintainer ensures that questions to be voted upon SHALL be phrased in a concise and unambiguous manner.
2. Questions SHOULD NOT be phrased as the “The group SHALL not do xyz”. Examples of appropriate questions are:
   • SHALL the group agree the Specification?
   • SHALL the liaison be approved?
   • SHALL the new Work Package be approved?
   • SHALL the existing Work Package be stopped?
   • If the issue is to choose between two options (i.e. A or B), an example of the appropriate question may be:
   • SHALL the group agree Option A or Option B?
3. The option receiving no less than 3/4 of the Supermajority Votes SHALL be the decision of the group.
4. If the issue is to choose between three or more options, the group SHOULD use informal voting to reduce the number of options to two, and then use formal voting, if necessary.

Voting on Technical Issues

1. Before voting, a clear definition of the issues SHALL be provided by the Maintainer.
2. Members eligible to vote, SHALL only be entitled to one vote each.
3. Each member MAY cast its vote as often as it wishes, and the last vote it casts counts.
4. Voting MAY be performed electronically.
5. Voting MAY be performed by show of hands and members announcing their vote verbally one by one, or paper ballots.
6. The result of the vote SHALL be recorded in the meeting minutes.
7. Groups MAY use informal voting to reach consensus. If the Group is still unable to reach consensus, then a formal vote MAY be taken.
8. Each member’s electronic vote SHALL be electronically acknowledged to confirm participation in the vote.
9. The voting period for proposals are:
   • In-person-meetings require at least 30 days prior written notice
   • Teleconference meetings require at least 7 days prior written notice
   • Electronic voting MUST remain open for no less than 7 days.