Skip to content

Latest commit

 

History

History
150 lines (107 loc) · 6.45 KB

CONTRIBUTING.md

File metadata and controls

150 lines (107 loc) · 6.45 KB

Contributing to URI Specification Development

This repository contains documentation and code for which copyright might be owned by various authors and/or employers. All contributors agree that their contributions are intended as both an IETF Contribution and as an open source Contribution under the Apache License 2.0. Contributions that are in the public domain remain in the public domain regardless of their incorporation in other works.

The Apache License 2.0 is the downstream license for all files herein unless otherwise noted inside an individual file (e.g., RFCs have their own license text and an additional BSD-style license on code fragments).

Before submitting feedback, please familiarize yourself with our current issues list(s). If you are new to this, you may also want to read the Tao of the IETF.

Following Discussion

Contributors have a few venues for discussion:

  • The URI mailing list is used for announcements, general discussion of drafts, and contributions that (for whatever reason) are not submitted via GitHub.

  • Meetings (if any) are informal and typically held in conjunction with an IETF or W3C meeting.

  • Specific issues and pull requests are discussed using this repository's Github collaboration tools.

Raising Issues

Before filing a new issue, please consider a few things:

  • Review the existing issues first to avoid filing a duplicate.
  • Only raise issues with regard to the specification(s), not to ask questions or make support requests.
  • If you're not sure how to phrase your issue, please ask on the mailing list.

Issues can also be raised via email to the list by clearly marking them as such (e.g., "New Issue" in the Subject: line).

Be aware that the editors might rephrase, change scope, split, or combine issues, depending on how the work seems to be progressing. If you feel that such a change loses an important part of your original issue, please bring that up in comments or on the list.

Off-topic and duplicate issues will be closed without discussion. Note that comments on individual git commits will only be responded to with best effort, and may not be seen.

Resolving Issues

Issues will be labeled by the editors as either editorial or design:

  • Editorial issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.

  • Design issues require discussion before they can be labeled resolved and closed.

Open design issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to design issues for the group's consideration by incorporating them into the draft(s). Additional labels are used to indicate when an issue needs-discussion, has-proposal, is editor-ready, incorporated, or has-consensus.

Closed design issues are believed to be not worth further discussion. This could be because they have already been resolved in the drafts, a decision has been made not to resolve them, they are invalid or a duplicate of other issues, or simply not applicable to the current work.

If you have a question or problem with an issue in the closed state, please comment on it (either in the issues list or mailing list) and the editors might adjust its state accordingly. Reopening issues that have been labeled as has-consensus requires new information.

Pull Requests

We welcome pull requests, both for editorial suggestions and to resolve open issues. Please include the relevant issue #number within the pull request.

Please do not use a pull request to open a new design issue; it may not be noticed.

Code of Conduct

The IETF Guidelines for Conduct applies to all of our communications and meetings.

NOTE WELL

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.