[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: results of staw poll
Here's the compiled results of the straw poll. Let's use this as the basis
for our discussion in today's meeting.
Jon: have you sent out the meeting details yet?
</karl>
=================================================================
Karl F. Best
OASIS - Director, Technical Operations
978.667.5115 x206
karl.best@oasis-open.org http://www.oasis-open.org
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
Eduardo
__ disagree to add these additional requirements
Tommie: It seems to me that we should encourage TCs to know who else is
doing related work, but should word any requirement that they state who
these people/groups are in a way that does not:
a) require coordination/liason
b) does not invalidate the work of a TC if such a group is discovered
after the TC begins work
Robin
Debbie: 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
Ken: Who is to assess how similar is "similar work"? Would the answer to
this possibly disqualify the committee from being created? I can see a
committee being very useful in investigating innovations and alternatives,
taking advantage of the process being offered by an OASIS TC.
__ neutral to add these additional requirements
__ I believe this warrants serious discussion
Lauren: Need discussion; it may not be possible to find all other groups
doing similar work; it may not be feasible given the resources of the TC;
and we need to make clear that they do not need to liaise or co-ordinate if
they choose not to (similar for conformance).
Karl: My intent agrees with Tommie's comment above; the proposers of the TC
would only be required to identify other groups doing this work so that
OASIS can encourage collaboration. It's a requirement to do the
interllectual exercise and nothing else.
--------------------------------
1b. 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
__ disagree to add these additional requirements
Eduardo
Tommie
Robin
Debbie: 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?
Ken (see above comment)
__ neutral to add these additional requirements
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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 require ratification
Eduardo
Lauren
__ disagree to require ratification
Robin
Debbie: 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.
__ neutral to require ratification
Tommie
Ken
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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 require different companies
Robin: I don't feel strongly about this (in fact, almost neutral). Thoughts:
what would/could it mean if two people in the same company COULD NOT find
anyone outside their company interested in the TC work? Or simply did not
want to? Would the OASIS Board (unnecessarily) be drawn into the picture if
a single company, for whatever reason, initiated (e.g.,) 15 TCs composed
only of its own company members [overhead!]. My inclination to agree is
rationalized thus: if the initial members cannot find other interested
parties outside their company, or if they do not want to include others --
better perhaps to conduct this work *inside* the company for a while
longer... why should OASIS resources be used, and "company" design be
branded as OASIS activity?
__ disagree to require different companies
Eduardo
Lauren: We discussed this at length previously; I have seen no evidence to
change our decision.
Tommie
Debbie: Why separate companies? Open is open. There are parts of Sun, IBM,
icrosoft
(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.
Ken: A company may not have a process like the TC process available to them
to take advantage of ... in this way OASIS is being a service to the member
company.
__ neutral to require different companies
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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 require eligibility at 15 days
__ disagree to require eligibility at 15 days
Eduardo
Lauren: As Eduardo said, what's wrong with last-minute membership scrambles?
I assume these will become less scrambly, since more companies have now
joined OASIS.
Tommie
Robin
Debbie
__ neutral to require eligibility at 15 days
Ken
__ I believe this warrants serious discussion
Karl: This is to solve an administrative problem: people are signing up for
the TC when they are not yet members; additional time is required for
additional tracking to make sure that they obtain OASIS membership before
the first meeting. The current language does not promote scalability.
----------------------------------------------------------------------------
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:
Eduardo: I think that person should already be out:
Meeting Meeting Meeting Meeting Meeting Meeting Meeting Meeting
N N Y <--- out, missed two out of three
Y N N <--- out, missed two out of three
Y N Y N <-- out, missed two out of three
Y Y N N <-- out, missed two out of three
Y N Y Y N N <-- out, missed two out
of three
What am I mis-reading? You basically can't miss two meetings in a row, and
you can't do Y/N/Y/N. I thought this was simple; obviously others are
reading the rules differently. Please enlighten me.
Lauren: [suggest that] warnings don't reset the clock.
Tommie: Limit people to one warning per year. This gives one "free"
restart, and after that there is an automatic out after missing two
meetings.
Debbie: Let's dicuss. The math gets odd.
Ken: we need to talk about this based on experiences in my XSLT committee.
----------------------------------------------------------------------------
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:
Lauren: In my TC it was useful to have the member still there; but he was
only unemployed for a short period of time (and then changed companies
again, but that's a different story).
Debbie: 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.
Ken: if they are a corporate member I think they would just become an
individual member and restart the observer process ... all they are missing
out on is voting, not on the participation or work of the committee
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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 that prospective member must participate
Ken
__ disagree that prospective member must participate
Lauren: We left this up to the chair with good reason; the TC may be large,
and there may be good reason to think the prospective member will drop out
before becoming a real member.
Tommie: I don't see how we can require this if we also allow TC Chairs to
exclude them from meetings.
Debbie: 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?)
__ neutral that prospective member must participate
Robin
__ I believe this warrants serious discussion
Eduardo: I would like to agree, but this entails modifying the chair's
discretion regarding participation of prospective members, particularly in
telcons.
----------------------------------------------------------------------------
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.
__ agree to allow invited experts
Eduardo
Robin: I would favor at least "invitation by the chair" which allows them to
be present at meetings and to contribute, perhaps without a vote.
Debbie: Chair invites, possibly at the suggestion of members. OTOH: wasn't
this what the $250 membership was for?
__ disagree to allow invited experts
Lauren: $250 is not a lot of money to join in. Perhaps OASIS could waive the
fees for particularly useful individuals, but I think everyone should be a
member.
Tommie: If the policy is that anyone who is serious can afford to be an
individual OASIS member, then we don't need to do this. Are there really
people we want to participate in TCs who can't/won't come up with the $250?
Ken: my gut feel is that they should just become individual members as that
is why individual membership exists
__ neutral to allow invited experts
__ I believe this warrants serious discussion
My suggestion for particpation requirements:
Eduardo: Same rights and duties as PEOTCPs. Otherwise we get into a
bureaucratic nightmare. The only question in my mind would be whether the
chair can also dis-invite invited experts. Does RR talk about this?
----------------------------------------------------------------------------
9. What happens when membership in a TC drops below three people? Is a
one-person TC still a TC? How many people are required to be in the TC when
it completes its work and votes to create a Committee Specification?
My suggestion:
Eduardo: Disband TCs whose membership drops to < 3 (or perhaps give them one
month to try to increase membership?)
Lauren: The TC should cease. If the people who committed to participating
aren't any more, then the TC needs to be reconstituted. I see no point in
allowing a grace period of more than a few days. There is nothing stopping a
new TC carrying on the work that a previous TC started.
Tommie: It took three people to start a TC; it should take 3 people to
sustain one.
Debbie: 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.
Ken: acceptable to have a minimum membership of three
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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.
__ agree that list subscribers don't need to be PEOTCPs
Tommie
Robin
Debbie
Ken: assuming the question is for "discussion list", not the actual
committee list
__ disagree that list subscribers don't need to be PEOTCPs
__ neutral that list subscribers don't need to be PEOTCPs
__ I believe this warrants serious discussion
Eduardo: Does agreement mean that lists would then become open to non-OASIS
members? I believe there was some to and fro on this subject, and it was
decided that the comments lists would obviate this. As far as I can see,
there has been very little (if not nil) activity in comments lists. I would
propose that comments lists be killed, and that TC lists be totally open to
the world. If members of a TC want to discuss something away from the
public's prying eyes they can always do so by other means.
Karl: Eduardo is probably mixing up discussion lists with comment lists. The
purpose of the discussion list is to discuss whether a TC should be started.
I'm suggesting that non-members be allowed to discuss whether to start a TC
in hopes that some of them may want to join the TC (and OASIS) once it
starts.
Lauren: Which do you mean here? Subscribing to the list and participating in
the discussions are two different things. Only members of the TC may
participate (I think this is a good rule).
----------------------------------------------------------------------------
Standards Process
=================
11. Is OASIS justified in calling the results of our process a "standard",
as we are not a de juere standards organization?
__ agree that OASIS should call its work "standards"
Lauren: Why not? As long as the adjective is there.
Tommie: An organization becomes a standards organization first by saying it
is, and then by other people accepting it. There is no "official"
designator of standards organizations; if OASIS wants to be a standards
organization then it needs to say so, and then act like it is.
Debbie: 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?
Ken: the ISO defines a difference between standards and reports: a standard
is something used by others, a report is something illustrating a standard;
for example, ISO 8879 is the International Standard for SGML, while ISO 9573
is a technical report on the use of SGML at ISO Central Secretariat - there
aren't many reports, but they are distinct from standards - I think we could
have the same distinction in OASIS
__ disagree that OASIS should call its work "standards"
__ neutral that OASIS should call its work "standards"
Robin: I'm not sure "justified" is the most relevant aspect of the question;
"standard" is used in many ways, and I don't think anyone has the authority
to declare what a "standard" is or is not. However, I am interested in the
notions of relative stability/maturity and competence, as possibly
communicated through the word "standard." I wish we had something like NISO
has in "Draft Standard For Trial Use (DSFTU)" -- the notion that "we think
this is a mature specification, but we won't know for a year or two, based
upon long-term implementation reports." I rather think "standard" should
be reserved for something that's proven to work, and question whether a
company's mere saying "yeah, we implemented it" [no real feedback from users
yet] is actually sufficient grounds for calling something a "standard" in
the sense of being proven to work well. Note that the "NISO Circulation
Interchange Protocol (NCIP)" as DSFTU is in limbo (extended Review Period)
January 15, 2001 - January 15, 2002.
__ I believe this warrants serious discussion
Eduardo: I thought we'd talked this one to death, but obviously not.
----------------------------------------------------------------------------
12. Define how existing/completed work can be submitted to OASIS to become
an OASIS Standard without having to go through a TC. (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
__ disagree that we should allow this
Robin: I can't quite see the urgency (less than 45 days). What political
force (beyond mere utilitarian value?) is gained by hasty/immediate adoption
of an existing standard as an OASIS standard?
Debbie: Standard process, why the hurry?
Ken: my perception is that there have been only problems at ISO/IEC JTC 1
with the PAS submission process ("Public Available Specification") and the
actions of qualified PAS Submitters (groups deemed to have sufficient public
input to qualify publicly available specifications as having been an open
and fair development) - to avoid problems I think anyone wishing to take
existing work in to OASIS go through all the regular channels to ensure
appropriate involvement
__ I believe this warrants serious discussion
My alternate suggestion:
Eduardo: I think that existing/completed work should be submitted to the
Oasis Board as if it was coming from a TC, and take it from there (that is,
submit it to Membership vote, etc.)
----------------------------------------------------------------------------
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.) Should the committee work product
still be reviewed by membership?
__ agree that committee work should be reviewed by members
Lauren
Robin: People change their minds.
__ disagree that committee work should be reviewed by members
Ken: when was it decided a test suite wouldn't be an OASIS standard? I
think it qualifies ... it is something that is used by others, not just
illustrative - one of the benefits of the process was that it was available
to members to be used as a tool to come to some kind of closure of their own
definition ... I don't see membership review as being required
__ neutral that committee work should be reviewed by members
__ I believe this warrants serious discussion
Eduardo: I think that test suites should be considered specs, not tools.
Don't see why they can't be submitted to vote.
Tommie: Where did the distinction between "tools" and "specs" come from? And
since when is a test suite not a specification? It's a specification for
conformance, and I don't see that it's any different from any other
specification.
Debbie: Disagree wholeheartedly. 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.
__ agree to base vote on membership at start of evaluation period
Eduardo; no need to discuss
Lauren
Tommie
Debbie
Ken
__ disagree to base vote on membership at start of evaluation period
__ neutral to base vote on membership at start of evaluation period
Robin
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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
Lauren
Robin
Ken
__ disagree to add IPR and copyright to checklist
Tommie: We discussed this at length, and decided that since there was
already an OASIS IPR policy anything we added would simply muddy the waters.
If there are two rules about the same thing there can be conflict about
which applies; if there is only one rule (the current OASIS IPR policy) then
it clearly applies. It might be appropriate to note in the non-normative
manual for committee chairs that there is an IPR policy.
Debbie
__ neutral to add IPR and copyright to checklist
__ I believe this warrants serious discussion
Eduardo: Sorry, this confuses the hell out of me. Doesn't including the
Oasis copyright moot all other IPR issues?
----------------------------------------------------------------------------
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
Ken: while I acknowledge it isn't being used well yet, I think the
distinction is important; as I understand it the committee is not obliged
(but may do so if they choose) to respond to any post or statement made to
the comments list; by having it separate this division of responsibility is
kept clear
__ I believe this warrants serious discussion
My alternate suggestion:
Eduardo: same comments as #10
Lauren: The ER TC list does use the comments list and we find it useful.
Maybe the problem is that people aren't yet used to the new process, and
most TCs aren't far enough along yet to use the comments lists?
Tommie: I don't mind if the requirement is stated functionally, but this
suggestion ignores one of the key functions of the dual list system. (The
argument that something people don't know about isn't needed because it
isn't used is specious). I think it would be very valuable for TC members to
be able to separate (by use of an email filter) mail from TC members and
mail from the outside about the TC. This will be especially important if
OASIS has any controversial TCs; without the ability to do this filtering
vociferous non-members could flood the TC list, making TC work on a list
virtually impossible.
Robin: Need discussion of the exact problem here...
Debbie: 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
Ken
__ disagree with suggestion
Tommie: Why is it embarrassing to say that there are groups working at
various speeds? And that some are available if needed but not currently
active?
Robin
Debbie
__ I believe this warrants serious discussion
My alternate suggestion:
Eduardo: Sustaining TC may not have reason to meet often. This does not
constitute a reason to kill them. I think there should be a provision for a
TC's chair to declare a TC inactive or terminated, thus permitting its
removal forthwith.
Lauren: Why is it embarrassing to OASIS when member initiatives aren't well
attended? You just say "they're member initiatives".
----------------------------------------------------------------------------
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
__ disagree that process should define subcomittees
Eduardo
Tommie: There should be a lot of variation at this point; large TCs will
want more subcommittees than small, and more structured subcommittees.
Since from the point of view of Roberts subcommittees are ephemeral I don't
see why we would need to be prescriptive in this area.
Debbie: Is it dangerous not to set up a process? In what way? Please prove
need.
Ken
__ neutral that process should define subcomittees
Lauren
Robin: What rules/guidelines/instructions need to be defined? I might agree
if there's a demonstrated need.
__ I believe this warrants serious discussion
----------------------------------------------------------------------------
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
__ disagree that more should be specified
Lauren
Tommie: The guidelines should be sufficient, and suggestive only. If we tie
this down too tightly we'll kill it.
Robin: What "more" would need to be said?
Debbie: Non-normative guidelines only!
Ken
__ neutral that more should be specified
__ I believe this warrants serious discussion
Eduardo: A non-normative guidelines document should be sufficient.
----------------------------------------------------------------------------
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"
Robin: If not "eligible person", something similar...
__ disagree to replace "PEOTCP" with "eligible person"
Eduardo: What I object is a global s/PEOTCP/eligible person/ I think some
thinking should be applied, as there may be some places where PEOTCP is
needed rather than "eligible person".
Lauren
Tommie: "eligible person" would have to be very carefully defined, and
might be confused with people eligible for something else. PEOTCP is ugly,
but it is clear.
Debbie: "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.
Ken
__ neutral to replace "PEOTCP" with "eligible person"
__ I believe this warrants serious discussion
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC