BMO/Requesting Changes: Difference between revisions

* The name of the product

* The [https://bugzilla.mozilla.org/enter_bug.cgi?full=1 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)

* The number of votes needed to confirm a bug (UNCO --> NEW) (optional, disabled by default)

* If you want review requests to require a reviewer (optional, false by default)

* The list of suggested reviewers for the review flag (optional, empty by default)

* The number of days until a review/needinfo/feedback is considered "overdue" and will trigger a reminder email (default 7 days)

* Any flags you want visible on the product (this can be per-component, or product-wide).

* The name of the component

* The product it should go in. When adding a component to Firefox, please CC gavin.sharp@gmail.com.

* A longer description

* Normally we default the assignee to be 'nobody@mozilla.org' but you can optionally set it to a specific individual

* Normally the "QA Contact" is empty, but you can optionally set it to a specific individial

* Any flags (bug and/or attachment) that will need to be visible for bugs against the new component

* The list of suggested reviewers for the review flag (optional, uses the product's review suggestions by default)

* The name of the version

* The product it should go in

* The name of the target milestone

* The product it should go in

Adding one requires running a script on the live server by an IT admin and is may cause downtime of BMO itself. They also add more complexity to the UI. You'll need to make your case before a custom field can be added. Generally, if a custom field is very specific to one niche area and do not concern the Project as a whole, we encourage the use of status whiteboard markers or other existing 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 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

* The value to be added

* The field it should be added to

* 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)

* Most security groups have a related "-team" group that is used for actually granting people into. For example, noone is in the 'client-services-security' group directly. There is a 'client-services-security-team' group which is a member of the 'client-services-security' group. The individual users are placed directly into the 'client-services-security-team' group when needed. Therefore they get access to the other group as well through inheritance. Only the 'client-services-security' group should be actually visible on the bug report.