Cutlery/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2025-08-11 09:13:54 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Contributing to Jellyfin (markdown)

Joshua M. Boniface 2019-01-01 15:46:28 -05:00
parent e87b8b3e67
commit f3bcd664cf
1 changed files with 8 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
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? ### 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 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.
author.
## How should you make changes? ## 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 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.
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. 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 ### 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 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.
anch.
1. Rebase your local branches against upstream `master`/`dev`: ```git fetch --all && git rebase upstream/<BRANCH>``` 1. Rebase your local branches against upstream `master`/`dev`: ```git fetch --all && git rebase upstream/<BRANCH>```
1. Create a local feature branch off of `dev`: ```git checkout dev && git checkout -b my-feature``` 1. Create a local feature branch off of `dev`: ```git checkout dev && git checkout -b my-feature```
@ -70,28 +67,22 @@ anch.
### CONTRIBUTORS.md ### 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 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!
eaves GitHub and lets everyone quickly see who's worked on the project for copyright or praise!
### Pull Request guidelines ### 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. 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". * 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. *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. *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 PR.
* 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 * 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.
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.
## The Master branch ## 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 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.
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.
# Other Contributions to Jellyfin # Other Contributions to Jellyfin