UbuntuBugControl

Differences between revisions 25 and 63 (spanning 38 versions)
Revision 25 as of 2008-06-25 20:18:21
Size: 4482
Editor: c-24-21-234-111
Comment: Have applications sent to mailing list not bdmurray
Revision 63 as of 2019-02-21 10:13:37
Size: 7365
Editor: brian-murray
Comment: BugControl can now target bugs to a release
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
The Ubuntu Bug Control team (ubuntu-bugcontrol in Launchpad), formerly known as ubuntu-qa, is a subset of the BugSquad who can change the [:Bugs/Importance:importance] of bugs and set the [:Bugs/Status:status] of a bug to "Triaged" or "Won't Fix". You do this when you are [:Bugs/HowToTriage:triaging]. ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||

The Ubuntu Bug Control team (ubuntu-bugcontrol in Launchpad) is a subset of the [[BugSquad|Ubuntu Bug Squad]] who can change the [[Bugs/Importance|importance]] of Ubuntu bug tasks, set the [[Bugs/Status|status]] of an Ubuntu bug task to "Triaged" or "Won't Fix" and target a bug for a release of Ubuntu. You do this when you are [[Bugs/Triage|triaging]] bug reports.
Line 6: Line 8:
You need to demonstrate four things: Both individuals and teams can join Ubuntu Bug Control. There are generic requirements and specific requirements.
Line 8: Line 10:
 1. That you promise to be polite to bug reporters, even if they don't deserve it, by signing the Ubuntu Code of Conduct.
 2. You need to understand [:Bugs/HowToTriage] and be familiar with [:Bugs/Assignment:assigning bugs], choosing a bug [:Bugs/Status:status] and setting a bug's [:Bugs/Importance:importance]. There's a particular procedure for triaging and Importance has a specific meaning, so we want to make sure you understand the conventions.
 3. You also need to be aware of the considerations to take when making an Apport crash report, there are private by default, publicly visible. Documentation regarding this can be found at [https://wiki.ubuntu.com/Bugs/HowToTriage#head-f46ac7bd66be716a03d2d4fb0788725cc9cc7ba0 Triaging Apport crash reports].
 4. Have a list of triaged bugs that demonstrate you understand triaging.
<<Anchor(Generic-reqs)>>
=== Generic Requirements ===
Line 13: Line 13:
Requirement 4 is waivable if you are an upstream developer / bug triager or if an Ubuntu developer vouches for you and your ability to triage bug reports.  * Understand [[Bugs/Importance]].
 * Understand [[Bugs/Status]].
 * Understand [[Bugs/Assignment]].
 * Read [[DebuggingProcedures]].
 * Read the [[Debugging]] sections relative to your interest.

=== Requirements for Individuals ===

To join Ubuntu Bug Control as an individual, you must:

 1. Be and promise to be polite to bug reporters, even if they are not polite, by signing the Ubuntu Code of Conduct.
 1. Understand [[Bugs/Triage]], [[Bugs/Assignment|assigning bugs]], choosing a bug task [[Bugs/Status|status]] and setting a bug task's [[Bugs/Importance|importance]]. There is a particular procedure for triaging and each possible importance has a specific meaning, so we want to make sure you understand the conventions.
 1. Know the requirements for making an Apport crash report publicly visible. (By default these are private.) Documentation regarding this can be found at [[ Bugs/Triage#Apport_crash_reports | Triaging Apport crash reports ]].
 1. Have a list of bug reports that you have worked on that demonstrate your understanding of the triage process.

/!\ Requirement 4 can be waived if you are an upstream developer or bug triager or if a Ubuntu developer vouches for you (your triaging ability).
Line 17: Line 32:
 * [https://launchpad.net/codeofconduct sign] the [http://www.ubuntu.com/community/conduct Ubuntu Code of Conduct].
 * read: [:Bugs/Importance].
 * read: [:Bugs/Status].
 * read: [:Bugs/Assignment].
 * triage: [https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=Unconfirmed&field.importance%3Alist=Undecided&assignee_option=none&field.assignee=&field.owner=&field.component=1&field.component=2&field.component-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_no_package.used=&search=Search some bugs] and keep a short list (at least 5) of your best ones.
 * Complete the [[#Generic-reqs| generic requirements]].
 * [[https://launchpad.net/codeofconduct|sign]] the [[http://www.ubuntu.com/community/conduct|Ubuntu Code of Conduct]].
 * Improve some bug reports and keep a short list (at least 5) of your best ones.

<<Anchor(Application)>>
==== Application ====
Line 24: Line 40:
 * Apply: to the [http://launchpad.net/people/ubuntu-bugcontrol Ubuntu Bug Control team] and send the the Ubuntu Bug Control team application you will receive to ubuntu-bugcontrol AT lists.launchpad.net '''or'''
 * Apply and e-mail ubuntu-bugcontrol AT lists.launchpad.net directly with responses to the application provided below '''or'''
 * If you are an upstream developer or bug triager contact [https://launchpad.net/~jorge Jorge Castro]
 * Direct Application: e-mail your application to ubuntu-bugcontrol AT lists.launchpad.net; please copy & answer the questions below
   1. Do you promise to be polite to bug reporters even if they are rude to you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
   1. Have you read [[Bugs/Triage]], [[Bugs/Assignment]], [[Bugs/Status]] and [[Bugs/Importance]]? Do you have any questions about that documentation?
   1. What sensitive data should you look for in a private Apport crash report bug before making it public? See [[Bugs/Triage]] for more information.
   1. Is there a particular package or group of packages that you are interested in helping out with?
   1. Please list five or more bug reports which you have triaged and include an explanation of your decisions. Please note that these bugs should be representative of your very best work and they should demonstrate your understanding of the triage process and how to properly handle bugs. For '''all''' the bugs in the list, please indicate what importance you would give it '''and''' explain the reasoning. ''Please use urls in your list of bugs.''
 
Notes:
 * If you are an upstream developer or bug triager for an upstream project contact [[https://launchpad.net/~brian-murray|Brian Murray]]
 * Membership in some teams also grants membership to Ubuntu Bug Control, for example: LaunchpadHome:ubuntu-core-dev, LaunchpadHome:ubuntu-core-doc, and LaunchpadHome:ubuntu-dev. You can find if your team is a member by visiting the team's homepage and looking at the "Subteam of" section.
 
==== Evaluation Criteria and Process ====
Line 28: Line 53:
== Application ==
  1. Do you promise to be polite to bug reporters even if they are rude to you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
  2. Have you read [:Bugs/HowToTriage], [:Bugs/Assignment], [:Bugs/Status] and [:Bugs/Importance]? Do you have any questions about that documentation?
  3. What sensitive data should you look for in a private Apport crash report bug before making it public? See [:Bugs/HowToTriage] for more information.
  4. Is there a particular package or group of packages that you are interested in helping out with?
  5. Please list of five or more bugs which you have triaged. These bugs should demonstrate your understanding of the triage process and how to properly handle bugs. If there is a bug in your list that does not have an importance indicate what importance you would give it after becoming a member of Ubuntu Bug Control. Please use urls in your list of bugs.

== Evaluation Criteria ==
The application review is a subjective process however a list of what we look for follows:
The application review is a subjective process; however a list of what we usually look for follows:
Line 39: Line 56:
  2. Is the applicant respectful and tactful in their communications?
  3. Are the applicant's comments detailed and do they explain their actions?
  4. Is the applicant following the DebuggingProcedures for the package the bug report is about?
  5. Has the applicant made bug titles or descriptions more descriptive?
  6. Has the applicant added any bug watches to bug reports? (Linked bugs upstream)
  7. Has the applicant forwarded any bugs upstream? (Registered in upstream bts and reported an Ubuntu bug)
  1. Does the reasoning for the bug Importance make sense?
  1. Has the applicant provided an explanation for every bug provided, is it logical?
  1. Is the applicant respectful and tactful in their communications?
  1. Are the applicant's comments detailed and do they explain their actions?
  1. Is the applicant following the DebuggingProcedures for the package the bug report is about?
  1. Has the applicant made bug titles or descriptions more descriptive?
  1. Has the applicant added any bug watches to bug reports? (Linked bugs upstream)
  1. Has the applicant forwarded any bugs upstream? (Registered in upstream bug tracking system and reported a bug)

The review process will take at least 7 days, to ensure that every Ubuntu Bug Control member has had an opportunity to review and comment on the application.

===== Example Application =====

The following are examples of a high quality Bug Control application which contained lots of different types of triaging work.

 * [[https://lists.launchpad.net/ubuntu-bugcontrol/msg00715.html | Application from Yofel]]
 * [[https://lists.launchpad.net/ubuntu-bugcontrol/msg01024.html | Application from Kamal Mostafa]]
 * [[https://lists.launchpad.net/ubuntu-bugcontrol/msg01083.html | Application from kermiac]]


=== Requirements for Teams ===

  1. The team '''must''' be a closed or moderated one.
  1. The team '''must''' require its members to [[https://launchpad.net/codeofconduct|sign]] the [[http://www.ubuntu.com/community/conduct|Ubuntu Code of Conduct]].
  1. The team '''must''' have at least one representative tasked with educating new members on Ubuntu Bug Control policies.
  1. The representative above '''must''' be a current member, directly or indirectly, of Ubuntu Bug Control.
  1. The team '''must''' limit their use of Ubuntu Bug Control permissions to a specific set of packages. (They should not be setting the importance of bugs about every package in Ubuntu.)

==== Application ====

One of the team's administrators should e-mail the team's application to ubuntu-bugcontrol AT lists.launchpad.net. Please give us:

  * a brief reasoning of why it is important for the team to be a member.
  * a list of Ubuntu source packages which the team plans to work on.
  * identify who is/are the representative(s) -- give us the link to the Launchpad page of each one.

==== Evaluation Criteria ====

One of the team's administrators will review the application and act on it. This may require e-mail/IRC exchange. Evaluation is subjective.

==== Length of Membership ====

Initial membership will be set for three months from the date of approval; after this initial period, membership will be valid for one year. Approximately one week before the expiry date an email will be sent warning of the expiration, and requesting action. You are expected to renew when needed, following the email's directions.
Line 50: Line 104:
 * [:Bugs/HowToTriage]
 * [:Bugs/Importance]
 * [:Bugs/Status]
 * [:Bugs/Assignment]
 * [http://launchpad.net/people/ubuntu-bugcontrol Ubuntu Bug Control in Launchpad]
 * [[Bugs/Triage]]
 * [[Bugs/Importance]]
 * [[Bugs/Status]]
 * [[Bugs/Assignment]]
 * [[http://launchpad.net/people/ubuntu-bugcontrol|Ubuntu Bug Control in Launchpad]]
Line 57: Line 111:
[:CategoryBugSquad][[BR]]
[:
CategoryUbuntuTeams]
[[CategoryBugSquad]]<<BR>>
[[CategoryUbuntuTeams]]

The Ubuntu Bug Control team (ubuntu-bugcontrol in Launchpad) is a subset of the Ubuntu Bug Squad who can change the importance of Ubuntu bug tasks, set the status of an Ubuntu bug task to "Triaged" or "Won't Fix" and target a bug for a release of Ubuntu. You do this when you are triaging bug reports.

Requirements for joining

Both individuals and teams can join Ubuntu Bug Control. There are generic requirements and specific requirements.

Generic Requirements

Requirements for Individuals

To join Ubuntu Bug Control as an individual, you must:

  1. Be and promise to be polite to bug reporters, even if they are not polite, by signing the Ubuntu Code of Conduct.
  2. Understand Bugs/Triage, assigning bugs, choosing a bug task status and setting a bug task's importance. There is a particular procedure for triaging and each possible importance has a specific meaning, so we want to make sure you understand the conventions.

  3. Know the requirements for making an Apport crash report publicly visible. (By default these are private.) Documentation regarding this can be found at Triaging Apport crash reports.

  4. Have a list of bug reports that you have worked on that demonstrate your understanding of the triage process.

Warning /!\ Requirement 4 can be waived if you are an upstream developer or bug triager or if a Ubuntu developer vouches for you (your triaging ability).

In order to join:

Application

Ways to join:

  • Direct Application: e-mail your application to ubuntu-bugcontrol AT lists.launchpad.net; please copy & answer the questions below

    1. Do you promise to be polite to bug reporters even if they are rude to you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
    2. Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and Bugs/Importance? Do you have any questions about that documentation?

    3. What sensitive data should you look for in a private Apport crash report bug before making it public? See Bugs/Triage for more information.

    4. Is there a particular package or group of packages that you are interested in helping out with?
    5. Please list five or more bug reports which you have triaged and include an explanation of your decisions. Please note that these bugs should be representative of your very best work and they should demonstrate your understanding of the triage process and how to properly handle bugs. For all the bugs in the list, please indicate what importance you would give it and explain the reasoning. Please use urls in your list of bugs.

Notes:

  • If you are an upstream developer or bug triager for an upstream project contact Brian Murray

  • Membership in some teams also grants membership to Ubuntu Bug Control, for example: ubuntu-core-dev, ubuntu-core-doc, and ubuntu-dev. You can find if your team is a member by visiting the team's homepage and looking at the "Subteam of" section.

Evaluation Criteria and Process

The application review is a subjective process; however a list of what we usually look for follows:

  1. Has the applicant provided the importance they would give a bug report?
  2. Does the reasoning for the bug Importance make sense?
  3. Has the applicant provided an explanation for every bug provided, is it logical?
  4. Is the applicant respectful and tactful in their communications?
  5. Are the applicant's comments detailed and do they explain their actions?
  6. Is the applicant following the DebuggingProcedures for the package the bug report is about?

  7. Has the applicant made bug titles or descriptions more descriptive?
  8. Has the applicant added any bug watches to bug reports? (Linked bugs upstream)
  9. Has the applicant forwarded any bugs upstream? (Registered in upstream bug tracking system and reported a bug)

The review process will take at least 7 days, to ensure that every Ubuntu Bug Control member has had an opportunity to review and comment on the application.

Example Application

The following are examples of a high quality Bug Control application which contained lots of different types of triaging work.

Requirements for Teams

  1. The team must be a closed or moderated one.

  2. The team must require its members to sign the Ubuntu Code of Conduct.

  3. The team must have at least one representative tasked with educating new members on Ubuntu Bug Control policies.

  4. The representative above must be a current member, directly or indirectly, of Ubuntu Bug Control.

  5. The team must limit their use of Ubuntu Bug Control permissions to a specific set of packages. (They should not be setting the importance of bugs about every package in Ubuntu.)

Application

One of the team's administrators should e-mail the team's application to ubuntu-bugcontrol AT lists.launchpad.net. Please give us:

  • a brief reasoning of why it is important for the team to be a member.
  • a list of Ubuntu source packages which the team plans to work on.
  • identify who is/are the representative(s) -- give us the link to the Launchpad page of each one.

Evaluation Criteria

One of the team's administrators will review the application and act on it. This may require e-mail/IRC exchange. Evaluation is subjective.

Length of Membership

Initial membership will be set for three months from the date of approval; after this initial period, membership will be valid for one year. Approximately one week before the expiry date an email will be sent warning of the expiration, and requesting action. You are expected to renew when needed, following the email's directions.


CategoryBugSquad
CategoryUbuntuTeams

UbuntuBugControl (last edited 2019-02-21 10:13:37 by brian-murray)