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: straw poll - 20 items


Works for me.

Everyone: please split item #1 into two sub-options, #1a for coordination
(agree, disagree, and neutral) and #1b for conformance (agree, disagree, and
neutral).

Please note that I'm only suggesting that the TC be required to identify
whether and where the work would/could be done, but it is not required that
the TC do the work themselves.

</karl>
=================================================================
Karl F. Best
OASIS - Director, Technical Operations
978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org


> -----Original Message-----
> From: eduardo@rug.Eng.Sun.COM [mailto:eduardo@rug.Eng.Sun.COM]On Behalf
> Of Eduardo Gutentag
> Sent: Tuesday, June 05, 2001 1:19 PM
> To: Karl F. Best
> Cc: workprocess@lists.oasis-open.org
> Subject: Re: straw poll - 20 items
>
>
> Item (1) below is in fact two items. One could agree to
> coordination but disagree
> with conformance, for instance. I'd suggest that you either
> renumber the items
> or have (1a) and (1b)
>
> Eduardo
>
> "Karl F. Best" wrote:
> >
> > PAC:
> >
> > Debbie suggested that we should straw poll the 20 items in
> advance of the 13
> > June meeting in order to save time at the meeting. In order to help
> > accomplish this I am resending the 20 items with choices to vote on.
> >
> > Please reply to the list with your choices marked on this
> message. I will
> > compile any votes received by the day before the meeting. Fell
> free to add
> > comments, especially if you're unsure what an agree/disagree vote would
> > mean.
> >
> > </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
> >   - 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)
> >   - 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
> > __ neutral to add these additional requirements
> >
> > 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
> > __ disagree to require ratification
> > __ neutral to require ratification
> >
> > 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
> > __ disagree to require different companies
> > __ neutral to require different companies
> >
> > 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
> > __ neutral to require eligibility at 15 days
> >
> > 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:
> >
> > 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:
> >
> > 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
> > __ disagree that prospective member must participate
> > __ neutral that prospective member must participate
> >
> > 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
> > __ disagree to allow invited experts
> > __ neutral to allow invited experts
> >
> > My suggestion for particpation requirements:
> >
> > 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:
> >
> > 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
> > __ disagree that list subscribers don't need to be PEOTCPs
> > __ neutral that list subscribers don't need to be PEOTCPs
> >
> > 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"
> > __ disagree that OASIS should call its work "standards"
> > __ neutral that OASIS should call its work "standards"
> >
> > 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
> > My alternate suggestion:
> >
> > 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
> > __ disagree that committee work should be reviewed by members
> > __ neutral that committee work should be reviewed by members
> >
> > 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 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
> > __ disagree to add IPR and copyright to checklist
> > __ 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:
> >
> > 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
> > __ disagree with suggestion
> > My alternate suggestion:
> >
> > 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
> > __ neutral that process should define subcomittees
> >
> > 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
> > __ neutral that more should be specified
> >
> > 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"
> > __ disagree to replace "PEOTCP" with "eligible person"
> > __ neutral to replace "PEOTCP" with "eligible person"
>
> --
> Eduardo Gutentag               |         e-mail: eduardo@eng.Sun.COM
> XML Technology Center          |         Phone:  (650) 786-5498
> Sun Microsystems Inc.          |         fax:    (650) 786-5727
>



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


Powered by eList eXpress LLC