User:Grundleborg/BugsquadHomePage: Difference between revisions
Grundleborg (talk | contribs) (New page: {{Tip| The next bug-day will be held from 0:00 UTC - 23:59 UTC on Sunday 6th April 2008. Join #kde-bugs on irc.freenode.net. More Information}} The '...) |
(big: "what is bug triage?" etc. ---blauzahl) |
||
| Line 1: | Line 1: | ||
{{Tip| | {{Tip| | ||
The next bug-day will be held from 0:00 UTC - 23:59 UTC on Sunday | The next bug-day will be held from 0:00 UTC - 23:59 UTC on Sunday 20th April 2008. Join #kde-bugs on irc.freenode.net. [[Contribute/Bugsquad/BugDay/060408|More Information]]}} | ||
The '''Bugsquad''' tries to keep track of bugs in KDE software and make sure that valid bugs | 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. | ||
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 Bug Triage?== | ==What is Bug Triage?== | ||
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. | |||
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. | |||
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. | |||
==Why do we do it?== | ==Why do we do it?== | ||
We do it because it is fun, addictive, and a great way to learn more about KDE software. Oh, and it helps people. | |||
==How can I get involved?== | ==How can I get involved?== | ||
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! | |||
==Further Reading== | ==Further Reading== | ||
A Google search will give you an interesting perspective of bug triage from the non-free-software world. | |||
==Credits== | ==Credits== | ||
Thanks to the gnome bug-squad for having such excellent wiki pages, which were invaluable in helping us to rework these pages | Thanks to the gnome bug-squad for having such excellent wiki pages, which were invaluable in helping us to rework and write these pages. | ||
Revision as of 20:12, 16 April 2008
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 Bug Triage?
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.
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.
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.
Why do we do it?
We do it because it is fun, addictive, and a great way to learn more about KDE software. Oh, and it helps people.
How can I get involved?
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!
Further Reading
A Google search will give you an interesting perspective of bug triage from the non-free-software world.
Credits
Thanks to the gnome bug-squad for having such excellent wiki pages, which were invaluable in helping us to rework and write these pages.