~satchmo/bytes

a365aa63f35d6ece3304c1f2a6c2876821d236a2 — Jason Phan 3 years ago 38e0fa9 main
docs: Remove contributing

We GitHub now bois
2 files changed, 0 insertions(+), 121 deletions(-)

M CONTRIBUTING.md
D docs/contributing/workflow.md
M CONTRIBUTING.md => CONTRIBUTING.md +0 -9
@@ 2,12 2,3 @@

Contributions to `bytes` are very welcome! This document provides some
guidelines and information to help you get started.

## Workflow

The project is hosted primarily on Sourcehut, which uses a largely email-driven
workflow. If that is something you're unfamiliar with, head over to the
[Workflow](docs/contributing/workflow.md) page for more information.

The project is also mirrored on GitHub, where you can make issues and pull
requests.

D docs/contributing/workflow.md => docs/contributing/workflow.md +0 -112
@@ 1,112 0,0 @@
# Workflow

Contributing to `bytes` is done primarily through email, which means that if
you have an email address and know how to send emails, you're already familiar
with 90% of `bytes`'s development workflow! The other 10% can be broken down
as follows:

- How do I set up Git to use email?
- Where do I send development emails?
- How do I work with patches?

## How to Set Up Git

To set up Git to use email, follow this super easy [guide](https://git-send-email.io/).

## Where to Send Emails

Now that your Git can send emails, where do you send them? In Sourcehut, you
send them to one of two places:

- **Mailing lists** — Patches and discussions.
- **Trackers** — Issues and feature requests.

The addresses of mailing lists and trackers on Sourcehut all follow the same
convention: `<user>/<name>@(list|todo).sr.ht`, where `<user>` is the username
of the project's owner and `<name>` is the name of the list or tracker. For
example, `bytes`, owned by me (`~satchmo`), has a list at
`~satchmo/bytes-devel@lists.sr.ht` and a tracker at
`~satchmo/bytes@todo.sr.ht`.

There can be multiple mailing lists and trackers for a single project on
Sourcehut, so be sure to check their project page for more information. For
`bytes`, you can find our various mailing lists and trackers below:

- [Mailing Lists](https://sr.ht/~satchmo/bytes/lists)
- [Trackers](https://sr.ht/~satchmo/bytes/trackers)

## How to Send Patches

The general process for patch submission is as follows:

1. Clone the upstream repository.
2. Create a new branch.
3. Make your changes.
4. Commit your changes.
5. **Send out a patch to the appropriate mailing list.**

Step 5 is the only part that may be unfamiliar to users coming from other
workflows, so we'll focus on that.

In short, use `git-send-email`. The command takes care of creating and sending
out patches; all you have to do is tell it where to send and what commits
should be included in the patch:

```sh
git send-email --to="~satchmo/bytes-devel@lists.sr.ht" <patch>
```

Here, `<patch>` is a [revision list](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection).
Generally, you'll either specify a commit ID (e.g., `1066b58`) or an ancestry
reference (e.g., `HEAD^`).

After the patch is sent, a maintainer will review it and push it upstream if
everything checks out. If there's a problem with your patch, simply fix any
issues pointed out and send another version of the patch like so:

```sh
git send-email --to="~satchmo/bytes-devel@lists.sr.ht" -v2 <patch>
```

#### Comments

Often times, you'll want to include comments in a patch but not the final git
log. For instance, you may want to note that a particular patch fixes an issue
raised by a previous version of the patch. To do this, use the `--annotate`
option to open the patch in an editor so that you may modify it:

```sh
git send-email --to="~satchmo/bytes-devel@lists.sr.ht" --annotate -v3 <patch>
```

Once in the editor, add your comments after the `---` mark:

```console
Subject: [PATCH v3] Fix typo in README

---
This fixes issues raised in the second patch.

README.md | 1 +
...
```

#### Cover Letters

For complex changes, multiple patches may be necessary. In such cases, it's
common to have a cover letter to introduce or provide additional context for
the patches. To do so, use the `--cover-letter` option to create a separate
email that will be sent ahead of your patches:

```sh
git send-email --to="~satchmo/bytes-devel@lists.sr.ht" --cover-letter --annotate <patchset>
```

Note that we must also use the `--annotate` option, as we need to edit the
cover letter's "Subject" header appropriately.

## Resources

- For a tutorial on sending patches: [git-send-email](https://git-send-email.io/)
- For general guidelines on email etiquette: [man.sr.ht](https://man.sr.ht/lists.sr.ht/etiquette.md)
- For more information on Git revision lists: [git-scm](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection)