faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
¿Triaged?
by Git on Wednesday 16/Apr/2008, @11:53
|
Hi, I'm not english native, and I don't know the meaning of "triaged". I've searched for it in wordreference and urban dictionary unsuccesfuly. Could someone explain what it means?
I suppose it means something related to confirm or clasify, because the announce says no program skill are needed, so I think people is wanted on IRC channel to test bugs, not to fix them... is it right?
it may be funny... ;-)
Thanks in advance for the explanations. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: ¿Triaged?
by Martin Fitzpatrick on Wednesday 16/Apr/2008, @12:47
|
Triage means classify or sort - in this case by severity. A more common-day usage is in casualty nursing where you classify patients to make sure the more serious get seen first.
There is a Wiktionary entry ( http://en.wiktionary.org/wiki/Triage ). From there you might be able to get to your native language ;)
|
[
Reply To This | View ]
|
Re: ¿Triaged?
by A. L. Spehr on Wednesday 16/Apr/2008, @13:04
|
Alas, while it is a fun word, it is not probably actually funny. :D
I was wondering if I needed to explain "triaged"... I would have just linked to our documentation, except we haven't written that page yet! So:
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. We'll be working on Konqueror stuffs, so you'll be able to get away with not using trunk. ;) A recent SVN 4.0 branch would work very nicely. 4.0.3 will also work. 4.0.2 will probably work. 4.0.1 or earlier is too old. We'll also write testcases. (http://konqueror.kde.org/investigatebug/ for a definition of that :)
Join #kde-bugs and you'll see the links for whatever we're currently working on in the topic. We're friendly!
Ha! I guess I just wrote some more documentation. *g*
|
[
Reply To This | View ]
|
Re: ¿Triaged?
by Git on Sunday 20/Apr/2008, @10:35
|
Thank you very much for your nice answer, all is clear now ;-)
|
[
Reply To This | View ]
|
|
Re: ¿Triaged?
by jospoortvliet on Wednesday 16/Apr/2008, @13:06
|
Yeah. It means something like going through them, testing them. At least, that's what my limited English knowledge tells me ;-)
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
