[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Meeting Minutes: 20 August 2013
Bryan, allI have an important amendment to the minutesAs Chet explainedLOA do not count as Votersso we had quorum at 80% with 8 out of 10 eligible voters present
People on LOA were Lucía, Helena, UweVictor regained voting rights in this meeting, I have changed his status in kaviOtherwise, the minutes look good to meCheersdFDr. David Filip=======================LRC | CNGL | LT-Web | CSISUniversity of Limerick, Irelandtelephone: +353-6120-2781cellphone: +353-86-0222-158facsimile: +353-6120-2734mailto: david.filip@ul.ieOn Tue, Aug 27, 2013 at 6:04 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:
Hello,
Kavi is not playing nicely. So here are the meeting minutes (thank Asanka):
b:
- attendance: David W, Yves, Victor, Asanka, Bryan, Kevin, Ryan, Fredrik, Tom, DavidF;
- achieved quorum: 7 voters (51%);
- df seconded the meeting minutes of 16th of July 2013. no objections.
- df seconded the meeting minutes of non-quorum meeting held on 6th of August 2013. no objections.
df:
- we should probably start with com1141.
b:
- agree; there are two different opinions for this and the TC have to come to an agreement;
df:
- we have 'state' and 'approved' both on segments;
- Ryan proposed to have the approved recursively inherited, but this is not a good idea; this is back again to the solution I presented in the non-quorum meeting, except for some qualifications driven by the discussion with Yves;
- opinions: whether approved and state are dependent attributes or whether they are independent attributes;
- if they are dependent, the solution in the current spec is ok; if the TC thinks they are independent then Yves’ proposal needs to be implemented; the final decision is whether they are dependent or not.
r:
- can we have a summary of the two proposals?
y:
- df's proposal I guess is the current one in the draft spec; what I would propose to do is to disconnect the state attribute from the approved attribute. First rename the approved attribute to canMerge, as it seems to be about merging; Also remove the PRs linked to the value of states... breaking down any links in the spec between approved and state; then make canMerge have "yes" as the default attribute value;
df:
- is it 'required' or 'optional'?
y
- there is a default; does not matter;
df:
- currently it is required and undefined.
b:
- there is a good workflow suggested by Yves for his proposal; was that clear Ryan?
r:
- clear enough; seems like we are still in two positions: df sees a need for a review state and Yves does not see a need for a review state;
y:
- no. I see a complete disconnection between a flag that would allow you or not allow you to merge something and the states; because I don’t see there is any reason for having a relationship between the state and what you can merge or not.
r:
- …whether the concept of reviewed is taken care of the final state?
y:
- well... there is a reviewed state as well.
r:
- …whether concept of approved is taken care by either reviewed or final in the states;
y:
- approved attribute is misnamed; it is not about approving anything; it is about allowing to merge or not;
r:
- agree. do you feel like there is a need for some kind of a flag or state to be able to approve or not-approve translations?
y:
- I think there is already a state; there is a flag that says if it is approved or not; that's the state;
r:
- that's reviewed or final;
y:
- exactly; there are sub-states in between ;
df:
- the fix I did was based as much as possible on what was in the spec before; it was largely driven by Ryan's observation; … there would be some strange combinations like approved and no; I tied these together by a better constraint staying initial must not be used, if and only if(IFF) the approved is yes and final must not be used IFF the approved is no; this would make a hierarchical method of indicating the readiness;... if you wanted you could expand by using the state and sub-states; basically, approved, state, sub-state specify different granularity; in this scenario, tie is needed to avoid conflicting combinations; ..it is required; now defined as default; I think it is not offensive; if people want to be able to merge right away ,they can set the flag to yes, otherwise set it to no; Yves thought approved is completely a different entity; it is just a readiness indicator; he also does not want to be forced to change the flag; this is also catered in this scenario when the flag is required and undefined; it comes back to the decision whether they are dependent or not; whether the flag is completely different or not; I think that the readiness indicator is narrowing down the semantics;
r:
- I actually can see a need for both; need for determining whether a translation has been reviewed and approved; or reviewed and not approved; I see that completely separate from being able to merge or not;
df:
- we all agree that we don’t' want to implement too much workflow prescription logic into the spec; if we have the approved flag, approved flag can be used as a readiness indicator; .. I would not multiply the flags; I prefer the current solution; if the TC wants to disconnect them, let's do it;
r:
- I don’t see readiness and approved … review as the same thing; our use case is similar to Yves’; merge can happen at any time independent of whether something has been translated and approved or not;
f:
- we do the same thing;
r:
- approved is a completely separate workflow concept;
- if we say that reviewed and final state values incorporate whether a translation has been approved or not, then I don’t even see a need for the approved or canMerge attributes at all;
f:
-I'd agree; I don't completely understand why all users could just derive from state if they wanted to merge that portion of the translation or not;
df:
- because state is optional and it has four states and it's not simple;
y:
- that does not present any merging based on the ...; you can decide what to do;
df:
- the default value is initial; does not seem very intuitive to merge back with the initial to me;
f:
- if a tool need on ... approved flag to be compatible I think it means that we would set the approved or canMerge to yes before we translate anything at all; in that case we would do a source-roundtrip test;
dF:
- what are you merging after you just generated the XLIFF?
f:
- we are running an automated copy of .. source to target;
df:
- it's ok to do; why not set a flag when doing that; when it goes away really for the translation you can set it again to No?
y:
- why make things complicated?
df:
- this was a month now; I don't know what to think;
y:
- approved flag has always been a problem; we got comments from outside people; it was there for a while;
df:
- when I started the discussion, no one reacted until I proposed the solution; let's agree on something;
y:
- it seems to me ... consensus on that state can provide information about the state of the translation and ... merge based on the state of the translation .. I am wondering why canMerge or approved flag is needed at all; the only reason was because you said that some process want to set ... is it something useful? I am just wondering whether it's useful to have that flag;
r:
- I don’t think it is useful;
df:
- everyone thinks (except me) state is enough;
f:
- state together with sub-state;
df:
- sub-state is not public so it is not interoperable; it's only useful if you are in a private loop;
r:
- if we think values for state does not cover general workflows well enough for most consumers, then we should consider changing values in state; I think most people agreed that's enough;
df:
- they are enough in general; values of state provide some interoperability for sub-state;
r:
- that's correct; we don't need any other values;
df:
- we currently have 1 PR and 1 constraint using the approved attribute;
r:
- they are too prescriptive;
df:
- if you don't have them, then LSPs have no way to say don't merge
y:
- it has the state values;
df:
- state values are about the state of the translation
y:
- and that's not enough for the decision of merging or not?
r:
- what are the criteria ... translation? this is a translation interchange format..
df:
- initial, translated, reviewed, final ... for tacking for what’s happening; [describes scenarios]; you can indicate by using the flags (canMerge or approved); why we artificially progress the state of the translation when we know it is not final; we just decided to merge now for whatever reason
y:
- that's a decision the merger takes;
df:
- ..is there a way for service provider to tell the merger not to merge?
y:
- if it does not set the state to the minimum level to which the other provider is merging .. that’s the way to do it;
df:
- it is overloading, you'd set to review or final just to give a signal;
f:
- if it's ready for merging, I would say its final in my opinion;
df:
- why so? it can be raw crowd sourced translation; it does not need to be final; it could be just published now;
f:
- then I would not want to merge it;
df:
- they would; they want some content;
y:
- in the crowdsourcing kind of merger, they are going to merge whatever they get;
df:
- there must be something in the target even if it is the copied source; there should be something in the target if you want to merge;
y:
- if … shouldn't merged what should you do?
df:
- if you don't merge you can call your LSP and ask them why it is not set for merge? ...
y:
- that would be probably fine ..;
df:
- it is not interoperable in the core;
y:
- adding something that says can merge, and not having the logic of the decision of why it has been set to merge is not interoperable either;
df:
- no one can misunderstand the yes or no;
y:
- why is it yes or no;
df:
- it is simple;
y:
- why it is set to yes or no; which criteria that have been chosen yes or no?
df:
- it is linked to the state to a certain extent;
y:
- I think it’s a weird case scenario; in the worst case scenario we could have one additional state like mergeable
;
df:
- it would confuse two different things in one value set;
y:
- there is a need for a flag that says you can merge or you cannot merge; and there is not enough discussion and proof of concept; we cannot make a decision on that at this point; it could be a module or something we add to .1; we don't need to stop everything to cater for one specific use case;
df:
- there could be more use cases [describes scenario];
f:
- my problem is really with PR requirements on the flag; if somebody hasn't set merge="yes" on the segment we are not going to skip merging if there is something to merge;
df:
- you can do it; one who provided with the file set to no for a good reason; they told you not to merge;
f:
- then they should not have submitted to the file on the first place;
df:
- it could be on a repository that could be accessible for the both;
b:
- do we have enough information here to go with either Yves’ scenario, DavidF’s scenario, or shall we postpone the resolution of this?
df:
- Ryan suggested other combinatorics; what would be the options for a ballot? Would you be happy with only two options or third or fourth options?
r:
- ... PR requirements around the approved state;
df:
- you don't like this?
r:
- I don't like prescriptiveness around the approved state; if there is only two options I would probably vote against the approved state due to prescriptiveness of it;
f:
- I agree; can merge with default "yes" ; if someone has set to "no" that means they have valid reasons to do so;
y:
- no specific PRs or any specific requirements; I’d be ok with that;
df:
- what would be usefulness if there was no PRs tied to it?
y:
- you could have "should" or so;
f:
- or say that an agent "may" refuse to merge segments for this state.;
df:
- are you saying "merger may refuse to merge if it set to no?"; I think the constraint on unit is not too restrictive; it says for a unit to be ready for merging it is required to have all the segments.. it is defining a state; it is not a PR..; you can do it but you have been told it is not being ready for merging;
y:
- it is a really weird requirement;
df:
- merger was told the unit is not ready for merging; it does not say you must not attend for merging; it only says on the segment; not on unit; we can move it from the segment if you like; but I would still define the state of readiness;
f:
- I think it should sit on unit, not on segment;
df:
- currently we have a PR on segment and a constraint on the unit; the constraint on the unit explains that the unit is not ready for merging if not all of its segments are not ready for merging..
r:
- I think the only way we are going to move forwards is to have a ballot
df:
- I think too; we need to know the exact options;
r:
two options: what is currently in the specification as you have worded..; Yves wants to have the canMerge attribute; or to remove approved attribute;
df:
- I can after this meeting write these three options for a simple majority ballot;
b:
- are you saying it is an electronic ballot?
df:
- I think the third option need to be elaborated; if we can do it now; let's do it now;
r:
- I think it is clear enough so we can do it now;
df:
- not against, I second it;
y:
- we need to state the three different options then;
df:
option 1: approved related to state through PRs; uses approved to define merging readiness
option 2: rename approved to canMerge; make it optional with default yes; remove relationship with state; add weak PR for Mergers
option 3: drop the flag approved/canMerge. no PRs;
df:
- roll call:
- t:abstain,f:2,r:3,y:3,b:2,a:abstain,k:3,df:1
df:
- option 3 got three votes;
df:
- summery approval of comments:
017 - sm/em justification
019 - inline codes solution justification
023 - clarifications in mtc module
026/032/048/054 - changes and examples in mda module
045 - handling of xmlns attributes
051 - justification and clarification of [ignorable]
052 - clarification of mtc origin attribute
059 - corrections of schema
leaves us with 031, 058, 003 to be still pursued offline;
f:
- very quick update on the two items that I have still: I have not been able to make good examples for slr module due to lack of time; for the other PR about renaming equivalent .... to Storage info I am actually against that because I believe that .. storage is more accurate name for the attribute; because it tells how many bytes of storage inline code would have in the native code when back coded
df:
- one of your slr actions would remain pending; one could be subsumed under the summery approval; which?
f: 31
df:
- I will include 31 - rejected rename; ...ballot for summery approval of solutions.
b:
- I second that. any objections?
df:
- ballot passes unanimously;
- dropping the flag is so simple;
- Tom and Fredrick will need to work on the examples by the end of August
b:
- if we have no controversy in the examples, this is quite doable; I feel that with this advancement I can take a second look at the calendar and predict when we are going to complete.
df:
- please commit and socialise. I will do the final printout out just in time for the meeting;
- f,t does it sound doable by the end of August;
f,t: yes;
b:
- no new business. meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]