Roadmap 2021 & 2022

[stasm]

At the next plenary meeting in September the chair group would like to discuss the following proposal for the roadmap of the WG's work for the next ~year.

The list is by no means exhaustive; the intent is rather to plan the next few months and adjust when needed. Each item is meant as a topic for a future plenary meeting. By knowing the schedule in advance we could try to prepare for and parallelize some of the discussions.

Many of these topics are interconnected or have dependencies in other topics. Choosing the right scope for discussions and the right order is challenging and we'll need everyone's help to do it best. Please take a look and share your thoughts before the next plenary meeting.

1. Placeholders and Function Calls — continued from the last meeting, with the goal of agreeing on a minimal data model kernel and setting the process for discussing the following topic based on it.
   • Placeholders and Function Calls #188
2. The runtime model and the selection data model: selection logic, exact number matches, formatting functions vs. selection functions.
   • How do we handle and represent selection for a multi-select message? #104
   • How do we support default case selection values in a multi-select message? #105
   • How do we support multiple selection args (selectors) in a multi-select message? #106
   • Add case selection specification #170
   • Can we treat selectors and placeholders similar somehow, or must they be distinct? #107
3. Registries, signatures of formatting functions, signature of messages.
4. Message references, glossaries, message groups, resources, name vs. path.
   • Restricting message references #149
5. Compatibility strategy (backward, forward), data model extensions.
   Compatibility strategy (backward, forward), data model extensions. #222
6. The runtime model continued: formatToParts.
   • formatToParts-like Iterator #41
7. Errors and fallback.
   • Specify error fallbacking #45
8. Syntax.
   • Defining the canonical syntax #178
9. How to localize UIs.
   • Separate out message value part responsible for formatting #186
10. CAT integration, tooling, authoring UIs.

[eemeli]

While I agree with @stasm and the chairs group about this being a decent enumeration of topics that need to be settled, I disagree with the premise that we really need another year or two discussing all of this before we can have a ready specification.

I think we're ready to move onwards from an exploratory stage, and to that effect we ought to refactor the way we're working, because right now we're not effectively producing concrete results. Put another way, our continuing conversations should be more about PRs rather than issues.

Specifically, I would like us to start working on the actual spec text, by first defining some initial bare-bones outline for the document with a decent process for accepting PRs into it. And that process should make it really easy for an empty section to receive its initial contents, so that as soon as possible we have at least one baseline that we're talking about changing on any given topic.

I fear that otherwise we'll still be here after another year, with rather little to show for it.

In order to put my money where my mouth is, I intend to file a PR adding a spec.md to this repo by the end of this week, followed by other PRs for individual sections at least once every two weeks, and to continue that until we have a specification.

My intent here is to provide a framework in which we can realise the benefits of the time and effort we've spent exploring this space, and to hopefully speed up our progress along this roadmap. I very warmly invite all other members of the WG to contribute to such an effort.

[romulocintra]

@eemeli those topics aren't strictly timeline-based and we want to parallelize as max as we can with exploratory phases for those items as possible. As a group, we have to decide how we can progress effectively(Task forces, meetings, championing topics, new workflows, etc).

Another topic that will be part of the next plenary agenda is a "Contribution Guide" where maybe your idea of :

defining some initial bare-bones outline for the document with a decent process for accepting PRs into it. And that process should make it really easy for an empty section to receive its initial contents

Would fit perfectly in developing a certain methodology, that can be scaled for plenary meetings etc...

About the spec text, we already started gathering some information to get things on track in a formal way(thanks to @srl295), but all efforts to get started on that would be warmly welcome!!

[romulocintra]

Hi @stasm @eemeli @mihnita ,

This roadmap can serve as a guide to help the "progress" of the data model, how do you think this could work?

Proposals

1. We follow a topic (example Placeholders and Function Calls Placeholders and Function Calls #188 ) we work on that issue to prepare a Design Doc then we start working on a PR?

2. We iterate through the Data Model and we prioritize on the fly then share possibilities on plenary meeting and start working on Desing Doc or PR ?

@eemeli you're creating the spec PR's following a certain order? what are the criteria?

Should we create a separate discussion for this topic or is it's ok to use this one?

[eemeli]

@eemeli you're creating the spec PR's following a certain order? what are the criteria?

I don't have a really specific order in mind. I've been writing sections and through that trying to figure out what actually depends on what else. I have drafts of the following in the works so far:

• Message Resource Data Model
• Message Resolution Algorithm
• Select Case Resolution Algorithm
• FormattableMessage
• Formatting Context

[romulocintra]

@eemeli you're creating the spec PR's following a certain order? what are the criteria?

I don't have a really specific order in mind. I've been writing sections and through that trying to figure out what actually depends on what else. I have drafts of the following in the works so far:

• Message Resource Data Model
• Message Resolution Algorithm
• Select Case Resolution Algorithm
• FormattableMessage
• Formatting Context

That's great we need definitely to find a "framework" to develop the spec and treat each individual part as an issue or something where we can work altogether! If any of you wants to have a brainstorm session to :

• Choose the workflow
• Prioritization of spec items and DM design

Here is a doodle for this and next week https://doodle.com/poll/3caghyffk66svbpy cc @stasm @zbraniecki @mihnita @eemeli ...