workprocess - end state

[Terry Allen <tallen@sonic.net>]

I'm glad Jon is doing this work; it needs doing.  I've worked
through the apparent starting point and will have other comments
on other docs later in the week.  

This is a good first cut, but there are some policy tendencies I find
I don't care for.

| DRAFT: POLICIES AND PROCESSES FOR THE DEVELOPMENT OF OASIS TECHNICAL
| SPECIFICATIONS

 [some sections deleted]

| 1999.11.01

I trust that .100 indicates the proper version number, and that you're
not using the abhorrent date=version hack.

| ORGANIZATIONAL CONTEXT
| 
|    OASIS is a Pennsylvania non-profit corporation, and all
|    decisions of that corporation are vested in its Board of
|    Directors, who are chosen by ballot as specified in the Bylaws
|    of the Corporation.  The Bylaws distinguish between voting and
|    nonvoting members, and they allow the OASIS board to institute
|    membership levels in such a way that some levels of membership
|    are in the voting category and some are in the nonvoting
|    category.  At the time of this writing, the voting members of
|    OASIS belong to the various levels of membership reserved for
|    organizations, while individuals have nonvoting memberships.

aside:  I am certain this will have to change if we want lots of
individuals, which I think we should.

| BASIC ASSUMPTIONS
| 
|    The procedures set forth in this document for the creation of
|    OASIS technical specifications are based upon the following
|    assumptions.
| 
|    1. That there is an established OASIS policy for
|       intellectual property that allows free, nondiscriminatory
|       use of specifications developed under this process.  Such a
|       policy has yet to be defined; see [ipr] for a current
|       placeholder.

sounds good.

|    2. That there is an established set of OASIS antitrust
|       guidelines.  The policies embodied in this process relating
|       to the visibility of technical committee work reflect the
|       antitrust guidelines assumed to be in place; see [atrust]
|       for the guidelines assumed to be operational for purposes
|       of the present document.  Note that the visibility
|       requirements for technical committees in the currently
|       assumed antitrust guidelines are presumed not to apply to
|       the separate pre-charter phase (see overview below) in
|       which requirements are gathered within an industry.

generally unobjectionable, but I do find a few nits.

|    3. That participation in all chartered OASIS technical
|       committees is open to all OASIS members and that their work
|       is open to public view (though not to public
|       participation).

details of this are among those nits, see separate comments.

|    4. That OASIS technical specifications do not attempt to
|       define core technologies such as XML but rather to create
|       industrial applications of core technologies.  This is
|       critical to the organization of the technical process
|       specified in this document, because it allows multiple
|       overlapping (or even directly competing) OASIS
|       specifications to exist with minimal risk of operational
|       collision.

I would phrase this the other way around:  avoiding multiple 
overlapping is very important; trying to delimit what is "core" is 
hopeless.  There are at least two edge cases in Regrep, and in fact 
the whole Regrep effort is intended to supply core technology.  
Furthermore, if there is core technology the W3C isn't supplying, 
they need competition.  

|    5. That once created, OASIS technical committees are
|       largely autonomous and that as a general rule they are not
|       burdened with reviewing each other's work in progress.

Good, although if we have thousands, they will certainly overlap.

|       This means that other mechanisms are assumed to be
|       available to the board, or to some person or group to which
|       it delegates the responsibility, for preventing (presumably
|       rare) genuine conflicts between parallel technical efforts.
|       Examples of such mechanisms could include joint meetings of
|       technical committees, task forces appointed by the board to
|       analyze an apparent conflict and recommend action,
|       workshops organized by the board to explore particular
|       questions, or direct intervention by the board.  More
|       formal mechanisms such as voluntary coordination committees
|       and joint subcommittees may be specified in a later stage
|       of development of this process.

Note that the IETF solves this issue up front, by ensuring that
Area Directors catch conflicts before WGs are chartered.

|    6. That in the general case, all resources for the work of
|       OASIS technical committees are contributed by participants.
|       This means that in the general case, minimum levels of
|       commitment must be secured before activities can be
|       started.  (There is nothing to prevent the OASIS Board from
|       providing resources for specific items of work, but the
|       normal OASIS technical process is designed to prevent OASIS
|       resource constraints from limiting the number of
|       industry-specific activities that can take place at a given
|       time.)

Another point to phrase the other way around - the parenthesis is
the real point.  BTW, is XML.org paying the phone bill for the Regrep
teleconferences or is OASIS (that is, is there precedent here)?

|    7. That the ordinary role of the OASIS board in the
|       technical specification process is to make overall policy
|       decisions and that in the general case it does not attempt
|       to manage committee work or to second-guess committee
|       decisions, though it always has the authority to do so.

Good, assuming that the decisions of the Board are also public.

|    8. That the function of the OASIS staff is to help out with
|       logistics and to otherwise stay out of the way.

Yes.  An entity not mentioned so far is what you might call the
technical-committee-as-a-whole (which met in Montreal to hear
Norbert's remarks).  Is there to be such, and if not, is there
still to be a Technical Director (or whatever Norbert's title is)?

|    9. That formal committee decisions are made by formal vote
|       according to formal methods.  It is a foundational precept
|       of the OASIS technical specification process that
|       "consensus" is the breath of life in the creation of
|       standards but the kiss of death in specifying procedures
|       for making decisions.  To put this in operational terms,
|       chairs of technical committees should never be prevented
|       from holding yet another straw poll in an attempt to find a
|       consensus, but they should always be able to force an
|       unambiguous decision via a determinate and non-arbitrary

nonarbitrary.  Sorry, I can't help myself.

|       process when it is time to move on.

I hope this process is to be the same (insofar as the formal method
of voting) for all committees.  Can a TC chair be impeached, and
if so, how?

|    10. That revisions to OASIS technical specifications are
|       considered to be new specifications and that they follow
|       the same process as for new specifications.

Ah, um.  This is appropriate in some cases, and I applaud the
goal of avoiding standing committees (which, as ISO shows, make
much mischief); but there are some other cases, including Docbook,
where permanent maintenance mode seems not inappropriate.

| OVERVIEW OF THE OASIS TECHNICAL SPECIFICATION PROCESS
| 
|    The successful creation of standards depends on finding a

specifications.  Unless we want to claim to be a standards body.

|    balance between the need to incorporate the widest range of
|    differing opinions and experiences in the design phase and the
|    need to move with decision and finality in the approval phase.
|    Several models have been developed by different standards
|    bodies in an attempt to find this balance.  For example, some
|    organizations vest final authority in a single individual,
|    with all the decisions made by technical committees serving
|    merely as advice to that individual.  Other organizations take

Is there more than one of these?

|    an approach nearly opposite to this, with all decisions made
|    by consensus of the participants.  Still others confer final
|    approval through a process of balloting by a federation of
|    subsidiary organizations whose constitution and methods of
|    operation are individually determined.
| 
|    The creation of standard specifications for structured
|    information exchange is further complicated by the need to
|    ensure that the requirements for specifications in each domain
|    are set primarily by users in that domain, typically by
|    organizations that intend to use the specification for
|    information interchange within a particular industry.  It is
|    essential to the success of such initiatives that they be
|    driven more by the practical needs of their intended users
|    than by purely theoretical considerations and that basic goals
|    agreed to at the beginning of an effort not be vitiated by a
|    futile or dilatory recursion to a reconsideration of those
|    goals while design is in progress.

Yes, decide it once and keep it decided.

|    Yet another dimension of complexity is added to the OASIS
|    specification process by the fact that not all OASIS projects
|    will have originated wholly within OASIS; the process must
|    also accommodate the adoption of projects started in other
|    industry groups and the harmonization of multiple projects
|    initiated by different groups to solve similar problems within
|    a common domain.  The method adopted here for merging projects
|    with variant beginnings into a common process is to modularize
|    the phases of the process and to structure the earlier phases
|    in a way that provides normalized inputs to the later phases,
|    following an approach that in the design of computer software
|    is sometimes called "pipelining."
| 
|    A final consideration in the design of the specification
|    process is the practical difficulty of managing a
|    theoretically unlimited number of industry-specific standards
|    efforts without requiring more of the participants in each
|    effort than the work needed to implement information exchange
|    agreements within their industry and without placing an undue
|    burden on OASIS as an organization.  This suggests a system in
|    which resources are allocated from the bottom up and which
|    depends heavily on principles of voluntary association.
|
|    The normal OASIS specification process can briefly be
|    described as follows.  (Note that this description is intended
|    to provide an informal orientation to the process; procedural
|    details are specified separately.  The term "board" refers to
|    the OASIS Board of Directors.)
| 
|       PHASE 1: PREPARING TO INCORPORATE AN OASIS ACTIVITY
| 
| 	 This optional preparatory phase applies when it is
| 	 proposed to adopt an existing specification effort into
| 	 OASIS or to use the OASIS process for the harmonization
| 	 of multiple pre-existing specification efforts.  In the
| 	 case of harmonization efforts, a process for proposing
| 	 and conducting industry unification conferences applies
| 	 at this stage.
| 
|       PHASE 2: PROPOSING AN OASIS ACTIVITY
| 
| 	 In this phase, a group of OASIS members (individuals or
| 	 organizations) meeting a specified set of criteria

criteria set by whom according to what rules?  I think this clause
should be dropped (as I said in Montreal).

| 	 submits an activity proposal to the board stating the
| 	 problem to be solved and containing (a) an abstract of a
| 	 strategy for solving the problem by means of one or more
| 	 OASIS specifications and (b) a list of OASIS members
| 	 committed to fulfilling certain specified roles
| 	 (convenor, requirements editor, etc.) in the development
| 	 of a charter for a committee to carry out the activity.
| 	 This phase and the ones that follow are essentially the
| 	 same regardless of whether the activity originated
| 	 within OASIS or outside of it.

Here is where we might want some role for the TC-as-a-whole, rather
than overloading the Board with potentially scores or hundreds of
proposals.  I'm feeling a gap in organization between board and
member.

Also, I don't think that we can insist that all participants be
OASIS members; especially for industry verticals we should allow
invited experts.  Fig leaves can be imagined, however.

| 	 Note that acceptance by the board of a proposal to form
| 	 a charter does not imply approval of the proposed
| 	 activity but simply licenses the interested parties to

What would the Board do if it did not approve?  Can the Board
decline a proposal and if so on what grounds?

| 	 hold meetings for the purpose of developing a proposed
| 	 charter in enough detail to be considered.  The board
| 	 may itself initiate an activity proposal by appointing a
| 	 set of persons meeting the criteria for a proposal group

those criteria again.

| 	 and asking them to submit the proposal.  Note also that
| 	 this phase need not be publicly visible.

I think it should be, by rule.  I don't want the Board initiating
stealth proposals, and I think all proposals should be publicized
so that the membership knows what's going on and how OASIS governance
is working.  If the Board declines a proposal it should have to say
why.  Also, it's important to air these proposals if we want to 
avoid overlaps and conflicts.  In the IETF this is the BOF stage,
which has to convince an Area Director of merit.

|       PHASE 3: CHARTERING AN OASIS TECHNICAL COMMITTEE
| 
| 	 Upon acceptance of the activity proposal by the board,
| 	 the convenor named in the proposal assembles the persons

We should probably allow for the case of convenors, even if one
is better than two or three.

| 	 specified in the proposal, together with such other
| 	 participants as he or she may designate, in a series of
| 	 meetings whose purpose is to create the charter for an

or e-mail discussion.

| 	 OASIS technical committee and to define a set of
| 	 functional requirements that must be met by the
| 	 specifications produced by the proposed committee.

The scope of the charter should be limited to that which is unique
to the problem.  Rosetta Net WGs waste lots of time deciding on
procedure for such things as voting - that should be common to
all TCs.  

Defining functional reqs may legitimately be part of the work
of the TC, as with Regrep, so this phase should not be the last
chance to do so.

| 	 Participation in this phase of the process may be
| 	 limited to specific individuals deemed best qualified to
| 	 create the charter and to define the activity
| 	 requirements, and the group may call upon individuals or
| 	 organizations outside of OASIS for information
| 	 contributing to its goal.  Since this phase creates no

Limited by whom, on what criteria?  In the IETF this is open to
all, and I would recommend that approach.

| 	 specifications, the deliberations of the group formed to
| 	 draft the committee charter and to define functional
| 	 requirements need not be exposed to persons outside the
| 	 group.

Disagree completely.  This is fundamental work, and should be public.

|       PHASE 4: PROPOSING AN OASIS TECHNICAL COMMITTEE

I'm confused about the difference between an Activity and a TC.
Is this section about what to do before you get Board approval?
If not, the "activity charter" mentioned below should already
have been promulgated.

| 	 No matter what its origin, a proposal to form an OASIS
| 	 technical committee (TC) contains three basic elements:
| 	 an activity charter, including background, mission, and

what is mission aside from "create the deliverables"?

| 	 deliverables; a definition of functional requirements to
| 	 be met by the specification(s) developed by the TC; and

okay to do that in this phase, but you have it in the previous
phase, too.

| 	 a list of OASIS members initially committed to the work,
| 	 including at least one person willing to perform the
| 	 duties of TC chair and at least one other person willing
| 	 to perform the duties of specification editor for each
| 	 specification proposed as part of the activity.  These
| 	 people need not have served in corresponding roles
| 	 during the previous phase or even have participated in
| 	 that phase.

I thought they were listed in Phase 2, (b).  Unless there's some
point in Phase 4, I say fold it into 2 and 3.

|       PHASE 5: DESIGNING OASIS SPECIFICATIONS
| 
| 	 A TC creates one or more specifications sufficient to
| 	 fulfill the requirements defined in the charter phase
| 	 according to procedures set forth in detail elsewhere in
| 	 this document.  TCs are open to any individual OASIS
| 	 member and to any employee of an OASIS member
| 	 organization who maintains a minimum level of
| 	 participation in the work, and they are closed to
| 	 participation by any other person.  The committee's
| 	 progress is evidenced by its mailing list, working
| 	 drafts, notes, and other publicly visible
| 	 manifestations.

I see no point in "minimum level of participation."  It will be
difficult to define and can be applied only in painful personal contexts,
and there's no harm in having members of the TC who do nothing.

| 	 Note that (a) no provision is made in this process for
| 	 invited experts, since OASIS membership is available to
| 	 any individual for a reasonable annual fee, and that (b)

I demur.  Individuals have no vote and the Board has no practice
of or procedure for communicating its deliberations and decisions
to the membership.  Were I fortunate enough to retire early, I would 
retain an interest in Docbook, but I'm hard pressed to say I'd pony
up $250 a year under these conditions - it's just not reasonable.
You might reasonably require that an activity (or TC?) proposal
come entirely from members.

| 	 no provision is made for the establishment of associated
| 	 interest groups; the charters, requirements, mailing
| 	 lists, and working drafts of an OASIS TC being open to
| 	 public view, its work may be discussed anywhere.  (In
| 	 the case of TC mailing lists, "open" means only that the
| 	 mail archive is world-readable.  The right to receive
| 	 mail as it is generated and to post to an OASIS TC
| 	 mailing list are privileges of OASIS membership not
| 	 available to the general public.)

Need to clarify whether members not TC members can subscribe;
it would help answer some of my points and if members not TC
members can subscribe but not post, there would be some
implications for technical infrastructure.

|       PHASE 6: COMPLETING AN OASIS SPECIFICATION

Whoa, we're not completing yet, we've only just gotten started.
The notes on Phase 5, below, show that there's more to the
Phase 5, above, than is here yet; I suggest breaking that into
two Phases.

| 	 A TC signifies the completion of an item of work by
| 	 formally approving a final draft specification and
| 	 passing it on to the board.  The OASIS Secretary (an
| 	 officer of the corporation) assigns the specification a
| 	 tracking number.  A numbered OASIS specification that
| 	 has passed out of committee but has not been formally
| 	 approved by OASIS is called an OASIS committee
| 	 specification (CS).

I feel as though some status has been left out, but amn't sure what.
Regrep is ready to put out for public review a draft specification
that is far from final.  There's a skew between committee/OASIS/board
and draft/final.

| 	 The idea of CS status is an especially important feature
| 	 of the OASIS technical specification process.  The
| 	 assignment of a CS number is a public statement that a
| 	 specification is ready for initial implementation but
| 	 has not yet attained the status of an OASIS technical
| 	 resolution.  A CS is a specification that has received
| 	 the formal approval of the committee that created it,
| 	 which depends on a vote of the committee's members in
| 	 good standing and signifies that the group of interested

I fear that "good standing" has to go.

| 	 and presumably expert *individuals* who have
| 	 participated in the work believe that their work is now
| 	 ready for use.  But it is not something that represents
| 	 OASIS itself, which, as described below, requires a vote
| 	 of the *organizations* having voting membership at the
| 	 OASIS level (or an extraordinary emergency action by the
| 	 OASIS board).

Well, good try.  In fact, the individuals employed by members 
better check to see that their employers approve (or don't disapprove)
of the CS, too, and I would expect employers to think that a CS
voted for by one of their employees would be seen as having been
approved by them.  

Need to flesh out "extraordinary emergency action".

| 	 In conjunction with the fact that the cost of a TC
| 	 effort is in the general case borne entirely by its
| 	 participants, this means that data exchange requirements

by their employers, if they work for member companies.

| 	 in particular industries can quickly be met through a
| 	 potentially unlimited number of domain-specific data
| 	 exchange specifications at the initiative of relatively
| 	 small groups of OASIS members (organizations or
| 	 individuals) and can achieve CS status entirely on the
| 	 authority of the participants in each TC without
| 	 requiring centralized management or coordination, as
| 	 long as each such initiative follows the rules set forth
| 	 in the process description.

As Murray would say, that's an assertion.  And I don't think it
follows logically from what preceded it.  I notice you snuck back
in the OASIS member organizations.  In addition, CS status *cannot*
be achieved entirely on the authority of TC members - the OASIS
Secretary must have approved it in some wise.  Surely there would
be cases in which the Secretary would withhold a tracking number,
such as a spec that was incorrectly formatted (for example, in
a proprietary format).

|       PHASE 7: BOARD REVIEW
| 
| 	 As with all formal decisions of OASIS as a non-profit

nonprofit

| 	 corporation, the disposition of a CS is legally at the
| 	 discretion of the OASIS board.  Actions that the board
| 	 can take range in theory (and under extraordinary
| 	 circumstances, in practice) from immediate approval at
| 	 one extreme to outright repudiation at the other, with
| 	 stages in between that can conceivably include the
| 	 return of a CS to its originating TC with instructions,
| 	 the dissolution of the TC without a replacement, or the
| 	 creation of a new TC to continue working with new
| 	 membership and/or a new set of directions.  In the
| 	 ordinary course of events, however, the board will

we do not know what the ordinary course of events will be.

| 	 typically wait for some amount of comment or
| 	 implementation experience and then either refer the CS
| 	 back to the originating TC for revision in the light of
| 	 experience or proceed to schedule an OASIS vote to
| 	 approve the specification as an OASIS technical
| 	 resolution.

Far too limp.  We need process for Board approval; the Board's
deliberations should be public; its actions and the reasons for
them should be documented; and the possible paths should be
established beforehand.

|       PHASE 8: OASIS REVIEW
| 
| 	 When, in the judgement of the board, a CS is ready for
| 	 review by OASIS as a whole, a process (described in
| 	 detail below) is set in motion that culminates in a vote
| 	 by the OASIS membership.  If the specification is
| 	 approved by the membership, it becomes an OASIS
| 	 technical resolution (TR).
| 
| 	 Note again that the vote to approve a TR counts the
| 	 number of OASIS member organizations favoring the
| 	 adoption of the resolution and is fundamentally
| 	 different from the vote to approve a committee
| 	 specification, which counts the number of individuals on
| 	 the committee favoring public implementation of the
| 	 specification, regardless of their organizational
| 	 affiliation.  It is possible and, indeed, anticipated
| 	 that some committee specifications may be adopted for
| 	 limited use within particular industries without ever
| 	 achieving the status of OASIS technical resolutions.

I see no point in having individuals do the work and orgs approve it.
What is the aim here?

|       PHASE 9: INTERNATIONAL STANDARDIZATION
| 
| 	 If the board judges an approved technical resolution to
| 	 have an appropriate level of importance, stability, and
| 	 breadth of implementation, the Board may submit the
| 	 specification to a relevant ISO committee with a request
| 	 that it be considered for approval as an International
| 	 Standard.

We absolutely must include the IETF here.

[deleted the rest]