be-gay-do-crimes
/
newpipe-documentation
mirror of https://github.com/TeamNewPipe/documentation
1
0
Fork 0
Code Issues Releases Wiki Activity

Redo changes

This commit is contained in:
snappyapple632 2019-08-17 13:53:07 -07:00
parent fc45bb4caa
commit 02d020fe7e
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/07_maintainers_view.md
View File

@ -1,19 +1,19 @@
# Maintainers' Section # Maintainers' Section
These are some basic principles that I want maintainers to follow when maintaining NewPipe. These are some basic principles that we want maintainers to follow when maintaining NewPipe.
### Keep it Streamlined ### Keep it Streamlined
NewPipe is a media player for smartphones on the Android platform, thus it is intended to be used for entertainment. This means it does not have to be some professional NewPipe is a media player for devices on the Android platform, thus it is intended to be used for entertainment. This means it does not have to be some professional
application, and it does not have to be complicated to be used. application, and it does not have to be complicated to be used.
However NewPipe might not focus on the casual user completely as there are However NewPipe might not focus on the casual user completely as there are
some features designed for more experienced users which may require some knowledge about some features designed for more experienced users which may require some knowledge about
code, however in essence NewPipe should be easy to use, even for your average Android user. code, however in essence NewPipe should be easy to use, even for your average Android user.
1. __Don't add too many special 1. __Don't add too many special
features.__ NewPipe does not have to be an air plane cockpit. Do not try to fill every single niche that might exist. If people wanted more advanced features, they features.__ NewPipe does not have to be an airplane cockpit. Do not try to fill every single niche that might exist. If people wanted more advanced features, they
would use professional tools. If you add too much functionality, you add complexity, and complexity scares away the average user. Focus on NewPipe's scope as a **media player** for the end user, and only as such. would use professional tools. If you add too much functionality, you add complexity, and complexity scares away the average user. Focus on NewPipe's scope as a **media player** for the end user, and only as such.
2. __Usability of the user interface should be priorized.__. Try to make it comply with 2. __Usability of the user interface should be prioritized.__ Try to make it comply with
[material design guidelines](https://material.io/design/guidelines-overview/). [material design guidelines](https://material.io/design/guidelines-overview/).
@ -21,7 +21,7 @@ code, however in essence NewPipe should be easy to use, even for your average An
![kde_in_a_nutshell](img/kde_in_a_nutshell.jpg)] ![kde_in_a_nutshell](img/kde_in_a_nutshell.jpg)]
*Disclaimer: This is a meme. Don't take it personally.* *Disclaimer: This is a meme. Please don't take it personally.*
__Always prioritize fixing bugs__, as the best application with the best features __Always prioritize fixing bugs__, as the best application with the best features
does not help much if it is broken, or annoying to use. Now if a program does not help much if it is broken, or annoying to use. Now if a program
@ -33,10 +33,10 @@ code, however in essence NewPipe should be easy to use, even for your average An
1. If there are multiple Pull Requests open, check the ones with bugfixes first. 1. If there are multiple Pull Requests open, check the ones with bugfixes first.
2. Do not add too many features every version, as every feature will inevitably 2. Do not add too many features every version, as every feature will inevitably
introduce more bugs. It is OK if PRs stay open for a while, but don't leave them open for too long. introduce more bugs. It is OK if PRs remain open for a while, but don't leave them open for too long.
3. If there are bugs that are stale, or open for a while bump them from time 3. If there are bugs that are stale, or open for a while bump them from time
to time, so devs know that there is still something left to fix. to time, so devs know that there is still something left to fix.
4. Never merge PRs with known issues. From my perception the community does not like to fix bugs, this is why you as a maintainer should 4. Never merge PRs with known issues. From our perception the community does not like to fix bugs, this is why you as a maintainer should
especially focus on pursuing bugs. especially focus on pursuing bugs.
@ -64,7 +64,7 @@ There also might be things that seem to not have any issues, but other things wi
### Community ### Community
When you talk to the community, stay friendly and respectful with good etiquette. When you talk to the community, stay friendly and respectful with good etiquette.
When you have a bad day, just don't go to GitHub (advice from my experience ;D ). When you have a bad day, just don't go to GitHub (advice from our experience ;D ).