Header changes related to issue #602

developer_manual/bugtracker/codereviews.rst

@@ -1,3 +1,4 @@
+======================
 Code Reviews on GitHub
 ======================
 

developer_manual/bugtracker/kanban.rst

@@ -1,3 +1,4 @@
+===================
 Development process
 ===================
 
@@ -14,7 +15,7 @@ The following list shows what the labels mean in the life-cycle and will
 hopefully help you decide how to label an issue.
 
 Backlog
-~~~~~~~
+^^^^^^^
 
 Why do we have it?
   To keep us focused on finishing issues that we started, new issues will be
@@ -38,7 +39,7 @@ Who is Assigned?
   to determine the responsible developer.
 
 Concept
-~~~~~~~
+^^^^^^^
 
 Why do we have it?
   Our think before you act phase serves two purposes. A Bug is in the concept
@@ -67,7 +68,7 @@ Who is Assigned?
   The maintainer that feels responsible for the issue.
 
 To Develop
-~~~~~~~~~~
+^^^^^^^^^^
 
 Why do we have it?
   Now that we have a plan, any developer can pick an issue from this column and
@@ -90,7 +91,7 @@ Who is Assigned?
   No one. Especially not if you are working on something else!
 
 Developing
-~~~~~~~~~~
+^^^^^^^^^^
 
 Why do we have it?
   This is where the magic happens. If it’s a Bug the fix will be submitted as a
@@ -115,7 +116,7 @@ Who is Assigned?
   The most active developer should assign himself.
 
 To Review
-~~~~~~~~~
+^^^^^^^^^
 
 Why do we have it?
   Instead of directly committing to master we agree that **a second set of eyes
@@ -138,7 +139,7 @@ Who is Assigned?
   No one. Especially not if you are working on something else!
 
 Reviewing
-~~~~~~~~~
+^^^^^^^^^
 
 Why do we have it?
   With the Gherkin Scenario from the Concept Phase reviewers have a checklist to
@@ -163,7 +164,7 @@ Who is Assigned?
   The most active reviewer should assign himself.
 
 To Release
-~~~~~~~~~~
+^^^^^^^^^^
 
 Why do we have it?
   This is a list of issues that will make it into the next release. It serves
@@ -202,7 +203,7 @@ Other Labels
 ------------
 
 Priority Labels
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 * Panic should be used with caution. It is reserved for Bugs that would result
   in the loss of files or other user data. An Enhancement marked as Panic is
@@ -223,21 +224,21 @@ Priority Labels
   it to the developer in charge of that part.
 
 App Labels
-~~~~~~~~~~
+^^^^^^^^^^
 
 In the apps repository there are labels like ``app:gallery`` and
 ``app:calendar``. The ``app:`` prefix is used to allow developers to filter
 issues related to a specific app.
 
 Resolution Status
-~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^
 
 * Fixed – Should be assigned to issues in to Release
 * Won’t fix – Reason is given as a comment
 * Duplicate – Corresponding bug is given in a comment (using #guthubissuenumber)
 
 Misc Labels
-~~~~~~~~~~~
+^^^^^^^^^^^
 
 * Needs info – Either from a developer or the bug reporter. This is nearly as
   severe as Panic, because no further action can be taken

developer_manual/bugtracker/triaging.rst

@@ -9,13 +9,15 @@ Nextcloud Bug Triaging
 Bug Triaging is the process of checking bug reports to see if they are still valid (the problem might be solved since the bug was reported), reproducing them when possible (to make sure it really is a Nextcloud issue and not a configuration problem) and in general making sure the bug is useful for a developer who wants to fix it. If the bug is not useful and can't be augmented by the original reporter or the triaging contributor, it has to be closed.
 
 Why do you want to join
-=======================
+-----------------------
+
 Helping to bring the number of issues down makes it easier for developers to spend their time productively and bug triagers thus **contribute greatly to Nextcloud development**! Triaging a bug doesn’t take long so the work comes in small chunks and you don’t need many skills, just some patience and sometimes perseverance.
 
 Bug triagers who contribute significantly should ask to be listed as an active contributor on the `nextcloud.com <https://nextcloud.com>`_ page!
 
 How do you triage bugs
-======================
+----------------------
+
 The process of checking, reproducing and closing invalid issues is called ‘bug triaging‘. Issues can be divided in one of three kinds:
 
 1. Bugs or feature requests which come with all needed information to allow a developer to fix or work on them
@@ -32,7 +34,7 @@ Triaging follows these steps:
 * Find the next bug-to-be-dealt-with and repeat!
 
 General considerations
-======================
+----------------------
 
 * You need a `GitHub account <https://github.com>`_ to contribute to bug triaging.
 * If you are not familiar with the GitHub issue tracker interface (which is used by Nextcloud to handle bug reports), you `may find this guide useful <https://guides.github.com/features/issues/>`_.
@@ -44,7 +46,7 @@ General considerations
     To be able to tag and close issues, you need to have access to the repository. For the core and sync app repositories this also means having signed the contributor agreement. However, this isn't really needed for triaging as you can comment after you're done triaging and somebody else can execute those actions.
 
 Finding bugs to triage
-======================
+----------------------
 
 GitHub offers several search queries which can be useful to find a list of bugs which deserve a closer look:
 
@@ -59,7 +61,7 @@ Once you have picked an issue, add a comment that you've started triaging:
     "I am triaging this bug"
 
 Checking if the issue is useful
-===============================
+-------------------------------
 
 Much content from https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
 
@@ -71,7 +73,8 @@ The goal of triaging is to have only useful bug reports for the developers. And
 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.
@@ -85,7 +88,8 @@ When the issue is a feature request, you can be helpful in the same way: merge r
 .. note:: Often our GitHub issue tracker is a place for discussions about solutions. Be friendly, inclusive and respect other people's position.
 
 Determining relevance of issue
-------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 Not all issues are relevant for Nextcloud. Bugs can be due to a specific configuration or unsupported platforms. Raspberry Pi's suffer from SQLite time-outs, nginx has problems Apache doesn't and Microsoft Server with IIS is not well supported. While external issues are not always a reason to close a report, be sure that they are clear: does the user use the 'standard' platform? Ask for information if this is missing.
 
 Last but not least, the problem might be due to the user doing something that simply does not work. Your general Nextcloud knowledge might be helpful here - if this is the case, you can often swiftly close the issue with a comment about what went wrong.
@@ -93,7 +97,8 @@ Last but not least, the problem might be due to the user doing something that si
 .. note:: You might have to say no to some requests, for example when a problem has been solved in a new release but won't become available for the release the reporter is using; or when a solution has been chosen which the reporter is unhappy about. Be considerate. People feel surprisingly strong about Nextcloud, and you should take care to explain that we don't aim to ignore them; on the contrary. But sometimes, decisions which benefit the majority of users don't help an individual. The extensibility and open availability of the code of Nextcloud is here to relieve the pain of such decisions.
 
 Determining if the report is complete
--------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 Now that you know that the bug report is unique, and that is not an external issue, you need to check all the needed information is there.
 
 Check `our bug reporting guidelines <https://github.com/nextcloud/server/blob/master/CONTRIBUTING.md#submitting-issues>`_ and make sure bug reports comply with it! The information asked in the `issue template <https://raw.github.com/nextcloud/server/master/issue_template.md>`_ is needed for developers to solve issues.
@@ -103,7 +108,8 @@ Once you added a request for more information, add a #needinfo tag.
 If there has been a request for more information on the report, either by you, a developer or somebody else, but the original reporter (or somebody else who might have the answer) has not responded for 1 month or longer, you can close the issue. Be polite and note that whoever can answer the question can re-open the issue!
 
 Reproducing the issue
----------------------
+^^^^^^^^^^^^^^^^^^^^^
+
 An important step of bug triaging is trying to reproduce the bugs, this means, using the information the reporters added to the bug report to force (recreate, reproduce, repeat) the bug in the application.
 
 This is needed in order to differentiate random/race condition bugs of reproducible ones (which may be reproduced by developers too; and they can fix them).
@@ -111,7 +117,8 @@ This is needed in order to differentiate random/race condition bugs of reproduci
 If you can't reproduce an issue in a newer version of Nextcloud, it is most likely fixed and can be closed. Comment that you failed to reproduce the problem, and if the reporter can confirm (or doesn't respond for a long time), you can close the issue. Also, be sure to add what exactly you tested with - the Nextcloud Master or a branch (and if so, when), or did you use a release, and if so - what version?
 
 Finalizing and tagging
-----------------------
+^^^^^^^^^^^^^^^^^^^^^^
+
 Once you are done reproducing an issue, it is time to finish up and make clear to the developers what they can do:
 
 * If it is a genuine bug (or you are pretty sure it is) add the 'bug' label.