Difference between revisions of "Contribute/Bugsquad/BugDays/Dolphin2012"

Revision as of 16:09, 19 October 2012

THIS WIKI PAGE IS NOT READY YET Still to do:

• Add batches of bugs (Frank already has a script for that)
• Add subsections for triaged bugs
• Add link to forum. A forum for the event has been requested: https://bugs.kde.org/show_bug.cgi?id=308594

Introduction

The Dolphin bug triage weeks start on October ??, 2012. We are going to triage the Dolphin bug reports listed at bugs.kde.org.

Goals of The Bug Triage Weeks

1. Make sure that the bug report contains all relevant information:
   • Check if the summary desribes clearly what the bug is about. This makes it much easier to find the right bug in bug lists or using Bugzilla's search.
   • If the description of a bug is somewhat unclear, try to provide a better step-by-step procedure how to reproduce it, or ask the reporter for a better description. A screenshot is sometimes helpful as well.
2. Assign meaningful meta data to the report, to make it easy for developers and potential new contributors to find something to work on:
   • Find more meaningful components for the bugs in the 'general' component.
   • If the bug is 100% reproducible with simple steps, add the 'reproduceable' keyword.
   • Check if the 'Version' is really the latest version that the bug has been reported for/can be reproduced with.
3. Close reports that are obsolete, and reassign bugs that are no Dolphin bugs at all:
   • If we are 100% sure that a bug does not exist any more, it should be closed. Always ask someone to double-check this, or maybe even better, ask the reporter if he/she still can reproduce the bug and put the bug into the "needs reporter feedback" section below. If there is no response after one month, the report should be closed.
   • If a report looks more like a wish than like a bug, the severity should be changed to 'wishlist'.
   • If a bug report is valid, but it is not a Dolphin bug (this is sometimes not easy to decide, even for the developers), it should be reassigned to the correct product.

Some Basic Principles

• Be friendly and respectful when you add comments. If there are inappropriate comments in the bug report, respond in a matter-of-fact way or do not respond at all. You can ask people to respect KDE's Code of Conduct and provide a link.
• Read the bug report carefully. It's very easy to miss an important detail which is essential to understand or to reproduce the bug.
• Some bugs may not be reproducible on every installation of KDE. Thus we use a 4-eye principle, having at least 2 triagers look at the bugs before we make any serious changes in the bug reports themselves.
• You should be working with KDE 4.9.2 or later for testing these bugs. If you add a comment to the bug report and say if you can reproduce the bug or not, be sure to list the exact version and if it is a source build or which distro you are using.
• Some more information on how to mark bugs can be found on this page.
• If you have any questions, feel free to ask in the forum.

Details

How to Get Started

• Sign in in the Sign-in section of this page.
• Select a batch of bugs from the Division of Labour section below and put your name next to it to show that you are working on it. When you have completed all the bugs in that section, please mark it as 'done'.
• For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.

Keep this page updated!

When you have triaged a bug, add it to one of the sections at the bottom of this page and give a brief summary of what you have found out/what needs to be changed in the report.

 

Tip
Please be sure to sign every bug or comment you add to this page with your nickname. You can use the wiki markup ~~~ to insert your wiki username or another signature, which can be configured in the 'User Profile' section of the Preferences, automatically.

You can add a link to a bug report easily: 'two curly open brackets' Bug |123456 'two curly closing brackets' becomes bug #123456.

After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself to the CC field of the report to be informed about updates. When a bug report is closed, it should be updated on this page. You can do this with the tag <s>...</s>

Sign-in

Before you start triaging, list your name (or the nickname you use in the forum/on IRC) and the KDE version you are using (including the distro) or the git branch here.

Division of Labour

Please choose a batch that is not already taken and then query bugs.kde.org for all bugs in that batch. Please add your name/nickname to the table below to claim a batch and to avoid duplication of effort.

TODO: ADD BATCHES

Completed Bugs

Add the bug reports that you have triaged to the various sections below. This makes sure that someone can double-check your work, and someone can make the actual changes in the bug report for those who do not have Bugzilla permissions yet..

Please note that this is a layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

TODO: ADD SUBPAGES FOR DIFFERENT SECTIONS