Re: [xliff] Re: Ballot on Feature Approval Procedure, XLIFF 2.0 program Charter Draft v0.4 committed to SVN

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Yves, the good thing is that we agree on moving on. The TC will choose from 4 options and it is well so..

This discussion might be still good to have as it reveals some important differences in opinions that are perhaps good to elaborate on.

I think that the procedure is important because it helps us put constraints onto the project. Without the constraints, no project can be completed. A standards body obviously is not a project, but its specifications are project deliverables. It might be OK for a standards body to move very slow for a couple of years, as it sounds what is happening to the previous spec out there. I agree with you that initiatives like IN! are symptoms of the slow institutional development. Clearly, now come the time when the TC must either deliver or fail, i.e. the TC must set constraints to the project.

This procedure is only a small part of the XLIFF 2.0 Charter effort and the goal of the Charter effort is to put more and more stringent constraints onto the project, to ensure that it can succeed at all. Without the constraints you would not know if it succeeded, so it would actually fail.

You are trying to push a non-procedure because you do not want to be hindered in technical work but this is exactly the way to scope creep and hence the failure to deliver in historically short timeframe.

Prison is one of our defenses against scope creep and therefore extremely important and I pledge for honoring the difference between "prison" and "under consideration".

Re your point that most of the considered features were there before the 1st Symposium, I say it is OK, many smart people were adding the features for a long time and the customer call is not for a long tail of features but for a small truly interoperable core. We must keep the spec small in order to be able to provide unambiguous processing requirements for all the included features. I hope that this will be greatly assisted by Andrew Pimlott who should join the TC very soon.

In my view it is not intrinsically good to bring every thinkable feature into the spec, I feel that the spec can be only as good and elaborate as is our availability of appropriate resources (i.e. mainly committee members). Good feature ideas will be inevitably dropped if they cannot be properly elaborated with the momentum we have succeeded to build by now. And I think it is not a small momentum for a localisation standard, still we do not have and will not have either unlimited resources or unlimited time to develop an ideal mother of all specs.

Features shelved in prison are not inevitably dead, after their prison term they might still play an important role in a 2.x module, who knows, but discarded features must not prevent us from delivering a committee spec well within Q1 2012, otherwise we have failed. P&L SC will do everything to push the spec through OASIS procedures well within Q2 2012 and then we can celebrate :-)

After the procedure has been sorted out I plan to put forward a ballot with this time constraint..

Best regards

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

mobile: +353-86-049-34-68

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Tue, Oct 4, 2011 at 22:00, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David,

> I can add your proposal as the 4th option
> if you insist.

Yes, I would appreciate, thanks.

> Both 3. and 4. I would consider insufficient,
> as they would undermine the very reason for
> having the "discarded" or prison section; as
> you rightly pointed out in the TC discussion.

Well... that is my underlying reason :)

I see the no fundamental difference between "discarded" and "under consideration". They're just convenient labels to sort things out a bit more. One should be able to take a feature from either sections to "approved" with the ease.

The bottom line is that all that is relatively un-important (to me). Getting those features into the specification is where I would rather spend time, not in the "prison" section :)

Don't take me wrong: I have nothing against organizing things, having priorities, processes, procedures, etc.
But we are now after the second XLIFF symposium, and a) we still have no 2.0 draft started, b) most of the features listed in our tracking pages have been there long before the first symposium.
We shouldn't be surprised there are efforts like IN! that try to move forward: we are not moving fast enough.

And please, understand that I'm really not criticizing anyone in particular: I'm "part of the problem" like anyone in the TC, as Bryan remind us often :)

We probably just need to spend more time in XLIFF work between calls to make faster progress.

> Anyway, I trust that all pros and cons were
> sufficiently discussed and rather than lingering
> and trying to arrive at a consensus, we should
> decide via a ballot and move on.

+1 to that :)


Cheers,

-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org