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

Open Community Working Meeting 2022-09-26 #244

Open
3 of 6 tasks
Relequestual opened this issue Sep 26, 2022 · 1 comment
Open
3 of 6 tasks

Open Community Working Meeting 2022-09-26 #244

Relequestual opened this issue Sep 26, 2022 · 1 comment
Labels
Working Meeting Identify working meetings

Comments

@Relequestual
Copy link
Member

Relequestual commented Sep 26, 2022

Open Community Working Meeting 2022-09-26 - 14:00 PT

Zoom Meeting link: https://postman.zoom.us/j/89562933116?pwd=OWlsQ0RrcDY4S1JQU2d2Q2M0aFFlZz09

Agenda:

Topic Owner Decision/NextStep
Review last call's action items [facilitator]

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

  • ADR decoupling from IETF and updates made to PR 1277
  • Should specification be a living document with snapshots ?
  • Use of normative language like IETF's RFC 21191 and its update on keyword capitalization RFC 8174.2
  • How to better prioritize issues, PRs, discussions as an organizational practice, methods touched upon were dedicated slack channel, pinned posts, notifications and labelling.
  • Discussion on SDLC (Specification Development Life Cycle) was deferred for later. Follow the Discussion.

Actions

Attendees

Name Account
Ben Hutton @relequestual
Greg Dennis @gregsdennis
Henry Andrews @handrews
Jason Desrosiers @jdesrosiers

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

  • Have not been rolled out to all repositories
  • There is no standard triage process in place
  • Labels and notification not conceptually mapped, making it difficult to set priority and to follow activity at a glance
  • Use of label, sorting by label and tagging by contributers not the most efficient or relevant and at times ignored

Nominating and Pinning a few things based on a consensus on their priority. The issues raised with the technique was that
members 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 which
can 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

  1. https://datatracker.ietf.org/doc/rfc2119/ 2

  2. https://datatracker.ietf.org/doc/rfc8174/ 2

  3. https://arai-a.github.io/ecma262-compare/

@handrews
Copy link

Agenda item:

  • Discuss the dependency order of major topics that need resolution. We are stuck in some deadlocks right now due to differing views on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working Meeting Identify working meetings
Projects
None yet
Development

No branches or pull requests

3 participants