BMO/Requesting Changes: Difference between revisions
m (moved Bugzilla Administration to BMO/Requesting Changes: Better name for content) |
|
(No difference)
| |
Revision as of 08:34, 20 April 2011
This page details the information you need to provide in order to get speedy resolution to requests to change the configuration of bugzilla.mozilla.org. The b.m.o. administration team aims to turn around all correctly-specified requests in 24 hours, and hopefully much quicker.
In general, the more significant a change you want to make, the more likely it is that you will need to provide evidence of discussion and consensus around the change.
Additions
File a bug, providing:
Products
- The name of the product
- The classification (group) you would like the product in
- A longer description, usually including a web link for more info on the product
- The initial list of components, with their info (see below)
- The initial list of versions, with their info (see below)
- The initial list of target milestones, with their info (see below)
- The security group(s) bugs should be classified under when a user checks the security flag (if you don't know, we can help figure this out for you)
- (optional) The number of votes needed to confirm a bug (UNCO --> NEW)
Components
- The name of the component
- The product it should go in
- A longer description
- The default assignee, if any (a valid Bugzilla account)
Versions
- The name of the version
- The product it should go in
Target Milestones
- The name of the target milestone
- The product it should go in
Custom Fields
- The name of the field
- A longer description
- The type (Bug ID, Large Text Box, Free Text, Multiple Selection Box, Single Selection Box or Date/Time)
- The initial set of values, if Multiple or Single Selection Box
- The product(s) it should show up in
- Whether it can be set on bug creation
Keywords
Keywords exist across all of Bugzilla, so we try to be careful about adding them. You'll need to make your case before a keyword can be added. Generally, if a keyword is very specific to one niche area and do not concern the Project as a whole, we encourage the use of status whiteboard markers.
- The name of the keyword
- The description to use
- A good reason why it should be added
Additional Field Values
This could be Hardware or OS.
- The value to be added
- The field it should be added to
Flags
- The name of the flag
- A longer description
- Which products/components the flag should appear in
- Whether the flag applies to bugs or attachments
- Whether the flag is requestable (i.e. users can ask for flags of this type to be set)
- Whether the flag should be requested from a specific person
- Whether the flag can be set multiple times
- If flags of this type are requestable, the group allowed to request them, if any
- The group allowed to grant/deny flags of this type, if any
- CC list for request notifications, if any (all valid Bugzilla accounts)
Users
Users can sign up for accounts themselves.
Statuses and Resolutions
Changing the Bugzilla workflow is a big deal, and is very unlikely to happen without serious discussion. If you don't know whether you are authorised to make this sort of change, you aren't.
Groups
Keeping bugs secret in the Mozilla project is also a big deal. If you want a group added to be used for bugs, you will need to have a good reason why those bugs should not be visible to everyone.
Changes
Merging or Renaming Products or Components
Disablings
Users
Email Gerv, giving sufficient evidence of violation of Mozilla policies or community norms.
Versions
Target Milestones
Old target milestones are normally disabled by the team at some point after the release has happened. This means that they can't be selected on bugs (although they will continue to show up if that's the current value) and you have to use the Boolean Charts to search for them.
Deletions
Things in Bugzilla rarely get deleted. Many things can be disabled (see above) instead. You should not expect deletions to happen fast. It's probably best to file a bug explaining what you need deleted and why, and expect questions.
Attachments
If you add an attachment and then realise it contains confidential or personal information, file a bug and it can be manually annulled. (The attachment links and name will remain, but the data will be removed.)
Users
We don't delete accounts because that would be messing with the historical record. However, users can disable all their bug mail in their preferences if they would like to stop hearing from Bugzilla, and they may change their email address to an inactive or throwaway one if they wish.