Redefine membership policy for Ubuntu Bug Control

Registered by Brian Murray on 2011-05-05

Modify the team membership policy of Ubuntu Bug Control to restrict team membership to allow modifications of only small sets of packages and communicate the change in policy.

Blueprint information

Status:
Complete
Approver:
Pete Graner
Priority:
Undefined
Drafter:
Brian Murray
Direction:
Approved
Assignee:
Brian Murray
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Implemented
Milestone target:
None
Started by
Brian Murray on 2011-05-25
Completed by
Brian Murray on 2011-05-25

Related branches

Sprints

Whiteboard

This topic came up during the Bug Squad meeting on 20110505 in #ubuntu-meeting and was also discussed on the ubuntu-bugcontrol mailing list. It was brought about because a team was applying for team membership.

Points to discuss or that have been raised:
 * part of adding a team requires they have team members already in Bug Control so those members will be able to vote for their team members
 * Bug Control members won't know who else is in the team or working on what <we could require a link to the team members list. Private teams should, by default, be rejected -- hggdh>
 * a conception that team membership is for a subset of packages not all of Ubuntu
 * if a team is just going to doing one thing (assigning bugs) do they need to know everything required for being in Bug Control - it is a fair bit of work to join the team
 * the team members being knowledgeable triagers could help Ubuntu bug quality

Discussion:
* ubuntu devleopers are a part of ubuntu-bugcontrol already
 * shouldn't the team rules apply to them too?
* team membership could be for a limited period of time to force them to apply individually
* hardware certification would be touching a wide variety of packages
* there is no way to monitor what members of ubuntu-bugcontrol do to bugs - we end up trusting them
* there isn't a way for a community member to join the hardware certification team
* team membership applications should indicate which sets of packages they will be working on
* the bug control member who is a member of the team is responsible for the team's activity
* memberships could require endorsement from an exisiting bug control member instead of having to apply
 * this short cuts the feedback regarding applications and positive feedback and constructive criticism
* create a bug supervisor for packages in Launchpad?
 * the distribution bug supervisor could still work with those packages in launchpad

Decisions:
 * team membership is for a specific set of packages and they need to be indicated in the application
 * the bug control member who is a member of the team is responsible for the team's activity
 * in the event that a team wants to touch a broad range of packages each member will need to apply individually
 * it'd be neat if somebody wrote a tool to monitor team member actions
  * jibel expressed some interest in this

Work items for oneiric-alpha-1:
 * rewrite team membership policy to indicate that it is only for a specific set of packages: DONE
 * announce team membership policy to ubuntu-bugcontrol and bugsquad: DONE

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.