OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

workprocess message

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


Subject: Re: The TRAC reconsidered


Jon wrote:

| I'm reconsidering the decision that some of us came to over lunch
| in San Jose during the OASIS/CEFACT meeting.  It has occured to
| me that the dual advisory committee method we proposed as an
| interim solution doesn't map well to where I thought we would be
| going in the long run, which seems to be the idea of autonomous
| committees, or at least committees whose voting membership (that
| is, who's a member and who's not) can be run on autopilot.
| 
| The long-term part of this project is driven by the requirement
| to put minimum demands on the central authority, in particular
| minimum demands for oversight.  This suggests a structure that
| operates from the bottom up, not one that is directed from the
| top down.  If non-hierarchical direction is a basic structural
| feature of the end state, then I don't think it's a good idea to
| create an interim solution with a structure designed to operate
| over a relatively long time from the top down.

I believe you are now discovering that it is not feasible to
separate interim from long-term solutions.  I don't have an
opinion on that right at this instant, but I do know that the
stage has not yet been set properly for discussion of the long-
term solution.  You have alluded to ("bullet-listed"?) certain
features of the desired end state, but little more.

To discuss the long-term solution intelligently we need to agree
on the desired end state.  To agree on the desired end state we
need a full prose description of it.  I suggest that this should
take the form of scenarios ("use cases"), functional requirements
derived from them, and a list of all other requirements we can
think of.  I don't know whether the requirement for minimum 
demand on the board is a functional req deduced from scenarios
or some other requirement, but it's the only one I've seen 
stated clearly.

You asked for a quick response, so I'll continue commenting 
(and maybe develop an opinion on interim vs. long-term), but
I really think we need to know better where we want to go tomorrow.

| I know that this contradicts the statement I made in San Jose
| that the interim process has to be able in theory to function
| indefinitely.  I didn't realize the organizational overhead
| implied by this position.
| 
| Let me review the possible interim solutions and maybe you'll see
| what I mean.
| 
|    Interim solution 1.
| 
|       Leave the existing structure alone until we get a new one
|       in place through changes to the bylaws.  This assumes we
|       know just when that's going to happen.  Personally, I find
|       this level of uncertainty either unacceptable or so close
|       to it that I can't tell the difference right now.  But a
|       case could be made for it.  So far I think that only one
|       person has suggested this alternative, but others may feel
|       the same way and just not be saying anything.  If a
|       majority is in favor of just leaving the existing structure
|       alone as an interim solution, I need to know that.

If I suggested it, I withdraw the suggestion; however, I don't 
think it conflicts with 3, because our existing "committees" need
proper authorization even to meet in Philadelphia (as committees).  

|    Interim solution 2.
| 
|       Institute an advisory committee of the board to create and
|       maintain technical subcommittees and to forward the reports
|       of technical subcommittees (in the form of specifications)
|       to the board for its disposition, in particular to propose
|       the question of the acceptance of the specification by the
|       OASIS membership as an OASIS Technical Resolution.  This

Here's a point where we probably have different opinions as to
the desired end state.  I am not sure I am happy with the board
acting as filter, and I think some earlier filtration is desireable.
A thorough description of a specification's life cycle in the
world of the end state needs to be composed so we can think on it.

I also wonder what the role of the membership is in the desired
end state - may it form committees?  overrule the board?  has 
it any power?

|       has been our plan for the last week, but it troubles me
|       that this structure of "board => advisory committee =>
|       technical subcommittee" does not map without a fair amount
|       of reorganization to the desired end state "board => TC".

That's not my desired end state.  It is abundantly clear that some
additional governance mechanism is needed, so that it may have
technical competence the board may lack as so that it may do some
filtering much earlier in the process than after a hopeful committee
submits a doomed specification for rejectionas TR.  The IETF has
found this essential.  How does the IEEE do it?

|       So if you figure that we are going to have a complete
|       solution mapped out by Paris (if not well before), then
|       reorganizing everyone only to reorganize them again a few
|       months later is not a pleasant thought.  When I also
|       consider the fact that our existing committees map very
|       nicely to the probable end state, then I feel reluctant to
|       disturb them structurally.

We don't have existing committees.  We have improperly constituted
working groups that are operating pretty much by consensus, which is
not your desired end state.  We must at least {re}authorize, if not
reorganize.  Unfortunately, as we must be able to have a quorum,
authorization requires some reauthorization.

|    Interim solution 3.
| 
|       Fix the existing committee structure.  This could be done
|       through formal appointment of new committees and
|       recertification of existing committees by formal resolution
|       and appointment of voting members.

This isn't a fix to existing committees, it's a restart of efforts
that weren't started right to begin with.

|       Observations about solution 3:
| 
|       - This solution avoids structural transitions.  If we
|         keep existing committees at their present organizational
|         level, then our long-term solution can be accomplished
|         largely by adding a membership autopilot to the bylaws
|         so that voting membership in the TCs and their
|         subcommittees does not have to be overseen by any
|         creating body (except in rare cases, by appeal).
|
|       - If, as assumed in Solution 2, the board has the power
|         to create an advisory committee that has the power to
|         create technical subcommittees that are themselves
|         empowered to draft reports back up the chain (which I
|         think it does), then the board has the power to appoint
|         those committees directly, because it would be absurd to
|         say of any committee that it could create subsidiary
|         entities more powerful than itself.

Yes, of course, except that the wording of 5.2 requires that they
all be advisory committees.

|       - I think that specifications developed by committees
|         that are intended for submission to the OASIS membership
|         by the board can be considered advisory reports to the
|         board.  

But that's not their intent.  Their intent is that they be
specifications approved by the membership.  They can be considered
as reports to the board in order to shoehorn them into R (in which
case we need to adopt some rules wrt what R has to say about 
"Reports of Committees" (index entry).

|                 So in the case of our current technical
|         committees, the task of the board is not to create them
|         but to put their creation on record (recertify them) and
|         determine their voting membership.

Right, although I think that assertion doesn't follow from the 
premise about intent.

|       - Properly appointed committees would apparently
| 	conflict with the bylaws only in the matter of their
| 	names, which (given our continuing diligence in solving
| 	this problem) is not something I think we need to worry
| 	about while we're putting a long-term solution in place.

I think we must.  They won't be properly established if not.
As these committees have not existed in the past, giving the
newly established committees proper names per the bylaws should
pose no problem.  And ignoring the bylaws in our present state
of knowledge would prejudice the legitimacy of the committees.

|       - The problem of providing a quorum remains a difficult
|         one, but it is invariant under the choice between
|         solutions 2 and 3.

True, although it should be easier to handle the task of booting
the sloths under 2.

| I'd like us to seriously consider interim solution 3 before committing
| to the multiple top-level advisory committees of interim solution 2.
| 
| With the temporary exception of their names, I think that our existing
| TCs would only need to do the following to become completely compliant
| with our implied process:

Again, we don't have existing committees.

|    1. Get formally appointed by the board; this means a
|       charter (including deliverables, schedule, etc.) and a set
|       of voting members appointed by name in a written resolution
|       formally approved by the board.

It doesn't require deliverables or schedule, only a charge (right?).

|    2. Start using Robert's at the committee level, at least in
|       theory.  In practice this means (a) using a majority vote
|       as the mechanism for deciding substantive questions and (b)
|       using the rest of the process only when someone thinks it's
|       necessary to do so; that is, to make sure that it's there
|       when it's needed and that everyone knows that.
| 
| When we briefly poked our heads down this path before (about 10 days
| ago), I suggested the following procedure, which I now think is a bad
| one, for blessing existing committees in a way that meets quorum
| requirements:
| 
|    Ask the chair of each committee to provide a paragraph
|    describing the goal of the committee (this should already be
|    on file somewhere) together with a list of what he or she
|    considers to be its actual current membership.  "Actual
|    membership" means the people who are known to be making
|    material contributions to the work of the committee and who
|    habitually vote when a question is put to them; otherwise the
|    committees will be unable to achieve a quorum.  Submit the
|    goal and current membership to the board for approval as the
|    committee charter.  If the chair is unable to form a list as
|    described, treat it as a new committee according to the
|    procedure below.

Yes, I would have refused.

| Now I think that it would be better to use self-nomination rather than
| putting chairs on the spot by asking them who the voting members
| should be.  By way of demonstration, I've put a revised proposal for
| such a process in an accompanying message under the subject line
| "Possible interim process fix."
| 
| Please comment after you've had a chance to look at the other message.
| In particular, please attempt to answer the following questions:
| 
| 1. Are there other viable solutions besides the three that
|    I've listed above?
| 
| 2. Which solution do you favor at this point?

Neutral between 2 and 3.

| Since I'm leaving for four days beginning December 1 and may not
| be able to establish mail contact again until December 4, it
| would be good to get quick answers to these questions from the
| people on this list who have signed up to participate as voting
| members of the PAC.
| 
| Jon

regards, Terry



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


Powered by eList eXpress LLC