Open-source Maintainers' Must Haves
Tags: opensource, programming, github
Published: 2020-09-21 12:33:01

---
title: Open-source Maintainers' Must Haves
published: true
description: If you're starting a new open-source project, keep this list of must-haves in it. That will not only help in building better quality code, but will also help in maintaining issues, documents, etc.
tags: opensource, programming, github
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/y3c08z7br5ipopmpi2c7.png
canonical_url: https://blog.shhdharmen.me/open-source-maintainers-must-haves
---

If you're starting a new open-source project, keep this list of must-haves in it. That will not only help in building better quality code, but will also help in maintaining issues, documents, etc.

# Table of Contents

- [Open-source](#open-source)
  - [Maintainer](#maintainer)
- [Tools](#tools)
  - [Linting](#linting)
    - [Prettier](#prettier)
    - [ESLint](#eslint)
  - [Commit, Changelog and Releases](#commit-changelog-and-releases)
    - [Commitizen](#commitizen)
    - [Standard Version](#standard-version)
    - [Semantic Release](#semantic-release)
  - [Documentation](#documentation)
    - [Make a README](#make-a-readme)
    - [readme-md-generator](#readme-md-generator)
    - [Badges - Shields.io](#badges---shieldsio)
    - [License](#license)
    - [Contributing Guidelines](#contributing-guidelines)
    - [All Contributors](#all-contributors)
    - [Contributor Covenant](#contributor-covenant)
  - [GitHub Issues & PRs Templates](#github-issues--prs-templates)
- [Other Guides](#other-guides)
  - [Open Source Guide](#open-source-guide)
  - [Mozilla Science Lab - Working Open Workshop](#mozilla-science-lab---working-open-workshop)
  - [Welcoming Open Source Project Metrics](#welcoming-open-source-project-metrics)
- [Conclusion](#conclusion)

# Open-source

When a project is open source, that means anybody is free to use, study, modify, and distribute your project for any purpose.

Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor’s product decisions.

## Maintainer

Well, goal of this article is not to dig deep in what is open-source maintainer. But, I will quote it from [Best Practices for Maintainers](http://opensource.guide/best-practices/#what-does-it-mean-to-be-a-maintainer "Best Practices for Maintainers | Open Source Guides"):

> If you maintain an open source project that a lot of people use, you may have noticed you’re coding less and responding to issues more.
>
> In the early stages of a project, you’re experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you’ll find yourself working with your users and contributors more.
>
> Maintaining a project requires more than code. These tasks are often unexpected, but they’re just as important to a growing project.

---

# Tools

Let's look into tools which can help to make life of a maintainer easy 😇.

I have divided tools in a few categories: Formatting and Linting, Commit, Changelog and Releases, Documentation and Github Templates.

## Linting

Linters have two categories of rules:

**Formatting rules**: eg: [max-len](https://eslint.org/docs/rules/max-len), [no-mixed-spaces-and-tabs](https://eslint.org/docs/rules/no-mixed-spaces-and-tabs), [keyword-spacing](https://eslint.org/docs/rules/keyword-spacing), [comma-style](https://eslint.org/docs/rules/comma-style)…

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it’s not possible for the programmer to make a mistake there anymore :)

**Code-quality rules**: eg [no-unused-vars](https://eslint.org/docs/rules/no-unused-vars), [no-extra-bind](https://eslint.org/docs/rules/no-extra-bind), [no-implicit-globals](https://eslint.org/docs/rules/no-implicit-globals), [prefer-promise-reject-errors](https://eslint.org/docs/rules/prefer-promise-reject-errors)…

ESLint helps us to be align with those rules. They are also the most important ones as they catch real bugs with your code!

In other words, use **Prettier for formatting** and **ESLint for catching bugs!**

### Prettier

https://prettier.io/

Prettier is an opinionated code formatter with support for:

- JavaScript (including experimental features)
- [JSX](https://facebook.github.io/jsx/)
- [Angular](https://angular.io/)
- [Vue](https://vuejs.org/)
- [Flow](https://flow.org/)
- [TypeScript](https://www.typescriptlang.org/)
- CSS, [Less](http://lesscss.org/), and [SCSS](https://sass-lang.com)
- [HTML](https://en.wikipedia.org/wiki/HTML)
- [JSON](https://json.org/)
- [GraphQL](https://graphql.org/)
- [Markdown](https://commonmark.org/), including [GFM](https://github.github.com/gfm/) and [MDX](https://mdxjs.com/)
- [YAML](https://yaml.org/)

Prettier enforces a consistent code style (i.e. code formatting that won’t affect the AST) across your entire codebase because it disregards the original styling* by parsing it away and re-printing the parsed AST with its own rules that take the maximum line length into account, wrapping code when necessary.

Prettier also provides [options](https://prettier.io/docs/en/options.html) to adjust it according to your need.

```bash
npm install --save-dev --save-exact prettier
echo {}> .prettierrc.json
npx prettier --write . # format the code
npx prettier --check . # check formatting of the code
```

### ESLint

https://eslint.org/

> ESLint statically analyzes your code to quickly find problems. ESLint is built into most text editors and you can run ESLint as part of your continuous integration pipeline.
>
> Many problems ESLint finds can be automatically fixed. ESLint fixes are syntax-aware so you won't experience errors introduced by traditional find-and-replace algorithms.
>
> Preprocess code, use custom parsers, and write your own rules that work alongside ESLint's built-in rules. You can customize ESLint to work exactly the way you need it for your project.

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs. Like Prettier, ESLint also comes with its set of [rules](https://eslint.org/docs/rules/).

It also provides [integrations](https://eslint.org/docs/user-guide/integrations) with editors, which will help you identify issues faster.

```bash
npm install eslint --save-dev
npx eslint --init
npx eslint yourfile.js # check for lint errors
npx eslint --fix yourfile.js # fix all auto-fixable lint errors
```

## Commit, Changelog and Releases

When it comes to generating changelog and/or releases, commit messages play a crucial role to achieve it in an automated way. Let's see which tools help us for it:

### Commitizen

http://commitizen.github.io/cz-cli/

> Simple commit conventions for internet citizens.

Commitizen helps you to keep your commit messages in a standard format. It follows the [Angular commit convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines).

Formatted commit messages also help in generating changelogs.

```bash
npm install commitizen -g
commitizen init cz-conventional-changelog --save-dev --save-exact
npx cz # run this instead of git commit
```

Example of commit messages:

![Commit messages generated using commitizen ](https://cdn.hashnode.com/res/hashnode/image/upload/v1600670580238/L2juSCe0b.png)

### Standard Version

{% github https://github.com/conventional-changelog/standard-version no-readme %}

> 🏆 Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org

`standard-version` will do the following:

1. Retrieve the current version of your repository by looking at `bumpFiles`, falling back to the last `git tag`.
2. `bump` the version in `bumpFiles` based on your commits.
3. Generates a `changelog` based on your commits (uses [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) under the hood).
4. Creates a new `commit` including your `bumpFiles` and updated CHANGELOG.
5. Creates a new `tag` with the new version number.

```bash
npx standard-version --first-release

# When you are ready, push the git tag and npm publish your first release
```

### Semantic Release

https://semantic-release.gitbook.io/

> Fully automated version management and package publishing

If you're using this, there is no need of using standard-version, because semantic-release takes care of everything.

**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.

It enforces [Semantic Versioning](https://semver.org/) specification. This can also be integrated with your [continuous integration workflow](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations).

Initially, you may find it somewhat difficult to setup semantic-release in your CI flow. But, once you have successfully done it, it's really worth.

This also has number of [plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list). This allows for support of different commit message formats, release note generators and publishing platforms.

```bash
cd your-module
npx semantic-release-cli setup
```

## Documentation

> Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
>
> Writing things down makes it easier to say no when something doesn’t fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
>
> Even if you don’t use full paragraphs, jotting down bullet points is better than not writing at all.
>
> Remember to keep your documentation up-to-date. If you’re not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.

Let's take a look at some documentation helper tools:

### Make a README

https://www.makeareadme.com/

A README is a text file that introduces and explains a project. It contains information that is commonly required to understand what the project is about.

Make a README will help you generate the very initial README file. Change it as you move ahead in your project journey.

### readme-md-generator

{% github https://github.com/kefranabg/readme-md-generator no-readme %}

> CLI that generates beautiful README.md files.

readme-md-generator will suggest you default answers by reading your `package.json` and `git` configuration.

```bash
npx readme-md-generator
```

### Badges - Shields.io

https://shields.io/

> Concise, consistent, and legible badges in SVG and raster format

Shields.io is a service for concise, consistent, and legible badges in SVG and raster format, which can easily be included in GitHub readmes or any other web page. The service supports dozens of continuous integration services, package registries, distributions, app stores, social networks, code coverage services, and code analysis services. Every month it serves over 470 million images.

It has been a one and only go-to place to generate badges in the most of open-source projects.

Including it in markdown (most probably `README.md` file) is pretty easy:

```markdown
<!-- Format -->
![Alt](https://img.shields.io/badge/<LABEL>-<MESSAGE>-<COLOR>)

<!-- Sample -->
![sample badge](https://img.shields.io/badge/sample-badge-brightgreen)
```

Output of above sample badge is below:

![sample badge](https://img.shields.io/badge/sample-badge-brightgreen)

### License

https://choosealicense.com/

> Public repositories on GitHub are often used to share open source software. For your repository to truly be open source, you'll need to license it so that others are free to use, change, and distribute the software.

A software license tells others what they can and can't do with your source code, so it's important to make an informed decision.

Github has created <https://choosealicense.com/> to help you understand how to license your code. The [Open Source Guide](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project) provides additional guidance on choosing the correct license for your project.

### Contributing Guidelines

A `CONTRIBUTING.md` file, in your open source repository or site, provides potential project contributors with a short guide to how they can help with your project or study group. It is convention to capitalize the word "contributing" as the file title, and to save it as a resource in markdown (hence the extension .md).

A nice guideline and template is provided at:

{% github https://github.com/nayafia/contributing-template no-readme %}

Github's Atom's [CONTRIBUTING.md](https://github.com/atom/atom/blob/master/CONTRIBUTING.md) is considered as one of the best example.

### All Contributors

https://allcontributors.org/

> Recognize All Contributors. Including those that don't push code.

This is a specification for recognizing contributors to an open source project in a way that rewards each and every contribution, not just code.

The basic idea is this:

> Use the project README (or another prominent public documentation page in the project) to recognize the contributions of members of the project community.

People are giving themselves and their free time to contribute to open source projects in so many ways, so they believe everyone should be praised for their contributions (code or not).

They highlight contribution area through [emojis](https://allcontributors.org/docs/en/emoji-key). Like 🐛 is for bug, 📝 is for blog, 📖 is for doc, 👀 is for review, etc. Fancy huh 😉!

It generates a table like below:

![contributors-table-small.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1600664582123/bPbZiIkyX.png)

They have a [bot](https://allcontributors.org/docs/en/bot/installation), which is recommended way. You can also achieve the same using CLI:

```bash
npm i -D all-contributors-cli
npx all-contributors init

# add contributor
npx all-contributors add

# generate table
npx all-contributors generate
```

### Contributor Covenant

https://www.contributor-covenant.org/

> A Code of Conduct for Open Source Projects

Adopting the Contributor Covenant can be one way to express and codify values and signal your intention to make your open source community welcoming, diverse, inclusive, and equitable.

You can take the content from [code_of_conduct.md](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md) or you can use CLI to generate the one:

```bash
npm install -g covgen; covgen "<your_email_address>";
```

## GitHub Issues & PRs Templates

{% github https://github.com/devspace/awesome-github-templates no-readme %}

This is a curated list of templates that can offer inspiration for your project. An awesome template is one that informs contributors how to proceed in a very detailed or unique way.

You need to create 2 files for the same in your project directory:

1. `.github/PULL_REQUEST_TEMPLATE.md`
2. `.github/ISSUE_TEMPLATE.md`

Below is one sample of issue template from their list:

```markdown
### Subject of the issue
Describe your issue here.

### Your environment
* version of angular-translate
* version of angular
* which browser and its version

### Steps to reproduce
Tell us how to reproduce this issue. Please provide a working demo, you can use [this template](https://plnkr.co/edit/XorWgI?p=preview) as a base.

### Expected behaviour
Tell us what should happen

### Actual behaviour
Tell us what happens instead
```

And below is sample of pull request template:

```markdown
### Your checklist for this pull request
🚨Please review the [guidelines for contributing](../CONTRIBUTING.md) to this repository.

- [ ] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). Don't request your master!
- [ ] Make sure you are making a pull request against the **canary branch** (left side). Also you should start *your branch* off *our canary*.
- [ ] Check the commit's or even all commits' message styles matches our requested structure.
- [ ] Check your code additions will fail neither code linting checks nor unit test.

### Description
Please describe your pull request.

💔Thank you!
```

You can also find more issue templates at:

{% github https://github.com/stevemao/github-issue-templates no-readme %}

# Other Guides

The open-source community is so wonderful that it has already provided a list of guides. Teams like [Github](https://github.com/) and [Mozilla](https://www.mozilla.org/en-US/) has came up with such guides.

## Open Source Guide

http://opensource.guide/

> Open source software is made by people just like you. Learn how to launch and grow your project.

Open Source Guides <https://opensource.guide/> are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project.

## Mozilla Science Lab - Working Open Workshop

[![Mozilla Science Lab - Working Open Workshop](https://cdn.hashnode.com/res/hashnode/image/upload/v1600667896982/X14KQU_Mc.png)](http://mozillascience.github.io/working-open-workshop/)

Mozilla Science Lab conducted a training session to make the most effective open projects possible, and build active communities of contributors around them.

They have around 10 minutes of presentation on around 9 topics. So, it would take around one and half hour to complete all.

## Welcoming Open Source Project Metrics

https://wospm.info/

> WOSPM (Welcoming Open Source Project Metrics) organization is for creating and maintaining documents and tools to measure how an open source project welcomes users as possible contributor

They have this really cool checklist called [WOSPM Checklist](https://checklist.atolye15.com/checklist/wospm-checklist). A checklist by WOSPM organization for project owners to measure their open source project if it is a welcoming project or not. The checklist is created based on the Open Source Guides.

---

# Conclusion

We saw fantastic set of tools and guidelines, which help open-source project maintainers to maintain quality of their code and also make their documents easier to read for contributors.

Let me know if you or your team uses any other tools which can be helpful in open-source project journey.

#### Credits

Some of the content is based on [github.com/github/opensource.guide](https://github.com/github/opensource.guide), [the Mozilla Science Lab and contributors](https://github.com/mozillascience/working-open-workshop/blob/gh-pages/LICENSE.md) used under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) license.