[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: straw poll - 20 items
-----------------------------------------------------------------
>
> TC Formation
> ============
> 1. Add to section 3 that the proposed charter should
1a:
> - Identify what other groups/committees inside and outside of OASIS are
> doing similar work, and specify what coordination/liaison could or will be
> done with those other groups. (This is the same as Robin's suggestion of
> 4/23)
__ agree to add these additional requirements
_X_ disagree to add these additional requirements
__ neutral to add these additional requirements
This seems to be to be in 2 parts, but I disagree with both of them in various
ways.
1a1) Yes, a committee SHOULD known who else is doing similar work, but I
don't see that we can require them to, particularly OUTSIDE of OASIS.
If a members-only organization like RosettaNet is working on it, how
would I (a non-member) know that?
And it seems to me that OASIS is in a better position to remind them gently,
"oh by the by, you did know that Jon Bosak's Blort Technical Committee"
is already working on a similar problem? Have you read their charter and
lists?"
1b1) "specify what coordination/liason" -- absolutely disagree
> - Specify whether conformance testing will be done by this TC or by
> another group.
> (Note that this is not requiring that the TC do the coordination or
> conformance work, just that it must be identified. If the TC does not feel
> it is necessary or that the TC does not have the resources to do the work
> they can say so, but they must specify this. At the very least this would be
> an intellectual exercise, but could also go a long way towards increasing
> the quality of OASIS technical work.)
>
__ agree to add these additional requirements
_X_ disagree to add these additional requirements
__ neutral to add these additional requirements
Conformance testing is not appropriate for all the types of things
that may be considered by TCs, only for some. This is also very cart-
before-the-horse to me. Scenario: A TC is starting, we are just now
deciding if we can get enough folks to meet to see if this *might* be
a good idea, and you want me to make decisions about conformance testing?
-----------------------------------------------------------------
>
> 2. Add to section 4 that the charter and chair of the TC must be ratified by
> the members at the first meeting. This would allow tweaking the charter if
> things have changed over the 45 days since the announcement, another group
> wants to join in, etc. and would also allow for a different chair if
> participants like the charter but not necessarily the person who suggested
> it. (However, this admittedly could also introduce problems if a large
> number of people wanted to hijack the TC; let's discuss this.)
>
__ agree to add these additional requirements
_X_ disagree to add these additional requirements
__ neutral to add these additional requirements
We talked about this at the time and I was in favor of it then. But I think
the concerns of the people who were worried about sabotage got to me. If
you disagree with a charter, go off and form a competing group; don't
kill my group.
-----------------------------------------------------------------
>
> 3. Add to section 3 that the three PEOTCPs that create a TC must be from
> different companies. This would prevent a single company from starting a TC.
>
__ agree to add these additional requirements
_X_ disagree to add these additional requirements
__ neutral to add these additional requirements
Why separate companies? Open is open. There are parts of Sun, IBM, Microsoft
(or any large company) that are as different from each other as they
are from me.
If this is one-company centric, the members can stop it in its tracks.
-----------------------------------------------------------------
>
> TC Membership
> =============
> 4. Add in section 4 that a person must be a PEOTCP at the time of notifying
> the chair of the person?s intent to join (i.e. 15 days before first
> meeting). This is to avoid last-minute membership scrambles.
>
__ agree to add these additional requirements
_X_ disagree to add these additional requirements (but not strongly)
__ neutral to add these additional requirements
-----------------------------------------------------------------
>
> 5. Currently, in section 6, to retain TC membership a person must attend two
> out of three meetings. What if a person misses two in a row, gets a warning,
> then attends the third meeting so he?s back in, but then misses the fourth?
> He?s now attended only one out of four meetings. (This is the case mentioned
> by Eve on 3/20 and forwarded by Jon on 4/20.)
>
> My suggestion:
Let's dicuss. The math gets odd.
-----------------------------------------------------------------
>
> 6. In sections 5, 6, and 7, how does a person retain TC membership when
> switching employment? How long can the person take to find a new job, and
> can they continue to participate while unemployed? (This is a case mentioned
> by Lauren on 1/15.)
>
> My suggestion:
This takes discussion.
The hard line: If switch to a member company no problem, if switch and
join as an individual again no problem, otherwise out.
The reality: the problem comes when a job is lost not voluntarily given up
and how long should a committee wait. Ouch.
-----------------------------------------------------------------
>
> 7. In section 5 add the requirement that a prospective TC member participate
> in the TC as an observer according to the existing "two out of three"
> attendance rules during the probationary period. This would make sure that
> the new member is committed and educated before being allowed to vote.
>
__ agree to add these additional requirements
_X_ disagree to add these additional requirements
__ neutral to add these additional requirements
In theory, I'd love to require this, but we run into several problems:
a) The potential cost/logistics of phone meetings
b) Since (I think) TC Chairs can exclude them from meetings, a Chair
could keep out anyone he/she wanted to (OR HAVE I MISSED
something?)
-----------------------------------------------------------------
>
> 8. We need to decide whether to allow invited experts to participate in TCs,
> and if allowed define how they are invited and what their rights in the TC
> are.
>
_X_ agree to allow invited experts (speak=yes, vote=no)
__ disagree to allow invited experts
__ neutral to allow invited experts
>
> My suggestion for particpation requirements:
Chair invites, possibly at the suggestion of members.
OTOH: wasn't this what the $250 membership was for?
-----------------------------------------------------------------
>
> 9. What happens when membership in a TC drops below three people?
It dies.
>Is a one-person TC still a TC?
NO
>How many people are required to be in the TC when
> it completes its work and votes to create a Committee Specification?
>
> My suggestion:
Three.
-----------------------------------------------------------------
>
> Discussion Lists
> ================
> 10. Add to section 2 that, while a discussion list is started by PEOTCPs,
> subscribers to the discussion lists do not need to be PEOTCPs. This would
> allow prospective OASIS members to participate in the discussion to see if
> they are interested in joining OASIS for the purpose of participating in the
> TC.
>
_X_ agree to add these additional requirements
__ disagree to add these additional requirements
__ neutral to add these additional requirements
-----------------------------------------------------------------
>
> Standards Process
> =================
> 11. Is OASIS justified in calling the results of our process a "standard",
> as we are not a de juere standards organization?
>
_X_ agree that OASIS should call its work "standards" (strongly!)
__ disagree that OASIS should call its work "standards"
__ neutral that OASIS should call its work "standards"
What is a standards organization? W3C is not one, ISO is by
international consent,
but what about IETF, IEEE, AMS, et al. There are no "standards police".
We are if we say we are and can back it up.
The process takes both implementations and votes. Enough?
-----------------------------------------------------------------
>
> 12. Define how existing/completed work can be submitted to OASIS to become
> an OASIS Standard without having to go through a TC.
This takes discussion
>(I suggest that we
> simply require three PEOTCPs to submit the work and certify three
> implementations on the existing quarterly schedule. This would save the
> effort of setting up a TC and the 45 days wait to hold the first TC
> meeting.)
>
__ agree with suggestion
_X_ disagree that we should allow this
My alternate suggestion:
Standard process, why the hurry?
-----------------------------------------------------------------
>
> 13. Should we do anything different for committee work that is not designed
> to be submitted to membership for creation as an OASIS Standard? (e.g.
> conformance test suites are considered tools, not specs, so are not
> submitted to become OASIS Standards.)
Disagree wholoeheartedly. Either this question shows a misunderstanding
of the entire process or I do not completely comprehend the question.
TC does NOT = standard; a standard is one possible result of the process.
But the converse is also true, there no committee work that "by definition"
is never destined to be a standard. The process is separated into many phases
for just this reason. At the end of each phase, a TC chooses whether or not to
move closer toward "standardness".
LOTS of TCs may never produce standards, because that
is not their goal, or they don't need to, or they don't think their work
was good enough, or technology overtook them, or lots of reasons.
Remember, a TC could CHOOSE not to try to make a standard. But I
am not at all sure that you can know, for certain and all, *when the process
starts* where it will wind up. A nothing of an idea may sprout into a
standard and a ripe, good idea may run afoul of any number of things.
I maintain that you cannot reliably identify this category of committee work.
>Should the committee work product
> still be reviewed by membership?
__ agree that committee work should be reviewed by members
__ disagree that committee work should be reviewed by members
__ neutral that committee work should be reviewed by members
None of the above. ONLY if the committee asks, should the
membership review. If a TC asks, then, yes it should. After all
a report out of committee is just that and needs no membership
approval or oversite.
Aside: Why isn't a test suite just the same as any other "standard"?
I feel this is an artificial distinction.
-----------------------------------------------------------------
>
> 14. Add that member organizations voting on a proposed OASIS spec must be
> members at the time the proposal is submitted to the membership, i.e. the
> start of the evaluation period. The 10% required for voting should be based
> on the number of member organizations at the start of the evaluation period.
> This is to prevent the vote from getting invalidated if we get a bunch of
> new members during a ballot period.
_X_ agree to base vote on membership at start of voting period
__ disagree to base vote on membership at start of voting period
__ neutral to base vote on membership at start of voting period
-----------------------------------------------------------------
> 15. Add to the checklist that the committee?s submission (for a TC
> specification to be voted on as an OASIS standard) must include a statement
> regarding IPR compliance. Also, the submitted committee specification doc
> must include the OASIS copyright statement that is in the IPR.
>
__ agree to add IPR and copyright to checklist
_X_ disagree to add IPR and copyright to checklist (but not strongly)
__ neutral to add IPR and copyright to checklist
-----------------------------------------------------------------
>
> General/Other
> =============
> 16. In section 9 the mail list requirements aren?t very workable: there are
> two lists (discuss and comment) used to satisfy three groups of people (TC
> members, OASIS members, and the public). The comment lists are required to
> exist but are unused. I suggest that the TC process should simply describe
> the effect (e.g. "allow outsiders to post comments to the discussion list")
> without describing the method to accomplish the goal; let the list
> administrator figure out how best to do it. For example, the discussion list
> could simply be opened to postings from the public; subscriptions would
> still be restricted to members. This would do away with the need for a
> separate comment list.
>
__ agree with suggestion
__ disagree with suggestion
My alternate suggestion:
Discuss. I really liked the idea of separate.
-----------------------------------------------------------------
>
> 17. I suggest a shorter amount of time to kill an inactive TC. Currently in
> section 11 an inactive TC can only be killed at the beginning of the year
> after a full year without a meeting; this could be 12-24 months of
> inactivity before the TC can be killed. I suggest that six to nine months of
> inactivity (no meetings, no substantive discussion) would be better. It?s
> publicly embarrassing to OASIS to have to publicize inactive TCs, and extra
> effort is required for OASIS to maintain the TC on our lists, etc.
>
__ agree with suggestion
_X_ disagree with suggestion (but not strongly)
-----------------------------------------------------------------
>
> 18. The TC Process does not define how to set up subcommittees of the TC,
> and doesn?t say anything about them at all other than mentioning them as
> part of the Joint Committee discussion. The Process should provide
> guidelines/rules for their creation and operation.
>
__ agree that process should define subcomittees
_X_ disagree that process should define subcomittees (not strongly)
__ neutral that process should define subcomittees
Is it dangerous not to set up a process? In what way? Please prove need.
-----------------------------------------------------------------
>
> 19. The TC Process says little or nothing about how a TC operates once it
> has been set up, other than specifying RRO for the conducting of business.
> Should more be specified? or is a non-normative guidelines document
> sufficient?
>
__ agree that more should be specified
_X_ disagree that more should be specified
__ neutral that more should be specified
Non-normative guidelines only!
-----------------------------------------------------------------
>
> 20. I suggest that throughout the process document we drop the acronym
> "PEOTCP" and simply use the phrase "eligible person" instead. This would
> make the process document easier to read.
>
__ agree to replace "PEOTCP" with "eligible person"
_X_ disagree to replace "PEOTCP" with "eligible person" (but not strongly)
__ neutral to replace "PEOTCP" with "eligible person"
"eligible person" would need defining. The beauty of an ugly
non-standard term is that it must be looked up, since no one will know it,
and is easy to remember and identity, once learned.
-----------------------------------------------------------------
--
======================================================================
Deborah Aleyne Lapeyre mailto:dalapeyre@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9633
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC