Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

{^} ACTION REQUIRED -- ballot of error handling #830

Closed
aphillips opened this issue Jul 16, 2024 · 17 comments
Closed

{^} ACTION REQUIRED -- ballot of error handling #830

aphillips opened this issue Jul 16, 2024 · 17 comments
Labels
Ballot Balloting issue errors Issues related to the errors section of the spec LDML46 LDML46 Release (Tech Preview - October 2024) normative

Comments

@aphillips
Copy link
Member

aphillips commented Jul 16, 2024

Per the discussion in the 2024-07-15 teleconference (along with preceding calls on the same topic), there has been a call for voting on the resolution of error handling in the LDML46 version of the specification.

WORKING GROUP BALLOT

Please read the instructions CAREFULLY before responding.

Please carefully read the design document before responding.
Please make pull requests against the design document for the addition of material facts or corrections.

Update (2024-07-17)

Apologies to all: I failed to publish the discussion thread. Please see #831 for that.

Balloting Instructions

Using the SINGLE TRANSFERABLE VOTE process, rank your choice(s) for error behavior.

The deadline is 1700 (5 PM) in the America/Los_Angeles time zone on Sunday, 21 July 2024 Votes received after the deadline will be considered at the discretion of the chair.

  • A group member in good standing MAY submit exactly one vote consisting of a ranked set of choices
    up until the deadline.
  • A group member MAY edit, change, or delete their vote up until the deadline.
  • Votes MUST be submitted as a comment on this github issue.
    Group members who cannot submit a comment on this issue should contact the chair (@aphillips) for assistance.
  • Votes MUST contain a stack ranked list of candidate options.
  • Votes MUST only contain votes for candidate options. Write in votes are not acceptable.
  • A vote MUST have at least one item in order to be counted and MAY rank as many items as desired.
  • Only ranked votes will be counted. That is, do not submit a vote equating two entries.
  • Group members MUST NOT comment on the votes of others in this issue. "Electioneering" or non-voting commentary is not permitted in the issue except the chair may seek clarification of a vote. Use Discussion issue for #830: balloting of error handling #831 to discuss.

Candidates

The candidates are:

(1) MUST signal errors and MUST provide fallback
(2) MUST signal errors or MUST provide fallback
(3) MUST signal errors and SHOULD provide fallback
(4) SHOULD signal errors and MUST provide fallback
(5) Error handling is not a normative requirement

Candidate Descriptions

(1) MUST signal errors and MUST provide fallback

  • Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
  • Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
  • An implementation is not conformant unless it provides access to both behaviors. It is compliant to do both in a single formatting attempt.

(2) MUST signal errors or MUST provide fallback

  • Implementation MUST either signal an error or errors or provide a fallback representation of a message in a given formatting attempt.
    • A single given message formatting attempt containing one or more errors can produce either error signaling (such as throwing an exception or returning an error code) or return a fallback string.
    • It is compliant to do both in a single formatting attempt. It is compliant to implement signaling and fallback separately (same as (1)). It is not compliant to do neither.

(3) MUST signal errors and SHOULD provide fallback

  • Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
  • Implementations SHOULD provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
  • Implementations are conformant if they only signal errors.

(4) SHOULD signal errors and MUST provide fallback

  • Implementations SHOULD provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
  • Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
  • Implementations are conformant if they only provide a fallback representation of a message.

(5) Error handling is not a normative requirement

  • Implementations are not required by MF2 to signal errors or to provide access to a fallback representation.
    • The specification provides guidance on error conditions; on what error types exist; and what the fallback representation is.
@aphillips aphillips added normative errors Issues related to the errors section of the spec LDML46 LDML46 Release (Tech Preview - October 2024) labels Jul 16, 2024
@aphillips
Copy link
Member Author

(chair hat off)

My vote:

5 > 2 > 3

@gibson042
Copy link
Collaborator

gibson042 commented Jul 16, 2024

1 >>> 4 > 3 >> 2 > 5

@eemeli
Copy link
Collaborator

eemeli commented Jul 16, 2024

1 > 4 > 2 > 5

@macchiati

This comment was marked as off-topic.

@alerque

This comment was marked as off-topic.

@aphillips
Copy link
Member Author

Thanks @alerque. @macchiati I have copied your comment to #831 before hiding it here.

@macchiati
Copy link
Member

macchiati commented Jul 17, 2024 via email

@sffc
Copy link
Member

sffc commented Jul 17, 2024

1 ~>> 3 > 5 > 4 > 2

Note: My signs are the ones we use in ICU4X-TC

  • '=' for no preference
  • '~>` for very weak preference
  • '>' for normal preference
  • '~>>' for strong preference, but not veto
  • '>>' for very strong/veto preference

@nordzilla
Copy link
Member

1 > 4 > 3 > 5 > 2

@echeran
Copy link
Collaborator

echeran commented Jul 18, 2024

3 > 5 > 2 > 1 > 4

@catamorphism
Copy link
Collaborator

1 > 3 > 4 > 2 > 5

@lucacasonato
Copy link

I do not know if I have good standing after two meetings yet, but in case I do, my vote is:

4 > 2 > 1 > 5 > 3

@harmitgoswami
Copy link

Ditto with above, but my vote is:

1 > 3 > 4 > 2 > 5

@aphillips
Copy link
Member Author

(chair hat on)

For clarity: good-standing means anyone who is a member of the WG and not otherwise declared as not in good standing. There is no requirement to have attended even one teleconference or made any other contribution.

@mradbourne
Copy link
Collaborator

1 > 4 > 3 > 2 > 5

@aphillips
Copy link
Member Author

Candidate (1) has 7 top votes (out of 11 voting) and finishes in first. Using STV methodology, candidate (3) finished second and (4) was third.

@mihnita
Copy link
Collaborator

mihnita commented Jul 22, 2024

2 > 5 > 3 > 4 > 1

echeran added a commit to echeran/message-format-wg that referenced this issue Jul 29, 2024
echeran added a commit that referenced this issue Aug 5, 2024
* Add design doc for error handling

* Apply suggestions from code review

Co-authored-by: Addison Phillips <[email protected]>

* Update exploration/error-handling.md

Co-authored-by: Tim Chevalier <[email protected]>

* Update text of proposed alternative to simplify and add incremental constraint

* Reword to unambiguously convey correct summary

* Add example of coding guidelines

* Add paragraph indicating word choice of "signal" vs. "emit" & "return"

* Add additional alternative still maintaining both MUST clauses

* Update exploration/error-handling.md

Co-authored-by: Addison Phillips <[email protected]>

* Apply suggestions from code review

Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>

* Apply suggestions from code review

Co-authored-by: Richard Gibson <[email protected]>

* Add ballot options from #830, designate selected design as such

* Add meeting notes and ballot issues

* Apply suggestions from code review

Co-authored-by: Eemeli Aro <[email protected]>

---------

Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Tim Chevalier <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Richard Gibson <[email protected]>
@aphillips aphillips added the Ballot Balloting issue label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ballot Balloting issue errors Issues related to the errors section of the spec LDML46 LDML46 Release (Tech Preview - October 2024) normative
Projects
None yet
Development

No branches or pull requests