Re: straw poll - 20 items

[Robin Cover <robin@isogen.com>]

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


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

1.1 "Identify what other groups/committees..."

> _X_ agree to add these additional requirements

1.2 "specify what coordination/liaison"

> _X_ disagree to add these additional requirements

1.3 "Specify whether conformance testing"

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

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?


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

> 
> 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
> _X_ 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.
> 
> _X_ agree to allow invited experts
> __ disagree to allow invited experts
> __ neutral to allow invited experts



> My suggestion for particpation requirements:

I would favor at least "invitation by the chair" which allows them to be
present at meetings and to contribute, perhaps without a vote.

> 
> 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.
> 
> _X_ 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"
> _X_ neutral that OASIS should call its work "standards"

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.


> 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
> _X_ disagree that we should allow this
> My alternate suggestion:

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?


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

People change their minds.

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

Need discussion of the exact problem here...


> 
> 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
> 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
> _X_ neutral that process should define subcomittees

What rules/guidelines/instructions need to be defined?  I might agree
if there's a demonstrated 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

What "more" would need to be said?

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

If not "eligible person", something similar...