Merge pull request #12341 from nextcloud/fix/archaic-wording

susnux · web-flow · commit aed434546d08 · 2024-11-11T12:48:01.000+01:00
fix(developer): Rephrase some parts to avoid archaic wording
diff --git a/developer_manual/design/introduction.rst b/developer_manual/design/introduction.rst
@@ -4,16 +4,21 @@
 Introduction
 ============
 
-Nextcloud design and brand standards are used to maintain the identity of Nextcloud apps. If you're a developer who wants to create or contribute to a Nextcloud app, following this guide will make sure your app looks like it belongs to the Nextcloud family.
+Nextcloud design and brand standards are used to maintain the identity of Nextcloud apps.
+If you're a developer who wants to create or contribute to a Nextcloud app, following this guide will make sure your app looks like it belongs to the Nextcloud family.
 
-Each Nextcloud app is unique and different, but there are a couple of standards that are used in everything. All Nextcloud apps are built keeping some basic principles in mind.
+Each Nextcloud app is unique and different, but there are a couple of standards that are used in everything.
+All Nextcloud apps are built keeping some basic principles in mind.
 
 
 * Software should be quick and easy to use. Show only the most important elements. Secondary elements can be showed on hover or via an "Advanced" function.
 * Nextcloud apps are built for everybody. Use a friendly tone with simple sentences. Make sure your app is responsive and runs on all browsers and devices.
 * Accessibility: Make sure to regularly test accessibility, for example with `Lighthouse <https://developers.google.com/web/tools/lighthouse>`_\ , `WAVE <https://wave.webaim.org/>`_\ , and `Google Accessibility Scanner <https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditor>`_. Aim for WCAG Level AA. You can learn more about accessibility standards in the `W3 website <https://www.w3.org/WAI/standards-guidelines/wcag/glance/>`_
-* Software should work. Only put features into master when they are complete. It is better to not have a feature instead of having one that works poorly.
-* Software should get out of the way. Do things automatically instead of offering configuration options. When people ask for a setting, find out what the root of the problem is and fix that instead. Also read `Choosing our Preferences <http://ometer.com/preferences.html>`_.
+* Software should work.
+  Only put features into main branch when they are complete. It is better to not have a feature instead of having one that works poorly.
+* Software should get out of the way.
+  Do things automatically instead of offering configuration options. When people ask for a setting, find out what the root of the problem is and fix that instead.
+  Also read `Choosing our Preferences <http://ometer.com/preferences.html>`_.
 * People’s data is sacred. Provide undo for most operations and optionally a confirmation for bigger more complex operations, but be careful about confirmations `as they might be dismissed <http://www.alistapart.com/articles/neveruseawarning/>`_.
 * The state of the application should be clear. If something loads, provide feedback. Reactions should be quick, ideally under 100ms as per `response time limits <https://www.nngroup.com/articles/response-times-3-important-limits/>`_\.
 * The state of the application should be clear. If something loads, provide feedback.
diff --git a/developer_manual/getting_started/codingguidelines.rst b/developer_manual/getting_started/codingguidelines.rst
@@ -9,13 +9,20 @@ General
 
 * Ideally, discuss your plans on the `forums <https://help.nextcloud.com>`_ to see if others want to work with you on it
 * We use `GitHub <https://github.com/nextcloud>`_, please get an account there and clone the repositories you want to work on
-* Fixes go directly to master, nevertheless they need to be tested thoroughly.
-* New features are always developed in a branch and only merged to master once they are fully done.
-* Software should work. We only put features into master when they are complete. It's better to not have a feature instead of having one that works poorly.
-* It is best to start working based on an issue - create one if there is none. You describe what you want to do, ask feedback on the direction you take it and take it from there.
-* When you are finished, use the merge request function on GitHub to create a pull request. The other developers will look at it and give you feedback. You can signify that your PR is ready for review by adding the label "3. to review" to it. See `the code review page for more information <../prologue/bugtracker/codereviews.html>`_
-* It is key to keep changes separate and small. The bigger and more hairy a PR grows, the harder it is to get it in. So split things up where you can in smaller changes - if you need a small improvement like a API addition for a big feature addition, get it in first rather than adding it to the big piece of work!
-* Decisions are made by consensus. We strive for making the best technical decisions and as nobody can know everything, we collaborate. That means a first negative comment might not be the final word, neither is positive feedback an immediate GO. Nextcloud is built out of modular pieces (apps) and maintainers have a strong influence. In case of disagreement we consult other seasoned contributors.
+* Fixes go directly to the main branch, nevertheless they need to be tested thoroughly.
+* New features are always developed in a branch and only merged to the main branch once they are fully done.
+* Software should work. We only put features into the main branch when they are complete.
+  It's better to not have a feature instead of having one that works poorly.
+* It is best to start working based on an issue - create one if there is none.
+  You describe what you want to do, ask feedback on the direction you take it and take it from there.
+* When you are finished, use the merge request function on GitHub to create a pull request.
+  The other developers will look at it and give you feedback. You can signify that your PR is ready for review by adding the label "3. to review" to it.
+  See `the code review page for more information <../prologue/bugtracker/codereviews.html>`_
+* It is key to keep changes separate and small. The bigger and more hairy a PR grows, the harder it is to get it in.
+  So split things up where you can in smaller changes - if you need a small improvement like a API addition for a big feature addition, get it in first rather than adding it to the big piece of work!
+* Decisions are made by consensus. We strive for making the best technical decisions and as nobody can know everything, we collaborate.
+  That means a first negative comment might not be the final word, neither is positive feedback an immediate GO. Nextcloud is built out of modular pieces (apps) and maintainers have a strong influence.
+  In case of disagreement we consult other seasoned contributors.
 
 Labels
 ------
@@ -64,12 +71,15 @@ Coding
 * No global variables or functions
 * Unit tests
 * HTML should be HTML5 compliant
-* When you ``git pull``, always ``git pull --rebase`` to avoid generating extra commits like: *merged master into master*
+* When you ``git pull``, always ``git pull --rebase`` to avoid generating extra commits like: *merged main into main*
 
 License headers
 ---------------
 
-Nextcloud is licensed under the `GNU AGPLv3 <https://www.gnu.org/licenses/agpl>`_. From June, 16 2016 on we switched to "GNU AGPLv3 or any later version" for better long-term maintainability. If you create a new file please use this header:
+Nextcloud is licensed under the `GNU AGPLv3 <https://www.gnu.org/licenses/agpl>`_.
+From June, 16 2016 on we switched to "GNU AGPLv3 or any later version" for better long-term maintainability.
+
+If you create a new file please use this header:
 
 .. code-block:: php
 
diff --git a/developer_manual/prologue/bugtracker/codereviews.rst b/developer_manual/prologue/bugtracker/codereviews.rst
@@ -18,7 +18,7 @@ code reviews shall take place on GitHub as well.
 Precondition
 ------------
 
-From now on no direct commits/pushes to master or any of the stable branches are
+From now on no direct commits/pushes to the main or any of the stable branches are
 allowed in general.  **Every code** change - **even one liners** - have to be
 reviewed!
 
@@ -37,8 +37,8 @@ How will it work?
 #. In case the reviewer is okay with the changes and thinks all their comments and
    suggestions have been taken into account a :+1 on the comment will signal a positive
    review.
-#. Before a pull request will be merged into master or the corresponding
-   branch at least 2 reviewers need to give :+1 score.
+#. Before a pull request will be merged into the main corresponding stable branch
+   at least 2 reviewers need to give :+1 score.
 #. Our continuous integration server will give an additional indicator for
    the quality of the pull request (the results can be accessed from the GitHub
    interface for that pull request).
diff --git a/developer_manual/prologue/bugtracker/triaging.rst b/developer_manual/prologue/bugtracker/triaging.rst
@@ -75,11 +75,18 @@ Let's go over each step.
 Finding duplicates
 ^^^^^^^^^^^^^^^^^^
 
-To find duplicates, the search tool in GitHub is your first stop. In `this screen <https://github.com/nextcloud/server/issues>`_ you can easily search for a few keywords from the bug report. If you find other bugs with the same content, decide what the best bug report is (often the oldest or the one where one or more developers have already started to engage and discuss the problem). That is the 'master' bug report, you can now close the other one (or comment that it can be closed as duplicate).
-
-If the bug report you were reviewing contains additional information, you can add that information to the 'master' bug report in a comment. Mention this bug report (using #<bug report number>) so a developer can look up the original, closed, report and perhaps ask the initial reporter there for additional information.
-
-If you can't find anything, look in closed bug reports. The problem might be solved already and be listed there! Of course, these other bug reports might be closed as duplicates of the one you are looking at now - if you can't find one that is solved nor can find any duplicates, you can move on to the next step. If you are unsure, just add a comment: "might be a duplicate of #<bug nr here>" will usually suffice.
+To find duplicates, the search tool in GitHub is your first stop.
+In `this screen <https://github.com/nextcloud/server/issues>`_ you can easily search for a few keywords from the bug report.
+If you find other bugs with the same content, decide what the best bug report is (often the oldest or the one where one or more developers have already started to engage and discuss the problem).
+That is the 'prime' bug report, you can now close the other one (or comment that it can be closed as duplicate).
+
+If the bug report you were reviewing contains additional information, you can add that information to the 'prime' bug report in a comment.
+Mention this bug report (using #<bug report number>) so a developer can look up the original, closed, report and perhaps ask the initial reporter there for additional information.
+
+If you can't find anything, look in closed bug reports.
+The problem might be solved already and be listed there!
+Of course, these other bug reports might be closed as duplicates of the one you are looking at now - if you can't find one that is solved nor can find any duplicates, you can move on to the next step.
+If you are unsure, just add a comment: "might be a duplicate of #<bug nr here>" will usually suffice.
 
 When the issue is a feature request, you can be helpful in the same way: merge related requests by adding information of one to the other and closing the first.
 
