saturneric/standard-readme
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
288e7e520c
standard-readme/README.md
Richard Littauer 288e7e520c Change capitalization
2016-07-07 16:18:46 +01:00

9.4 KiB
Raw Blame History

Standard Readme

standard-readme compliant

Readme Standard Style

This repo is for standardizing how READMEs should look. The goal is to have a spec, a linter, a generator, a badge, and examples.

Table of Contents

Background

Standard Readme started with in the issue originally posed by @maxogden over at feross/standard in this issue. A lot of that discussion ended up in zcei's standard-readme repository. While working on maintaining the IPFS repositories, I needed a way to standardize Readmes. This is a result of that.

Your documentation is complete when someone can use your module without ever having to look at its code. This is very important. This makes it possible for you to separate your module's documented interface from its internal implementation (guts). This is good because it means that you are free to change the module's internals as long as the interface remains the same.

Remember: the documentation, not the code, defines what a module does.

~ Ken Williams, Perl Hackers

Goals:

  1. A well defined specification. This can be found in the Specification section. It is a constant work in progress; please open issues to discuss changes.
  2. An example README. This Readme is fully standard-readme compliant, and there are more examples in the example-readmes folder.
  3. A linter that can be used to look at errors in a given Readme. Please refer to the tracking issue.
  4. A generator that can be used to quickly scaffold out new READMEs. See generator-standard-readme.
  5. A compliant badge for users. See the badge.

Installation

This project uses node and npm. Go check them out if you don't have them locally installed.

$ npm i -g standard-readme

Usage

Currently, this is only a Readme spec.

$ standard-readme
// Will output spec (this Readme)

Generator

To use the generator, look at generator-standard-readme.

Badge

If your README is compliant with Standard-Readme and you're on GitHub, it would be great if you could add the badge. This allows people to link back to this Spec, and helps adoption of the README. The badge is not required.

standard-readme compliant

To add in Markdown format, use this code:

[![standard-readme compliant](https://img.shields.io/badge/standard--readme-OK-green.svg?style=flat-square)](https://github.com/RichardLitt/standard-readme)

Example Readmes

To see how the specification has been applied, see the example-readmes.

Specification

Requirements

A compliant README must:

  • Be called README.md (with capitalization).
  • Be a valid Markdown file.
  • Sections must appear in order delineated below. Optional sections may be omitted.
  • Must be new lines between each section.

Suggestions:

  • A "Back to Top" link for longer sections can be useful, but is not required by any means.

Sections

Title

Status: Required.
Requirements:

  • Must match repository name. If it cannot, there must be a note in the long description about why.
  • Must match package manager name. If it cannot, there must be a note in the long description about why.

Suggestions:

  • Should be self-evident.

Banner

Status: Optional.
Requirements:

  • Must link to local image in current repository.
  • Must appear directly after the title.

Badges

Status: Optional.
Requirements:

  • Must be newline delimited.

Short Description

Status: Required.
Requirements:

  • Must be less than 120 characters.
  • Must start with >
  • Must be on it's own line.
  • Must match the description in the packager manager's description field.
  • Must match GitHub's description (if on GitHub).

Suggestions:

  • Use gh-description to set and get GitHub description.
  • Use npm show . description to show the description from a local npm package.

Long Description

Status: Optional.
Requirements:

  • Must have no heading.

Suggestions:

  • If too long, consider moving to the Background section.

  • Cover the main reasons for building the repository.

  • "This should describe your module in broad terms, generally in just a few paragraphs; more detail of the module's routines or methods, lengthy code examples, or other in-depth material should be given in subsequent sections.

    Ideally, someone who's slightly familiar with your module should be able to refresh their memory without hitting "page down". As your reader continues through the document, they should receive a progressively greater amount of knowledge."

    ~ Kirrily "Skud" Robert, perlmodstyle

Table of Contents

Status: Required.
Requirements:

  • Must link to all Markdown sections in the file.
  • Must start with the next section; do not include the title or Table of Contents headings.
  • Must be at least one-depth: must capture all ## headings.

Suggestions:

  • May capture third and fourth depth headings. If it is a long ToC, these are optional.

Security

Status: Optional.
Requirements:

  • May go here if visibility of security section is important. Otherwise, should be in Extra Sections.

Background Section

Status: Optional.
Requirements:

  • Cover motivation.
  • Cover abstract dependencies.
  • Cover intellecutal provenance: A See Also section is also fitting.

Installation

Status: Required.
Requirements:

  • Code block illustrating how to install.

Subsections:

  • Dependencies. Required if necessary.
  • Updating. Optional.

Suggestions:

  • Link to prerequisite sites for language. [npmjs][], [godocs][], etc.
  • Include any system-specific information needed for Installation.
  • Subsection for dependencies needed for install to work.

Usage Section

Status: Required.
Requirements:

  • Code block illustrating common usage.
  • If CLI compatible, code block indicating common usage.
  • If importable, code block indicating both import functionality and usage.

Subsections:

  • CLI. Required if CLI functionality exists.
  • If relevant, point to a runnable file for the usage code.

Suggestions:

  • Cover basic choices that may affect usage: for instance, if JavaScript, cover promises/callbacks, ES6 here.

Extra Sections

Status: Optional.
Requirements:

  • None.

API

Status: Optional.
Requirements:

  • Describe exported functions and objects.

Suggestions:

  • Describe signatures, return types, callbacks, and events.
  • Cover types covered where not obvious.
  • Describe caveats.
  • If using an external API generator (like go-doc, js-doc, or so on), point to an external API.md file. This can be the only item in the section, if present.

Contribute

Status: Required.
Requirements:

  • State where users can ask questions.
  • State whether PRs are accepted.
  • List any requirements for contributing; for instance, having a sign-off on commits.

Suggestions:

  • Link to CONTRIBUTE.md file -- if there is one.
  • Be as friendly as possible.
  • Link to the GitHub issues.
  • Link to Code of Conduct. This is often in Contribute, or organization wide, so may not be necessary for each module.

License

Status: Required.
Requirements:

  • State license initials or name.
  • State license owner.
  • Must be last section.

Suggestions:

  • Link to longer License file in local repository.

Contribute

Feel free to dive in! Open an issue or submit PRs.

Standard Readme follows the Contributor Covenant Code of Conduct.

License

MIT (c) Protocol Labs