newpipe-documentation/09_maintainers_view/index.html

274 lines
15 KiB
HTML
Raw Normal View History

<!DOCTYPE html>
<html class="writer-html5" lang="en" >
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="shortcut icon" href="../img/favicon.ico" />
<title>Maintainers' Section - NewPipe Development Documentation</title>
<!-- local fonts -->
<link rel="stylesheet" href="../css/local_fonts.css" type="text/css" />
<link rel="stylesheet" href="../css/theme.css" type="text/css" />
<link rel="stylesheet" href="../css/theme_extra.css" type="text/css" />
<link rel="stylesheet" href="../css/theme_child.css" type="text/css" />
<!-- local code syntax highlighting -->
<link rel="stylesheet" href="../css/github.min.css" type="text/css" />
<link rel="stylesheet" href="../css/highlight.css" type="text/css" />
<script>
// Current page data
var mkdocs_page_name = "Maintainers\u0027 Section";
var mkdocs_page_input_path = "09_maintainers_view.md";
var mkdocs_page_url = null;
</script>
<script src="../js/jquery-2.1.1.min.js" defer></script>
<script src="../js/modernizr-2.8.3.min.js" defer></script>
<script src="../js/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body class="wy-body-for-nav" role="document">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side stickynav">
<div class="wy-side-scroll">
<div class="wy-side-nav-search">
<a href=".." class="icon icon-home"> NewPipe Development Documentation
</a><div role="search">
<form id ="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" title="Type search term here" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
<ul>
<li class="toctree-l1"><a class="reference internal" href="..">Welcome to the NewPipe Development Docs</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../00_Prepare_everything/">Before You Start</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../01_Concept_of_the_extractor/">Concept of the Extractor</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../02_Concept_of_LinkHandler/">Concept of the LinkHandler</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../03_Implement_a_service/">Implementing a Service</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../04_Run_changes_in_App/">Testing Your Changes in the App</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../05_Mock_tests/">Mock Tests</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../06_releasing/">Releasing a New NewPipe Version</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../07_release_instructions/">Release instructions for normal releases</a>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../08_documentation/">About This Documentation</a>
</li>
</ul>
<ul class="current">
<li class="toctree-l1 current"><a class="reference internal current" href="./">Maintainers' Section</a>
<ul class="current">
<li class="toctree-l2"><a class="reference internal" href="#keep-it-streamlined">Keep it Streamlined</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#bugfixes">Bugfixes</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#features">Features</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#pull-requests">Pull Requests</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#community">Community</a>
</li>
<li class="toctree-l2"><a class="reference internal" href="#managing-translations-via-weblate">Managing translations via Weblate</a>
<ul>
<li class="toctree-l3"><a class="reference internal" href="#update-weblate">Update Weblate</a>
</li>
<li class="toctree-l3"><a class="reference internal" href="#merge-changes-from-weblate-into-newpipe">Merge changes from Weblate into NewPipe</a>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" role="navigation" aria-label="Mobile navigation menu">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="..">NewPipe Development Documentation</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content"><div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href=".." class="icon icon-home" alt="Docs"></a> &raquo;</li>
<li>Maintainers' Section</li>
<li class="wy-breadcrumbs-aside">
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div class="section" itemprop="articleBody">
<h1 id="maintainers-section">Maintainers' Section</h1>
<p>These are some basic principles that we want maintainers to follow when maintaining NewPipe.</p>
<h3 id="keep-it-streamlined">Keep it Streamlined</h3>
<p>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.
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
code, however in essence NewPipe should be easy to use, even for an average Android user.</p>
<ol>
<li><strong>Don't add too many special
features.</strong> 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 <strong>media player</strong> for the end user, and only as such. </li>
<li><strong>Usability of the user interface should be prioritized.</strong> Try to make it comply with
<a href="https://material.io/design/guidelines-overview/">material design guidelines</a>.</li>
</ol>
<h3 id="bugfixes">Bugfixes</h3>
<p><img alt="kde_in_a_nutshell" src="../img/kde_in_a_nutshell.jpg" />]</p>
<p><em>Disclaimer: This is a meme. Please don't take it personally.</em></p>
<p><strong>Always prioritize fixing bugs</strong>, 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 break. This
is one reason why NewPipe still has no "1" in the beginning of its version
number.
By now, NewPipe is in a stage where there should be a strong focus on
stability.</p>
<ol>
<li>If there are multiple Pull Requests open, check the ones with bugfixes first.</li>
<li>Do not add too many features every version, as every feature will inevitably
introduce more bugs. It is OK if PRs remain open for a while, but don't leave them open for too long.</li>
<li>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.</li>
<li>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.</li>
</ol>
<h3 id="features">Features</h3>
<p>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:</p>
<ul>
<li>Was the feature requested by only a few, or by many?<ul>
<li>Avoid introducing niche features to satisfy a small handful of users.</li>
</ul>
</li>
<li>Was the code rushed and messy, and could a cleaner solution be made? <ul>
<li>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.</li>
</ul>
</li>
<li>Does the amount of code justify the feature's purpose? <ul>
<li>Use critical thinking when considering new features and question
whether that features makes sense, is useful, and if it would benefit NewPipe's users.</li>
</ul>
</li>
</ul>
<h3 id="pull-requests">Pull Requests</h3>
<p>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.</p>
<h3 id="community">Community</h3>
<p>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 our experience ;D ).</p>
<h3 id="managing-translations-via-weblate">Managing translations via Weblate</h3>
<p>NewPipe is translated via <a href="https://hosted.weblate.org/projects/newpipe">Weblate</a>.
There are two different components which are open for translation:</p>
<ul>
<li>The app <a href="https://hosted.weblate.org/projects/newpipe/strings/"><code>strings</code></a>.</li>
<li>The fastlane <a href="https://hosted.weblate.org/projects/newpipe/metadata/">metadata</a>;
this includes the F-Droid store description and changelogs.</li>
</ul>
<p>Maintainers can access more options to handle Weblate via the
<a href="https://hosted.weblate.org/projects/newpipe/#repository">Manage &gt; Repository Maintenance</a> button
or via the <a href="https://docs.weblate.org/en/latest/wlc.html#wlc">Weblate CLI</a>. These options include
basic access to Git operations like commit and rebase
as well as locking Weblate to prevent further changes to translations.</p>
<p><a href="https://hosted.weblate.org/projects/newpipe/#repository"><img alt="Weblate Web Interface" src="../img/weblate.png" /></a>
<code>HINT: When updating Weblate via the web interface, please use the "Update &gt; Rebase" option.</code></p>
<h4 id="update-weblate">Update Weblate</h4>
<p>Weblate is based on NewPipe's <code>dev</code> branch and is configured to automatically update its repository to be in sync with NewPipe.
However, Weblate does not update its branch often, therefore it is better to update it manually after changing strings in NewPipe.</p>
<p>To do thus manually, commit the Weblate changes and rebase the repository.
Sometimes conflicts need to be resoled while rebasing the repository.
Conflicts need to be addressed ASAP, because Weblate is automatically locked once conflicts occur.
To do so, <a href="#merge-changes-from-weblate-into-newpipe">merge the changes from Weblate into NewPipe</a>.
If Weblate does not recognize the new commit by itself, ask Weblate to rebase once more.
Weblate unlocks the translations when all conflicts are resolved and no errors are detected.</p>
<h4 id="merge-changes-from-weblate-into-newpipe">Merge changes from Weblate into NewPipe</h4>
<p>Weblate does not push the translation changes to NewPipe automatically.
Doing this manually, allows the maintainers to do a quick review of the changes.</p>
<p>Before merging weblate changes into NewPipe, make sure to commit all Weblate changes and
lock the Weblate to prevent modifications while you update Weblate.
To merge the changes into NewPipe, checkout Weblate's <code>dev</code> branch.
You have read access to Weblate's repository via <code>https://hosted.weblate.org/git/newpipe/strings/</code>.
If there are conflicts when rebasing weblate, resolve them.</p>
<p>Check the following things:
- Is there a translation for a new language? If yes, <a href="https://github.com/TeamNewPipe/NewPipe/pull/5721">register the language with the app's langauge selector</a>
- Use <code>Analyse &gt; Inspect Code</code> in Android Studio to find unused strings and potential bugs introduced by Weblate.
Pay attention to plurals in Asian languages. They are broken by Weblate on a regular basis.</p>
<p>Push the changes to NewPipe's <code>dev</code> branch, <a href="#update-weblate">update Weblate</a> and unlock it.</p>
</div>
</div><footer>
<div class="rst-footer-buttons" role="navigation" aria-label="Footer Navigation">
<a href="../08_documentation/" class="btn btn-neutral float-left" title="About This Documentation"><span class="icon icon-circle-arrow-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<!-- Copyright etc -->
</div>
Built with <a href="https://www.mkdocs.org/">MkDocs</a> using a <a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<div class="rst-versions" role="note" aria-label="Versions">
<span class="rst-current-version" data-toggle="rst-current-version">
<span><a href="../08_documentation/" style="color: #fcfcfc">&laquo; Previous</a></span>
</span>
</div>
<script>var base_url = '..';</script>
<script src="../js/theme_extra.js" defer></script>
<script src="../js/theme.js" defer></script>
<script src="../search/main.js" defer></script>
<script defer>
window.onload = function () {
SphinxRtdTheme.Navigation.enable(true);
};
</script>
</body>
</html>