Notes: s/LBR/LEO

Ref tc39/notes#55

meetings/notes-2019-09-26.md

@@ -4,7 +4,7 @@ September 26 Attendees:
 - Daniel Ehrenberg - Igalia (DE)
 - Frank Tang - Google i18n, V8 (FYT)
 - Jahziel Villasana - Student working with Igalia (JVA)
-- Leo Balter - Bocoup (LBR)
+- Leo Balter - Bocoup (LEO)
 - Long Ho - Dropbox, Format.js, react intl (LHO)
 - Steven Loomis - IBM (SRL)
 
@@ -83,15 +83,15 @@ Additional comments from FYT:
 
 - [PR](https://github.com/tc39/ecma402/pull/349)
 - Previously: Consensus based on #351.
-- Last month: LBR: If whoever is writing the tests finds it's not possible, let me know so I can proceed with merging the PR.
+- Last month: LEO: If whoever is writing the tests finds it's not possible, let me know so I can proceed with merging the PR.
 
 SFC: Is this observable behavior such that we need changes in V8/SM?
 
 FYT: It's implementation-dependent.  I did update V8.  The question is whether it is possible to write a test for that behavior.
 
-LBR: Test262 cannot force implementations to have observables that are not required by the spec.
+LEO: Test262 cannot force implementations to have observables that are not required by the spec.
 
-LBR: This is implementation-dependent so we shouldn't block on vendors.
+LEO: This is implementation-dependent so we shouldn't block on vendors.
 
 SFC: I would like to have buy-in from vendors before merging.
 
@@ -143,7 +143,7 @@ Do we have MDN for these?
 - https://github.com/tc39/ecma402/pull/333
 
 - Last month:
-  - LBR: Tests are covered.
+  - LEO: Tests are covered.
   - RCA: I'm checking the issues.
 
 
@@ -346,7 +346,7 @@ SRL: my presentation on CLDR day periods: https://cdn.rawgit.com/srl295/srl295-s
 
 SRL: So we're saying that this is an am/pm API and we should stick to those two strings.
 
-LBR: Yeah. I think I'm in agreement with Daniel. am/pm is viscous because it is English-centric.  At the same time, numeric values don't make any more sense than using am/pm.  If we use string values, we can scale this API in the future if necessary.  If we use numbers, and we don't do it correctly, we have problems in the future.  And numeric values might be received differently and have different meanings for different people.  Strings seem the lesser of the evils.  +1, we don't need to discuss camel case for these.
+LEO: Yeah. I think I'm in agreement with Daniel. am/pm is viscous because it is English-centric.  At the same time, numeric values don't make any more sense than using am/pm.  If we use string values, we can scale this API in the future if necessary.  If we use numbers, and we don't do it correctly, we have problems in the future.  And numeric values might be received differently and have different meanings for different people.  Strings seem the lesser of the evils.  +1, we don't need to discuss camel case for these.
 
 LHO: I agree; numbers also have 0/1 ambiguity.  am/pm is clearer.
 
@@ -385,7 +385,7 @@ DE: Yes
 
 SRL: I would also mention BCP47, but that could be a follow on
 
-LBR: I think it looks great
+LEO: I think it looks great
 
 FYT: What is the process?
 

meetings/notes-2019-10-24.md

@@ -5,7 +5,7 @@ October 24 Attendees:
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)
 - Jahziel Villasana - Student working with Igalia (JVA)
 - Jeff Walden - Spidermonkey (JSW)
-- Leo Balter - Bocoup (LBR)
+- Leo Balter - Bocoup (LEO)
 - Long Ho - Dropbox, Format.js, react intl (LHO)
 - Myles C. Maxfield - Apple (MCM)
 - Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
@@ -34,27 +34,27 @@ SYG: I'm interested in spinning up more TGs within TC39 like Intl, to do things
 
 SRL: We should make it more apparent that this meeting is TG2.
 
-LBR: Yeah, I'm fine with adding more clarity.
+LEO: Yeah, I'm fine with adding more clarity.
 
 FYT: Yeah, we made it official a few months ago.
 
 SYG: I find this a success story of what we were able to spin off from Plenary and do more in parallel with plenary.
 
 FYT: It helps for developing proposals in early stages, and getting more people involved at later stages.
 
-LBR: Here is the official TG2 doc: https://www.ecma-international.org/memento/tc39-tg2.htm
+LEO: Here is the official TG2 doc: https://www.ecma-international.org/memento/tc39-tg2.htm
 
-LBR: To answer SYG's question, I believe we have enough decision-making power.  We have some back-and-forth with TG1, but that's not a problem where we struggle.  We have reasonable decision-making power.
+LEO: To answer SYG's question, I believe we have enough decision-making power.  We have some back-and-forth with TG1, but that's not a problem where we struggle.  We have reasonable decision-making power.
 
 SYG: Did you have to wait for TG1?
 
-LBR: Yeah, the camel case discussion.
+LEO: Yeah, the camel case discussion.
 
 SYG: Maybe you could say, you have power until Stage 2.
 
 FYT: We go to TC39 for stage advancement.  We try to address all the concerns before we go there.
 
-LBR: I like how we basically report something early, because we might have someone who wants to participate.  We tell TC39 that we have this new proposal.
+LEO: I like how we basically report something early, because we might have someone who wants to participate.  We tell TC39 that we have this new proposal.
 
 SYG: Yes, that's important, regardless of where stage advancement gets done.  The reporting back to plenary that you have been doing has been very valuable.
 
@@ -83,16 +83,16 @@ JSW: I started looking at how to implement this in SpiderMonkey but need to look
 
 - [PR](https://github.com/tc39/ecma402/pull/351)
 - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e
-- LBR wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
+- LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
 - FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) 
 
-LBR: I tried to resolve the conflict, but I would like to get that from Daniel, the author.
+LEO: I tried to resolve the conflict, but I would like to get that from Daniel, the author.
 
 ### Normative: Allow calendar to determine choice of pattern (#349)
 
 - [PR](https://github.com/tc39/ecma402/pull/349)
 - Covered by above tests
-- LBR wrote: "@littledan would you mind rebasing this one as well?"
+- LEO wrote: "@littledan would you mind rebasing this one as well?"
 - FYT flip the bit to ship it in Chrome m80. (with #351 and #175)
 
 Action: DE to rebase the PRs.
@@ -150,7 +150,7 @@ Do we have MDN for these?
    - RCA no Documentation related with this issue 
 
 - Last month:
-  - LBR: Tests are covered.
+  - LEO: Tests are covered.
   - RCA: I'm checking the issues.
 
 
@@ -260,11 +260,11 @@ JSW: We are waiting on ICU issues being fixed.
 - Advanced to Stage 3 in TC39 Oct meeting
 - Add “calendar” option to get name for “month”, “weekday”, “quarter” and “dayPeriod”
 
-LBR: Working on the tests, planning to have them done before the next TG2 meeting.
+LEO: Working on the tests, planning to have them done before the next TG2 meeting.
 
 FYT: After the TC39 October meeting, we added the calendar option.  We still need to address how to access the leap month.
 
-LBR: We can have tests for most of the API even with these open issues.
+LEO: We can have tests for most of the API even with these open issues.
 
 ### Intl.Segmenter (Stage 2)
 
@@ -293,7 +293,7 @@ ZB: We formed the Rust Intl interest group.  It is aimed to coordinate efforts t
 
 SRL: Even broader, for any i18n implementation should look at ECMA-402.  I think it's good that ECMA-402 looks at what is actually needed.
 
-LBR: Do we have videos of the panel and mentioned presentations?
+LEO: Do we have videos of the panel and mentioned presentations?
 
 ### Potential problem with data loading #17
 
@@ -303,7 +303,7 @@ SRL: You could have cases where a certain operation expects a heavyweight operat
 
 FYT: The data for format and formatRange have minimal common data.  So there's a lot of waste.  If we know in the constructor, it can make it more efficient.  We can save some space, like ⅔.
 
-LBR: While I like and appreciate the concept of using a promisified API, I have concerns.  We cannot break things we have already shipped.
+LEO: While I like and appreciate the concept of using a promisified API, I have concerns.  We cannot break things we have already shipped.
 
 ZB: Could we say, some data is pre-loaded by default, and then in an option bag, you can specify more data to load.  But if you need data in a terminal method, then that gets loaded at that point.
 
@@ -318,7 +318,7 @@ const fmt = new Intl.DateTimeFormat( … , {
 fmt.formatRange(start, end);
 ```
 
-LBR: `await Intl.load();` then classical API follows up
+LEO: `await Intl.load();` then classical API follows up
 
 ZB: (proposal): 
 ```

meetings/notes-2019-11-14.md

@@ -1,7 +1,7 @@
 November 14 Attendees:
 
 - Shane Carr - Google i18n (SFC), Moderator
-- Leo Balter - Bocoup (LBR)
+- Leo Balter - Bocoup (LEO)
 - Jeff Walden - Spidermonkey (JSW)
 - Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
 - Younies Mahmoud - Google i18n (YMD)
@@ -57,33 +57,33 @@ SFC: DE will delegate MDN and tests.
 
 - [PR](https://github.com/tc39/ecma402/pull/351)
 - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e
-- LBR wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
+- LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
 - FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) 
-- Last month: LBR: I tried to resolve the conflict, but I would like to get that from Daniel, the author.
+- Last month: LEO: I tried to resolve the conflict, but I would like to get that from Daniel, the author.
 
-LBR: Yeah, resolving the conflict requires editing the table/paragraph.
+LEO: Yeah, resolving the conflict requires editing the table/paragraph.
 
 DE: I'll follow up offline.  Can you point me to the thing that needs to be updated?
 
-LBR: It's PR #351
+LEO: It's PR #351
 
 DE: Might end up delegating this to CLA.
 
-LBR: It's good to have an extra pair of eyes.  Resolving conflicts is a little bit tricky.
+LEO: It's good to have an extra pair of eyes.  Resolving conflicts is a little bit tricky.
 
 CLA: OK
 
 ### Normative: Allow calendar to determine choice of pattern (#349)
 
 - [PR](https://github.com/tc39/ecma402/pull/349)
 - Covered by above tests
-- LBR wrote: "@littledan would you mind rebasing this one as well?"
+- LEO wrote: "@littledan would you mind rebasing this one as well?"
 - FYT flip the bit to ship it in Chrome m80. (with #351 and #175)
 - Last month: DE to rebase the PRs.
 
 SFC: Same status as #351, right?
 
-LBR: Yeah.
+LEO: Yeah.
 
 SFC: DE, can you pick up the ball on both of these?
 
@@ -454,21 +454,21 @@ SFC: Yes, perhaps.  There's the other constructor intent issue though that could
 - [Firefox bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1557727)
 - Advanced to Stage 3 in TC39 Oct meeting
 - Add “calendar” option to get name for “month”, “weekday”, “quarter” and “dayPeriod”
-- Last month: LBR: Working on the tests, planning to have them done before the next TG2 meeting.
+- Last month: LEO: Working on the tests, planning to have them done before the next TG2 meeting.
 
-LBR: Work in progress, finishing before the TC39 meeting. Missing tests for `supportedLocales` and `of`, mostly.
+LEO: Work in progress, finishing before the TC39 meeting. Missing tests for `supportedLocales` and `of`, mostly.
 
 FYT: Starting to implement in V8, now in code review. How to deal with 13 month years? The leap month in Chinese is not the same as in other calendars, not always the same numeric value for month.
 
 SFC: Please make recommendation for next month’s meeting. Agreed.
 
 RCA: Should we move without any implementation?
 
-LBR: I think we could get started on docs and test.  On tests, we have some initial tests.  We are missing tests for supportedLocalesOf. There will be adjustment as soon as FYT gives more information.
+LEO: I think we could get started on docs and test.  On tests, we have some initial tests.  We are missing tests for supportedLocalesOf. There will be adjustment as soon as FYT gives more information.
 
 SFC: This is our newest Stage 3 proposal.
 
-LBR: It would be very nice to see this shipping soon, perhaps in Feb 2020. It depends on getting small parts defined. He has hope for it by Feb. 2020.
+LEO: It would be very nice to see this shipping soon, perhaps in Feb 2020. It depends on getting small parts defined. He has hope for it by Feb. 2020.
 
 FYT: Doesn’t think it can go to S4 by Feb. 2020.
 
@@ -573,13 +573,13 @@ SRL: Is this a string properly vs. ???
 
 DE: The main thing we should do from here is reach out and ask for use cases, and stages are not so relevant. Stage 1 will not provide any practical value of S0, so let’s work on the use cases at this time.
 
-LBR: All of this points to my next topic on this.  I still believe this should be a 262 proposal.  I went to the last TC53 meeting (embedded systems), and talking to POH, I think there is an interest in working with Unicode properties.  So he's probably someone to whom you can reach out.  So I think this might be brought to 262 where we can find use cases.
+LEO: All of this points to my next topic on this.  I still believe this should be a 262 proposal.  I went to the last TC53 meeting (embedded systems), and talking to POH, I think there is an interest in working with Unicode properties.  So he's probably someone to whom you can reach out.  So I think this might be brought to 262 where we can find use cases.
 
 SFC: A real benefit of presenting for S1 is that it will raise awareness and may prompt more use cases.
 
 DE: S0 vs. S1 - not so much value for pushing S1 in December.
 
-FYT: What LBR said is right.  Because regex is in 262, not 402.  So even if we find a use case, it should sit in 262.
+FYT: What LEO said is right.  Because regex is in 262, not 402.  So even if we find a use case, it should sit in 262.
 
 DE: Do you regret unicode properties in regex?
 
@@ -593,7 +593,7 @@ FYT: We really need to build up use cases to make a stronger case.
 
 SFC: let’s take this discussion offline.
 
-LBR: Don’t need to shift the whole API to accommodate.
+LEO: Don’t need to shift the whole API to accommodate.
 
 SFC: There are people here who know a lot about Unicode properties.
 

meetings/notes-2019-12-12.md

@@ -194,9 +194,9 @@ CLA: MDN is updated (https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScrip
 
 - [PR](https://github.com/tc39/ecma402/pull/351)
 - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e
-- LBR wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
+- LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table."
 - FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) 
-- Last month: LBR: I tried to resolve the conflict in #351, but I would like to get that from Daniel, the author.
+- Last month: LEO: I tried to resolve the conflict in #351, but I would like to get that from Daniel, the author.
 - Last month: I'll follow up offline.
 
 SFC: Please follow the status wiki.
@@ -205,7 +205,7 @@ SFC: Please follow the status wiki.
 
 - [PR](https://github.com/tc39/ecma402/pull/349)
 - Covered by above tests
-- LBR wrote: "@littledan would you mind rebasing this one as well?"
+- LEO wrote: "@littledan would you mind rebasing this one as well?"
 - FYT flip the bit to ship it in Chrome m80. (with #351 and #175)
 - Last month: DE to rebase the PRs.
 - Last month: JSW: Off the top of my head I don't think we [need a SM implementation], but I'm not sure.
@@ -382,7 +382,7 @@ SFC: Out of time, so made quick mention on dateStyle/TimeSTyle #2 and #15.
 - [Firefox bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1557727)
 - Advanced to Stage 3 in TC39 Oct meeting
 - Add “calendar” option to get name for “month”, “weekday”, “quarter” and “dayPeriod”
-- Last month: LBR: Working on the tests, planning to have them done before the next TG2 meeting.
+- Last month: LEO: Working on the tests, planning to have them done before the next TG2 meeting.
 
 SFC: Proposes that browsers ship display names but don’t ship type Month because this should be resolved in Temporal.