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


"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
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)
_X_ agree to add these additional requirements
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
> _X_ 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.)
> 
> _X_ agree to require ratification
> __ disagree to require ratification
> __ neutral to require ratification

Agree also that this requires discussion. In particular, I think that something
should be said about changing charter mid-stream, which I believe is currently
happening without provision for it in the process (or is there?)

> 
> 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
> _X_ disagree to require different companies
> __ neutral to require different companies

I actually violently disagree with this proposal. It hijacks the simplicity of
stating that any three PEOTCPs can start a TC. 


> 
> 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
> _X_ disagree to require eligibility at 15 days
> __ neutral to require eligibility at 15 days

I disagree mostly because I don't see the point. What's so bad with membership
scrambles?

> 
> 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.)

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?



> 
> My suggestion:

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.
> 
> 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:

I don't have a 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

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.
> 
> _X_ agree to allow invited experts
> __ disagree to allow invited experts
> __ neutral to allow invited experts
> 
> My suggestion for particpation requirements:

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:

Disband TCs whose membership drops to < 3 (or perhaps give them one month to
try to increase membership?)

> 
> 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

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.
> 
> 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"

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
> My alternate suggestion:

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
> __ disagree that committee work should be reviewed by members
> __ neutral that committee work should be reviewed by members

I think that test suites should be considered specs, not tools. Don't see
why they can't be submitted to vote.

> 
> 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
> 

_X_ agree to base vote on membership at start of evaluation period

no need to discuss.

> 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

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
> My alternate suggestion:

See my comments on #10

> 
> 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:

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.

> 
> 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
> __ 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

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"
> _X_ disagree to replace "PEOTCP" with "eligible person"
> __ neutral to replace "PEOTCP" with "eligible person"

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".

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@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