Internet-Draft contributing.txt June 2022
Binotto Expires 24 December 2022 [Page]
WG Working Group
Intended Status:
V. Binotto

a simple way to provide informations for contributors


Open source projects rely on the cooperation of third parties. Other websites also rely on user feedback, for example, when bugs occur. There are various platforms that enable effective collaboration. However, this diversity also presents a challenge. Where should users who have discovered an error report it? Or how can third parties participate in a project? This document presents one way to communicate such information in a consistent manner.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at Status information for this document may be found at

Discussion of this document takes place on the V434 Project Working Group mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 December 2022.

Table of Contents

1. Introduction

Currently, there are various platforms for collaboration on projects or communication with users of websites, services and so on. This creates opportunities, for example in open source projects, to work with contributors and exchange information. However, such opportunities differ from project to project. Users who are interested in participating in a project need to be aware of these different procedures. This can be a challenge due to the inconsistent form of the information and might also lead to users deciding not to participate because they cannot find a contact point.

At the same time, there is a need for "bug reports" in other forms of websites as well. Users are expected to point out bugs to the person in charge and thus lead to a better user experience for all users. Unfortunately, the ways and procedures for such "bug reports" also differ from website to website. These differences mean that users might not be able to find a contact person to report a bug, and thus fail to report it.

The goal of this document and the proposed form of communication in the "contributing.txt" file is:

  1. to provide open source or similar projects with the opportunity to inform interested parties about the possibilities of contributing.
  2. to offer any kind of website the possibility to define a contact person for bug reports etc.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. The Specification

This document defines a file called "contributing.txt", which provides information about possible contribution to a project or website. The file format of "contributing.txt" MUST be plain text (MIME type "text/plain") (Section 4.1.3 of [RFC2046]) and MUST be encoded using UTF-8 ([RFC3629]).

The file "contributing.txt" MUST be placed directly under the domain (for example:

The file "contributing.txt" MUST contain at least:

Admin: Valentin Binotto
Figure 1: Example 1

OPTIONALLY the following paragraphs can be added to the "contributing.txt" file:

Open Source:
License: Creative Commons Attribution 4.0 Int. Public License
Figure 2: Example 2

OPTIONALLY, comments can be added to the "contributing.txt" file. Each line of the comment must start with "#" (%x23).

# Hello, world!
Figure 3: Example 3

The specified paragraphs MUST be placed in the following order:

  1. Admin
  2. Bugs
  3. Open Source
  4. License
  5. Guidelines
  6. (Comments)
    Only one entry is allowed per paragraph

    However, paragraphs can be reused an unlimited number of times, as long as the order of the paragraphs is still as specified.

Admin: Valentin Binotto
Open Source:
License: Creative Commons Attribution 4.0 Int. Public License
# Hello, world!
Figure 4: Example for a "contributing.txt" file

4. Security Considerations

Because of the use of URIs, security considerations of [RFC3986] apply here.

5. IANA Considerations

This document has no IANA actions.

6. Normative References

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <>.
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.


Author's Address

Valentin Binotto