1 of 13

reducing wasted effort

due to proposal churn

Michael Ficarra • July 2023

2 of 13

background

overview of our current stage process

(please don't sweat the details)

  • research affected use cases
  • create a proposal document & repo

Stage 1

problem is defined

Stage 0

idea

Stage 2

solution is chosen

  • research/compare solutions
  • solicit feedback
  • choose a preferred solution
  • write early spec text

Stage 3

details are "final";�recommended for implementation

Stage 4

draft standard

  • implementation begins
  • test262 tests are written
  • 2+ implementations ship
  • get implementor feedback
  • editors approve final spec text
  • work out remaining details
  • write full spec text
  • get reviews from assigned reviewers
  • editors review for integration issues
  • identify a problem space
  • editors merge proposal into draft spec

3 of 13

activities in increasing level of effort

4 of 13

if we delay higher-effort activities until after we've used lower-effort methods to discover any issues, we will reduce total expended effort

5 of 13

we should do these in order

1st

2nd

3rd

last

6 of 13

why don't we? issues with our process

In stage 3, while writing tests,

  1. discovering issues that require changes to the proposal (and thus in-progress implementations)

​

But we can't simply require tests before stage 3 (implementation) because

  • the committee flip-flopping on design choices after tests have been written

still requires significant repeated effort to update or rewrite the tests

7 of 13

proposed solution

A way to signal our commitment to the current proposal design. Allows tests to be written, but not yet recommended for implementation.

A stage between Stage 2 and Stage 3.

Once this stage has been reached, changes are only made based on feedback from tests or implementations. No flip-flopping allowed.

Stage 2

solution is chosen

Stage 3

recommended for implementation

  • implementation begins
  • 2+ implementations ship
  • get implementor feedback
  • editors approve final spec text
  • work out remaining details
  • write full spec text
  • get reviews from assigned reviewers
  • editors review for integration issues

New Stage

details are "final"

​

​

  • test262 tests are written
  • if appropriate, polyfills or transpilers may be developed

SAME

8 of 13

will this slow down the proposal process?

Not necessarily.

Tests can be written before the committee commits to the design, jumping directly from Stage 2 to Stage 3, but they risk having to be redone if design changes are requested.

The new stage won't be another chance to relitigate the design. It is not an IETF Last Call. Advancement to Stage 3 is based solely on adequacy of the tests.

9 of 13

who writes the tests?

The champion(s), or someone working with them.

10 of 13

do the tests need to be perfect?

No. They just need to be deemed adequate by the committee.

This may be subjective based on the size or complexity of the proposal. We may also define objective measures in the future to set a minimum bar.

11 of 13

what do we do about stage numbers/names?

we can call it Stage 2¾ for now

🤷

12 of 13

should we apply this retroactively?

  • current unimplemented Stage 3 proposals with no/insufficient test262 tests
  • proposals that advance(d) to Stage 3 at this meeting without tests

13 of 13

discuss