User:Grundleborg/BugsquadHomePage: Difference between revisions

From KDE TechBase
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{Tip|{{:Contribute/Bugsquad/NextBugDay}}}}
{{Tip|{{:Contribute/Bugsquad/NextBugDay}}}}


The '''Bugsquad''' tries to keep track of bugs in KDE software and make sure that developers can most easily find valid bugs. You do not need any programming knowledge to be in the Bugsquad; it is simply a great way to give practical support to the KDE community without needing any prior experience.
==What is the Bugsquad?==
The '''Bugsquad''' is a team of people who are responsible for keeping the [http://bugs.kde.org KDE bug database] (known as ''bugzilla'') in order.


==What is Bug Triage?==
Our aims include:
* removing old bugs that are now fixed from bugzilla
* reproducing new bugs and providing more detail to make it easier for developers to fix them
* finding and reporting bugs in KDE software.


If you do a Google search on the term, you'll find lots of articles about the economic cost of deciding which bugs to fix, and which bugs not to fix. In free software, the cost is our developer's time. They decide what to fix based on a time-severity tradeoff. Many of them have very long TODO lists, and bugs.kde.org is part of that.
This work is known as '''bug triage'''.


BugSquad aims to help developers by keeping what is in b.k.o as useful as possible. In general, bug triage checks incoming bug reports to see if they can be replicated, make sure they aren't duplicates, and see if they give enough information. For BugDays, we do the same, but for a particular component of KDE. And we start by going through all the old reported bugs. "Does this bug reported in 3.2.1 still exist in 4.0.3?" In addition, we try to sort out things into categories. We also look for any major bugs that have slipped through, and not been noticed by developers, for example "Google.com does not display". This could happen if the bug report was not written very clearly, and the fact that Big Things broke is only mentioned at the very end, and not clear in the title.
==What skills do I need to join?==
The bugsquad is a very easy and useful way to help KDE. It's a great way for people to contribute for the first time. It is '''not''' necessary for you to know any programming language to join. All you need is a copy of KDE and a little bit of spare time.


In the end, developers make the call as to what is "hard to fix" vs. "important enough to bother". So you don't need to know any programming, you just need to have a recent version of KDE4 to join in.  
Bug triage is also good for people with limited time. Once you are familiar with what to do, you can do it for just a few minutes at a time and it will still be beneficial to the KDE community.


==Why do we do it?==
==How do I get involed?==
First, you should read the [[#Documentation|Documentation]].


We do it because it is fun, addictive, and a great way to learn more about KDE software. Oh, and it helps people.  
Next, join our [http://mail.kde.org/mailman/listinfo/bugsquad mailing list] and our IRC channel ('''#kde-bugs''' on '''irc.freenode.net''') which is where we coordinate our efforts.


==How can I get involved?==
Finally, although you can get started anytime, the best way to make your first steps in the bugsquad is to join us for one of our [[#Events|events]].


Join our mailing list (link), which is currently rather low traffic. And then join us on irc.freenode.net in the channel #kde-bugs. Say hi. You'll see whatever we're working on in the topic. Feel free to ask for guidance, we're friendly!
==Documentation==
* [[Contribute/Bugsquad/Documentation/Introduction|Introduction to triaging bugs]]
- This is a basic introduction to how we go about checking old bugs.


==Further Reading==
* [[Contribute/Bugsquad/Documentation/Backtrace|How to create a useful backtrace]]
- This article covers how to create a backtrace that provides useful information about a crash to developers.


A Google search will give you an interesting perspective of bug triage from the non-free-software world.
* [[Contribute/Bugsquad/Documentation/Testcase|How to create a testcase]]
- This document explains what a testcase is and what it isn't, as well as how to create a useful one to illustrate an issue.


==Credits==
* [[Contribute/Bugsquad/Documentation/ConfirmBug|How to confirm a bug]]
Thanks to the gnome bug-squad for having such excellent wiki pages, which were invaluable in helping us to rework and write these pages.
- This article explains what information is useful to developers when Confirming a bug.
 
*[[Contribute/Bugsquad/Documentation/AppSpecific|Application specific tips]]
- This section contains tips on what to do and what not to do for certain applications. It is '''vital''' that you follow the advice in this section when triaging bugs for an application.
 
==Events==

Latest revision as of 03:31, 19 May 2008


What is the Bugsquad?

The Bugsquad is a team of people who are responsible for keeping the KDE bug database (known as bugzilla) in order.

Our aims include:

  • removing old bugs that are now fixed from bugzilla
  • reproducing new bugs and providing more detail to make it easier for developers to fix them
  • finding and reporting bugs in KDE software.

This work is known as bug triage.

What skills do I need to join?

The bugsquad is a very easy and useful way to help KDE. It's a great way for people to contribute for the first time. It is not necessary for you to know any programming language to join. All you need is a copy of KDE and a little bit of spare time.

Bug triage is also good for people with limited time. Once you are familiar with what to do, you can do it for just a few minutes at a time and it will still be beneficial to the KDE community.

How do I get involed?

First, you should read the Documentation.

Next, join our mailing list and our IRC channel (#kde-bugs on irc.freenode.net) which is where we coordinate our efforts.

Finally, although you can get started anytime, the best way to make your first steps in the bugsquad is to join us for one of our events.

Documentation

- This is a basic introduction to how we go about checking old bugs.

- This article covers how to create a backtrace that provides useful information about a crash to developers.

- This document explains what a testcase is and what it isn't, as well as how to create a useful one to illustrate an issue.

- This article explains what information is useful to developers when Confirming a bug.

- This section contains tips on what to do and what not to do for certain applications. It is vital that you follow the advice in this section when triaging bugs for an application.

Events

Retrieved from "https://techbase.kde.org/index.php?title=User:Grundleborg/BugsquadHomePage&oldid=26427"