Closed Bug 1033897 Opened 10 years ago Closed 10 years ago

Firefox OS MCTS Waiver Request Submission Form

Categories

(bugzilla.mozilla.org :: Custom Bug Entry Forms, enhancement, P1)

Product:
bugzilla.mozilla.org
Component:
Custom Bug Entry Forms
Version:
Production
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: vchen, Assigned: dylan)

References

Details

(Keywords: bmo-big)

Attachments

(1 file)

bug-1033897-v2.patch
9.40 KB, patch
glob
: review+
Details | Diff | Splinter Review 
We'd like a form created to submit the MCTS waivers request from partners

This is the structure that we're thinking:

Product: FireFox OS (this would be new)
Component:  MCTS Waiver Request (this would be new)

The following are the MCTS Waiver Request form fields and the Bugzilla field that they map to:

* Company Name
** Description: Please enter the legal name of the company requesting the Waiver
** Maps to Bugzilla field: Comment 0 (Required)

*Device Description
** Description: Please enter the Make, Model, Chipset, screensize and type the device associated with the waiver request. For example type may be mobile phone, tablet, dongle, tv, etc.
** Append  to Bugzilla field: Comment 0 (Required) 

*FFOS Release
** Description: Please Enter the Release this Waiver applies to for this partner.
** Append  to Bugzilla field: Comment 0 (Required) 

*Branding Tier
** Description: Please Enter the Branding Tier associated with the Waiver Request (Powered by Firefox OS or Co-Branded).
** Append  to Bugzilla field: Comment 0 (Required) 

*Distribution Countries
** Description: Please include list of countries where the device is planned to be distributed.
** Append  to Bugzilla field: Comment 0 (Required) 

*Distribution Channel
** Description: Please identify how this device will be sold.  For example, Operator, Retail.
** Append  to Bugzilla field: Comment 0 (Required) 

*Reason for Waiver Request
** Description:  Please describe which test cases,  Branding Guidelines and/or Requirements the Partner is request waived.
** Append  to Bugzilla field: Comment 0 (Required) 

*Rationale for Granting Waiver Request
** Description:  Please document why the Partner thinks a waiver should be granted.
** Append  to Bugzilla field: Comment 0 (Required) 

*Impact Analysis
** Description:  Please provide an assessment of the impact of granting this waiver in general business terms (this should include broad perspective of potential issues such as brand consistency, impacts on reporting & tracking capabilities, help desk/support issues, etc.)
** Append  to Bugzilla field: Comment 0 (Required) 

*Engineering Analysis
** Description:  Please provide an assessment of the impact of granting this waiver in engineering terms including impact on current and future development.
** Append  to Bugzilla field: Comment 1  (Optional - this field will need to be completed; however it may require that the bug is flagged for ‘Needs Info” from a specific person other than the TAM.)

*TAM Recommendation
** Description:  Please provide your recommendation to either approve or reject the Waiver.
** Append  to Bugzilla field: Comment 2  (Required)

Not an urgent request, but it would be useful if we could test it out in the next two weeks in a staging area if that is possible. Thanks for your help!
> Product: FireFox OS (this would be new)
> Component: MCTS Waiver Request (this would be new)

For new components, we need a bit more information that just the name:
https://wiki.mozilla.org/BMO/Requesting_Changes#Products

Also, will there be other components in this product? Products with single components are not usually created, unless they need to belong to a specific security group.
Status: NEW → ASSIGNED
Flags: needinfo?(vchen)
Re: Comment 1, I mean, for both new products and new components we need the information outlined in the wiki. Sorry for the ambiguity.
Assignee: nobody → dylan
(In reply to Dylan William Hardison [:dylan] from comment #2)
> Re: Comment 1, I mean, for both new products and new components we need the
> information outlined in the wiki. Sorry for the ambiguity.

Hi Dylan, sorry, my bad, the product "FireFox OS" is not a new one but an exist product name. 

As here is the detail information of the new component "MCTS Waiver Request"

The name: MCTS Waiver Request

Description:This component is use to identify the MCTS(Mozilla Certification Test Suite) waiver request submitted by TAM for each partner

Default assignee : 'nobody@mozilla.org'

CC-ed Email addresses : fxos-cert@mozilla.com

Please let me know shall you need more information
Flags: needinfo?(vchen) → needinfo?(dylan)
Blocks: 1009912
Thanks! I believe that is everything I need.
Flags: needinfo?(dylan)
Noticed in my testing and re-reading the initial request that there is something I do not understand.

Can you explain in more detail how the Engineering Analysis field is suppose to operate?

If it is not filled in, you would like a "Need Info" flag to be set on "specific person" other than the TAM, how does the form know which person is the specific person?

Thanks!
Flags: needinfo?(vchen)
(In reply to Dylan William Hardison [:dylan] from comment #5)
> Noticed in my testing and re-reading the initial request that there is
> something I do not understand.
> 
> Can you explain in more detail how the Engineering Analysis field is suppose
> to operate?
> 
> If it is not filled in, you would like a "Need Info" flag to be set on
> "specific person" other than the TAM, how does the form know which person is
> the specific person?
> 
> Thanks!

Thanks for catching this Dylan. I think the origin description is incorrect. if this filed is not filled in, a TAM should be flag as "Need Info". I think for now we can just need info me when the Engineering Analysis filed is left unfilled. Let's wait for Karen's comment

ni Karen. Hi Karen, I am thinking if the Engineering Analysis in not filled, it might either mean there is no need to provide engineering analysis(this is not a engineering waiver), or the submitter simply don't know hot to fill it, either case, need info a TAM would be necessary to double check. So I think maybe we can just need info me when the Engineering Analysis filed is not filled? What do you think?

Thanks

Vance
Flags: needinfo?(vchen) → needinfo?(kward)
Keywords: bmo-big
Priority: -- → P1
The form is up on https://bugzilla-dev.allizom.org/form.fxos.mcts.waiver for testing purposes.
Currently, I am not sure that needinfo? on a specific user makes sense in form code -- but otherwise the functionality is there to test.
Flags: needinfo?(dylan)
(In reply to Dylan William Hardison [:dylan] from comment #7)
> The form is up on https://bugzilla-dev.allizom.org/form.fxos.mcts.waiver for
> testing purposes.
> Currently, I am not sure that needinfo? on a specific user makes sense in
> form code -- but otherwise the functionality is there to test.

Still testing, but the branding tiers have changed since Vance submitted the bug.  Can you change this to reflect 3 values instead of 2.  The list should be:
Firefox OS Inside
Powered by Firefox OS
Firefox OS Co-branded.
The bug created by this form should be Mozilla Confidential (only available to Mozilla staff)
and
Can you create the Engineering Analysis and TAM Recommendation fields when the bug is created?  The person submitting the initial request should not see or enter anything in those fields.
Flags: needinfo?(kward)
(In reply to Karen Ward [:kward] from comment #9)
> The bug created by this form should be Mozilla Confidential (only available
> to Mozilla staff)
No problem!

> Can you create the Engineering Analysis and TAM Recommendation fields when
> the bug is created?  The person submitting the initial request should not
> see or enter anything in those fields.

I'm not sure I follow here. Would these be fields on show_bug? That is, after the bug is created you'd visit the bug and there would be fields for this? This almost sounds like a review flag-type thing.

Forms only create new bugs; modifying existing ones with specific fields is not something forms typically do.
Flags: needinfo?(kward)
(In reply to Dylan William Hardison [:dylan] from comment #10)
> (In reply to Karen Ward [:kward] from comment #9)
> > The bug created by this form should be Mozilla Confidential (only available
> > to Mozilla staff)
> No problem!
> 
> > Can you create the Engineering Analysis and TAM Recommendation fields when
> > the bug is created?  The person submitting the initial request should not
> > see or enter anything in those fields.
> 
> I'm not sure I follow here. Would these be fields on show_bug? That is,
> after the bug is created you'd visit the bug and there would be fields for
> this? This almost sounds like a review flag-type thing.
> 
> Forms only create new bugs; modifying existing ones with specific fields is
> not something forms typically do.

So can the form create the empty fields even though the fields are not displayed to the user who initially completes the form?
Flags: needinfo?(kward)
We cannot created additional fields on the bug for a form like this. What could be done, is the form (sans TAM recommendation and Engineering Analysis) is used to post a bug, and instead of using comment #1 / comment #2 for the recommendations the user story field is updated.

Another possibility is that comments 1 and 2 are just added as normal, but it really depends on what the work flow for this is going to be.
Flags: needinfo?(dylan)
Reviewed & approved proposal to include space in the User Story for the Engineering Analysis and TAM recommendation via vidyo.  Will change the labels to: Mozilla Engineering Analysis and Mozilla Technical Account Manager Recommendation.
Revised form up for review. It provides a default template into the UserStory field.
The UserStory field can be edited by anyone with editbugs (the kward@mozilla.com account on bugzilla-dev was not a member of editbugs previously, so that is why it was not editable.)

Let me know if this needs any other changes!
Flags: needinfo?(kward)
I'm ready to submit a waiver request from one of our partner.
Please let me know when the template is ready to be used or add me to the system
Thanks
Vance, I am ok with this.  If you are too, please indicate that in this bug so that Dylan can make it live in production.
Flags: needinfo?(vchen)
Hi (In reply to Karen Ward [:kward] from comment #16)
> Vance, I am ok with this.  If you are too, please indicate that in this bug
> so that Dylan can make it live in production.

Hi Karen, Dylan, the form looks good to me, let launch it~

Thanks
Flags: needinfo?(vchen)
Flags: needinfo?(kward)
Flags: needinfo?(dylan)
Simple form to review.
Attachment #8470281 - Flags: review?(glob)
Flags: needinfo?(dylan)
Component: Administration → Custom Bug Entry Forms
Version: Development/Staging → Production
Comment on attachment 8470281 [details] [diff] [review]
bug-1033897-v2.patch

Review of attachment 8470281 [details] [diff] [review]:
-----------------------------------------------------------------

r=glob

::: extensions/BMO/template/en/default/bug/create/create-fxos-mcts-waiver.html.tmpl
@@ +42,5 @@
> +  font-size: 1em;
> +}
> +.yui-calcontainer {
> +  z-index: 2;
> +}

this can be removed as calendar isn't used here

@@ +90,5 @@
> +   style = inline_style
> +   javascript = inline_javascript
> +   javascript_urls = [ 'extensions/BMO/web/js/form_validate.js',
> +                       'js/field.js', 'js/util.js' ]
> +   yui = [ "autocomplete", "calendar", "selector" ]

none of these yui modules are used and can be removed.
Attachment #8470281 - Flags: review?(glob) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   d95aecb..d999330  master -> master
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
oops; yui selector _is_ used:
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   d999330..cf5c164  master -> master
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: