[OPSAWG][VELOCE] Discussion (3/3): How does the broader WG stay involved in GitHub-based YANG development?

[Mahesh Jethanandani <[e-mail]>]

Series note: This is the third and final email in the series. The first covered the platform choice and the second covered the RFC-to-repo relationship. All three topics will be presented and discussed at the upcoming IETF meeting in Vienna.

Dear OPSAWG participants,

The previous two emails in this series asked where VELOCE repositories should live and how an RFC should reference a module in a repo. This email addresses the next natural question: once YANG module development moves to GitHub, how does the broader WG — including participants who do not actively follow GitHub — stay informed and retain meaningful input?

This touches three related issues: #17 (activity monitoring), #18 (PR approval authority), and #51 (issue lifecycle).

KEEPING THE WG INFORMED (#17)

RFC 8874 §4.3 recommends that WGs using GitHub send a weekly digest of repository activity to the mailing list. The current VELOCE draft says participants SHOULD do this. PR#55 proposes aligning more explicitly with RFC 8874's guidance. The question for the WG is whether this SHOULD become a MUST — a mandatory requirement for any WG participating in the VELOCE experiment — or whether it should remain advisory.

WHO CAN APPROVE AND MERGE CHANGES (#18)

When a pull request is ready to merge, who has the authority to do so? PR#56 proposes that the WG chairs determine rough consensus on the mailing list, mirroring the normal IETF process. An alternative view is that any listed author can merge once sufficient review has occurred on the PR itself. The WG needs to decide which model it prefers, and whether the answer differs for changes made during active I-D development versus post-publication updates.

THE ISSUE LIFECYCLE (#51)

When a problem is identified — whether during development or after RFC publication — what is the expected path from first report to resolution? Issue #51 proposes a standard workflow: open a GitHub issue, discuss on the issue thread or mailing list, reach rough consensus, write a pull request, review, merge, and close. Having this written down prevents issues from drifting open indefinitely and ensures everyone follows the same process.

QUESTIONS FOR THE WG

Should the weekly GitHub activity digest be a MUST for VELOCE participants, or is a SHOULD sufficient?

Who should have the authority to merge a pull request — chairs only, any author with write access, or someone else?

Should the issue lifecycle be normative (MUST follow this workflow) or informative (suggested practice)?

These are among the more straightforward questions in the VELOCE draft, and resolving them early will provide a solid procedural foundation for the harder post-publication discussions. We look forward to your input before the meeting in Vienna.

Posting on behalf of all the authors.

Mahesh Jethanandani
[e-mail]