Cutlery/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2025-07-09 03:04:24 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Contributing to Jellyfin (markdown)

Joshua M. Boniface 2018-12-30 16:21:28 -05:00
parent 139cb390dc
commit 1314f98274
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Contributing-to-Jellyfin.md

@ -32,7 +32,7 @@ We adhere to a fairly standard fork-and-PR model of development:
3. Submit a pull request from your feature branch back to the upstream `dev` branch. PRs that target `master` will be changed to target `dev`, so please double-check this when submitting. 3. Submit a pull request from your feature branch back to the upstream `dev` branch. PRs that target `master` will be changed to target `dev`, so please double-check this when submitting.
Please ensure you provide a detailed explanation, in each pull request discription, of what problems the PR solves (with action keywords and links to issue numbers if possible), and how the PR solves them. This aids both in review, as well as in future understanding of why a given set of changes were made. More detail is always better here. Also please ensure that if your issue fixes an issue (or several issues), that you explicitly reference this, preferably with the `closes` or `fixes` keywords, e.g. `Closes #199`. Please ensure you provide a detailed explanation, in each pull request discription, of what problems the PR solves (with action keywords and links to issue numbers if possible), and how the PR solves them. This aids both in review, as well as in future understanding of why a given set of changes were made. More detail is always better here. Also please ensure that if your issue fixes an issue (or several issues), that you explicitly reference this, preferably with the `closes` or `fixes` keywords, e.g. `Closes #199`, in the original description.
All PRs to the `develop` branch require review by at least 1 member of the core team. Once that is done, if the PR is not tagged with the WIP label, it should be merged by the reviewer if able. We do however encourage reviews from any contributor as more eyes always helps. All PRs to the `develop` branch require review by at least 1 member of the core team. Once that is done, if the PR is not tagged with the WIP label, it should be merged by the reviewer if able. We do however encourage reviews from any contributor as more eyes always helps.