How to Contribute to restic

Updated

restic is an open-source project, and contributions are welcome. The project's own site states that contributions are welcome and points to the restic contribution guidelines for details. If you want to contribute, the practical starting point is to read those guidelines, then use the project's GitHub presence for code, issues, and collaboration. The site also notes a design document that describes restic's design and the data structures it stores on disk — useful reading before changing anything that touches repository formats or backup logic.

Where contributions happen

The restic website lists GitHub as the project's code home and links to a contribution guidelines document. It also mentions a design document covering restic's design and on-disk data structures. Those two documents are the natural first stop: the guidelines tell you how the project expects contributions to be made, and the design document gives you the background needed to make changes that fit the existing architecture.

Ways to contribute

The site's contribution section is brief, but the surrounding structure of the project suggests several concrete paths:

  • Code — via the GitHub project, following the contribution guidelines.
  • Documentation — the site links to both a released-version manual and a development-version manual, so documentation changes are part of the project's surface area.
  • Bug reports and feature suggestions — the site explicitly invites opening a GitHub issue for bugs or feature ideas, and asks that you fill out the issue template you are shown.
  • Design and data-structure work — the design document is the reference for how restic is built and how it stores data, which matters for any change affecting repositories.

Before you start: compatibility matters

restic follows Semantic Versioning, and the project treats the repository and the data structures inside it as the "Public API." The site states that once version 1.0.0 is released, backward compatibility of all repositories within one major version is guaranteed — as long as the major version is not incremented, data can be read and restored. The project also says it strives to be fully backward compatible with all prior versions. During initial development (versions before 1.0.0), maintainers and developers do their utmost to keep backward compatibility and stability, though breaking changes are possible without a major version increase.

That context matters for contributors: changes that affect how backups are stored or restored carry compatibility implications, so the design document and contribution guidelines are not optional background reading.

Getting help and asking questions

The site separates support from development:

  • Usage or support questions go to the forum.
  • Bugs or feature suggestions go to GitHub issues, using the issue template.
  • Contact — the site lists several ways to reach the project and its community, with the forum and GitHub issues being the two named channels for questions and bug reports respectively.

If you are unsure whether something is a bug or a usage question, the split above is the project's own guidance: usage questions to the forum, defects and ideas to GitHub.

A practical first contribution path

  1. Read the contribution guidelines linked from the restic site.
  2. Read the design document if your change touches how data is stored or restored.
  3. Check the compatibility rules above so you understand what can and cannot change within a major version.
  4. Open a GitHub issue for a bug or feature idea, filling out the template.
  5. Ask usage questions in the forum rather than the issue tracker.

The site does not describe a more detailed contribution workflow beyond pointing to the guidelines, so the guidelines themselves are the authoritative next step.