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

I see everyone is eager to go on without procedures, which is a very bad sign for me. I have no problem with continuing the work on SC..

BUT

In the TC meeting, there was a consensus including Rodolfo, not to move procedure out of TC as it directly influences technical work.

I am all for having most of the discussion on mailing list and ballots on kavi in between meetings, rather than direct discussion in TC, so far it did not take much online time in the TC either.. 

But moving charter discussion in and out between TC and SC seems impractical. I do not see how we generate buy in for the procedures, goals, deadlines, etc. of the TC if the discussion only happens in SC.

Besides, the SC already has an enormous bulk of stuff on its table: liaisons (we just started to tackle), to start collecting, managing, and displaying state of the art data, customer voice report(s), etc.

In my view a working charter is and must be a living document and should be approved piecemeal, without of course taking too much of the online time..

As I said I am happy to have the discussion on mailing list rather than live on the TC, just that until this heated discussion broke off there was very little mailing discussion around these topics.

I welcome the heated discussion, as it is much better to have a heated discussion (which shows that people care) rather than no discussion at all.

I agree with Yves that Committee Spec by Q12012 is funny unless we quickly put constraints on the work and stick to them.

I remind you the momentum is significant.

IBM rejoined, LIOX rejoined, GALA joined (i.e. Arle out and in), Multicorpora joined. Welocalize, Kilgray, and TAUS to join imminently. [sorry if I forgot anyone in my haste] Oracle is on its way to rejoin (working on it with Paul Leahy)

I see the procedures as a must to funnel the momentum towards sound results. Just technical work without procedures and project management will not lead to desirable results.

I do not see how people are to prevent scope creep without procedures. Does *anyone* on the TC including the "heavy hitters" have a patent on excluding/including features without a procedure? I do not believe so..

Therefore I have an alternative proposal to Bryan, Yves, Rodolfo, Helena.

1. Move the "procedure" ballot to kavi immediately, i.e. not waiting for the next TC

2. Minimize online "Charter" time and prefer kavi over life balots going on, but not to move the discussion from the TC list to the SC list.

I will provide wording for all 4 options and the procedure as a whole immediately, if this move is seconded.

Pending work on Charter IMHO

1. Aprove "procedure"

2. Use cases, IMHO use cases are enormously important and the only possible base for real processing requirements. [we heard the customer][this is big bulk of work that I am taking myself,  hoping to be joined by Andrew soon][Again I will publish the use cases on SVN and have offline discussion on them]

3. Non essential and "marketing" details, OK to move to SC

Adding use cases will take some time but after that the Charter will stabilize and will be ready for ballot as a whole.

Thanks everyone for reading this carefully

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 Thu, Oct 6, 2011 at 02:36, Yves Savourel <ysavourel@enlaso.com> wrote:

Not fast enough: I third.

-yves

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Helena S Chapman
Sent: Wednesday, October 05, 2011 6:51 PM
To: Rodolfo M. Raya
Cc: 'Dr. David Filip'; xliff@lists.oasis-open.org

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

 

I second.

Best regards,

Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
Waltham, Massachusetts




From:        "Rodolfo M. Raya" <rmraya@maxprograms.com>
To:        <xliff@lists.oasis-open.org>, "'Dr. David Filip'" <David.Filip@ul.ie>
Date:        10/05/2011 04:21 PM
Subject:        RE: [xliff] Re: Ballot on Feature Approval Procedure, XLIFF 2.0 program Charter Draft v0.4 committed to SVN
Sent by:        <xliff@lists.oasis-open.org>

---

Hi Bryan,
 
I formally propose that the charter discussion happens only at SC level and then, when the charter is ready, a ballot for approving it is created on Kavi.
 
Would someone please second this proposal?
 
Best regards,
Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com
 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Wednesday, October 05, 2011 4:49 PM
To: Yves Savourel; xliff@lists.oasis-open.org; Dr. David Filip
Subject: RE: [xliff] Re: Ballot on Feature Approval Procedure, XLIFF 2.0 program Charter Draft v0.4 committed to SVN
 
David and Yves,
 
Thank you for your wisdom and energy on this. I've been a lurker on this thread. I very much value the education I get from observing a debate between two brilliant thinkers.
 
My role as chair I think, does not enable/anoint me to set policy/procedures anymore than any other voting member of the TC. But I think my role does empower me to influence the pace at which our TC progresses.
 
Toward that end, so far, I've done some things. (1) Listen-to/hear the voices of those with a bent for technical progress toward the XLIFF 2.0 specification and schema. I put myself in that camp. I've tried to segregate the agendas to clear the way for technical work, and I've tried to prioritize the technical work above the other XLIFF business. And (2) I've endorsed, encouraged, and joined the P & L SC. I am in this camp as well. My thinking is that in an absence of documented, agreed upon, and enforced policy and procedures, technical progress is burdened with waste, mis-starts, rework, disorganization, etc. (drawing from my own experience).
 
In my mind, David and his excellent SC members have already cleared the TC of much of the current business, paving the way for less burdened meetings from a technical perspective (granted it took a while, and a fair share of the TC's energy to sort out the details).
 
I think the one remaining item is the working charter. The question is, do we need to work on the details of the charter in the TC? Or can we move the charter work to the SC, have the debate there, and only bring the subject to the TC once a vetted proposal is ready for ballot? I don't know the answer to this. But I would surely cast my vote if somebody proposed this. And if the working charter is already vetted and ready for ballot, I will be more than happy to get a ballot going, between meetings.
 
I really think that once the charter is in place, we will have a luxurious portion of each TC meeting to devote to nothing but technical work. I look forward to this.
 
But let me please throw out one last plea to the TC. When this day comes (and I think it will come soon),  let us *please* be ready to make good use of it. That is, we've all expressed an appetite to get technical - let's be prepared to do so. Let's do our share of off-line work toward the technical features/issues that matter to use, and let's hit the ground running at the meetings. I will follow Yves' excellent example on this, and try myself to be as active as he is between meetings.
 
I will move us quickly to the technical work portion of the agenda. I just ask that once we get there, let's have disciplined technical work ready to act on.
 
Thanks,
 
Bryan
 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, October 05, 2011 4:43 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Re: Ballot on Feature Approval Procedure, XLIFF 2.0 program Charter Draft v0.4 committed to SVN
 
Dear David,
 
I’m afraid I tend to disagree with some of the things you wrote.
 
I think, ultimately, people, not rules, stop “scope creep”.
 
I think end-users, not self-imposed constraints, tell you if you failed or succeeded.
 
I think using the work done before the 1^st symposium is just fine, I’m just sad not much has been added since.
 
I think delivering a spec within Q1-12, if we continue to work the way we have, is very funny.
 
I think I should make some efforts to accommodate people who see rules and procedures as an important part of the work, as long as they make similar efforts in the other direction.
 
I think it’s fine for us to disagree on the procedural aspects, as long as we end up agreeing on the technical ones.
 
And finally I think I should stop arguing about non-technical topics, open the wiki pages of the features assigned to me and start outlining requirements and solutions; so Rodolfo has some rough material for the draft when we get at that point. Because we will get there, ...I think :)
 
Cheers,
-yves
 
 
 
 
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Tuesday, October 04, 2011 5:09 PM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Re: Ballot on Feature Approval Procedure, XLIFF 2.0 program Charter Draft v0.4 committed to SVN
 
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