[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting Minutes: 20 August 2013
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]