]> valentinbinotto

valentinbinotto@vauly.net

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 . 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 .

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 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 ) and MUST be encoded using UTF-8 ().

The file "contributing.txt" MUST be placed directly under the domain (for example: 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:
  
  Admin: Valentin Binotto
  Bugs: bugs@vauly.net
  
  
  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:
  
  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:
  
  # Hello, world!
  
  
  
  The specified paragraphs MUST be placed in the specified order. 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@vauly.net
  Open Source: github.com/valentinbino
  License: Creative Commons Attribution 4.0 Int. Public License
  Guidelines: github.com/valentinbinotto/v434/guidelines.txt
  # Valentin Binotto
  # Hello, world!

Security Considerations Because of the use of URIs, security considerations of apply here.

IANA Considerations This document has no IANA actions.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

Acknowledgments