[Pkg-owncloud-commits] [owncloud-doc] 03/33: Much improved!
David Prévot
taffit at moszumanska.debian.org
Sun Dec 7 20:56:30 UTC 2014
This is an automated email from the git hooks/post-receive script.
taffit pushed a commit to branch master
in repository owncloud-doc.
commit ad58943dc76181252dcaaac7d9774e406d8071c3
Author: Jos Poortvliet <jospoortvliet at gmail.com>
Date: Thu Nov 27 16:36:32 2014 +0100
Much improved!
---
developer_manual/bugtracker/triaging.rst | 83 +++++++++++++++------------
developer_manual/images/triage work flow.png | Bin 0 -> 81127 bytes
2 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/developer_manual/bugtracker/triaging.rst b/developer_manual/bugtracker/triaging.rst
index 8181096..447e6ce 100644
--- a/developer_manual/bugtracker/triaging.rst
+++ b/developer_manual/bugtracker/triaging.rst
@@ -10,46 +10,35 @@ Bug Triaging is the process of checking bug reports to see if they are still val
Why do you want to join
-----------------------
-While a seemingly small task, triaging is of tremendous benefit to ownCloud. Having a less daunting number of issues makes it far easier for developers to spend their time productively and bug triagers thus **contribute greatly to ownCloud development**!
+Helping to bring the number if issues down makes it easier for developers to spend their time productively and bug triagers thus **contribute greatly to ownCloud 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 `owncloud.org <http://owncloud.org>`_ page!
-Who can join
-------------
-Anyone who is interested in helping out ownCloud and has a little spare time should join. Triaging does not require hefty skills although a willingness to learn is of course very helpful.
-
-How do you join
----------------
-Register on the `testpilot mailing list <http://mailman.owncloud.org/mailman/listinfo/testpilots>`_ and send an introduction of your personal setup and interests to `testpilots at owncloud.org <testpilots at owncloud.org>`_ for starters. On this list we announce and discuss testing and bug triaging related subjects.
-
-You can also join the **#owncloud-testing** channel on **irc.freenode.net** (`link for IRC clients <irc://#owncloud-testing@freenode.net>`_ and `link to webchat<https://webchat.freenode.net/>`_) but keep in mind that people aren't active 24/7 and it can occasionally take a while to get feedback.
-
-For further questions or help you can also send a mail to:
+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:
-* X (IRC: Y)
+1. Bugs or feature requests which come with all needed information to allow a developer to fix or work on them
+2. Incomplete or duplicate bug reports or feature requests
+3. Irrelevant or wrong bug reports or feature requests
-We are looking forward to working with you!
+The job of a bug triager is to identify the One’s for developers to look at, help remove, merge or improve any Two to a One and dismiss Three’s in a friendly and emphatic way.
-How do you triage bugs
-----------------------
Triaging follows these steps:
-* Find a bug somebody should look at
-* Be that somebody and see if the bug is useful for a developer
- * this can include testing to reproduce the bug
-* Act: reply and close, ask a question, add information or a label.
+* Find an issue somebody should look at
+* Be that somebody and see if the issue is useful for a developer
+* Reply and close, ask a question, add information or a label.
* Find the next bug-to-be-dealt-with and repeat!
General considerations
----------------------
- **Be polite**: when you need to request information or feedback be clear and polite, and you will get more information in less time. Think about how you'd like to be treated were you to report a bug!
Often our github issue tracker is a **place for discussions** about solutions. Be friendly, inclusive and respect other people's position.
- 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 ownCloud, 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 e [...]
- Last but not least, don't try to do too many things at the same time; otherwise you will end up with a headache!
- You need a `github account <http://github.com>`_ to contribute to bug triaging.
- If you are not familiar with the github issue tracker interface (which is used by ownCloud to handle bug reports), you `may find this guide useful <https://guides.github.com/features/issues/>`_.
- You will initially only be able to comment on issues. The ability to close issues or assign labels will be given liberally to those who have shown to be willing and able to contribute. Just ask on IRC!
- Read `our bug reporting guidelines<https://github.com/owncloud/core/blob/master/CONTRIBUTING.md#submitting-issues>`_ so you know what a good report should look like and where things belong. The `issue template<https://raw.github.com/owncloud/core/master/issue_template.md>`_ asks specifically for some information developers need to solve issues.
- It might even be fixed, sometimes! It can also be fruitful to contact the `developers on irc <irc://freenode/#owncloud-dev>`_. Tell them you're triaging bugs and share what problem you bumped into. Or just ask on the test-pilots mailing list.
+
+* You need a `github account <http://github.com>`_ to contribute to bug triaging.
+* If you are not familiar with the github issue tracker interface (which is used by ownCloud to handle bug reports), you `may find this guide useful <https://guides.github.com/features/issues/>`_.
+* You will initially only be able to comment on issues. The ability to close issues or assign labels will be given liberally to those who have shown to be willing and able to contribute. Just ask on IRC!
+* Read `our bug reporting guidelines<https://github.com/owncloud/core/blob/master/CONTRIBUTING.md#submitting-issues>`_ so you know what a good report should look like and where things belong. The `issue template<https://raw.github.com/owncloud/core/master/issue_template.md>`_ asks specifically for some information developers need to solve issues.
+* It might even be fixed, sometimes! It can also be fruitful to contact the `developers on irc <irc://freenode/#owncloud-dev>`_. Tell them you're triaging bugs and share what problem you bumped into. Or just ask on the test-pilots mailing list.
Open question: do you need to sign the contributor agreement for this? Shouldn't be the case...
@@ -58,23 +47,21 @@ Finding bugs to triage
Github offers several search queries which can be useful to find a list of bugs which deserve a closer look:
-* `the oldest bugs <TBD>`_
-* `new, not-yet-classified bugs <TBD>`_
-* `bugs which #needinfo <TBD>`_
-* `bugs which haven't seen any comments in a long time <TBD>`_
+* `The bugs least recently commented on <https://github.com/owncloud/core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+>`_
+* `Least commented issues <https://github.com/owncloud/core/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee+no%3Amilestone+no%3Alabel+sort%3Acomments-asc>`_
+* `bugs which need info <https://github.com/owncloud/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+info%22+sort%3Acreated-asc>`_
But there are more methods. For example, if you are a user of ownCloud with a specific setup like using nginx as web server or dropbox as storage, or using the encryption app, you could look for bugs with these keywords. You can then use your knowledge of your installation and your installation itself to see if bugs are (still) valid or reproduce them.
-Each of the links above (or the search you come up with yourself)
-
-The actual triaging
--------------------
+Checking if the issue is useful
+-------------------------------
Much content from https://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging
The goal of triaging is to have only useful bug reports for the developers. And you don't have to know much to be able to judge at least some bug reports to be less than useful. There are duplications, incomplete reports and so on. Here is the work flow for each bug:
-[image: bug workflow from https://techbase.kde.org/images.techbase/5/5c/DarioAndres_GuideToBugTriaging_Workflow.png]
+.. figure:: ../images/kanbanexample.png
+ :scale: 50
Let's go over each step.
@@ -87,6 +74,10 @@ If you can't find anything, look in closed bug reports. The problem might be sol
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.
+**Notes**
+* Be polite: when you need to request information or feedback be clear and polite, and you will get more information in less time. Think about how you'd like to be treated, were you to report a bug!
+* Often our github issue tracker is a place for discussions about solutions. Be friendly, inclusive and respect other people's position.
+
### Identifying external issues
Bugs can be due to a specific configuration or unsupported platforms. Raspberry Pi's suffer from SQLite time-outs, nginx has issues Apache doesn't and Microsoft Server with ISS is simply not supported at all. While external issues aren't 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.
@@ -94,6 +85,9 @@ Last but not least, the problem might be due to the user doing something that si
XXX - more about this?
+**Notes**
+* 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 ownCloud, 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 extensi [...]
+
### 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.
@@ -101,6 +95,7 @@ Check `our bug reporting guidelines<https://github.com/owncloud/core/blob/master
xxx anything specific to add?
TODO:
+
* When do we add what tags;
* should we let triagers add 'severity' tags? Which, when, how?
* when do we assign things;
@@ -115,6 +110,18 @@ To reproduce an issue, please refer to our testing documents: :doc:`../testing/i
If you can't reproduce an issue in a newer version of ownCloud, 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.
-**Credit:** this document is in no small part in debt to the extensive `KDE guide to bug triaging <https://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging>`_.
+Collaboration
+-------------
+You can just get started with bug triaging. But if you want, you can register on the `testpilot mailing list <http://mailman.owncloud.org/mailman/listinfo/testpilots>`_ and perhaps introduce yourself to `testpilots at owncloud.org <testpilots at owncloud.org>`_. On this list we announce and discuss testing and bug triaging related subjects.
+
+You can also join the **#owncloud-testing** channel on **irc.freenode.net** (`link for IRC clients <irc://#owncloud-testing@freenode.net>`_ and `link to webchat <https://webchat.freenode.net/>`_) to ask questions but keep in mind that people aren't active 24/7 and it can occasionally take a while to get a response.
+
+For further questions or help you can also send a mail to:
+
+* X (IRC: Y)
+
+We are looking forward to working with you!
+
+**Credit:** this document is in debt to the extensive `KDE guide to bug triaging <https://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging>`_.
diff --git a/developer_manual/images/triage work flow.png b/developer_manual/images/triage work flow.png
new file mode 100644
index 0000000..8ae9a29
Binary files /dev/null and b/developer_manual/images/triage work flow.png differ
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-owncloud/owncloud-doc.git
More information about the Pkg-owncloud-commits
mailing list