Bryan, all,
[below, bottom of my message, I pasted our full current feature approval procedure..]
Owners who are proposing to move their features to approved section should pay attention to the procedure, especially this bit:
"Owners must demonstrate to the TC not only the technical appropriateness of the feature but also explain what resources and timeframe is needed for elaboration and if those resources are available."
IMHO Chair can decide not to create the ballot if the owner's proposal does not formally address the above. In case this is not in place, Bryan should ask the owner for explanation along with asking TC for contrary opinions.
Rgds
dF
Feature approval procedure
[as approved by TC on Nov 1,
2011]
Features not listed
here:
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking
will not be considered at all for inclusion in any XLIFF 2.x spec.
The feature tracking
wiki comprises three sections. 1. Approved, 2. Under Consideration, 3.
Discarded.
Section 2. Features
under consideration is the default section:http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#Featuresunderconsideration.28notyetevaluatedbyTC.29
Any TC member can record
a feature in Section 2., preferably following an e-mail or meeting
discussion.
Features can be moved
into section 1. or 3. only following a formal TC ballot.
Features can be proposed
for ballot in a regular TC meeting by the listed
Owner (Champion) or the TC Chair.
Owners must demonstrate
to the TC not only the technical appropriateness of the feature but also
explain what resources and timeframe is needed for elaboration and if those
resources are available.
TC Chair can suggest
moving a feature from Section 1. to section 2. Or even 3. if it does not show
reasonable progress close to XLIFF 2.x spec release deadline.
Any TC member
can suggest reconsideration of an item in section 3, and no additional
conditions apply.
Approval of core features
Only features in the
Section 1. Approved Features can be proposed for XLIFF 2.x Core.
This is recorded as
“Core/Module: [Not determined/Core/Module]”
Otherwise the procedure is the same as feature approval.
A feature moving away
from Section 1. gets its core status set to “Module”
“Not determined” is
being used as initial value only, all subsequent changes are between “Core” and
“Module” only.
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
On Sun, Feb 19, 2012 at 02:05, Dr. David Filip
<David.Filip@ul.ie> wrote:
Bryan, I think it is OK if you just use your judgement and simply set up approval ballots shortly after the proposal of an owner is seconded. You may formally ask the TC if anyone wants to raise objections. But, unless the proposal or secondment is withdrawn as result of someone else's valid point being raised, I believe you even cannot decide not to have the ballot..
It is the owner's responsibility and risk if he or she proposes the ballot on something that did not have proper discussion.
Remember, in case even approved features do not make progress, we can park them again..
Rgds
dF
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Fri, Feb 17, 2012 at 21:25, Schnabel, Bryan S
<bryan.s.schnabel@tektronix.com> wrote:
I kind of like the precedence Yves (and I, imitating him with my styling proposal) is establishing.
By moving for approval of proposed XLIFF 2.0 features on the TC list, and having somebody second, we can hope for good dialog between meetings. We could be that much further ahead by the time the meeting takes place. Maybe we could even hold an official online ballot (in cases where the thread does not indicate a need for meeting discussion).
What if we set up a set of guidelines that went something like this:
1) if a formal request for approval is made on the TC list and seconded X days before the next meeting, and 2) if after Y days it does not receive contrary commentary, 3) the chair shall establish an official online ballot that will last for Z days to pass, reject, or abstain the proposed feature.
The key would be to make sure we don't cut off meaningful discussion. I think the tricky thing might be to make an objective judgment of whether or not 2) is demonstrated.
I'm happy to hear other opinions.
- Bryan
Bryan Schnabel
Content Management Architect
Phone: 503.627.5282
www.tektronix.com
