message-format-wg

message-format-wg copied to clipboard

The MFWG has recently spent a considerable amount of effort in coming up with a single starting point for our syntax that is sufficiently good to act as a base for further discussions. Many of those further discussion topics have been identified, with the intent that we might be able to discuss and resolve them somewhat independently.

The current syntax.md in the "develop" branch has a lot of good points, but I and others have also pointed out a number of problems and made friendly suggestions on the previous slide deck version and then on the pull request that were largely not accommodated before merging.

I didn't think that having a file in the "develop" branch gives it special status in the WG's process; maybe I was wrong.

This PR upends that working model quite thoroughly, and once again sets us up with two entire solutions pitted against each other. Our past experience of discussions around the data model in particular would indicate that this is not a likely source of joy and success.

While there are certainly good ideas in this PR, it does need to be split up into multiple PRs modifying spec/syntax.md so that each part may be considered on its own merits.

It might work to debate lots of feedback items in isolation, but that can also lead to going around in circles; I have experienced that myself in another standards effort last year. It's like getting lost in the trees and not seeing the forest. In the end, in that other committee we had to consider many issues together and look at what the whole system looks like with one whole set of choices vs. another whole set.

So this is what I am offering here: Roll a whole set of choices, intended to deal with multiple problems together, into one complete and coherent compromise syntax.

Note that I did not start from scratch and just invent my own thing out of whole cloth. I started from what I think are the good points of "develop" syntax.md and tried to fix what I think are the problems with it.

As I worked on this compromise version of the whole thing, I actually ended up doing some things differently from some of my own earlier feedback, especially the part about starting in "code" mode -- because as I was looking at the whole thing, it became clear that that is the better option.

I also tried to provide a rationale for every part and choice of the compromise syntax.

I left various TODOs for details where I think there is no obvious right answer, or it's really just a style preference.

Prior to post-CLDR-committee syntax discussions, my preferred syntax was the one put forth in the EM proposal. It's slightly more verbose than what was merged in #230, but I like the consistency and readability of it. As mentioned previously (in the PR and mtg), I don't feel that syntax and some other comments were reflected much in #230.

This PR uses #230 as a starting point, so it differs from what I would like, but it does avoid taking on some of the things that I have found confusing or unnecessary, etc. I do appreciate that the rationale for the significant design points are explained well, and the areas of options/bike-shedding are demarcated with comments. Some of the explanations and differences are things I/we had not considered previously but are important. So I'm okay with the differences between this PR as it is now and my original preferred syntax -- they definitely feel acceptable.

I agree with earlier comments that this PR is heading in the right direction. I think that this PR gets us to a place that would be closer to a solution than before.

I'm concerned about conflating the value of the arguments made in this PR with the format in which they're proposed. Elango's comment in particular feels like it links the two.

I think that this PR gets us to a place that would be closer to a solution than before.

Would you write the same if this PR was, in your opinion, moving us away from the solution you'd like us to end up with?

In other words. I think as a WG we're bouncing back and forth between collaborative ("Let's find a common ground") and competitive ("Here's my proposal and here are people that agree with me") approaches and micro ("Let's zero-down on question X in isolation") and macro ("Let's propose a cohesive solution to a class of questions") approaches. I think the variations are healthy, but the way they are introduced feels hectic and deteriorates trust in process we establish.

In particular, Eemeli and Stas asked everyone multiple times if they should take the task of coming up with a single proposal that could be merged into the tree as a "competitive macro" approach, and serve to start "collaborative micro" discussions, issues and PRs out of. They did this, in my understanding, because they wanted to make sure that they have support of all of us to go ahead, take all the feedback and arguments we all laid down over the last two years, break the ties and design a cohesive, opinionated solution. They promised to take all of the feedback and arguments into account, but asked for license to decide on their own which ones to follow. That means, they asked if if they decide to dismiss one of us preferences, will we accept this outcome as a starting point and file an issue, or dismiss the result of their work as "not sufficiently incorporating what I want".

I felt we, as a WG, explicitly responded to their question by giving them authority to go on.

They spent last months debating every argument and every spectrum we disagreed on, taking feedback from CLDR-TC and all stakeholders and wrote the #230.

Now, this PR does similar thing, with, I assume, slightly less background since Markus did not spend 2 years in every WG meeting debating every point till exhaustion. This is valuable, since some of those disagreements are more likely to lead to "win by persistence" than "the best solution wins", but it also asks everyone who notices Markus' PR not including something we discussed to now explain that to Markus which repeats the work we've all done over those two years of surfacing all possible arguments. I consider Stas and Eemeli to posses deeper understanding of the MF2.0 WG problem space.

My main point is that I think there are two separate themes in response to this PR:

• Merit value of this PR and this proposal. How good is it, how many "checkboxes" it checks, what tradeoffs it makes and how aligned it is with our goals.
• How it affects the work group

On the merit, I think it's a good proposal. I don't think it's better than what Stas and Eemeli put forth, but I'd be happy to see a revision of Stas and Eemeli's proposal with Markus' key themes incorporated.

On the effect on the group, I imagine it may be deteriorating trust in the system if the WG asks people to do a very daunting and challenging task based on a agreed process, and then discards it on a whim. I can see Elango's frustration that the result of Stas and Eemeli's work does not align with Elango's positions - but I believe this is what we asked them to do. Decide. And they trusted that if they take a challenging task of making decisions, we will accept them (as a starting point) even if those decisions diverge from our preference. And they asked us to go on and file issues against their solution, rather than introduce a second full proposal.

If we as a group believe that that process was not optimal, and it's better to have new proposal be the starting point, I think we should explicitly discuss it, recognize the change and maybe ask ourselves how can we avoid in the future putting people in position that we put Stas and Eemeli in.

...the way they are introduced feels hectic and deteriorates trust in process we establish.

These are the thoughts and feelings behind my previous concerns about #230 and the discussion we had in Monday's meeting. It sounds like, as a group, we still need to discuss these issues, because these particular non-technical issues are important to how well we work as a group.

... dismiss the result of their work as "not sufficiently incorporating what I want".

To be clear, I'm most interested in getting the best technical solution, and the technical discussions to get us there. (...which is why I care about the thoroughness of our technical arguments, too.) It's not about my ideas as it is having the best ideas percolate to the top. Of course, ideas need to be represented to have a fair shake at that. I don't enjoy the non-technical discussions that take us away from the technical ones, but these particular concerns are important to hash out for the health of the group.

...discards it on a whim. I can see Elango's frustration that the result of Stas and Eemeli's work does not align with Elango's positions

Please don't misrepresent. We clearly need to talk this out.

... how can we avoid in the future putting people in position that we put Stas and Eemeli in.

Keep in mind that we also had other people not included or whose our previous feedback was at risk of the same, as we discussed earlier.

...I think we should explicitly discuss...

Yes

If at all possible, you want string delimiters that are less likely to occur in strings.

On Tue, May 31, 2022 at 11:11 AM Richard Gibson @.***> wrote:

@.**** commented on this pull request.

In spec/compromise-syntax.md https://github.com/unicode-org/message-format-wg/pull/266#discussion_r885952487 :

+Options are not allowed when no function is specified.

+Value literals are important for developers to control the output.

+For example, certain strings may need to be inlined as literals so that

+they are not changed during translation.

+Numeric constants need to be formatted differently depending on the target language

+(e.g., which digits and separators, and the grouping style).

+Date constants need to be formatted according to the target language’s calendar system.

+If only a value literal is given, without specifying a function,

+then its string value is used verbatim and it is read-only for translators.

+- TODO: Value literals need to be delimited (they may contain spaces),

• and the starting delimiter needs to be distinct from the prefixes for

• argument names and functions.

• Reasonable choices include <>, (), [], ||, or a pair of `` characters.

I am not sure how to use Markdown to show a pair of grave accents in code style...

By using a longer string of enclosing backticks (cf. CommonMark Code spans https://spec.commonmark.org/0.30/#code-spans). ⬇️ Suggested change

• Reasonable choices include <>, (), [], ||, or a pair of `` characters.

• Reasonable choices include <>, (), [], ||, or ``.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/message-format-wg/pull/266#pullrequestreview-990901187, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMDUIUF72ODINR5XPVTVMZI6PANCNFSM5V4XXWOQ . You are receiving this because you commented.Message ID: @.***>

@markusicu We're cleaning up old branches and PRs in the repo. For posterity, would you mind moving the contents of your branch to the experiments folder on the experiments branch?

The syntax proposed in this PR is now available here: https://github.com/unicode-org/message-format-wg/blob/experiments/experiments/markus/compromise-syntax.md

Closing the PR, as agreed at the last meeting.