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: Is the default process correctly described?



Jon,

first of all, considering the time it took me to read in detail all the
material you sent, I shudder at the thought of the time you have spent
on this. Like others, I thank you for the effort, and for the results.

In this note I'd like to address first your last two questions. Then I
would like to highlights some of the things that occurred to me as I
was reading the materials and some of the answers to the thread.

> Date: Sat, 6 Nov 1999 21:02:10 -0800 (PST)
> From: "Jon Bosak" <bosak@boethius.eng.sun.com>
> Subject: Is the default process correctly described?
> To: workprocess@lists.oasis-open.org

> Based on Terry's comments, which I'm not going to attempt to reply to
> point by point right now (I intend to collate the more important
> issues he has raised for later discussion), I think that we should
> start not with the proposed process, which was the first thing I
> wrote, but with the default process, which I only started to get a
> handle on a couple of weeks ago.
> 
> My analysis of the default process is at
> 
>    http://metalab.unc.edu/bosak/wkproc/doc/defaultp.101
> 
> This is just like the original version I posted on 1999.11.01
> (defaultp.100) except that I've excised some vacuuous commentary.

I don't think the commentary on the meaning of "adjourn" is vacuuous,
since most people assign to it a meaning quite different from the
parlamentarian one. Even knowing what the intended meaning is, I still
have trouble reading sections 9 and 12 of defaultp.10x

> 
> I would like everyone to please read this piece (if they haven't
> already) and attempt to answer the following questions:
> 
>    1. I assert in defaultp.101 that the OASIS Bylaws do
>       presently describe a detailed committee process that as a
>       Pennsylvania Non-profit Corporation we are legally bound to
>       follow.  Am I right?

Yes, in spite of Terry's comments, because the question is whether we are
legally bound to follow the described process, and Terry's answer is that the
process is described through "macro expansion" rather than explicitly and, it
would seem, we're therefore not bound to follow it. Since I can't follow
Terry's logic (inasmuch as even explicitely described processes can be
open to various interpretations), I don't agree with him.

> 
>    2. I further assert in defaultp.101 that the process we are
>       bound to follow is the one that I've described.  Is it?
> 
> I am quite certain that we cannot properly operate except as specified
> in the OASIS Bylaws, and that means that we cannot set about proposing
> changes to the process until we completely understand and are agreed
> upon an interpretation of those Bylaws as they apply to committees.
> If what I've described in defaultp.101 is not our initial state, then
> we need to arrive at a common understanding of our initial state
> before we can continue.

I agree that the description in defaultp.101 is, in theory, our initial state.
If all we need is a common understanding of the theoretical initial state, I
believe we're in good shape. If, on the other hand, we need to arrive at a
common understanding of the actual status of affairs (and I am not asserting
that we do), then I'm not sure defaultp.101 covers it. For example, I don't
think that the status of the DocBook TC is covered.

> 
> Please post an answer the two questions above by the close of business
> Tuesday, November 9.
> 
> Jon
> 

1) Regarding the need to modify the ByLaws:

a) in changes.100, the first modification proposed is to remove the word
"advisory" in committees names. 

Article 5, sect 2 states:  "These additional committees shall act in an
advisory capacity only to the board and shall be clearly titled as `advisory'
committees."

We could easily obtain compliance with the bylaws by changing all TC names to
"Advisory Technical Committee", instead of chaning the bylaws. You say, in
changes.100, "We customarily don't put "advisory" in the names of technical
committees, and I think that practice over the last several years indicates
that we don't want to." That's very thin ice. It could be argued that it
indicates ignorance of the bylaws rather than active antipathy. However, if
the intention is to change "shall act in an advisory capacity", then yes, the
bylaws have to be changed. My feeling is that indeed "The Process Outline"
attempts to change the advisory capacity of the TCs to a quasi-autonomous
one, certainly in what concerns CSs.

b) the second modification proposed is to replace the default rules for
appointment. I do agree that a change of this magnitude would require a change
of the bylaws. I am sure we will have a detailed discussion of the proposed
new rules, but I would like to state up-front that I am  uncomfortable with
where the "Process Outline" is going as regards TC voting, viz. that what is
counted is the votes of individuals rather than organizations. This is, in my
view, a slippery slope that can lead to situations where even a small company,
not to mention a large one, can dominate by the sheer number of its people 
participating in a TC.

c) I have no problem with the third proposed modification.

d) In the fourth proposed modification, there is again the issue of TC
membership and voting. It is true that "a Committee Specification can have
considerable normative force under the right circumstances in a particular
industry"; this makes it all the more important to make sure that the 
danger of stacking votes is avoided. I am not sure that any of the current
proposals (either of bylaws ammendment or through the  process outline)
accomplishes this.

e) No problems with the fifth and sixth proposals.

f) I believe that another possible modification would be the addition of
standing committees. As Terry observed, the existing Docbook TC has more the
characteristics of a standing committee than anything else. Further, I think
that there is an inherent tension between the need to produce a viable first
specification and the need to revisit it at a later date, not just to correct
errata, but to add to it things that may have fallen by the side of the road
in the haste necessary to produce something by a certain date. It is
unfortunate that in many cases (in other organizations) there is actually no
provision to ensure that those things that fall by the side are ever taken up
again, thus allowing a tiny minority to derail proposals by saying "it's too
late in the game, let's leave it for version 2", knowing full well that there
may never be a version 2. In the context of Oasis, it would be desirable,
I believe, for the following to be possible: for the Board to create a standing
committee with the explicit charter to maintain a given TR; or for a TC
to declare the need for (and create?) a standing committee to carry on
the work of the TC when its charter becomes exhausted; or for a TC to
declare itself (with Board approval) a standing committee after issuing a
CS; or all three of the above.

g) I agree with Tommie that the committee process should be well enough 
documented. Of course, "well enough" is ambiguous enough. So I would
propose that either the macro expansions be incorporated into the bylaws,
or that a separate document, referenced in the bylaws, be produced.

2) Regarding notifications

At some point we'll have to deal with the timelines and methods 
for notifications. I've counted the following methods:

a) mail
b) first class postal mail
c) telephone
d) electronic mail
e) other means of written communication
f) registered mail
g) postal mail

and some of the deadlines plainly belong to another era (4 days postal mail,
where the days [with no clarification as to whether these are work days or
just plain calendar days] are counted starting with the day the mail is
sent!!!) This by itself requires a modification of the bylaws ;-)

3) The words "private" and "public" are rather ambiguous, and expecting
the context to make clear what they mean is sometimes not enough. I can
think of the following possible meanings:
	a) Board private
	b) Membership private
	c) TC private
	d) public to the membership
	e) public to the public
I have the following passages in mind when talking about ambiguity (there
may be others I'm missing):

xproc.100:  "that their [TC's] work is open to public view (though not to public
participation)." -- is this world public or Oasis public? As far as I know
world public has never been true.

ibid: "Note also that this phase need not be publicly visible." Again, world
public or Oasis public?

There are others; in some cases the meaning world public is obvious, in others
not so. I would suggest that this be made clear in all cases.

4) Regarding justification for negative votes, I tend to align with Jon
and Tommie on this (probably because I never had Terry's unfortunate
experience), but I think that stating explicitly that a justification
can be as simple as pointing at a given thread in the archives may go
a long way in allaying some of Terry's misgivings about this.

5) Time to send this. I have some comments about the process outline, but
they can wait.

Eduardo







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


Powered by eList eXpress LLC