Anyone can contribute to MASQUE; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work, as outlined below, is part of the MASQUE Working Group.
Before doing so, it's a good idea to familiarize yourself with our charter, and home page. If you're new to this, you may also want to read an informal guide to the IETF process and the Tao of the IETF.
The MASQUE Working Group has a few venues for discussion:
-
We have a session at most IETF meetings, and sometimes in between (called an "interim" meeting). See our meeting materials repository, and the official IETF proceedings for details.
-
Our mailing list is used for notifications of meetings, adoption of documents, consensus calls, issue discussion, and other business. It's not mandatory to subscribe, but you're likely to miss important things if you don't.
-
We discuss most document issues on GitHub. Summaries of GitHub activity are sent to the MASQUE mailing list every week. You may also subscribe and follow activity on draft repositories under the MASQUE Working Group organization.
To be active in the Working Group, you can participate in any or all of these places.
We use GitHub to track items for discussion and their resolution.
Before filing a new issue, please consider a few things:
-
Issues should be specific to the document in the repository; discussion of implementations or related documents should happen on the mailing list.
-
There may be an existing duplicate issue, so please review the issues list first.
-
If you're not sure how to phrase your issue, please ask on the mailing list.
Issues can also be raised on the Working Group mailing list by clearly marking them as such (e.g., in the Subject: line).
Be aware that issues might be rephrased, changed in scope, or combined with others, so that the group can focus its efforts. If you feel that such a change loses an important part of your original issue, please bring it up, either in comments or on the mailing list.
Off-topic and duplicate issues will be closed without discussion. Note that comments on individual commits will only be responded to with best effort, and may not be seen.
As in all IETF Working Groups, final consensus of the Working Group is determined during Working Group Last Call; consensus established in discussion of issues provides a limited precedent, to prevent revisiting topics unnecessarily. Our GitHub issues list provides a mechanism for tracking those discussions and their outcomes.
Some issues might be labeled as editorial; they can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself. If you believe an editorial issue is not purely editorial, please say so on the issue; the Chair(s) will make a determination.
The remaining open issues in the issues list are those that need Working Group discussion.
Issues can be discussed on the mailing list or the issues list. Issues should be resolved with Pull Requests. Each Pull Request should reference the corresponding issue(s). This increases visibility of document changes in response to issues. Editors are responsible for merging Pull Requests that resolve issues. Editors are highly encouraged to seek Pull Request feedback in the form of reviews.
Some issues might require an explicit consensus call; if consensus is achieved in this manner, the issue will be labeled with has-consensus. Reopening issues with has-consensus requires new information (in the judgement of the chairs).
When an issue is closed, it implies that the issue's proposed resolution is reflected in the draft(s). When a new draft is published, the issues that have been closed since the last draft will be highlighted in the draft's change notes and/or on the mailing list, to aid reviewers.
Note that whether or not an issue is closed does not necessarily reflect consensus of the Working Group; an issue's open/closed state is only used to organize our discussions. If you have a question or problem with an issue in the closed state, please comment on it (either in the GitHub issues list or mailing list), and we'll adjust its state accordingly.
We welcome pull requests, both for editorial suggestions and to resolve open issues. In the latter case, please identify the relevant issue.
Please do not use a pull request to open a new issue. Instead, file an issue and refer to it from the pull request.
The IETF Guidelines for Conduct applies to all Working Group communications and meetings.
Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:
- The IETF plenary session
- The IESG, or any member thereof on behalf of the IESG
- Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices
- Any IETF working group or portion thereof
- Any Birds of a Feather (BOF) session
- The IAB or any member thereof on behalf of the IAB
- The RFC Editor or the Internet-Drafts function
- All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).
Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.
Please consult RFC 5378 and RFC 3979 for details.
A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.
A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.