I would agree, Matt. My preference would be 2-hours
every two weeks, which would provide ample time in between meetings to review
material. An example flow that has worked well in other standards groups
is:
1 Opening remarks/roll
call
2 Approval of the
Agenda
3 Approval of previous
meeting minutes
4 Review of action
items:
·
status of each item is
either a carryover or closed;
·
if an action item involves
creating a proposal, then the action item is closed upon delivery of the first
draft of the proposal, since it then
first becomes a new business item, followed by becoming an old business item if
it is not successfully approved the first
time (i.e, it is carried as an agenda item instead of an action item;
action items track things to do,
agenda items track discussions/proposals to
consider/vote on).
5 Old
Business
5.1 (old business item
1)
5.2 (old business item
2)
5.3 (etc)
6 New
Business
6.1 (new business item
1)
6.2 (new business item
2)
6.3 (etc)
7 Next Meeting
Requirements (optional)
8 Review New Action Items
9
Adjournment
It is also very helpful if
proposals against a standard are numbered and include a revision number (e.g.,
v0, v1, etc), so the agenda can accurately reflect what is being reviewed. It doesn’t appear that OASIS/KMIP has a
document numbering tool, so I’m not sure how proposals can be sequenced other
than by name and revision as posted.
As an example, your action item
for creating an alignment proposal would be closed now, and we’d have an agenda
item to review your actual proposal against the standard. It would be helpful if there was just
one proposal (e.g., either the 32-bit or the 64-bit or something) to consider
and discuss. Based on the
discussion, you may receive feedback to revise and post (and remain an agenda
item) until a clear consensus is reached to warrant a motion for incorporation
into the standard. Given the large
group, someone could decide to move on a revision that seemed acceptable enough
to pass a vote (whether on the call or electronic doesn’t matter so much). There may not be unanimous support for every
proposal.
There can be agenda items that
seek guidance on a direction to pursue in drafting an actual proposal, which
could result in “group” action items to provide input to the requestor (e.g.,
32-bit vs. 64-bit, or use of application specific identifiers). But usually agenda items end up being
draft changes to the standard to consider (e.g., new sections, edits, etc).
Just some thoughts (since you asked).
Rod Wideman
Quantum
From:
[mailto:]
Sent: Thursday, May 07, 2009 2:18
PM
To:
Subject: Re: [kmip] Length
of meetings
Hi Folks,
I think scheduling 2 hours is also a good
idea. As the group gets larger, it becomes necessary to extend the meeting
length just because the procedural portions (taking attendance, roll call votes,
etc) also get longer. Plus the work load usually increases.
I'm
unhappy that we only got through one item today, and doubly so that it was
partly my fault. The group is still pretty new, and I think we're still
trying to find the efficiency point. Early in the alignment discussion,
someone suggested that we immediately start an electronic ballot and get the
issue over with. In retrospect, that would have been more expedient,
although I think we had some useful dialog on the pros/cons of 32-bit vs
64-bit.
I dislike meetings that go down a rat hole as much as the rest of
you, and hope that we can learn (possibly through some trial-and-error) the
processes that keep the meetings efficient. Here are some of my thoughts
on how we can keep the meetings lean-and-mean:
Post agendas and (mostly) stick to them
Streamline the taking of attendance: I'm hoping that we can find a
fast way to use WebEx to create the initial attendee list and avoid phone roll
calls. Ideally, we could use a Kavi tool to take attendance
automatically (does OASIS support this?).
During review of action items, only discuss status of the action items,
not the item itself. Otherwise, you may never get status updates on the
other action items, or get Liaison reports and such... :)
Adopt a policy of requiring all proposals to go to a 7-day electronic
ballot before adoption by the committee and inclusion into the draft. I
learned this while fumbling through about 3 different revisions of the main
motion in today's meeting. This was made clear when a whole bunch of new
objections were raised when the motion was changed from "requiring 64-bit
alignment of the value field" to "adopt the 64-bit proposal". I'm
assuming that most of the objections were because the members did not have
ample time to review the proposal. By doing a 7-day electronic ballot,
this provides time for a review.
Thoughts? It always takes a
little bit of time to figure out the group dynamic, but I think that after we
get the mechanics down to a well-oiled machine we'll be able to make progress
very quickly.
Cheers,
-Matt
Marcus Streets wrote:
I believe it is clear that we do not achieve
sufficient progress in a
one hour meeting.
Therefore, I propose we
increase the meeting to two hours each
week.
---------------------------------------------------------------------
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
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
