a simple way to provide informations for contributors
Internet-Draft draft-valentinbinotto-contributingtxt-01
Valentin Binotto
valentinbinotto
valentinbinotto@vauly.net
22 June 2022
AREA
WG Working Group
next generation
unicorn
sparkling distributed ledger
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
The latest revision of this draft can be found at https://github.com/valentinbinotto/id-valentin-contributingtxt/blob/gh-pages/draft-valentinbinotto-valentinbinotto-contributingtxt.txt. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-valentinbinotto-contributingtxt/.
Discussion of this document takes place on the V434 Project Working Group mailing list (mailto:rfc@vauly.net), which is archived at https://github.com/valentinbinotto/id-valentin-contributingtxt-list.
Source for this draft and an issue tracker can be found at https://github.com/valentinbinotto/id-valentin-contributingtxt.
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.
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.
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: https://example.com/contributing.txt).
The file "contributing.txt" MUST contain at least:
- Paragraph "Admin" with the name of the administrator or the webmaster.
- Paragraph "Bugs" with a mail address or a web address to report bugs.
Example 1

Admin: Valentin Binotto
Bugs: bugs@example.com

OPTIONALLY the following paragraphs can be added to the "contributing.txt" file:
- Paragraph "Open Source" with a web address to a suitable platform for third party collaboration (for example github.com or gitlab.com).
- Paragraph "License" with information about the license that applies to the content of the website.
- Paragraph "Guidelines" with a web address to the guidelines for contributing to this project.
Example 2

Open Source: github.com/valentinbinotto
License: Creative Commons Attribution 4.0 Int. Public License
Guidelines: github.com/valentinbinotto/v434/guidelines.txt

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

# Hello, world!

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.
Example for a "contributing.txt" file

Admin: Valentin Binotto
Bugs: bugs@example.com
Open Source: github.com/valentinbinotto
License: Creative Commons Attribution 4.0 Int. Public License
Guidelines: github.com/valentinbinotto/v434/guidelines.txt
# Hello, world!

Security Considerations
Because of the use of URIs, security considerations of [RFC3986] apply here.
IANA Considerations
This document has no IANA actions.
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC2046]

Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
N. Freed
N. Borenstein
November 1996
RFC 2046
DOI 10.17487/RFC2046
[RFC3629]

UTF-8, a transformation format of ISO 10646
F. Yergeau
November 2003
STD 63
RFC 3629
DOI 10.17487/RFC3629
[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax
T. Berners-Lee
R. Fielding
L. Masinter
January 2005
STD 66
RFC 3986
DOI 10.17487/RFC3986
Acknowledgments