forked from TeamNewPipe/documentation
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
3e81f09
commit 051f8a8
Showing
1 changed file
with
37 additions
and
45 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,78 +1,70 @@ | ||
| # Maintainers View | ||
| # Maintainers' Section | ||
|
|
||
| So I want to document some of the views i have when maintaining NewPipe. | ||
| These are some basic principles that I want maintainers to follow when maintaining NewPipe. | ||
|
|
||
|
|
||
| ### Keep it Streamlined | ||
| NewPipe is a Player for online videos on a smart phone, by means it is used | ||
| for entertainment reason. This means it does not have to be some professional | ||
| 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 | ||
| 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 | ||
| many features that are a bit more "tecki" and may require some knowledge about | ||
| technology, however all in all NewPipe should be easy to use, even for not teck | ||
| guys. | ||
|
|
||
| 1. NewPipe does not have to be a air plane cockpit: __Don't add to much special | ||
| features__. If people want to do professionally things with Videos they | ||
| might use professional tools. | ||
| 2. __Design the UI so it does make sense to the user__. Try to make it comply with | ||
| many features that are a bit more "techy" and may require some knowledge about | ||
| code, however in essence NewPipe should be easy to use, even for your average Android user. | ||
|
|
||
| 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 want 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. | ||
| 2. __Design the UI so that it is easy for the user__. Try to make it comply with | ||
| [material design guidelines](https://material.io/design/guidelines-overview/). | ||
| 3. __Don't add to much features__: Think about the Betamax vs. VHS phenomena | ||
| or the Unix principle of having one program designed for one specific task: | ||
| If you add to much functionality you add complexity and this is not appealing | ||
| to the user. Focus on what NewPipe should be, and make it be only that. | ||
|
|
||
|
|
||
| ### Bugfixes | ||
|
|
||
| ] | ||
|
|
||
| *Disclaimer: This is a meme maybe in real live it is different. Pleas no shit storm.* | ||
| *Disclaimer: This is a meme. Don't take it personally.* | ||
|
|
||
| __Always go for Bugfixes__, 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 | ||
| is in an early stage it is quite understandable that many things brake. This | ||
| is one reason why NewPipe still has no 1 in the beginning of its version | ||
| is in an early stage it is quite understandable that many things break. This | ||
| is one reason why NewPipe still has no "1" in the beginning of its version | ||
| number. | ||
| However by now NewPipe is in a stage where there should be a strong focus on | ||
| By now, NewPipe is in a stage where there should be a strong focus on | ||
| stability. | ||
|
|
||
| 1. If there are multiple Pull requests open, check the ones with the bugfixes first. | ||
| 2. Do not add to much features every version, as every feature will inevitable | ||
| introduce more bugs. It is quite ok, if PRs stay open for a while (not to long though). | ||
| 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 | ||
| introduce more bugs. It is OK if PRs stay 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 | ||
| to time, so devs know that there is still something left to fix. | ||
| 4. Never accept bugs. From my perception the community does not like to fix bugs, this is why you as a maintainer should | ||
| especially focus on perusing bugs. | ||
| 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 | ||
| especially focus on pursuing bugs. | ||
|
|
||
|
|
||
| ### Features | ||
|
|
||
| Well features are also something that can cause a headache. You should always see adding features critical and question | ||
| whether that features does make sense, is useful and would actually be an advantage for the app. You should not blindly | ||
| say yes to features even if they are small, however you should also not directly say no as well. Think about it, may | ||
| be even for days before deciding whether you want to accept a feature or not. If you are not sure, try it, look into the | ||
| code, speak with the developer, and then make a decision and justify it. The criteria whether to add a feature or not | ||
| should be: | ||
| Features are also something that can cause a headache. You should not blindly | ||
| say yes to features, even if they are small, but you should also not immediately say no. If you are not sure, try the feature, look into the | ||
| code, speak with the developer, and then make a decision. When considering a feature, ask yourself the following questions: | ||
|
|
||
| - Was the feature requested by only a few, or by many? | ||
| - Avoid introducing niche features to satisfy a small handful of users. | ||
| - Was the code rushed and messy, and could a cleaner solution be made? | ||
| - A pull request that adds a frequently requested feature could implement the feature in a messy way. Such PRs should not be merged as it will likely cause problems later down the line, either through problems of extending the feature by introducing many bugs, or simply by breaking the architecture or the philosophy of NewPipe. | ||
| - Does the amount of code justify the feature's purpose? | ||
| - Use critical thinking when considering new features and question | ||
| whether that features makes sense, is useful, and if it would benefit NewPipe's users. | ||
|
|
||
| - Is the features just requested by one or two people or was the feature requested by multiple people? | ||
| - Is the code of the feature written well? | ||
| - Is it a quick and hacky solution and could a proper solution be implemented later on? | ||
| - Does the amount of code justify the outcome? | ||
|
|
||
| Maybe people will send a pull request that will add a frequently requested feature, but is implemented in a hacky way, | ||
| than don't add it, as you might get into trouble with that solution later on. Either through problems of extending the | ||
| feature, by introducing to much bugs or simply by braking the architecture or the philosophy of NewPipe. If so don't add it. | ||
|
|
||
| ### PRs | ||
| ### Pull Requests | ||
|
|
||
| If a PR contains one or more features/bugs be curious. The more stuff a PR changes the longer it will take to be added. | ||
| Also there might be things you are ok with, but then there are other parts that are not ok with and because of these you | ||
| can't merge it. This is why you should insist to make the dev chop down the PR into multiple smaller PRs if it's possible. | ||
| If a PR contains more than one feature/bugfix, be cautious. The more stuff a PR changes, the longer it will take to be added. | ||
| There also might be things that seem to not have any issues, but other things will, and this would prevent you from merging a PR. This is why it is encouraged to keep one change per pull request, and you should insist that contributors divide such PRs into multiple smaller PRs when possible. | ||
|
|
||
| ### Community | ||
|
|
||
| When you talk to the community stay friendly and respectful, and make sure a friendly and respectful tone will stay. | ||
| When you have a bad day just don't go to GitHub (an advice from my experience ;D ). | ||
| 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 ). | ||
|
|
||
|
|
||
|
|