Open Community Working Meeting 2022-09-26 #244
Labels
Status: Stale
It's believed that this issue is no longer important to the requestor.
Working Meeting
Identify working meetings
Open Community Working Meeting 2022-09-26 - 14:00 PT
Zoom Meeting link: https://postman.zoom.us/j/89562933116?pwd=OWlsQ0RrcDY4S1JQU2d2Q2M0aFFlZz09
Agenda:
AOB?
If you want to discuss any other business not on the agenda, please add comments during the meeting.
If we do not complete the agenda, your discussion item will likely be rolled over to the next call.
Actions and Minutes
Go To Previous Meeting
Hightlights
Actions
Attendees
Details
Prioritization and Organizational Practices
Labels
were suggested, so that they can be used to generate a list based on WG meetings. The issues, PRs etc.discussed can then be triaged based on the discussion. At present, use of labels have the following issues
Nominating
andPinning
a few things based on a consensus on their priority. The issues raised with the technique was thatmembers involved may have conflicting priorities and a consensus might be difficult to reach.
To
triage
an hour each day can be handled by someone dedicatedly. Those can be used to assess critical, high priority things whichcan help set agenda for WG meetings. Along with issues, PRs and discussions carrying a dedicated label to be decided which can be used to
add those items to meeting agenda otherwise to be left out of meetings.
A dedicated
slack channel
which has some automation to deal with prioritaztion was also discussed. Although administering it would be a task in itself,hence the idea was dropped.
Method of consensus and priority was
agreed
upon, which can be a markdown file in the community repo whose notifications can then be posted to slack channel.The issue raised in this regard was that people spend more time in test suite and spec repo than the community repo, to which the solution suggested was
notifying priorities to a slack channel.
Specification Document Governance Model
Specification document snapshot with every release, like the ECMAScript.3 Although there is backward compatibility in living specs
and future feature can be tagged to be ignored the advantage of snapshots is that they set a bound to material
that one has to deal with for a software that was written based on a specific spec.
The disadvantage of snapshots and an advantage for the spec as a living document pointed out was that clarifications, bug fixes etc.
may quickly desynchronize understanding thereby people running into issues which were easily avoidable.
A solution suggested was to add an errata to snapshots which would require least effort and modifying the spec text will not be necessary.
Also, a spec standard is suggested to use normative language so as to not confuse between types of requirements.12
(FYI: The above minutes and actions are the first test of our new minutes and actions contract work!)
Recording: link
Footnotes
https://datatracker.ietf.org/doc/rfc2119/ ↩ ↩2
https://datatracker.ietf.org/doc/rfc8174/ ↩ ↩2
https://arai-a.github.io/ecma262-compare/ ↩
The text was updated successfully, but these errors were encountered: