[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