Update notes-2020-04-20.md

Author: romulocintra

meetings/2020/notes-2020-04-20.md

@@ -1 +1,223 @@
+TCQ :https://tcq.app/meeting/dcvm
+Github: Meeting Agenda : 2020-04-24: #74
 
+Attendees:
+Please fill in a 3-letter acronym if this is your first meeting:
+- Suggestion 1: First letter of given name, First letter of surname, Last letter of surname
+- Suggestion 2: First initial, middle initial, last initial
+- Suggestion 3: Custom
+
+#### April 20 Attendees:
+- Romulo Cintra - CaixaBank (RCA)
+- Elango Cheran - Google (ECH)
+- Mihai Nita (MIH)
+- Nicolas Bouvrette - Expedia (NIC)
+- Staś Małolepszy - Mozilla (SMY)
+- David Filip - ADAPT Centre - Trinity College Dublin (DAF)
+- Addison Phillips - Amazon.com - (APP)
+- Eemeli Aro - OpenJSF (EAO)
+- George Rhoten - Apple (GWR)
+- Nick Felker - Google (NFR)
+- Richard Gibson - OpenJSF (RGN)
+- Zibi Braniecki - Mozilla (ZBI)
+- Mike McKenna (MGM)
+- Shane F. Carr - Google (SFC)
+
+## MessageFormat Working Group Contacts: 
+
+- [Mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+
+
+
+## Next Meeting
+
+May 18, 10am PDT (6pm GMT)
+
+## Agenda
+- [ Agenda on Github ](https://github.com/unicode-org/message-format-wg/issues/74)
+
+Easy way to volunteer to participate in Chair Group :  [Link](https://github.com/unicode-org/message-format-wg/pull/70)
+
+## Updates from Chair Group Meetings
+
+RCA : We changed the way we run the meetings and now we try to rate between members of the chair group to “run ” the meetings. This week DAF will be incharge of TCQ and overall meeting discussions.
+ 
+### Goals Non-Goals - (#77 #59)
+ 
+SMY: Created PR of draft of goals & non-goals (https://github.com/unicode-org/message-format-wg/pull/77).
+ 
+We don't have to be precise since we will iterate on this, but want to have something more concrete and not nebulous.
+
+Once we agree on the goals, I think the next step is to have an agreement on how we can get there, dedicate more time and evaluate the goals and agree … 
+
+My goal for today is to try to have a list of goals that represents our common understanding. 
+
+Goals are splitted in 4 major points. 
+Data model for defining translations
+
+APP: When you talk about a data model this includes a file format ? or is API type definition that we wrap around and work from that.
+
+MIH  : In my point of view the Data model is separated from the syntax and api, so if people want to convert their old syntax to a new one, they can because the data model guarantees compatibility.  Data model is syntax independent.  Data model is a higher level than AST, AST is just about parsing tokens like open parentheses, curly braces, etc.
+More than that, you should be able to write a conversion from old-format => data-model => new-format. Or if we design some APIs that take the “data-model” as argument (maps, and sets, and maps of sets, etc.) one can consume directly old and new syntax (new-syntax => data-model => API and old-syntax => data-model => API). So an old-format => data-model parser is the only thing needed.
+The trap: the data-model should be able to represent the old-format. In some cases the conversion might not be trivial (for example nested switches converted to a single switch on tuples).
+
+SMY: For  me Data Model is similar from AST interpretation where (Please Fill)
+
+EAO: Could we refer to the canonical data model for resources, much as we do for syntax?
+
+Where are the boundaries between a translation management system and MF ?
+APP: I think is clear the difference between message format and a translation management system (TMS).  TMS is for , (Please fill ) 
+
+ECH: Okay, sounds good.  
+
+NIC: I think backward compatibility is an important point.
+
+APP: Backwards not necessary, but we should at least address.
+
+SMY: You should have a good story for backwards compatibility, otherwise people won't use it.
+
+DAF: Support for the idea of self-contained messages / translation units.  It makes it more complex to support the linking of one message to another.
+
+SMY: Let's leave this question open.  From Fluent experience, it helped to have variants of one message's inflections used in other messages.  George (GWR)'s presentation about Siri's handling is similar to what we use in Fluent.
+
+APP: Sounds good to me.
+
+ZB (on chat): Intra-message references should be considered. @Mihai pointed out that it can be done using MessageFormat like API by passing a list of messages that can be references (in Fluent we call it a FluentBundle) to `format`.
+
+MIH: Do you want the ability to support some kind of tagging , example how can i “bold/italic” this how data model can handle this,in XLIFF you have open/close placeholder...
+
+a tag is another kind of placeholder ? 
+
+SMY: Is a good question andsh
+
+MIH: Yes, let's add this to the goals / non-goals doc, make it possible to express features (like markup) as placeholders.
+
+APP: We can add this as a goal, but we shouldn't go too much into detail in this document since it is about high-level descriptions of goals.
+
+EAO: Messages have a simple structure.  We do not and cannot have a fully backwards compatibility because it will at least break some aspects of the syntax (ex: in the MessageFormat.js library).
+
+SMY: To summarize briefly, there are still open questions on data model for collections of messages, relationship of data model to API, and protecting structural features.  And maybe backwards compatibility is a design principle.
+
+Next section of the goals document is having a canonical syntax for the data model.  Parsing, validation.
+
+APP: The first part of what you said sounds like what we would use ICU MessageFormat.  But the rest of what you said, sounds like more than that.
+
+DAF: I agree with canonical syntax.
+
+MIH: How do you react to parsing errors in different programming languages at runtime?
+
+SMY: I agree, build-time errors may be different than runtime errors?
+
+RCA: Should the errors we check for be a part of the language (implementation) rather than a part of the MF specification?
+
+APP: The MF spec can define what is correct, and it is up to implementations in the different languages to handle errors.
+
+MIH: We should have a standard mapping to XLIFF.
+
+APP: +1 to XLIFF
+
+RCA: This is an open PR, so please add any further comments there.  https://github.com/unicode-org/message-format-wg/pull/77
+
+### Establish the decision making process (#76 #58)
+
+https://github.com/unicode-org/message-format-wg/pull/76
+ 
+DAF: It is time to decide some lightweight decision making process.  There are already some comments on the PR.
+ 
+Preamble is nothing normative, just describes where we are.  Describes consensus is lack of opposition, and voting is method of last resort.  Chair group doesn't have decision making authority, the decision making authority is the monthly meeting. Process is intentionally lightweight, which is common in standards groups that are full of professionals.
+ 
+There were suggestions to define disciplinary actions against bad behavior.  But so far, no such negative behavior, so no need to define just yet. Intended to be short and sweet. Anything can be resolved by consensus.
+ 
+APP: I like the intention and intentionality behind this.  It captures the previous discussion.  Only things I would like to mention are that Unicode already has descriptions of processes for recourse in difficult situations.
+ 
+You don’t need any of the formal stuff until you do, and then you really do need it.  But if you don't already them pre-defined, then you open yourself up for being perceived as discrimination.
+ 
+DAF: I followed the link but it’s really defined for companies. It doesn’t have information about how to deal with members (?)
+ 
+APP: It’s uncommon in CLDR, ICU to vote.  You always have that in your back pocket, just in case.  I would never want to use it, but it is good to have it defined.
+ 
+GWR (on chat): I agree with Addison about being clear up front and not in the middle of a conflict
+ 
+DAF: Romulo says maybe we should separate decision making from disciplinary parts.  That's point 7 of the Rules section of decision-process.md
+ 
+RCA: I think we can establish it.
+ 
+DAF: I really tried to make it modular.  The blacklist is defined, but we can have a separate document to describe how it is created and added to.
+ 
+Apart from the case of trolling or negative behavior, does the rest of it seem good to you?
+ 
+NIB: Just a minor comment; otherwise everything looks okay from my standpoint.
+ 
+RCA: What are the next steps?  Preamble, etc. look good.  As a group, what should we do to move this forward?
+ 
+DAF: I haven't heard anything that sounds like a "no-go" for this.
+ 
+DAF: Perhaps we need to create a document for the blacklist procedures.
+ 
+NIC: I agree.
+ 
+RCA: We should add that document for blacklist procedures.
+ 
+EAO (on chat): I like having an explicit definition of "consensus". Also helps that it's a good definition.
+ 
+SMY: I like this doc.  I see "group member" being used a lot.  I don't know what the process is of becoming a member.  What if someone joins and blocks our progress in a sustained way?
+ 
+DAF: We need membership guidelines.  It should discuss the process of getting temporarily banned, etc.
+ 
+APP: We don't want to create a barrier to valid objections.  We should look at ICU, CLDR, etc., where you can appeal to Unicode if anything goes wrong.
+ 
+SFC: Being part of an established organization gives us access to their practices: https://www.unicode.org/policies/policies.html
+ 
+As far as membership, when talking with Markus (Scherer) and Mark Davis, Unicode has companies and members.  Non-company members are considered to be subject matter experts.  If it gets to the point of conflict, we can bubble up concerns to the higher Unicode bodies.
+ 
+In summary, I'm in favor of the decision making process, and we can link to Unicode policies for resolving issues, but we shouldn't link those two.
+ 
+MIH: I think it's important to contribute without becoming a member, in the spirit of contributing on Github.  
+ 
+APP (on chat): agree that we want community participation, but we need to address IP
+ 
+MIH: Being a part of ECMA-402 (JS Intl), when I moved from Adobe to Netflix, the change in company meant I was no longer a part of the committee.
+ 
+APP: We want to be clear on IP and stipulate that contributions are one-way.  I distinguish between capital-M Member and lowercase-m subject expert member.
+ 
+ECH: APP was pointing out that if we need, we can point to Unicode procedures. MFWG is under Unicode. SFC's previous comments covered my question well.
+ 
+DAF: My experience from OASIS is that any member can do wiki, contribute to the spec, whatever, but non-members can only do issues.  Their PRs wouldn't be accepted.  And issues are covered by the feedback license.
+ 
+SFC: Reiterate previous comments about definition of non-members as invited experts, and there is a procedure that helps cover concerns IP from them, which we can use if we need it.
+https://unicode.org/consortium/tc-procedures.html
+ 
+RCA: My question was about who can be a member?
+ 
+SMY: I agree, this is an important topic, maybe we should have a separate document.  Is this the same topic, or a different topic?
+ 
+DAF: I think membership topic is a different one from decision making topic.  I can delete preamble from decision making doc and we can adopt it as the decision making doc.  Does that sound viable?
+ 
+DAF: I will delete the preamble paragraph and merge the doc as our decision-making process.  Is that okay?
+ 
+(silence)
+ 
+ 
+ 
+### Review Terminology (#78 #19 #30)
+ 
+https://github.com/unicode-org/message-format-wg/issues/78
+ 
+ 
+APP: How do you want to get feedback?
+ 
+ECH: Comments in the issue/PR.
+ 
+SMY: Commit the file as .md and have people file PRs against it?
+ 
+SFC: What are people’s opinions about wiki vs. .md files, more generally, not just for this specific instance?  I think it's easier and better supported to have markdown files in the repo.  There are no reviews required and no logs when editing a wiki page.
+ 
+RCA: I agree.
+ 
+APP: Using markdown files instead of the wiki avoids having wiki page editing wars.
+ 
+MIH: Also, we should document terms as we go. Sometimes it’s easier for someone not directly involved in a discussion to notice that the participants mean different things. Clarify and document then and there.
+ 
+ 
+### Why MessageFormat needs a successor (#49)
+This topic was moved for the next meeting