Happy New Year to all!
I am all for simplicity. We should adopt a
process that minimizes unnecessary overhead and bottleneck. Electronic tools
allow us work asynchronously and in parallel. The main source of bottleneck is TC
meeting/voting. In that regard, I wonder:
-
Is it
necessary for the TC to vote to accept/reject each submitted issue? Before taking
this vote, we need to discuss the merit of the issue. After an issue is
accepted, we then start the real discussion. Why don’t we just automatically
accept all submitted issues and start discussion right away? Rejecting an issue
is a resolution one can propose.
-
Do we go
over all open issues in every TC meeting? If there are many open issues that
are not yet ready for decision, this just turns parallel discussions into a serial
one, even though we are trying to determine the status of each one in the
meeting. Ideally, in each TC meeting, we only want to handle issues that are ready
for decision or that need conscious action to make further progress.
In that case, who decide which issue is ready or needs attention? What are the
guidelines? If a single person is to monitor the progress of all issues, that
person can become a bottleneck.
One can picture the transition states as below:
The options seem to be
(1) We assess the status of every open issue at each TC meeting, and vote
on those that are ready.
(2) A few designated members pick out category (A) and (B) issues according
to certain guidelines and put them on TC meeting agenda. To prevent issues from
falling through cracks, any member can ask to put any additional open issue on
TC meeting agenda. This approach would allow us to utilize our meeting time
more effectively.
david
From: Al Brown
[mailto:albertcbrown@us.ibm.com]
Sent: Tuesday, January 06, 2009
2:08 PM
To: Choy, David
Cc: cmis@lists.oasis-open.org;
gershon@qroot.com
Subject: RE: [cmis] Proposal CMIS
TC issue process
Welcome back from Holidays!
I think let us try the process for the next few meetings and then we can put it
to the vote by ballot for Full Majority.
On the process Gershon sent to the list, it seems reasonable to vote on opening
as well as resolution. It also makes the TC meetings center around issue
tracking, which in my opinion, is quite good as everything is public and
documented as well as provide structure for working during the meetings.
I would prefer to simplify the process however after an issue resolution has been
accepted by the TC. The updated flow would be:
The votes here would be Simple Majority Vote and handled during the call. The
issue is voted on to accept or reject the issue. Once a resolution has been
identified, the resolution would be voted on (or rejection of issue if found
impractical also by vote). Once the resolution is accepted by vote, then the
working draft is updated and the issue is closed with no further action
required.
If this process is followed, for the next call on Jan-12th, we would vote on
the following issues:
(See attached file: 2009-01-12 Issue list
for Accept.xls)
Since we have not accepted any issues yet, there are no resolutions to vote on.
Thoughts?
-Al
Al Brown
ECM CTO Staff, Information Managament
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments,
are confidential and are intended solely for the use of the person or entity to
whom the message was addressed. If you are not the intended recipient of this
message, please be advised that any dissemination, distribution, or use of the
contents of this message is strictly prohibited. If you received this message
in error, please notify the sender. Please also permanently delete all copies
of the original message and any attached documentation.
Choy_David---12/19/2008
02:11:22 PM---Hi, Gershon,
|
|
|
|
|
|
|
|
|
|
|
|
Hi, Gershon,
Thanks
for your Issue Process proposal.
To all:
Issue
resolution process is of utmost importance to the TC since it governs how all
the issues are to be handled. I consider it a TC “standing rule”
which requires a “full majority vote of the TC” according to OASIS
TC Procedure. That is, it requires a majority vote of all the voting members
(not just a majority of those attending a meeting) to approve. We need to set
up a ballot for this purpose. To make sure everybody has a chance to vote on
it, I propose the ballot to stay open until at least 1 day after the Jan 26 TC
meeting (so that people can gain voting right by attending Jan 12 and Jan 26
meetings). We do want to decide soon so that v0.52 can incorporate some of the
issue resolutions. In the meantime, let us fine-tune the process before we set
up the ballot.
I think
the proposal to have every issue brought to TC meeting for disposition has
merit. However, I have a couple of comments on Gershon’s proposal.
- I
think the initial step to “accept” new issue is unnecessary for us.
What value does it provide? Who gets to decide whether or not a new issue is
accepted? Do we need to vote on every one?
- The
real work is all the lines going in and out the “Open” box. Should
we go over every single open issue at every TC meeting? Or, should someone
monitor the open issues and only bring those that are ready for decision (or
that are in stalemate or are inactive) to TC meeting? If the latter, who does
that and what is the criteria to bring an issue to the meeting? If we have a
lot of open issues, should we divide the workload to avoid bottleneck? The
original proposal attempted to address some of these questions. The new
proposal does not. If we rely solely on TC meeting to sort out all the open
issues in our bag, it may not be the best use of our meeting time.
I have
included this topic on Monday’s agenda.
david
From: Gershon Janssen [mailto:gershon@qroot.com]
Sent: Monday, December 08, 2008 10:55 AM
To: cmis@lists.oasis-open.org
Subject: [cmis] Proposal CMIS TC issue process
Hi,
I overheard the discussion
during today’s TC about the issue process. I was in a very noisy
environment so I didn’t had a chance to speak up without letting
everybody enjoy all the background noise.
Personally I feel that
Dennis is quite right about issues not defaulting into a resolved state without
the TC actually discussing it – only if it’s just talking about it
for a very short while.
So as a contribution to
the discussion, I looking over some materials from another TC I’m
participating in (BPEL4PEOPLE) and borrowed some texts from them, incorporated
the guidelines from the CMIS TC as posted by Al, as a proposal for the issue process.
This is somewhat heavier than the current proposed guidelines, but works quite
well and keeps things organized.
I’m not suggesting
we should use all of it, but it seems like a good issue process flow to me;
maybe we can tailor it to this TCs needs.
Regards,
Gershon Janssen