Subject: Re: [xliff] A good way to move items to approved/rejected?
[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.
Feature approval procedure
[as approved by TC on Nov 1, 2011]
Features not listed
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.
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..RgdsdFDr. David Filip
On Fri, Feb 17, 2012 at 21:25, Schnabel, Bryan S <email@example.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.
Content Management Architect