diff --git a/Contributing-to-Jellyfin.md b/Contributing-to-Jellyfin.md index 8765806..9526170 100644 --- a/Contributing-to-Jellyfin.md +++ b/Contributing-to-Jellyfin.md @@ -36,13 +36,11 @@ Finally there are a few more issue types to assist in managing the project: ### What if there isn't an issue? -If there isn't already an issue dealing with the changes you want to make, please [create an issue] to track it first, then ensure your PR(s) reference the issue in question. Especially useful for bugs that are found and then fixed by the -author. +If there isn't already an issue dealing with the changes you want to make, please [create an issue] to track it first, then ensure your PR(s) reference the issue in question. Especially useful for bugs that are found and then fixed by the author. ## How should you make changes? -Once you've found something you want to work on or improve, the next step is to make your changes in the code, test them, then submit a PR. This section details how to go about doing that. For simplicity, all examples assume the developer -is operating on Linux with SSH access to GitHub, however the general ideas can be translated to Windows or OSX. +Once you've found something you want to work on or improve, the next step is to make your changes in the code, test them, then submit a PR. This section details how to go about doing that. For simplicity, all examples assume the developer is operating on Linux with SSH access to GitHub, however the general ideas can be translated to Windows or OSX. If you aren't familiar with Git, we recommend the [official documentation](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) to get yourself going. @@ -59,8 +57,7 @@ You should now be ready to begin building or modifying the project. ### Making changes to the repo -Jellyfin uses a "feature branch" model, though usually a feature branch is local to each developer and is integrated in one shot, though in the future project-wide feature branches may become common. This section assumes a local feature br -anch. +Jellyfin uses a "feature branch" model, though usually a feature branch is local to each developer and is integrated in one shot, though in the future project-wide feature branches may become common. This section assumes a local feature branch. 1. Rebase your local branches against upstream `master`/`dev`: ```git fetch --all && git rebase upstream/``` 1. Create a local feature branch off of `dev`: ```git checkout dev && git checkout -b my-feature``` @@ -70,28 +67,22 @@ anch. ### CONTRIBUTORS.md -If it's your first time contributing code, please add yourself to the `CONTRIBUTORS.md` file at the bottom of the `Jellyfin Contributors` section. While GitHub does track this, having the written document makes things clearer if the code l -eaves GitHub and lets everyone quickly see who's worked on the project for copyright or praise! +If it's your first time contributing code, please add yourself to the `CONTRIBUTORS.md` file at the bottom of the `Jellyfin Contributors` section. While GitHub does track this, having the written document makes things clearer if the code leaves GitHub and lets everyone quickly see who's worked on the project for copyright or praise! ### Pull Request guidelines When submitting a new PR, please ensure you do the following things. If you haven't, please read [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) as it is a great resource for writing useful commit messages. * Write a good title that quickly describes what has been changed. For example, "Adds LDAP support to Jellyfin". -* For anything but the most trivial changes (that can be described fully in the title), write a detailed PR body to describe, in detail: +* For anything but the most trivial changes that can be described fully in the title, write a detailed PR body to describe, in detail: 1. *Why* the changes are being made. Reference specific issues with keywords (`fixes`, `closes`, `addresses`, etc.) if at all possible. 1. *How*, in broad strokes, you approached the issue (if applicable) and briefly describe the changes, especially for large PRs. - 1. *Which area* of the project this addresses, to assist in tagging. -* Manually update the target branch from `master` to `dev`; PRs against `master` are only considered in the most exceptional circumstances and all new work should go to `dev`. GitHub does not know this, so you must be explicit with every P -R. -* Expect review and discussion. If you can't back up your changes with a good description and through review, please reconsider whether it should be done at all. All PRs to `dev` require at least one approving review from an administrative - team member, however we welcome and encourage reviews from any contributor, especially if it's in an area you are knowledgeable in. More eyes are always better. +* Manually update the target branch from `master` to `dev`; PRs against `master` are only considered in the most exceptional circumstances and all new work should go to `dev`. GitHub does not know this, so you must be explicit with every PR. +* Expect review and discussion. If you can't back up your changes with a good description and through review, please reconsider whether it should be done at all. All PRs to `dev` require at least one approving review from an administrative team member, however we welcome and encourage reviews from any contributor, especially if it's in an area you are knowledgeable in. More eyes are always better. ## The Master branch -The `master` branch is the current working branch of Jellyfin. Until we reach a first official release with our own versioning, releases are limited to build identifiers (i.g. `3.5.2-X`). Each update to `master` occurs through a roll-up PR - made by an admin team member, on a semi-regular basis, which will identify the relevant PRs (and issues) that are fixed and help ensure there is a consistent trail of development work in the history. `master` merges must be approved by tw -o administrative team members, thus ensuring a majority of the team accepts the changes. +The `master` branch is the current working branch of Jellyfin. Until we reach a first official release with our own versioning, releases are limited to build identifiers (i.g. `3.5.2-X`). Each update to `master` occurs through a roll-up PR made by an admin team member, on a semi-regular basis, which will identify the relevant PRs (and issues) that are fixed and help ensure there is a consistent trail of development work in the history. `master` merges must be approved by two administrative team members, thus ensuring a majority of the team accepts the changes. # Other Contributions to Jellyfin