Actions
底下列出幾個在分類report時你會用到的幾個動作(actions)，主要有三種『Confirming』，『Forwarding upstream』和『Marking duplicate』，在處理這些動作時，可以嘗試用『Launchpad Greasemonkey scripts』，會節省你很多時間。
請注意一下有些團隊在分類時會有些不一樣的規則，詳情請參考：
而有些套件在分類時也會有一些特殊的規則，詳請請參考：
Confirming
這個『Confirmed』狀態通常是使用在當你確定這個report確實是一個『bug』時，如果這個『bug』有包含底下這幾種狀況的話，就可以被考慮成『confirmed』：
- 是否有包含『patch』來修復這個bug?
- 是否有充足的『log』和『crash dumps』，就像描述在『DebuggingProcedures』上面一樣？
- 你是否可以複製(reproduce)這條bug?
- 其他的發行版(distribution)是否有完整或是被確認的bug?
- upstream的作者是否有完整或是被確認的bug?
如果有符合上面的狀況發生，而且你也不是最初的reporter的話，你就可以『Confirm』這個report，由底下的三個步驟完成：
- 將『Status』改為『Confirmed』。
- 指派適當的『Importance』。
- 點選『Save changes』。
Ubuntu有許多的bugs，而工程師通常都會先優先看『confirmed』的bug，所以你就不用擔心如果轉『confirmed』以後，就不能發送給upstream。就像之前講過的，狀態『Triaged』代表的是你已經分類完這個bug了，而只有在『Bug Control』團隊的成員才能做這件事，所以只有在確認這個bug的root cause被找到以後工程師已經可以開始開工了，在去轉成『Triaged』。
Forwarding upstream
將bug給轉發到『upstream』是當『triager』這個角色一件很重要的事，如果沒有通知他們的話，你在做的這些分類的事，他們就不會知道，也沒有人會處理。
當底下這兩種狀況發生時，你就必須要轉發給upstream:
- 這個Ubuntu的bug已經被『Confirmed』或是『Triaged』而且
- 這個issue並不是因為打包(packaging)時或是Debian/Ubuntu的patch所造成的。
請注意如果你在做這些事時，是代表Ubuntu upstream，所以請留下一個好印象。而且嘗試描述這個bug的狀況和提供連結給原始的reporter是一個很好的練習，盡量讓所有的資訊越完整越好。
在寫這個新的bug report給upstream時，你應該注意一下這個bug是否已經存在了，如果你以發現其實已經在Ubuntu已經存在相同的but report了，那就請你描述一下，並且附加一個連結上去。如果沒有找到已經存在的案例的話，在創建一個新的。
接下來下一步是將這個upstream bug給連結到Launchpad上的Ubuntu bug，這樣Ubuntu的團隊才可以持續的追蹤他的狀況，請由底下幾步來完成這個工作：
- 按一下『Also affects project』。
- 如果有必要的話，搜尋並且挑一個正確的project。
- 選擇選項『I have the URL for the upstream bug:』並且將相關的URL貼上去。
- 按一下『Add to Bug Report』。
當upstream的狀態被改變時，Launchpad接下來會追蹤這個『upstream bug』並且提醒在『Ubuntu bug』上的所有的訂閱者。 如果想要知道更多的『upstream bug trackers』的話請參考頁面『Bugs/Upstream』。
Marking a bug as requiring forwarding
如果你有發現一個bug需要被轉發，則最好是馬上就將其轉發出去。然而，如果你的時間不夠的話，你也可以將這個bug給標記成『needing to be forwarded』:
- 開起一個upstream task(點選『Also affects project』)，藉由選取『I just want to register that it is upstream right now; I don't have any way to link it.』，這樣才不會指派一個『bug watch』，然後點選『Add to Bug Report』，其他的注意事項請參考『bug #353097』。
- 這會將這個bug標記成『needs forwarding』。
- 你可以藉由點選在『Advanced Search』裡面的『Show only bugs that need to be forwarded to an upstream bugtracker』來搜尋這些bugs。
Marking duplicate
通常許多在Ubuntu上的reports都會有很多類似的其他reports，就個就是所謂的重複(duplicate)的bug，通常是由於一個high profile bug被引進Ubuntu後，造成很多的使用者都在報同一個bug。
在很多種狀況之下，reporters會不知道要怎麼去檢查是否相同的bug已經被發布了，或者是他們也很難決定是否這條bug跟其他的bug是否一樣。找到這些重複的bug和收集這些資訊是非常有價值的貢獻。
通常當有相同的『root cause』就代表這些bug是重複的，有辦法去決定這些也是一項技能，而且當你挑選某個套件或是subsystem後，你會更加的熟悉。
但是如果bugs有相同的現象的話，不太表他們就是重複的，舉個例子來說，許多不同的bugs有可能會造成X 不能運作，所以決定哪個bug應該會被分到哪裡也是『bug triage 』很重要的素養。
如果不確定的話，可以問別人意見，也可以問一下reporter看一下你覺的似是而非的其他bug report來做決定，通常reporter對自己所發布的report都會很有興趣。
實際上的作法，當你第一次看到一個新的bug，想要嘗試著在系統裡面找到相似的另一條bug，請由底下的步驟來嘗試看看：
- 點選在bug頁面底下的『List open bugs』連結，或是點選在頁面上方的『Bugs』tab。
- 搜尋相似描述的bugs或是相關的標題。
- 如果描述的是相同的『root cause』的話，接下來就是決定哪個report會是主要的report(primary)。通常不一定是最舊的bug(數字比較小的)才會是主要的report，而是最好理解，並且包含最多訊息的report才對。
- 然後剛剛已經決定哪個是主要的report了，接下來在其他的bug上的評論上，增加一個像是底下的標準回應：
Include: Nothing found for "^== A duplicate ==$"! - 然後點選在右上角的連結『Mark as Duplicate』並且輸入primary bug的號碼。
在Firefox上有許多的extension，有著這些相關的標準回應(standard responses)還有許多很威的script，PPA的話可以如下取得： https://launchpad.net/~gm-dev-launchpad/+archive/ppa
當你上傳了你的responses後。你應該也要使用Firefox的extension將你的responses給更新到相關的資料庫，如果你想要看看這些responses的話可以經由bazaar 的branch 『lp:ubuntu-bugcontrol-tools』底下的『gm-xml-files/bugsquad-replies.xml』，如果想要checkout一個branch，請使用底下的語法：
bzr branch lp:ubuntu-bugcontrol-tools
只有『bug control』的成員才能commit到這個branch，但是你可以發送一個『merge proposal』，Brian Murray將會幫你review/merge (請參考這個email messgae)，這樣在merge以後，其他人也可以用你的格式了。