MozillaWiki - User contributions [en]

Mozilla.org/Demo Servers

2016-03-16T18:22:02Z

Espressive: Demo4 for new button styles testing

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1251283-update-hello-ftu-firefox-45 || Alex Gibson || 2016-03-08
|-
| http://www-demo2.allizom.org || bug-1250433-update-firefox-accounts-page || Alex Gibson || 2016-03-08
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || New Button Styles || Schalk Neethling || 2016-03-25
|-
| http://www-demo5.allizom.org || demo__jpetto || Jon Petto || 2015-03-18
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2016-02-24T08:20:36Z

Espressive: Taking demo4 for new infobar testing

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || global-passthrough || Josh Mize || 2016-01-30
|-
| http://www-demo2.allizom.org || bug-1239863-remove-legacy-firefox-os-pages || Alex Gibson || 2016-03-08
|-
| http://www-demo3.allizom.org || bug-1249042-firefox-newsletter-testing || Craig Cook || 2016-03-01
|-
| http://www-demo4.allizom.org || New InfoBar || Schalk Neethling || 2016-02-26
|-
| http://www-demo5.allizom.org || bug-1249752-firefox-sync-begin-fxa-signup || Jon Petto || 2015-02-26
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2016-01-07T11:32:24Z

Espressive: Update description for demo4

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188577-smarton-surveillance || Craig Cook || 2015-12-01
|-
| http://www-demo2.allizom.org || bug-1233773-tp-tour-close-tab || Alex Gibson || 2016-01-15
|-
| http://www-demo3.allizom.org || demo3-branch || Jon Petto || 2015-12-23
|-
| http://www-demo4.allizom.org || New Get Involved Hub & Lean Data || Schalk Neethling || 2015-01-21
|-
| http://www-demo5.allizom.org || || ||
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-12-16T07:53:26Z

Espressive: Extending need for demo4 server until end of wek

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188577-smarton-surveillance || Craig Cook || 2015-12-01
|-
| http://www-demo2.allizom.org || kyoshino-bug-1219957-mozilla-clients || Alex Gibson || 2015-12-04
|-
| http://www-demo3.allizom.org || demo3-branch || Jon Petto || 2015-12-18
|-
| http://www-demo4.allizom.org || contribute-signup2-v2-landing-and-tasks || Schalk Neethling || 2015-12-18
|-
| http://www-demo5.allizom.org || malena-bug-1182225-release-notes-redesign || Malena Andrade (via sgarrity) || 2015-11-27
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-11-12T04:32:47Z

Espressive: Taking demo4 for agile project

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188572-smarton || Craig Cook || 2015-10-16
|-
| http://www-demo2.allizom.org || kyoshino-bug-1216225-get-firefox-details || Alex Gibson || 2015-11-20
|-
| http://www-demo3.allizom.org || demo3-branch || Jon Petto || 2015-11-06
|-
| http://www-demo4.allizom.org || Contribute Agile Project || Schalk Neethling || 2015-11-24
|-
| http://www-demo5.allizom.org || bug-1221303-FFOS2.5-landing-page || Malena Andrade || 2015-11-09
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-10-27T13:49:29Z

Espressive: Taking demo4

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188572-smarton || Craig Cook || 2015-10-16
|-
| http://www-demo2.allizom.org || demo2-branch || Alex Gibson || 2015-10-03
|-
| http://www-demo3.allizom.org || bug-1208495-update-mozilla-news-signup-forms || Jon Petto || 2015-10-22
|-
| http://www-demo4.allizom.org || ga-dnt || Schalk Neethling || 2015-10-30
|-
| http://www-demo5.allizom.org || private/bug-1141846-patent-page || Malena Andrade || 2015-09-18
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-10-13T13:30:21Z

Espressive: /* Free demo4 server */

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188572-smarton || Craig Cook || 2015-10-16
|-
| http://www-demo2.allizom.org || demo2-branch || Alex Gibson || 2015-10-03
|-
| http://www-demo3.allizom.org || bug-1209569-gtm-updates || Jon Petto || 2015-09-30
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || private/bug-1141846-patent-page || Malena Andrade || 2015-09-18
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-09-30T13:16:05Z

Espressive: /* Taking demo4 for fall campaign */

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1188572-smarton || Craig Cook || 2015-10-16
|-
| http://www-demo2.allizom.org || demo2-branch || Alex Gibson || 2015-10-03
|-
| http://www-demo3.allizom.org || bug-1209569-gtm-updates || Jon Petto || 2015-09-30
|-
| http://www-demo4.allizom.org || bug1205357-fall-campaign-landing-page || Schalk Neethling || 2015-10-10
|-
| http://www-demo5.allizom.org || private/bug-1141846-patent-page || Malena Andrade || 2015-09-18
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-05-12T20:27:32Z

Espressive: Freeing demo4

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || integration_gtm || Gareth Cull || 2015-04-30
|-
| http://www-demo2.allizom.org || demo2-spring-campaign || Alex Gibson || 2015-06-02
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || jpetto-demo5 || Jon Petto || 2015-06-02
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || To be determined - Firefox Onramp || Mike Hoye || 2015-05-01 to 14
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-05-08T16:23:04Z

Espressive: Taking demo 4 for the WOM page.

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-30
|-
| http://www-demo2.allizom.org || demo2-spring-campaign || Alex Gibson || 2015-06-02
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || https://github.com/mozilla/bedrock/pull/2950 [Bug 1150328] || Schalk Neethling || 2015-05-11
|-
| http://www-demo5.allizom.org || spring campaign || Jon Petto || 2015-06-02
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-04-07T18:39:55Z

Espressive: demo5 is free

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-10
|-
| http://www-demo2.allizom.org || bug-1137805-reading-list-ftu || Alex Gibson || 2015-04-10
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || bug-1068067-mozid-logo || Cory Price || 2015-04-03
|-
| http://www-demo5.allizom.org || || ||
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-04-07T14:06:35Z

Espressive: takeing demo 5 and updating available date

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-10
|-
| http://www-demo2.allizom.org || bug-1137805-reading-list-ftu || Alex Gibson || 2015-04-10
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || bug-1068067-mozid-logo || Cory Price || 2015-04-03
|-
| http://www-demo5.allizom.org || bug1121460-move-plugincheck-clientside-into-bedrock|| espressive || 2015-04-13
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || || ||
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-04-07T11:34:52Z

Espressive: /* Mozilla.org Demo Servers */

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-10
|-
| http://www-demo2.allizom.org || bug-1137805-reading-list-ftu || Alex Gibson || 2015-04-10
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || bug-1068067-mozid-logo || Cory Price || 2015-04-03
|-
| http://www-demo5.allizom.org || kyoshino-bug-1129624-refactor-download-links|| jgmize || 2015-03-27
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || || ||
|-
| http://www-demo2.allizom.org || || ||
|-
| http://www-demo3.allizom.org || || ||
|-
| http://www-demo4.allizom.org || || ||
|-
| http://www-demo5.allizom.org || bug1121460-move-plugincheck-clientside-into-bedrock || espressive || 2015-04-07
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-04-07T11:33:58Z

Espressive: table update

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-10
|-
| http://www-demo2.allizom.org || bug-1137805-reading-list-ftu || Alex Gibson || 2015-04-10
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || bug-1068067-mozid-logo || Cory Price || 2015-04-03
|-
| http://www-demo5.allizom.org || kyoshino-bug-1129624-refactor-download-links|| jgmize || 2015-03-27
|}

{| class="wikitable"
|-
! Reserve a Server !! Branch !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || ||
|-
| http://www-demo2.allizom.org || ||
|-
| http://www-demo3.allizom.org || ||
|-
| http://www-demo4.allizom.org || ||
|-
| http://www-demo5.allizom.org || bug1121460-move-plugincheck-clientside-into-bedrock || espressive || 2015-04-07
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-04-07T11:32:56Z

Espressive: Requesting demo5 server for plugincheck

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || ap-gtm-demo1 || Gareth Cull || 2015-04-10
|-
| http://www-demo2.allizom.org || bug-1137805-reading-list-ftu || Alex Gibson || 2015-04-10
|-
| http://www-demo3.allizom.org || bug-1142147-content-services || Steven Garrity || 2015-04-30
|-
| http://www-demo4.allizom.org || bug-1068067-mozid-logo || Cory Price || 2015-04-03
|-
| http://www-demo5.allizom.org || kyoshino-bug-1129624-refactor-download-links|| jgmize || 2015-03-27
|}

{| class="wikitable"
|-
! Reserve a Server !! Contact !! Dates Needed
|-
| http://www-demo1.allizom.org || ||
|-
| http://www-demo2.allizom.org || ||
|-
| http://www-demo3.allizom.org || ||
|-
| http://www-demo4.allizom.org || ||
|-
| http://www-demo5.allizom.org || bug1121460-move-plugincheck-clientside-into-bedrock || espressive || 2015-04-07
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Mozilla.org/Demo Servers

2015-02-18T18:47:17Z

Espressive: /* Mozilla.org Demo Servers */

=== Mozilla.org Demo Servers ===

{| class="wikitable"
|-
! Server !! Branch !! Contact !! Free On
|-
| http://www-demo1.allizom.org || bug-1120686-mwc-partners || Steven Garrity || 2015-03-03
|-
| http://www-demo2.allizom.org || hello-tours || Alex Gibson || 2015-02-29
|-
| http://www-demo3.allizom.org || bug1120700 new firefox/os design impl || Schalk Neethling || 2015-02-29 ||
|-
| http://www-demo4.allizom.org || automate-mozid-data-tableau-1116511 || Paul McLanahan || 2015-02-20
|-
| http://www-demo5.allizom.org || bug-1128726-firstrun-experiments || Jon Petto || 2015-02-13
|}

=== Reference Links ===
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdE5JMDZGdFl2MWFHdE9YbXFxV3JSQWc&usp=sharing#gid=0 Project Dashboard]
* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=1802733#BedrockCluster%28www.mozilla.org%29-Update/Pushprocedure Demo Server Admin Links] (access required)

Platform/Projects/BuddyUp/SprintsQA/November-25-2014

2014-11-25T09:39:11Z

Espressive: /* More clarifying questions */

== SprintsQA ==

November-25-2014

[https://trello.com/b/GhThgP6h/buddy-up-schedule-phase-1 Trello board for sprint details]

=== Temp sprint (11/11 - 11/25) ===

* [DONE] As a Helpee, I receive confirmation that my question was submitted so that I am confident it will be addressed.
* [DONE] As a FxOS BuddyUp Mobile client user I can launch the BuddyUp app so that I can provide help.
* [DONE] [S] As a helper I can select a question so that I can add a comment and get visual confirmation of submission.
* [DONE] [S] As a Helper, I can see a list of help requests, so that I can decide which request I want to address.
* [DONE] [S] As a Helpee, I get assigned a random display name as a concatenation of an adjective and an animal name (similar to Google Doc) so that I can be identified by other users.
* [DONE] As a Helpee, I can see my previous questions
* [DONE] As a Helper, I can set a friendly name, my preferred languages, my preferred operator and my preferred handset, so that I can define my profile.
* [DONE] As a Helpee, I can set a friendly name, so that I can decide how other users identify me.

=== Asking Questions advanced (11/25 - 12/09) ===

* [M] As a Helpee, I want my help request to be categorized automatically based on my OS language, my OS version, my handset type and my operator, so that my help request gets answered more quickly and efficiently.
* [S] As a Helpee I can mark as helpful a specific comment, so that I can notify the helper that his comment helped me.
* [S] As a Helpee I can mark a comment as resolution of a discussion thread I created, so that I can notify the helper that I have an answer to my question and I stop receiving notifications.
* [M][Front End] As a Helpee, I get a OS notification when someone added a comment on one of my discussion threads, so that I can review it quickly.
* [S][Front End] As a helper I receive OS notifications when new comments are added by the Help Requester on a thread I already commented, so that I can provide further clarifications.

=== Questions ===

1) For the first item I am guessing we are going to mock mozSettings for the three items we are interested in and then once https://bugzilla.mozilla.org/show_bug.cgi?id=846200 land, we can update the manifest and use mozSettings directly, correct?

2) On the second item, there seems to be a contradiction in the UX document on the page 'Helpee - Mark a Comment as Helpful'. Under the first screen it states "User has asked a question and found the response to be helpful." but then on the side notes it states "A helpee can only mark a comment as helpful in a question that is not their own." - I am taking this simply as an oversight and that anyone can actually mark a comment as helpful. The general flow being, tap the thumbs up, the icon turns to an active state, the count is incremented by one and the new count is sent to the server.

What happens when the user taps the icon again though? It is easy enough when the user has not left the thread, closed the app etc. but, once the user has navigated to a different context/view and returns to the question thread, we need to know which comments the user has already marked as useful so that:

1. We can set the relevant icons to an active state
2. Decrement the count if the user taps on a thumbs up icon of a comment they have already marked as helpful and set the icon back to it's inactive state.

Currently I do not see any correlation between helpful votes given and the user(s) who voted.

3) Just making sure I am clear on this one.

* The option to mark a comment as the answer will only be visible to the Helpee the asked the question?
* There can only be one comment marked as the answer?
* Once the question has been marked as answered, no more comments are allowed and the 'receive notifications' checkbox field is remove[disabled]?
* In the UX doc it mentions 'Once a question has been marked solved it will appear in the suggested answers list.' Is this a list that will be managed on the server or, is it simply the list we will get if we call the Questions API with is_solved = true?

4) I have a general question regarding notifications. I know that we have decided for phase 1, unless the user is on the thread that received and update, we are sticking all notifications in the tray. My question regarding this is, when the user then taps on the notification in the tray, what happens next?

So, the notification event itself will wake the app so, will tapping the notification simply bring the app to the foreground? If so, we run into this issue of the app opening up, there is something new, but we do not provide the user with any indication o what is new. Am I missing something?

Platform/Projects/BuddyUp/SprintsQA/November-25-2014

2014-11-25T09:34:48Z

Espressive: /* Questions regarding the next sprint */

== SprintsQA ==

November-25-2014

[https://trello.com/b/GhThgP6h/buddy-up-schedule-phase-1 Trello board for sprint details]

=== Temp sprint (11/11 - 11/25) ===

* [DONE] As a Helpee, I receive confirmation that my question was submitted so that I am confident it will be addressed.
* [DONE] As a FxOS BuddyUp Mobile client user I can launch the BuddyUp app so that I can provide help.
* [DONE] [S] As a helper I can select a question so that I can add a comment and get visual confirmation of submission.
* [DONE] [S] As a Helper, I can see a list of help requests, so that I can decide which request I want to address.
* [DONE] [S] As a Helpee, I get assigned a random display name as a concatenation of an adjective and an animal name (similar to Google Doc) so that I can be identified by other users.
* [DONE] As a Helpee, I can see my previous questions
* [DONE] As a Helper, I can set a friendly name, my preferred languages, my preferred operator and my preferred handset, so that I can define my profile.
* [DONE] As a Helpee, I can set a friendly name, so that I can decide how other users identify me.

=== Asking Questions advanced (11/25 - 12/09) ===

* [M] As a Helpee, I want my help request to be categorized automatically based on my OS language, my OS version, my handset type and my operator, so that my help request gets answered more quickly and efficiently.
* [S] As a Helpee I can mark as helpful a specific comment, so that I can notify the helper that his comment helped me.
* [S] As a Helpee I can mark a comment as resolution of a discussion thread I created, so that I can notify the helper that I have an answer to my question and I stop receiving notifications.
* [M][Front End] As a Helpee, I get a OS notification when someone added a comment on one of my discussion threads, so that I can review it quickly.
* [S][Front End] As a helper I receive OS notifications when new comments are added by the Help Requester on a thread I already commented, so that I can provide further clarifications.

=== Questions ===

1) For the first item I am guessing we are going to mock mozSettings for the three items we are interested in and then once https://bugzilla.mozilla.org/show_bug.cgi?id=846200 land, we can update the manifest and use mozSettings directly, correct?

2) On the second item, there seems to be a contradiction in the UX document on the page 'Helpee - Mark a Comment as Helpful'. Under the first screen it states "User has asked a question and found the response to be helpful." but then on the side notes it states "A helpee can only mark a comment as helpful in a question that is not their own." - I am taking this simply as an oversight and that anyone can actually mark a comment as helpful. The general flow being, tap the thumbs up, the icon turns to an active state, the count is incremented by one and the new count is sent to the server.

What happens when the user taps the icon again though? It is easy enough when the user has not left the thread, closed the app etc. but, once the user has navigated to a different context/view and returns to the question thread, we need to know which comments the user has already marked as useful so that:

1. We can set the relevant icons to an active state
2. Decrement the count if the user taps on a thumbs up icon of a comment they have already marked as helpful and set the icon back to it's inactive state.

Currently I do not see any correlation between helpful votes given and the user(s) who voted.

3)

4) I have a general question regarding notifications. I know that we have decided for phase 1, unless the user is on the thread that received and update, we are sticking all notifications in the tray. My question regarding this is, when the user then taps on the notification in the tray, what happens next?

So, the notification event itself will wake the app so, will tapping the notification simply bring the app to the foreground? If so, we run into this issue of the app opening up, there is something new, but we do not provide the user with any indication o what is new. Am I missing something?

Platform/Projects/BuddyUp/SprintsQA/November-25-2014

2014-11-25T09:20:47Z

Espressive: /* Asking Questions advanced (11/25 - 12/09) */

== SprintsQA ==

November-25-2014

[https://trello.com/b/GhThgP6h/buddy-up-schedule-phase-1 Trello board for sprint details]

=== Temp sprint (11/11 - 11/25) ===

* [DONE] As a Helpee, I receive confirmation that my question was submitted so that I am confident it will be addressed.
* [DONE] As a FxOS BuddyUp Mobile client user I can launch the BuddyUp app so that I can provide help.
* [DONE] [S] As a helper I can select a question so that I can add a comment and get visual confirmation of submission.
* [DONE] [S] As a Helper, I can see a list of help requests, so that I can decide which request I want to address.
* [DONE] [S] As a Helpee, I get assigned a random display name as a concatenation of an adjective and an animal name (similar to Google Doc) so that I can be identified by other users.
* [DONE] As a Helpee, I can see my previous questions
* [DONE] As a Helper, I can set a friendly name, my preferred languages, my preferred operator and my preferred handset, so that I can define my profile.
* [DONE] As a Helpee, I can set a friendly name, so that I can decide how other users identify me.

=== Asking Questions advanced (11/25 - 12/09) ===

* [M] As a Helpee, I want my help request to be categorized automatically based on my OS language, my OS version, my handset type and my operator, so that my help request gets answered more quickly and efficiently.
* [S] As a Helpee I can mark as helpful a specific comment, so that I can notify the helper that his comment helped me.
* [S] As a Helpee I can mark a comment as resolution of a discussion thread I created, so that I can notify the helper that I have an answer to my question and I stop receiving notifications.
* [M][Front End] As a Helpee, I get a OS notification when someone added a comment on one of my discussion threads, so that I can review it quickly.
* [S][Front End] As a helper I receive OS notifications when new comments are added by the Help Requester on a thread I already commented, so that I can provide further clarifications.

=== Questions ===

1) For the first item I am guessing we are going to mock mozSettings for the three items we are interested in and then once https://bugzilla.mozilla.org/show_bug.cgi?id=846200 land, we can update the manifest and use mozSettings directly, correct?

2) On the second item, there seems to be a contradiction in the UX document on the page 'Helpee - Mark a Comment as Helpful'. Under the first screen it states "User has asked a question and found the response to be helpful." but then on the side notes it states "A helpee can only mark a comment as helpful in a question that is not their own." - I am taking this simply as an oversight and that anyone can actually mark a comment as helpful. The general flow being, tap the thumbs up, the icon turns to an active state, the count is incremented by one and the new count is sent to the server.

What happens when the user taps the icon again though? It is easy enough when the user has not left the thread, closed the app etc. but, once the user has navigated to a different context/view and returns to the question thread, we need to know which comments the user has already marked as useful so that:

1) We can set the relevant icons to an active state
2) Decrement the count if the user taps on a thumbs up icon of a comment they have already marked as helpful and set the icon back to it's inactive state.

Currently I do not see any correlation between helpful votes given and the user(s) who voted.

Platform/Projects/BuddyUp/SprintsQA/November-25-2014

2014-11-25T08:18:54Z

Espressive: Created page with "== SprintsQA == November-25-2014 [https://trello.com/b/GhThgP6h/buddy-up-schedule-phase-1 Trello board for sprint details] === Temp sprint (11/11 - 11/25) === * [DONE] As..."

Platform/Projects/BuddyUp

2014-11-25T08:09:30Z

Espressive: Created page with "BuddyUP - The live support app for FirefoxOS Content to be added."

BuddyUP - The live support app for FirefoxOS

Content to be added.

MozWeek/2014 Portland

2014-11-12T18:25:14Z

Espressive: /* Extra Curriculars */

'''What is it?''' -- multiple work weeks, happening in the same city, at the same time, all within a few city blocks of each other + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a giant party, Mozilla-style!

=='''Dates'''==
Monday, December 1st - Friday, December 5th, 2014 (travel days Monday & Saturday)

''For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on Monday the 8th if you choose.''

=='''Location'''==
Portland, Oregon, USA (various venues): https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0

* Weather Forecast: [http://forecast.weather.gov/MapClick.php?lat=45.517&lon=-122.683&unit=1 °C] or [http://forecast.weather.gov/MapClick.php?lat=45.517&lon=-122.683 °F]

=='''Attendees'''==
Because this event is a grouping of traditional team work weeks, only those Mozillians who would otherwise attend them will be invited (this includes core volunteers and Elancers). Contractors and seasonal staff will be invited at the discretion of the business unit.

===Volunteer Reimbursement via Reps===
Volunteers attending this event may submit for visa and U.S. travel/health insurance- related costs (and other incidentals) via Mozilla Reps:
* Mozilla Reps attending this event may submit for reimbursement through the [https://bugzilla.mozilla.org/form.reps.budget standard process].
* Mozillians who are not Mozilla Reps should contact a local Rep and the Rep will help them get reimbursed. The process is as follows:
** '''Step 1:''' contact a Rep [https://reps.mozilla.org/people/ in your country]*
** '''Step 2:''' once the Rep has accepted to process your reimbursement, give them an estimate of what your costs will be. If you need the funds beforehand, be sure to say that
** '''Step 3:''' after the event, send him/her all your scanned receipts and bank details/paypal account
** '''Step 4:''' inform the Rep once you have successfully received the funds

== '''Travel''' ==
All travel will be booked by our event company during registration (beginning September 29th ). DO NOT BOOK YOUR OWN TRAVEL OR HOTEL ROOM. We'll arrange transportation to/from the airport too.

Once you've registered, a travel agent will send you an email with 2-3 flight options. You will need to respond to that email within 24 hours to secure one of them (or suggest an alternative, provided it's within our travel policy guidelines).
=== Visa? ===
Check here to see if you need a visa: http://united-states.visahq.com/
=== Thanksgiving Travel Rush ===
Be aware that Sunday, November 30, is the Sunday following the US Thanksgiving holiday, and is therefore one of the busiest travel days of the year for domestic travel in the United States.

== '''Hotels & Meeting Space''' ==
The idea is that teams will stay in the same hotel. Won't be perfect, but we'll get as close as we can. All of the hotels are within walking distance from each other and from the Portland Art Museum. One (Marriot Waterfront) is a bit farther out (where we have a big chunk of rooms) so we'll likely have transportation to/from the PAM from there. You can see all hotels here: https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0.

=== wifi ===
* '''Portland Art Museum (all-hands space, mofo, engagement, IT, WPR)'''
** 100MB bandwidth (5 MB down/2 MB up per user)
** 26 access points (dualband 802.11ac)
** Ethernet switches and router
** Custom network.

* '''Marriott Waterfront (engineering hub)'''
** 100Mb bandwidth dedicated to the meeting space + extra 100MB dedicated (for 200 MB total)
** 18 Ruckus 7962 Zoneflex G access points each capable of carrying up to 500 users. The Ruckus Zone director 3000 series prevents dropping from AP to AP.

* '''Hilton (apps day, some engineering breakouts, content services, legal/bd/privacy)'''
** 71 Mbps of bandwidth dedicated to the meeting space exclusively.
** 35 access points (Cisco 1130G) with dynamic Allocation (roughly one+ per space)

*'''Heathman (HR/Finance, small number of breakouts)'''
** Total Bandwidth is 100 mb(down) x 20mb (up) - this is shared between all guests at the hotel.
** Free access is 3X1 with a 5x2 5 second burst.
=== white boards, projectors, access to central printer, etc.===
Will be available in all spaces. Process TBD.

== '''Airport Transportation''' ==

There will be Mozilla airport shuttles from the Portland airport ("PDX") to hotels for arrivals between 8:00 am and 10:00 pm on December 1.

There will be return Mozilla airport shuttles from hotels to PDX between 5:00 am and 2:00 pm on December 6 (there will be shuttles starting at Marriott Waterfront at 4:00 am for the 6:40 am flight to SFO)

More details coming soon about the shuttles and where to find them. We recommend leaving two hours or more before your flight.

These are transportation options for those arriving outside of the shuttle hours.

'''Light rail ("MAX")'''
* The MAX light rail Red Line is the easiest way to travel to and from the airport.
* The trip between the airport and downtown Portland takes about 38 minutes.
* An adult ticket costs $2.50 (Youth $1.65, Honored Citizen $1). MAX ticket machines return change in coins, so small bills are recommended.
* You can roll your luggage on board.
* The first train of the day arrives at PDX at 4:45 a.m. The last train departs PDX at 11:50 p.m.
* The MAX station and ticket machines are located on the lower level, next to the south baggage claim area (turn right at the base of the escalator).
* For complete schedules and more information, visit www.trimet.org/schedules/maxredline.htm

'''[http://www.bluestarbus.com/downtown-express.php Blue Star Bus Downtown Shuttle]'''
* Book online in advance
* $14 one way
* When leaving the airport, you can find the Downtown Airport Express and other hotel shuttle buses on the terminal’s lower roadway.

'''Taxi'''
* Should be used when two above options are not available
* $35 one way + tip ($3 - $5 is reasonable)
* The one-way trip takes 20-40 minutes.
* Taxis will be waiting in the center section of the airport terminal’s lower roadway outside of baggage claim.
* To get back to the airport from the city center, you can order a cab through the city’s main operators or from a hotel with a dedicated taxi stand.

'''If you are arriving during shuttle hours, please take the shuttle, we are saving a spot for you!'''

=='''Time Blocks''' (subject to change)==

Work week schedule (will be updated): https://docs.google.com/a/mozilla.com/spreadsheets/d/12K2OIUKAURjtQOcOMcPCOi4qeB1i80UWCA4EZLX94b4/edit#gid=0

'''Monday''':
* 5:00pm - 8:00pm (cocktails, informal)

'''Tuesday + Wednesday''':
* All-hands block: 9:00am - 11:00am PT
* Work week blocks:
** 11:00am - 2:00pm
** 2:00pm - 5:00pm (some spaces are available until 4:00pm only)
** 5:00pm - 8:00pm (dinner reservations will likely start at 6:30pm)

'''Thursday'''
* Work week blocks (we have a reduced number of meeting spaces so there will be shuffling):
** 8:00am - 11:00am
** 11:00am - 2:00pm
** 2:00pm - 5:00pm (some spaces are available until 4:00pm only)
** 5:00pm - 8:00pm (dinner reservations will likely start at 6:30pm)

'''Friday'''
* Work week blocks (we have a reduced number of meeting spaces so there will be shuffling):
** 8:00am - 11:00am
** 11:00am - 2:00pm
** 2:00pm - 4:00pm
** 5:00pm - late (dinner + closing + after party)

===Sessions===
If you have one to propose, add it here with a sign up link.

[https://etherpad.mozilla.org/web-media-mozlandia-2014 Teach us how to do web media on Air Mozilla] Possible super-team for all people who know about media and how to best put it on the web. Hosted by the Air Mozilla team who are eager to learn.

===Extra Curriculars===
If you have one to propose, add it here with a sign up link.

* '''Hockey!!!''' (ice, shinny style) - 8-9:15am on Thursday, Dec 4th - [https://etherpad.mozilla.org/mozlandia-hockey sign ups are full, waitlist available] -- feel free to come cheer/photograph
* '''SNOW Summit outing to Mount Hood''' (tentative) - [https://etherpad.mozilla.org/snow-summit-2014 Sign up + Information Here]
* '''Zumba! With our very own Rowe Hoffer''' (We will do it if there is interest) - [https://etherpad.mozilla.org/PDXZumba Sign up + Information Here]
* '''Find running partners!''' - [http://goo.gl/forms/ouh00YmVIt Sign up Here]
* '''Ping Pong!!!''' - There are loads of great places where Mozillians can play ping pong. And if we have enough signed up, we'll organize a tournament! [https://etherpad.mozilla.org/PDX-pingpong-extravaganza Sign up + Information Here]
* '''Indoor Kart Racing''' - Evenings Monday-Thursday (tentative) [https://etherpad.mozilla.org/portland-indoor-karting-2014-12 Interested? SIGN UP!]
* '''Homozilla''' (LGBTQ Mozillians and allies) will be doing a couple of [https://etherpad.mozilla.org/homozilla-night-out social things]
* '''Scotch, Whiskey, Bourbon!''' - Evening pub crawls to taste the best of Portland's brown. [https://etherpad.mozilla.org/pdx-brown-tour Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Beer!''' - Evening pub crawls to taste the best of Portland's beer. [https://etherpad.mozilla.org/pdx-beer-tour Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Crossfit''' - After a night of drinking, come work out and try not to puke :) [https://etherpad.mozilla.org/pdx-crossfit Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Christians''' - Early morning [https://etherpad.mozilla.org/christians-in-portland prayer and fellowship]
* '''Board/Card Games''' - [https://etherpad.mozilla.org/portland-board-games organize here]
* '''UI/UX <3''' - Calling all UI and UX Mozillians. Let's carve out a hour or more to get together during Mozlandia for free hugs, good conversation and all the things that make our minds tick. [http://goo.gl/forms/y7LYr4MRuO Signup open to all]

=== '''Food''' ===
Portland has an amazing [http://en.wikipedia.org/wiki/Foodie foodie] culture and some of the coolest [http://www.foodcartsportland.com/ food carts] around. Rather than serve up standard conference fare for the whole week we're going to mix it up a bit. Some of our meals will be catered (hard to get out of that entirely), some won't. Some will be paid for centrally (meaning no cash/credit card needed), some won't (meaning you'll need to pay and submit for reimbursement). If paying up front for a meal that is not provided is not something you can reasonably do, please contact your manager OR, if you're a volunteer, the person that invited you to their work week.

==== Breakfast ====
* '''Tuesday/Wednesday''', breakfast will be catered and provided at the PAM (our all-hands session starts there at 9:00am, so breakfast will be available by 7:30am).
* '''Thursday/Friday''', breakfast will be catered and provided within each of the hotels where we have work week breakout space (Hilton, Marriott Waterfront, and Heathman).
* You may want to try coffee from [http://stumptowncoffee.com/location/portland/ Stumptown] at some point, and a donut or two from [http://voodoodoughnut.com VooDoo] both of which are distinctly Portland.
<blockquote>If you want donuts, you're much better off with [http://www.bluestardonuts.com/ Blue Star]. If you want coffee, Stumptown is OK, but try Coffeehouse Northwest, or Courier, or Public Domain, or Sterling, or Water Avenue, or any number of more interesting, small cafes.

Sincerely,
Portland.</blockquote>

==== Lunch ====
Mozillians are encouraged to head to the food cart center for lunch (although you'll need to pay for this on your own and submit for reimbursement). It's walking distance from most of our work week hotels and from the PAM. You can find it on this map (or ask a native): https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0.

For those folks working out of the Marriott Waterfront, the food cart center is a bit of a walk. So, we're going to bring the carts to you.

In some cases (TBD) on some days, we'll provide catered lunches. More on this soon.

==== Dinner ====

===== '''Monday'''=====
There will be a cocktail party reception at the Portland Art Museum that starts at 6:00pm. There will be lots of great appetizers there as well as, well, cocktails (we'll have juice and sparkly water too). While it's not a formal dinner, it's likely enough to get you started. We have no other dinner plans for Monday evening so if you need more food, you'll need to head to a nearby restaurant (the range of expense expected for dinner is between $30 - $40 USD per person).

===== '''Tuesday, Wednesday, Thursday'''=====
So we can experience a bit of Portland, and still stay within our budget, we've arranged for three-evenings of Portland dine-arounds. Dine-arounds are a collection of local restaurants that have agreed to feed us a pre-set menu for a fixed price (includes one drink, the rest is up to you). In each case, depending on which restaurant you choose, your meal is pre-paid by Mozilla (you don't need to bring cash unless you want extras). We have enough seats each evening to cover about 75% of us, understanding there will be folks with other plans.

* Most of the restaurants are within walking distance of the Portland Art Museum and where they aren't, you can cab it or take public transit. Our reservations times vary but generally start after 6:00pm. Specific times will be noted on the Dine-Around sign-up sheet.

* Dietary restrictions can be accommodated. We have listed these under each restaurant and will update as we have more information. The only exceptions would be the restaurants doing buffets. There may be options, but no modifications. Let us know if you have specific accommodations needed and we can suggest some options.

* In some cases, menus have not been posted. Many restaurants use fresh, local, in season ingredients and won't know what they will feature until mid-month. We'll update the document as we get more information.

* If a restaurant is at its max and you'd still like to dine there, please add your name anyway. In lots of cases, restaurants can accommodate more than they've indicated. We wanted to start with a conservative estimate.

'''SIGN-UPS''': http://mzl.la/signups (pro tip: this link will take you to an un-editable version if you try to access it from a non-Mozilla Google account OR if you have a non-Mozilla and a Mozilla account open in the same browser session).

'''MENUS/RESTAURANT DETAIL''': http://mzl.la/menus

===== '''Friday''' =====
AMAZING dinner + party at Pure Space. Save your calories for this. We'll eat at about 7:30pm (although the party starts at 6:00pm).

==== Snacks ====
These will be provide at each of the work week sites (other than our office, where there are snacks already) at stations throughout the space.

== Your Old Phones Needed in Portland ==
Did you know that the estimated 500,000 mobile devices discarded daily can have another life improving someone's life?

[http://medicmobile.org/ Medic Mobile], a not-for-profit that seeks to advance healthcare in 16 countries with mobile technology (their app in the Firefox Marketplace here: https://marketplace.firefox.com/app/medic-mobile) recycles any type of mobile device through their Hope Phones program (https://hopephones.org/) to fund public health program around the world.

They need your help. '''Let's collect 1,000 old phones to the Mozilla offsite''' to empower health workers and improve the lives of many more. Bring your old Blackberry, StarTac, Chocolate, Galaxy or anonymous device to Portland and help us show that Mozilla cares. We'll have collections points around the offsite for easy drop-off.

Many thanks. Questions: Pete Scanlon (pscanlon@mozilla.com)
== FAQ ==
Please add your questions to this document: https://docs.google.com/a/mozilla.com/document/d/1g-KqjCWwjJtgYHJYuFXgWYW9i0MY234_tMRPbXxq5Jc/edit

== Links ==
* Guest speaker suggestions: https://etherpad.mozilla.org/workweekspeakers
* Fun things to do suggestions: https://etherpad.mozilla.org/hogwarts

MozWeek/2014 Portland

2014-11-11T09:11:16Z

Espressive: /* Extra Curriculars */

'''What is it?''' -- multiple work weeks, happening in the same city, at the same time, all within a few city blocks of each other + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a giant party, Mozilla-style!

=='''Dates'''==
Monday, December 1st - Friday, December 5th, 2014 (travel days Monday & Saturday)

''For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on Monday the 8th if you choose.''

=='''Location'''==
Portland, Oregon, USA (various venues): https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0

* Weather Forecast: [http://forecast.weather.gov/MapClick.php?lat=45.517&lon=-122.683&unit=1 °C] or [http://forecast.weather.gov/MapClick.php?lat=45.517&lon=-122.683 °F]

=='''Attendees'''==
Because this event is a grouping of traditional team work weeks, only those Mozillians who would otherwise attend them will be invited (this includes core volunteers and Elancers). Contractors and seasonal staff will be invited at the discretion of the business unit.

===Volunteer Reimbursement via Reps===
Volunteers attending this event may submit for visa and U.S. travel/health insurance- related costs (and other incidentals) via Mozilla Reps:
* Mozilla Reps attending this event may submit for reimbursement through the [https://bugzilla.mozilla.org/form.reps.budget standard process].
* Mozillians who are not Mozilla Reps should contact a local Rep and the Rep will help them get reimbursed. The process is as follows:
** '''Step 1:''' contact a Rep [https://reps.mozilla.org/people/ in your country]*
** '''Step 2:''' once the Rep has accepted to process your reimbursement, give them an estimate of what your costs will be. If you need the funds beforehand, be sure to say that
** '''Step 3:''' after the event, send him/her all your scanned receipts and bank details/paypal account
** '''Step 4:''' inform the Rep once you have successfully received the funds

== '''Travel''' ==
All travel will be booked by our event company during registration (beginning September 29th ). DO NOT BOOK YOUR OWN TRAVEL OR HOTEL ROOM. We'll arrange transportation to/from the airport too.

Once you've registered, a travel agent will send you an email with 2-3 flight options. You will need to respond to that email within 24 hours to secure one of them (or suggest an alternative, provided it's within our travel policy guidelines).
=== Visa? ===
Check here to see if you need a visa: http://united-states.visahq.com/
=== Thanksgiving Travel Rush ===
Be aware that Sunday, November 30, is the Sunday following the US Thanksgiving holiday, and is therefore one of the busiest travel days of the year for domestic travel in the United States.
=== Your Old Phones Needed in Portland ===
Did you know that the estimated 500,000 mobile devices discarded daily can have another life improving someone's life?

[http://medicmobile.org/ Medic Mobile], a not-for-profit that seeks to advance healthcare in 16 countries with mobile technology (their app in the Firefox Marketplace here: https://marketplace.firefox.com/app/medic-mobile) recycles any type of mobile device through their Hope Phones program (https://hopephones.org/) to fund public health program around the world.

They need your help. '''Let's collect 1,000 old phones to the Mozilla offsite''' to empower health workers and improve the lives of many more. Bring your old Blackberry, StarTac, Chocolate, Galaxy or anonymous device to Portland and help us show that Mozilla cares. We'll have collections points around the offsite for easy drop-off.

Many thanks. Questions: Pete Scanlon (pscanlon@mozilla.com)

== '''Hotels & Meeting Space''' ==
The idea is that teams will stay in the same hotel. Won't be perfect, but we'll get as close as we can. All of the hotels are within walking distance from each other and from the Portland Art Museum. One (Marriot Waterfront) is a bit farther out (where we have a big chunk of rooms) so we'll likely have transportation to/from the PAM from there. You can see all hotels here: https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0.

=== wifi ===
* '''Portland Art Museum (all-hands space, mofo, engagement, IT, WPR)'''
** 100MB bandwidth (5 MB down/2 MB up per user)
** 26 access points (dualband 802.11ac)
** Ethernet switches and router
** Custom network.

* '''Marriott Waterfront (engineering hub)'''
** 100Mb bandwidth dedicated to the meeting space + extra 100MB dedicated (for 200 MB total)
** 18 Ruckus 7962 Zoneflex G access points each capable of carrying up to 500 users. The Ruckus Zone director 3000 series prevents dropping from AP to AP.

* '''Hilton (apps day, some engineering breakouts, content services, legal/bd/privacy)'''
** 71 Mbps of bandwidth dedicated to the meeting space exclusively.
** 35 access points (Cisco 1130G) with dynamic Allocation (roughly one+ per space)

*'''Heathman (HR/Finance, small number of breakouts)'''
** Total Bandwidth is 100 mb(down) x 20mb (up) - this is shared between all guests at the hotel.
** Free access is 3X1 with a 5x2 5 second burst.
=== white boards, projectors, access to central printer, etc.===
Will be available in all spaces. Process TBD.

=='''Time Blocks''' (subject to change)==

Work week schedule (will be updated): https://docs.google.com/a/mozilla.com/spreadsheets/d/12K2OIUKAURjtQOcOMcPCOi4qeB1i80UWCA4EZLX94b4/edit#gid=0

'''Monday''':
* 5:00pm - 8:00pm (cocktails, informal)

'''Tuesday + Wednesday''':
* All-hands block: 9:00am - 11:00am PT
* Work week blocks:
** 11:00am - 2:00pm
** 2:00pm - 5:00pm (some spaces are available until 4:00pm only)
** 5:00pm - 8:00pm (dinner reservations will likely start at 6:30pm)

'''Thursday'''
* Work week blocks (we have a reduced number of meeting spaces so there will be shuffling):
** 8:00am - 11:00am
** 11:00am - 2:00pm
** 2:00pm - 5:00pm (some spaces are available until 4:00pm only)
** 5:00pm - 8:00pm (dinner reservations will likely start at 6:30pm)

'''Friday'''
* Work week blocks (we have a reduced number of meeting spaces so there will be shuffling):
** 8:00am - 11:00am
** 11:00am - 2:00pm
** 2:00pm - 4:00pm
** 5:00pm - late (dinner + closing + after party)

===Sessions===
If you have one to propose, add it here with a sign up link.

[https://etherpad.mozilla.org/web-media-mozlandia-2014 Teach us how to do web media on Air Mozilla] Possible super-team for all people who know about media and how to best put it on the web. Hosted by the Air Mozilla team who are eager to learn.

===Extra Curriculars===
If you have one to propose, add it here with a sign up link.

* '''Hockey!!!''' (ice, shinny style) - 8-9:15am on Thursday, Dec 4th - [https://etherpad.mozilla.org/mozlandia-hockey SIGN UP! and more info]
* '''SNOW Summit outing to Mount Hood''' (tentative) - [https://etherpad.mozilla.org/snow-summit-2014 Sign up + Information Here]
* '''Zumba! With our very own Rowe Hoffer''' (We will do it if there is interest) - [https://etherpad.mozilla.org/PDXZumba Sign up + Information Here]
* '''Find running partners!''' - [http://goo.gl/forms/ouh00YmVIt Sign up Here]
* '''Ping Pong!!!''' - There are loads of great places where Mozillians can play ping pong. And if we have enough signed up, we'll organize a tournament! [https://etherpad.mozilla.org/PDX-pingpong-extravaganza Sign up + Information Here]
* '''Indoor Kart Racing''' - Evenings Monday-Thursday (tentative) [https://etherpad.mozilla.org/portland-indoor-karting-2014-12 Interested? SIGN UP!]
* '''Homozilla''' (LGBTQ Mozillians and allies) will be doing a couple of [https://etherpad.mozilla.org/homozilla-night-out social things]
* '''Scotch, Whiskey, Bourbon!''' - Evening pub crawls to taste the best of Portland's brown. [https://etherpad.mozilla.org/pdx-brown-tour Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Beer!''' - Evening pub crawls to taste the best of Portland's beer. [https://etherpad.mozilla.org/pdx-beer-tour Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Crossfit''' - After a night of drinking, come work out and try not to puke :) [https://etherpad.mozilla.org/pdx-crossfit Sign up + Information here] [http://bit.ly/1tuj04H Portland Fun Map]
* '''Christians''' - Early morning [https://etherpad.mozilla.org/christians-in-portland prayer and fellowship]
* '''Board/Card Games''' - [https://etherpad.mozilla.org/portland-board-games organize here]
* '''UI/UX <3''' - Calling all UI and UX Mozillians. Let's carve out a hour or more to get together during Mozlandia for free hugs, good conversation and all the things that make our minds tick. [Signup http://goo.gl/forms/y7LYr4MRuO]

=== '''Food''' ===
Portland has an amazing [http://en.wikipedia.org/wiki/Foodie foodie] culture and some of the coolest [http://www.foodcartsportland.com/ food carts] around. Rather than serve up standard conference fare for the whole week we're going to mix it up a bit. Some of our meals will be catered (hard to get out of that entirely), some won't. Some will be paid for centrally (meaning no cash/credit card needed), some won't (meaning you'll need to pay and submit for reimbursement). If paying up front for a meal that is not provided is not something you can reasonably do, please contact your manager OR, if you're a volunteer, the person that invited you to their work week.

==== Breakfast ====
* '''Tuesday/Wednesday''', breakfast will be catered and provided at the PAM (our all-hands session starts there at 9:00am, so breakfast will be available by 7:30am).
* '''Thursday/Friday''', breakfast will be catered and provided within each of the hotels where we have work week breakout space (Hilton, Marriott Waterfront, and Heathman).
* You may want to try coffee from [http://stumptowncoffee.com/location/portland/ Stumptown] at some point, and a donut or two from [http://voodoodoughnut.com VooDoo] both of which are distinctly Portland.
<blockquote>If you want donuts, you're much better off with [http://www.bluestardonuts.com/ Blue Star]. If you want coffee, Stumptown is OK, but try Coffeehouse Northwest, or Courier, or Public Domain, or Sterling, or Water Avenue, or any number of more interesting, small cafes.

Sincerely,
Portland.</blockquote>

==== Lunch ====
Mozillians are encouraged to head to the food cart center for lunch (although you'll need to pay for this on your own and submit for reimbursement). It's walking distance from most of our work week hotels and from the PAM. You can find it on this map (or ask a native): https://mapsengine.google.com/map/u/0/viewer?mid=zGDglM1VcNwI.khD1s_r2QdO0.

For those folks working out of the Marriott Waterfront, the food cart center is a bit of a walk. So, we're going to bring the carts to you.

In some cases (TBD) on some days, we'll provide catered lunches. More on this soon.

==== Dinner ====

===== '''Monday'''=====
There will be a cocktail party reception at the Portland Art Museum that starts at 6:00pm. There will be lots of great appetizers there as well as, well, cocktails (we'll have juice and sparkly water too). While it's not a formal dinner, it's likely enough to get you started. We have no other dinner plans for Monday evening so if you need more food, you'll need to head to a nearby restaurant (the range of expense expected for dinner is between $30 - $40 USD per person).

===== '''Tuesday, Wednesday, Thursday'''=====
So we can experience a bit of Portland, and still stay within our budget, we've arranged for three-evenings of Portland dine-arounds. Dine-arounds are a collection of local restaurants that have agreed to feed us a pre-set menu for a fixed price (includes one drink, the rest is up to you). In each case, depending on which restaurant you choose, your meal is pre-paid by Mozilla (you don't need to bring cash unless you want extras). We have enough seats each evening to cover about 75% of us, understanding there will be folks with other plans.

* Most of the restaurants are within walking distance of the Portland Art Museum and where they aren't, you can cab it or take public transit. Our reservations times vary but generally start after 6:00pm. Specific times will be noted on the Dine-Around sign-up sheet.

* Dietary restrictions can be accommodated. We have listed these under each restaurant and will update as we have more information. The only exceptions would be the restaurants doing buffets. There may be options, but no modifications. Let us know if you have specific accommodations needed and we can suggest some options.

* In some cases, menus have not been posted. Many restaurants use fresh, local, in season ingredients and won't know what they will feature until mid-month. We'll update the document as we get more information.

* If a restaurant is at its max and you'd still like to dine there, please add your name anyway. In lots of cases, restaurants can accommodate more than they've indicated. We wanted to start with a conservative estimate.

'''SIGN-UPS''': http://mzl.la/signups (pro tip: this link will take you to an un-editable version if you try to access it from a non-Mozilla Google account OR if you have a non-Mozilla and a Mozilla account open in the same browser session).

'''MENUS/RESTAURANT DETAIL''': http://mzl.la/menus

===== '''Friday''' =====
AMAZING dinner + party at Pure Space. Save your calories for this. We'll eat at about 7:30pm (although the party starts at 6:00pm).

==== Snacks ====
These will be provide at each of the work week sites (other than our office, where there are snacks already) at stations throughout the space.

== FAQ ==
Please add your questions to this document: https://docs.google.com/a/mozilla.com/document/d/1g-KqjCWwjJtgYHJYuFXgWYW9i0MY234_tMRPbXxq5Jc/edit

== Links ==
* Guest speaker suggestions: https://etherpad.mozilla.org/workweekspeakers
* Fun things to do suggestions: https://etherpad.mozilla.org/hogwarts

Breakpad/Status Meetings/2014-10-08

2014-10-08T18:07:49Z

Espressive: /* Travel, etc */

[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[Breakpad/Status_Meetings|index]] –
[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=Breakpad/Status_Meetings/Template create?]


== Meeting Info ==

Breakpad status meetings occur on Wed at 11:00am Pacific Time.

Conference numbers:
Vidyo: Stability
650-903-0800 x92 conf 98200#
800-707-2533 (pin 369) conf 98200#
IRC backchannel: #breakpad 
Mountain View: Dancing Baby (3rd floor) 

== Operations Updates ==

=== AWS ===

=== DB ===

=== ES ===

=== Other ===
* collectors are running a bad crashstorage class that is causing us to run out of inodes, config needs updating
* processor2015 is ready to test on stage and then ship
* lots of outages this week

== Project Updates ==
[https://crash-analysis.mozilla.com/rkaiser/socorro-bugs/2014.weeklybugs.html Socorro Bug Tracker] 
[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&target_milestone=106&product=Socorro this week's bugs]

=== PR Triage ===
* https://prs.paas.allizom.org/mozilla/socorro

== other business ==
* Mozilandia -- register for the work week if you haven't already
* LeeroyBot now a permanent channel resident. Propose changes via PRs here: https://github.com/Lonnen/leeroybot

== Travel, etc ==

* phrawzty @ tribe training Thu 9, Fri 10, Mon 13, Tue 14 October; Paris.
* schalk - out next week Tuesday [14 October] - Friday [17 October] (New York) | in MV 19 October - 25 October | out 26 October - 31 October [Boston UI19]

== Links ==

[[Category:Wikipage templates]]

Breakpad/Status Meetings/2014-10-01

2014-10-01T18:11:49Z

Espressive: /* Travel, etc */

[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[Breakpad/Status_Meetings|index]] –
[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=Breakpad/Status_Meetings/Template create?]


== Meeting Info ==

Breakpad status meetings occur on Wed at 11:00am Pacific Time.

Conference numbers:
Vidyo: Stability
650-903-0800 x92 conf 98200#
800-707-2533 (pin 369) conf 98200#
IRC backchannel: #breakpad 
Mountain View: Dancing Baby (3rd floor) 

== Operations Updates ==

=== AWS ===

=== DB ===

* Immediate requirement to patch all servers requiring security updates
* Performance health check, including digestion server? https://bugzilla.mozilla.org/show_bug.cgi?id=1072604
* Data expiration API
* Removing limits on text fields.

=== ES ===

=== Other ===
* Everything's getting rebooted today: note Jenkins, etherpad, phones, Zeus etc. generic memcache will be offline for 20 minutes

== Project Updates ==
[https://crash-analysis.mozilla.com/rkaiser/socorro-bugs/2014.weeklybugs.html Socorro Bug Tracker] 
[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&target_milestone=105&product=Socorro this week's bugs]

=== PR Triage ===
* https://prs.paas.allizom.org/mozilla/socorro

== other business ==

== Travel, etc ==

Schalk out at Tech4Africa [talk, running booth] Oct 8 - 9 (some of 7)

== Links ==

Breakpad/Status Meetings/2014-09-17

2014-09-17T18:09:22Z

Espressive: /* Travel, etc */

[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[Breakpad/Status_Meetings|index]] –
[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=Breakpad/Status_Meetings/Template create?]


== Meeting Info ==

Breakpad status meetings occur on Wed at 11:00am Pacific Time.

Conference numbers:
Vidyo: Stability
650-903-0800 x92 conf 98200#
800-707-2533 (pin 369) conf 98200#
IRC backchannel: #breakpad
Mountain View: Dancing Baby (3rd floor)

== Operations Updates ==

=== AWS ===

=== DB ===
* hardware has arrived, being installed

=== ES ===

=== Other ===

== Project Updates ==

[[Socorro:Releases|Socorro Release Tracker]] 
[https://crash-analysis.mozilla.com/rkaiser/socorro-bugs/2014.weeklybugs.html Socorro Bug Tracker]

=== Planned for this week ===
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&target_milestone=103&product=Socorro bugs]
<bugzilla>
{
"product": "Socorro",
"target_milestone": "103",
"include_fields": "id, summary, assigned_to, target_milestone, priority, status, resolution, whiteboard"
}
</bugzilla>

=== PR Triage ===
* https://prs.paas.allizom.org/mozilla/socorro

== other business ==
* https://etherpad.mozilla.org/webeng-q32014
* https://etherpad.mozilla.org/webeng-q42014
* Bramwelt is presenting this afternoon at 2 PST
* Bob wants you! https://etherpad.mozilla.org/webeng-workweek-2014-topics

== Travel, etc ==
* phrawzty PTO on 17 September (the day of this very meeting).
* lars likely out on Friday & Monday -- may be in PDX on Tuesday
* peterbe at pgopen Thursday and Friday
* mbrandt 1/2 day of pto on Friday -- tis desert season, heading to Utah
* schalk out on 24 September - Heritage Day

== Links ==

Webdev/GetInvolved

2014-07-15T12:59:42Z

Espressive: /* Website Projects */

Get involved with making Mozilla's web sites even better. This page lists contribution opportunities that you're welcome to work on.

Most of the code on our sites is HTML, CSS, JavaScript and Django (Python) and you can read about how we do web development in the [http://mozweb.readthedocs.org Webdev Bootcamp].

If you have questions or are unsure how you can help, just ask on the [https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.webdev webdev forum] (to sign up to the forum as a mailing list, go to [https://lists.mozilla.org/listinfo/dev-webdev lists.mozilla.org/listinfo/dev-webdev]) or [irc://irc.mozilla.org#webdev IRC in #webdev] or talk to [https://twitter.com/potch @potch], [https://twitter.com/groovecoder @groovecoder] or [https://twitter.com/r1cky @r1cky] on Twitter.

{{FeaturedProject
|icon=firefox-100.jpg
|pagelocation=Webdev/GetInvolved/mozilla.org
|pagetitle=Featured Project: Mozilla.org
|description=Mozilla.org is the main web property for Mozilla products. [[Webdev/GetInvolved/mozilla.org#Mentored_Bugs|View List Of Mentored Tasks]] and [[Webdev/GetInvolved/mozilla.org|Learn More]]
}}

= Website Projects =
=== [[Webdev/GetInvolved/mozilla.org | www.mozilla.org]] ===
Having retired the Mozilla.com domain, Mozilla.org is now the main web property for Mozilla products and Engagement. Firefox, Thunderbird, Apps, B2G, Identity and Privacy, plus Press Center, Get Involved and others live under this domain.

* [[Webdev/GetInvolved/mozilla.org | Find out more about how to get involved with www.mozilla.org]]

=== [[Webdev/GetInvolved/addons.mozilla.org | addons.mozilla.org (AMO)]] ===
The [https://addons.mozilla.org Firefox Add-ons site] is a gallery of available customizations for the Firefox Web Browser. This is our highest trafficked website (20K+ hits per second) and uses technology like Memcached, Elasticsearch, RabbitMQ and Celery, and more.

=== [[Marketplace/Contributing/Code | Firefox Marketplace / marketplace.firefox.com]] ===
[https://marketplace.firefox.com Firefox Marketplace] has an API built on Django and several frontends using JavaScript. Some of these frontends run on websites and some are pre-loaded onto devices, providing a rich portal for users to be able to buy and sell open web apps on their desktop and mobile devices.

=== [[Webdev/GetInvolved/air.mozilla.org | air.mozilla.org]] ===
[https://air.mozilla.org Air Mozilla] is the Internet multimedia presence of Mozilla, with live and pre-recorded shows, interviews, news snippets, tutorial videos, and features about the Mozilla community.

* [[Webdev/GetInvolved/air.mozilla.org | Find out more about how to get involved with air.mozilla.org]]

=== [[Webdev/GetInvolved/support.mozilla.org | support.mozilla.org (SUMO)]] ===
[http://support.mozilla.org Mozilla Support] is the support site for Mozilla products. It helps millions of users every week through a knowledge base and support forum. It also provides collaboration and localization tools for the contributors. It uses technology like Python, Django, MySQL, Redis, Memcached, Elasticsearch and more.

* [[Webdev/GetInvolved/support.mozilla.org | Find out more about how to get involved with support.mozilla.org (SUMO)]]

=== [[Webdev/GetInvolved/developer.mozilla.org | developer.mozilla.org (MDN)]] ===
The [http://developer.mozilla.org Mozilla Developer Network] is our technical resource for developers - including documentation and demos for Mozilla and open web technologies.

* [[Webdev/GetInvolved/developer.mozilla.org | Find out more about how to get involved with developer.mozilla.org (MDN)]]

See also: [https://github.com/groovecoder/wp-promote-mdn/ Promote MDN WordPress plugin]

=== [[Webdev/GetInvolved/crash-stats.mozilla.org | crash-stats.mozilla.org (Socorro) ]] ===
Socorro is a server to accept and process Breakpad crash reports from Firefox, Thunderbird, etc.

* [[Webdev/GetInvolved/crash-stats.mozilla.org | Find out more about how to get involved with crash-stats.mozilla.org (Socorro) ]]

=== [[Webdev/GetInvolved/mozillians.org | mozillians.org (Mozillians)]] ===
This is a great first project to get involved! [http://mozillians.org/ Mozillians] is our community directory for core Mozilla volunteers and staff. It's a tool used by everyone involved with Mozilla, and it's the primary way that Mozillians can find each other. There are both front-end and back-end development opportunities, and we have mentors from the team to guide you through your first contributions.

* [[Webdev/GetInvolved/mozillians.org | Find out more about how to get involved with mozillians.org]]

=== [[Webdev/GetInvolved/reps.mozilla.org |reps.mozilla.org (ReMo)]] ===
The [https://reps.mozilla.org/ Mozilla Reps site] is where Mozilla Reps report their activities and share the events they run. There are both front-end and back-end development opportunities, and we have mentors to help you with your first contributions.

* [[Webdev/GetInvolved/reps.mozilla.org |Find out more about how to get involved with reps.mozilla.org]]

=== [[Webdev/GetInvolved/input.mozilla.org | input.mozilla.org ]] ===
[https://input.mozilla.org/ Firefox Input] is the user feedback system.

* [[Webdev/GetInvolved/input.mozilla.org | Find out more about how to get involved with input.mozilla.org ]]

=== [[Webdev/GetInvolved/careers.mozilla.org | careers.mozilla.org ]] ===
[https://careers.mozilla.org/ Careers] is the Mozilla jobs listings system.

* [[Webdev/GetInvolved/careers.mozilla.org | Find out more about how to get involved with careers.mozilla.org ]]

=== [http://dxr.mozilla.org dxr.mozilla.org] ===
DXR is Mozilla's code search and navigation tool, aimed at making sense of large projects like Firefox. It supports full-text and regex searches as well as structural queries like "Find all the callers of this function." Behind the scenes, it uses trigram indices, the re2 library, and structural data collected by a custom compiler plugin. A great project for folks interested in parsers or search.

* [[DXR | Get started here.]]

=== [[Webdev/GetInvolved/PluginCheck | PluginCheck]] ===
Most user know Plugin Check from pointing their browsers to [https://mozilla.org/plugincheck mozilla.org/plugincheck] but, there is a lot more to it than a single web page. There are some really interesting and challenging problems to help solve, from QA automation to improving the flow of reporting plugin updates and a whole bunch of JavaScript to be improved.

[[Webdev/GetInvolved/PluginCheck | Find out how you can get involved with PluginCheck]]

= WordPress =
Mozilla runs a number of WordPress sites, and has developed a number of WordPress plugins.

* [[Webdev/GetInvolved/WordPress | Find out more about how to get involved with WordPress projects]]

= Libraries =

We've got lots of libraries we've written, many of which are looking for help.

=== [[Webdev/GetInvolved/django-browserid |django-browserid]] ===
Django library providing BrowserID/Persona based authentication.

* [[Webdev/GetInvolved/django-browserid |Find out more about how to get involved with django-browserid]]

=== [https://github.com/andymckay/django-paranoia django-paranoia] ===
Django library for warning people about attempted security intrusions.

=== [https://github.com/andymckay/django-statsd django-statsd] ===
Django library for creating metrics using Graphite and Statsd.

= Firefox OS =

If you are interested in HTML, CSS, and JavaScript, we could also use your help building our new [http://www.mozilla.org/firefoxos/ Firefox OS]. Find out more about how to help with that:

* https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking

= Learning Web Development =

If you're interested in learning more about web development and how the web works, you may be interested in our Webmaker project:

* https://webmaker.org/

== Monthly Challenges ==

Want to learn more about web development? Try your hand at the [https://developer.mozilla.org/demos/devderby Dev Derby], our monthly web development challenge. While some entries are very impressive, you absolutely do not need to be an expert to get started. In fact, many of our best contributors tell us that they knew nothing about the monthly topic before the challenge started.

= Web Technology Demos =

The [https://developer.mozilla.org/demos Mozilla Demo Studio] is a platform for showing the world what you can do with the Web. Not an expert? No problem. Some of the most interesting demos (like [https://developer.cdn.mozilla.net/media/uploads/demos/t/u/tuxie/fa3427d4b07c782f827580b5016550bc/santas-media-queries_1319913515_demo_package/index.html Santa's Media Queries]) are actually pretty simple under the hood. As long as you have a sense of creativity and a passion for making things better, we would love to have you.

= Contributor Achievements =

You will earn these distinct Mozilla Contributor Achievements:

{| border="1"
| Name
| Mozilla Webdev Fork
| Mozilla Webdev Pull request
| Mozilla Webdev Merge
| Mozilla Webdev Merge 10
| Mozilla Webdev Merge 25
| Mozilla Webdev Merge 50
| Mozilla Webdev Merge 100
|-
| Description
| Fork a Mozilla Webdev repository on GitHub
| Submit a Pull request to a Webdev repository on GitHub
| Finish a Pull request to successful merge
| Finish 10 Pull requests to successful merge
| Finish 25 Pull requests to successful merge
| Finish 50 Pull requests to successful merge
| Finish 100 Pull requests to successful merge
|-
| Possible Recognitions
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
|}

Webdev/GetInvolved/PluginCheck

2014-07-15T12:52:48Z

Espressive: Created page with "= Get Involved: PluginCheck = == Description == [https://mozilla.org/plugincheck PluginCheck] is the part of a three tiered system to ensure your plugins are up to date and w..."

= Get Involved: PluginCheck =

== Description ==
[https://mozilla.org/plugincheck PluginCheck] is the part of a three tiered system to ensure your plugins are up to date and when they are not, provides you with the needed assistance.

== Code ==
* Backend Database System ~ [https://github.com/mozilla/plugindir plugins.mozilla.org]
* [https://github.com/ossreleasefeed/Perfidies-of-the-Web Client JS]
* UI ~ [https://github.com/mozilla/bedrock mozilla.org/plugincheck]

== Contacts ==
* Who:
** Schalk Neethling (espressive)
* IRC: [irc://irc.mozilla.org/#plugincheck #plugincheck]

== Mentored Bugs ==
More to come soon

Breakpad/Status Meetings/2014-07-02

2014-07-02T15:56:46Z

Espressive: /* PTOs, etc */

Breakpad/Status Meetings/2014-07-02

2014-07-02T15:56:03Z

Espressive: Created page with " « previous meeting — index – [[Breakpad/Status_Meeting..."

Breakpad/Status Meetings/2014-06-11

2014-06-11T18:40:58Z

Espressive: /* PTOs, etc */

[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[Breakpad/Status_Meetings|index]] –
[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=Breakpad/Status_Meetings/Template create?]


== Meeting Info ==

Breakpad status meetings occur on Wed at 11:00am Pacific Time.

Conference numbers:
Vidyo: Stability
650-903-0800 x92 conf 98200#
800-707-2533 (pin 369) conf 98200#
IRC backchannel: #breakpad
Mountain View: Dancing Baby (3rd floor)
Notes: https://etherpad.mozilla.org/breakpad-2014-06-11

== Operations Updates ==
* https://bugzilla.mozilla.org/show_bug.cgi?id=1023481?

=== Ceph ===

=== DB ===
https://bugzilla.mozilla.org/show_bug.cgi?id=993104

primary -

secondary -

standby -

=== ES ===

== Project Updates ==

[[Socorro:Releases|Socorro Release Tracker]] 
[https://crash-analysis.mozilla.com/rkaiser/socorro-bugs/2014.weeklybugs.html Socorro Bug Tracker]

=== Planned for this week ===
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&target_milestone=89&product=Socorro bugs]
<bugzilla>
{
"product": "Socorro",
"target_milestone": "89",
"include_fields": "id, summary, assigned_to, target_milestone, priority, status, resolution, whiteboard"
}
</bugzilla>

=== PR Triage ===
* https://prs.paas.allizom.org/mozilla/socorro

== other business ==
* continuous delivery
* Shared ADI library? https://github.com/mozilla/olympia/pull/115
* Problem with crontabber jobs that are cascading failures: https://bugzilla.mozilla.org/show_bug.cgi?id=1023873
* Ordering postgres hardware based on Pg hardware spec'd here: https://bugzilla.mozilla.org/show_bug.cgi?id=993090 (status: got an updated quote, scheduling meeting for details with Derek)

== PTOs, etc ==
* peterbe Monday 16
* phrawzty PTO 13 -> 18 June
* laura in MV 17-27 June, at Apps Days 17-18, at Velocity 24-26
* schalk Monday 16 (public holiday)

== Links ==

Websites/Plugincheck

2014-05-07T14:48:30Z

Espressive:

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Infrastructure ==

ToDo

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.

3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.

4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

# Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
# From there a cron would process the mailbox ever say 8 hours
# If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
# This data would be inserted into a kind of sandboxed table
# There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
# At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

# JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
# From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
# Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
# Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
# Trusted users who have been given merge access to the main project repo can then review the PR and merge
# Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
# Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

Websites/Plugincheck

2014-05-07T14:47:33Z

Espressive: /* Plugin Release Notifications by Vendors and Community */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.

3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.

4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

# Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
# From there a cron would process the mailbox ever say 8 hours
# If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
# This data would be inserted into a kind of sandboxed table
# There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
# At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

# JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
# From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
# Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
# Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
# Trusted users who have been given merge access to the main project repo can then review the PR and merge
# Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
# Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

Websites/Plugincheck

2014-05-07T14:37:06Z

Espressive: /* Plugin Data as an Open Service */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

# Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
# From there a cron would process the mailbox ever say 8 hours
# If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
# This data would be inserted into a kind of sandboxed table
# There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
# At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

# JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
# From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
# Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
# Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
# Trusted users who have been given merge access to the main project repo can then review the PR and merge
# Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
# Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

Websites/Plugincheck

2014-05-07T14:36:45Z

Espressive: /* Plugin Data as an Open Service */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

# Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
# From there a cron would process the mailbox ever say 8 hours
# If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
# This data would be inserted into a kind of sandboxed table
# There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
# At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

# JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
# From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
# Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
# Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
# Trusted users who have been given merge access to the main project repo can then review the PR and merge
# Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
# Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any.

Websites/Plugincheck

2014-05-07T14:34:50Z

Espressive: /* Plugin Announcements via Email */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

# Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
# From there a cron would process the mailbox ever say 8 hours
# If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
# This data would be inserted into a kind of sandboxed table
# There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
# At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

1) JSON files for each plugin are stored at:
https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
2) From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
3) Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
4) Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
5) Trusted users who have been given merge access to the main project repo can then review the PR and merge
6) Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node:
https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
7) Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any.

Websites/Plugincheck

2014-05-07T14:30:26Z

Espressive: /* Ideas On Improving PluginCheck */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

1) Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
2) From there a cron would process the mailbox ever say 8 hours
3) If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
4) This data would be inserted into a kind of sandboxed table
5) There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
6) At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:

1) JSON files for each plugin are stored at:
https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
2) From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
3) Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
4) Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
5) Trusted users who have been given merge access to the main project repo can then review the PR and merge
6) Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node:
https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
7) Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.

However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any.

Websites/Plugincheck

2014-05-07T14:06:00Z

Espressive: /* Ideas On Improving PluginCheck */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck

== Environments ==

=== Front End ===

* Prod URL: http://www.mozilla.org/plugincheck
* Stage URL: http://www.allizom.org/plugincheck

=== Back End ===

* Prod URL: http://plugins.mozilla.org
* Stage URL: http://plugins.allizom.org

== Code Repositories ==

* Back-end Repo: https://github.com/mozilla/plugindir/
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

== Communication ==

* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

= Ideas On Improving PluginCheck =

== Plugin Release Notifications by Vendors and Community ==

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

== Plugin Announcements via Email ==

Another idea that was discussed was plugin release notifications via email.

1) Emails would be sent, in a specified format, from the vendors directly to a dedicated email address.
2) From there a cron would process the mailbox ever say 8 hours
3) If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB.
4) This data would be inserted into a kind of sandboxed table
5) There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements
6) At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.

== Plugin Data as an Open Service ==

Websites/Plugincheck

2014-05-07T13:40:59Z

Espressive:

Websites/Plugincheck

2014-05-07T13:40:12Z

Espressive:

Breakpad/Status Meetings/2014-04-30

2014-04-30T17:46:07Z

Espressive: /* PTOs, etc */

Websites/Plugincheck

2014-04-24T06:08:46Z

Espressive: /* Overview */

Breakpad/Status Meetings/2014-04-23

2014-04-23T18:06:50Z

Espressive: /* PTOs, etc */

[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[Breakpad/Status_Meetings|index]] –
[[Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=Breakpad/Status_Meetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=Breakpad/Status_Meetings/Template create?]


= Meeting Info =

Breakpad status meetings occur on Wed at 11:00am Pacific Time.

Conference numbers:
Vidyo: Stability
650-903-0800 x92 conf 98200#
800-707-2533 (pin 369) conf 98200#
IRC backchannel: #breakpad
Mountain View: Dancing Baby (3rd floor)

[[Socorro:Releases|Socorro Release Tracker]] 
[https://crash-analysis.mozilla.com/rkaiser/socorro-bugs/2014.weeklybugs.html Socorro Bug Tracker]

= 83 =
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&target_milestone=83&product=Socorro bugs]
<bugzilla>
{
"product": "Socorro",
"target_milestone":"83",
"include_fields": "id, summary, assigned_to, target_milestone, priority, status, resolution, whiteboard"
}
</bugzilla>

= PR Triage =
* https://prs.paas.allizom.org/mozilla/socorro

= Other issues =

= Ops Updates =

== release ==

== DB ==
stage - after hours raid level change this evening

master -
slave -
standby -

== other items ==
* need some volunteers (for what?)
* Now running Elasticsearch 0.90.x on Stage and Prod. Upgrade to 1.x some time ?

= PTOs, etc =
* Lonnen has limited availability for 10 days or so starting Friday.
* phrawzty is off on Friday (25 April).
* Schalk is off Monday (28 April - public holiday), also Thursday (1 May)

= Links =

Websites/Plugincheck

2014-04-22T09:10:54Z

Espressive: /* Overview */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck
* Prod URL: http://www.mozilla.org/plugincheck
* Back-end Repo: http://svn.mozilla.org/projects/plugindir/ (moving to https://github.com/mozilla/plugindir/ as master)
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck
* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

Websites/Plugincheck

2014-04-22T09:01:29Z

Espressive: /* Overview */

This page contains all of the important details for the PluginCheck websites.

== Overview ==
* Project name: PluginCheck
* Prod URL: http://www.mozilla.org/plugincheck
* Back-end Repo: http://svn.mozilla.org/projects/plugindir/ (moving to https://github.com/mozilla/plugindir/ as master)
* 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
* Front-End Repo: https://github.com/mozilla/bedrock
* Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck
* Product Owner: Kev Needham
* Dev Team: Schalk Neethling (espressive), Carsten Book (Tomcat)
* IRC Channel: [irc://irc.mozilla.org:6697/plugincheck #plugincheck on irc.mozilla.org]

= Team =

The primary and secondary contacts for each role of this project:

* Product owner - Kev Needham
* Web Project Manager - Laura Thomson
* Developers - Schalk Neethling, Carsten Book
* Designer - John Slater
* QA - Matt Brandt
* UX - John Slater

= Current Trackers =

* [https://bugzilla.mozilla.org/show_bug.cgi?id=990856 Tracker for The New PluginCheck for Firefox 29+]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=990857 Tracker for Bugs and Feature Requests PluginCheck.current]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=991664 Test Automation for PluginCheck]

== Bugs Needing Triage ==

[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]

Breakpad/Status Meetings/2014-04-16

2014-04-16T18:01:09Z

Espressive: /* PTOs, etc */

Websites/Plugincheck/Plugin Status Service

2014-04-13T11:55:24Z

Espressive: /* Database */

= Plugin Status Service =
Source: https://github.com/ossreleasefeed/plugin-status-service

== Elevator Pitch ==

Rewrite plugins.m.o, leveraging the current data but expose the raw JSON data so that plugin developers and the general community can be part of the process of keeping plugin version data up to date. This will be achieved by making use of tools/services that users are already familiar with, such as via pull requests on Github and, should have a hook to enable plugin vendors to make this part of their automated release procedure again, using familiar tools such as git (edit, add, commit, push) and pull requests using the Github API.

== Use Cases ==

=== Community ===

==== Scenario 1 ====

Community member discovers a new release of a particular plugin.

The user either:
# Checks their current plugin, prior to updating, and discovers that mozilla.org/plugincheck still marks it as up to date.
# Updates their plugin and discovers that mozilla.org/plugincheck marks it as newer.

Both these scenarios indicate that the plugin status service does not have this new information.

Community member heads to Github, updates the content of the relevant plugin and opens a pull request. Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

==== Scenario 2 ====

User navigates to mozilla.org/plugincheck to determine whether all of their plugins are still up to date. The service labels some of their plugins as unknown and marks one (or more) as newer. Below each group i.e. 'newer' and 'unknown' there is a link stating:

# For unknown plugins - 'Suggest a plugin to track'
# For plugins marked as newer - 'Suggest a new version'

Both of these will link to the main repository' issues tracker with some base information about the unknown or newer plugin(s). Again, maintainers are notified and can take action.

NOTE: This is much the same as issues are done for Shumway using the [http://swf.codeazur.com.br/index.php Shumway SWF Archive test platform].

=== Plugin Vendors ===

Vendor is about to release a new, updated, security release of their plugin.

Vendor opens the relevant JSON file either locally or via their fork on Github and edits/adds the relevant information. Next, as part of their automated release procedure, they have the following:

<nowiki>
git add .
git commit -m 'Short blurb about release, perhaps even just new version number'
git push vendor plugin_versionnumber</nowiki>

Uses Github PR API [https://developer.github.com/v3/pulls/#create-a-pull-request] to initiate a pull requests (as part of the above automated process). Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

== Data Structure ==

The data structure requirement is as follows:

* We need to store information about the following releases:
** The latest release
** The latest '''safe''' release i.e. There might be a new release of the plugin but, the version before is still safe and does not suffer from vulnerabilities. For example having Java 7u51 even though Java 8 has been released.
** Vulnerable

Other statuses such as newer and unknown will be determined programmatically by either the absence of the plugin from the maintained data or, the fact that the version number for a known plugin is greater than what we have in the database.

There also exists a need, which is currently not satisfied, to track and support ESR releases for various plugins based on OS level. Especially for Flash and Java this is increasingly important in order to offer accurate reporting of a plugin's status. With that in mind, releases should be tracked against the operating system version up to a patch level granularity using semantic versioning.

== Database ==

As most all processing of the data happens on the client, the requirements from a database perspective are pretty low and only a few requirements are really needed to satisfy this dependency.

# The database should support the ability to import, export and query JSON. Querying directly against JSON is not a requirement as long as the first two are well supported.
# Each plugin will be a self contained JSON document and updating the database from these JSON documents should be supported. See [https://github.com/ossreleasefeed/plugin-status-service/blob/master/data/adobe-flash-player.json Flash player JSON] for an example.
# Queries against the data will be limited to a few predefined queries.
* The most run query will be to get all plugins for a specific operating system.
* Query to update data based on a JSON document as described in point 2 above.

On a schedule, ~once in a fortnight, a process will be run to extract all the data from the database, format the data and publish the result as a JSON file back to the plugin status service repository. [https://github.com/ossreleasefeed/plugin-status-service/blob/master/data.json View a sample file.]

== Development Depencies ==

* [http://nodejs.org/ Nodejs]
* [http://www.mongodb.org/ MongoDB]

Websites/Plugincheck/Plugin Status Service

2014-04-13T08:32:49Z

Espressive: /* Database */

= Plugin Status Service =
Source: https://github.com/ossreleasefeed/plugin-status-service

== Elevator Pitch ==

Rewrite plugins.m.o, leveraging the current data but expose the raw JSON data so that plugin developers and the general community can be part of the process of keeping plugin version data up to date. This will be achieved by making use of tools/services that users are already familiar with, such as via pull requests on Github and, should have a hook to enable plugin vendors to make this part of their automated release procedure again, using familiar tools such as git (edit, add, commit, push) and pull requests using the Github API.

== Use Cases ==

=== Community ===

==== Scenario 1 ====

Community member discovers a new release of a particular plugin.

The user either:
# Checks their current plugin, prior to updating, and discovers that mozilla.org/plugincheck still marks it as up to date.
# Updates their plugin and discovers that mozilla.org/plugincheck marks it as newer.

Both these scenarios indicate that the plugin status service does not have this new information.

Community member heads to Github, updates the content of the relevant plugin and opens a pull request. Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

==== Scenario 2 ====

User navigates to mozilla.org/plugincheck to determine whether all of their plugins are still up to date. The service labels some of their plugins as unknown and marks one (or more) as newer. Below each group i.e. 'newer' and 'unknown' there is a link stating:

# For unknown plugins - 'Suggest a plugin to track'
# For plugins marked as newer - 'Suggest a new version'

Both of these will link to the main repository' issues tracker with some base information about the unknown or newer plugin(s). Again, maintainers are notified and can take action.

NOTE: This is much the same as issues are done for Shumway using the [http://swf.codeazur.com.br/index.php Shumway SWF Archive test platform].

=== Plugin Vendors ===

Vendor is about to release a new, updated, security release of their plugin.

Vendor opens the relevant JSON file either locally or via their fork on Github and edits/adds the relevant information. Next, as part of their automated release procedure, they have the following:

<nowiki>
git add .
git commit -m 'Short blurb about release, perhaps even just new version number'
git push vendor plugin_versionnumber</nowiki>

Uses Github PR API [https://developer.github.com/v3/pulls/#create-a-pull-request] to initiate a pull requests (as part of the above automated process). Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

== Data Structure ==

The data structure requirement is as follows:

* We need to store information about the following releases:
** The latest release
** The latest '''safe''' release i.e. There might be a new release of the plugin but, the version before is still safe and does not suffer from vulnerabilities. For example having Java 7u51 even though Java 8 has been released.
** Vulnerable

Other statuses such as newer and unknown will be determined programmatically by either the absence of the plugin from the maintained data or, the fact that the version number for a known plugin is greater than what we have in the database.

There also exists a need, which is currently not satisfied, to track and support ESR releases for various plugins based on OS level. Especially for Flash and Java this is increasingly important in order to offer accurate reporting of a plugin's status. With that in mind, releases should be tracked against the operating system version up to a patch level granularity using semantic versioning.

== Database ==

As most all processing of the data happens on the client, the requirements from a database perspective are pretty low and only a few requirements are really needed to satisfy this dependency.

# The database should support the ability to import, export and query JSON. Querying directly against JSON is not a requirement as long as the first two are well supported.
# Each plugin will be a self contained JSON document and updating the database from these JSON documents should be supported. See [https://github.com/ossreleasefeed/plugin-status-service/blob/master/data/adobe-flash-player.json Flash player JSON] for an example.
# Queries against the data will be limited to a few predefined queries.
* The most run query will be to get all plugins for a specific operating system.
* Query to update data based on a JSON document as described in point 2 above.

On a schedule, ~once in a fortnight, a process will be run to extract all the data from the database, format the data and publish the result as a JSON file back to the plugin status service repository.

== Development Depencies ==

* [http://nodejs.org/ Nodejs]
* [http://www.mongodb.org/ MongoDB]

Websites/Plugincheck/Plugin Status Service

2014-04-13T08:25:41Z

Espressive: /* Database */

= Plugin Status Service =
Source: https://github.com/ossreleasefeed/plugin-status-service

== Elevator Pitch ==

Rewrite plugins.m.o, leveraging the current data but expose the raw JSON data so that plugin developers and the general community can be part of the process of keeping plugin version data up to date. This will be achieved by making use of tools/services that users are already familiar with, such as via pull requests on Github and, should have a hook to enable plugin vendors to make this part of their automated release procedure again, using familiar tools such as git (edit, add, commit, push) and pull requests using the Github API.

== Use Cases ==

=== Community ===

==== Scenario 1 ====

Community member discovers a new release of a particular plugin.

The user either:
# Checks their current plugin, prior to updating, and discovers that mozilla.org/plugincheck still marks it as up to date.
# Updates their plugin and discovers that mozilla.org/plugincheck marks it as newer.

Both these scenarios indicate that the plugin status service does not have this new information.

Community member heads to Github, updates the content of the relevant plugin and opens a pull request. Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

==== Scenario 2 ====

User navigates to mozilla.org/plugincheck to determine whether all of their plugins are still up to date. The service labels some of their plugins as unknown and marks one (or more) as newer. Below each group i.e. 'newer' and 'unknown' there is a link stating:

# For unknown plugins - 'Suggest a plugin to track'
# For plugins marked as newer - 'Suggest a new version'

Both of these will link to the main repository' issues tracker with some base information about the unknown or newer plugin(s). Again, maintainers are notified and can take action.

NOTE: This is much the same as issues are done for Shumway using the [http://swf.codeazur.com.br/index.php Shumway SWF Archive test platform].

=== Plugin Vendors ===

Vendor is about to release a new, updated, security release of their plugin.

Vendor opens the relevant JSON file either locally or via their fork on Github and edits/adds the relevant information. Next, as part of their automated release procedure, they have the following:

<nowiki>
git add .
git commit -m 'Short blurb about release, perhaps even just new version number'
git push vendor plugin_versionnumber</nowiki>

Uses Github PR API [https://developer.github.com/v3/pulls/#create-a-pull-request] to initiate a pull requests (as part of the above automated process). Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

== Data Structure ==

The data structure requirement is as follows:

* We need to store information about the following releases:
** The latest release
** The latest '''safe''' release i.e. There might be a new release of the plugin but, the version before is still safe and does not suffer from vulnerabilities. For example having Java 7u51 even though Java 8 has been released.
** Vulnerable

Other statuses such as newer and unknown will be determined programmatically by either the absence of the plugin from the maintained data or, the fact that the version number for a known plugin is greater than what we have in the database.

There also exists a need, which is currently not satisfied, to track and support ESR releases for various plugins based on OS level. Especially for Flash and Java this is increasingly important in order to offer accurate reporting of a plugin's status. With that in mind, releases should be tracked against the operating system version up to a patch level granularity using semantic versioning.

== Database ==

As most all processing of the data happens on the client, the requirements from a database perspective are pretty low and only a few requirements are really needed to satisfy this dependency.

# The database should support the ability to import, export and query JSON. Querying directly against JSON is not a requirement as long as the first two are well supported.
# Each plugin will be a self contained JSON document and updating the database from these JSON documents should be supported. See [https://github.com/ossreleasefeed/plugin-status-service/blob/master/data/adobe-flash-player.json Flash player JSON] for an example.
# Queries against the data will be limited to 2 or 3 predefined queries.
* The most used query will be to get all plugins for a specific operating system
* Query to extract all the data from the database, will be run periodically. (~once in a fortnight)
* Query to update data based on a JSON document as described in point 2 above.

== Development Depencies ==

* [http://nodejs.org/ Nodejs]
* [http://www.mongodb.org/ MongoDB]

Websites/Plugincheck/Plugin Status Service

2014-04-13T08:22:48Z

Espressive:

= Plugin Status Service =
Source: https://github.com/ossreleasefeed/plugin-status-service

== Elevator Pitch ==

Rewrite plugins.m.o, leveraging the current data but expose the raw JSON data so that plugin developers and the general community can be part of the process of keeping plugin version data up to date. This will be achieved by making use of tools/services that users are already familiar with, such as via pull requests on Github and, should have a hook to enable plugin vendors to make this part of their automated release procedure again, using familiar tools such as git (edit, add, commit, push) and pull requests using the Github API.

== Use Cases ==

=== Community ===

==== Scenario 1 ====

Community member discovers a new release of a particular plugin.

The user either:
# Checks their current plugin, prior to updating, and discovers that mozilla.org/plugincheck still marks it as up to date.
# Updates their plugin and discovers that mozilla.org/plugincheck marks it as newer.

Both these scenarios indicate that the plugin status service does not have this new information.

Community member heads to Github, updates the content of the relevant plugin and opens a pull request. Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

==== Scenario 2 ====

User navigates to mozilla.org/plugincheck to determine whether all of their plugins are still up to date. The service labels some of their plugins as unknown and marks one (or more) as newer. Below each group i.e. 'newer' and 'unknown' there is a link stating:

# For unknown plugins - 'Suggest a plugin to track'
# For plugins marked as newer - 'Suggest a new version'

Both of these will link to the main repository' issues tracker with some base information about the unknown or newer plugin(s). Again, maintainers are notified and can take action.

NOTE: This is much the same as issues are done for Shumway using the [http://swf.codeazur.com.br/index.php Shumway SWF Archive test platform].

=== Plugin Vendors ===

Vendor is about to release a new, updated, security release of their plugin.

Vendor opens the relevant JSON file either locally or via their fork on Github and edits/adds the relevant information. Next, as part of their automated release procedure, they have the following:

<nowiki>
git add .
git commit -m 'Short blurb about release, perhaps even just new version number'
git push vendor plugin_versionnumber</nowiki>

Uses Github PR API [https://developer.github.com/v3/pulls/#create-a-pull-request] to initiate a pull requests (as part of the above automated process). Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

== Data Structure ==

The data structure requirement is as follows:

* We need to store information about the following releases:
** The latest release
** The latest '''safe''' release i.e. There might be a new release of the plugin but, the version before is still safe and does not suffer from vulnerabilities. For example having Java 7u51 even though Java 8 has been released.
** Vulnerable

Other statuses such as newer and unknown will be determined programmatically by either the absence of the plugin from the maintained data or, the fact that the version number for a known plugin is greater than what we have in the database.

There also exists a need, which is currently not satisfied, to track and support ESR releases for various plugins based on OS level. Especially for Flash and Java this is increasingly important in order to offer accurate reporting of a plugin's status. With that in mind, releases should be tracked against the operating system version up to a patch level granularity using semantic versioning.

== Database ==

# The database should support the ability to import, export and query JSON. Querying directly against JSON is not a requirement as long as the first two are well supported.
# Each plugin will be a self contained JSON document and updating the database from these JSON documents should be supported.
# Queries against the data will be limited to 2 or 3 predefined queries.
* The most used query will be to get all plugins for a specific operating system
* Query to extract all the data from in the database, will be run periodically. (~once in a fortnight)
* Query to update data based on a JSON document as described in point 2 above.

== Development Depencies ==

* [http://nodejs.org/ Nodejs]
* [http://www.mongodb.org/ MongoDB]