MozillaWiki - User contributions [en]

Outreachy

2016-09-19T09:27:08Z

Wcosta: taskcluster-cli is not taking new applicants

Mozilla has participated in the Outreachy program for several years. The goals of the program are to increase participation from under-represented groups in free and open source software. Participation is open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer three month paid contribution opportunities twice a year.

==Useful links for More Information==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]
==Applications for Round 13 (Dec 2016-March 2017) open Monday September 12==
===Project List===

====Make WebExtension Development More Awesome====
* Mentor: [https://mozillians.org/en-US/u/kumar/ Kumar McMillan] (kumar on IRC)

[https://developer.mozilla.org/en-US/Add-ons/WebExtensions WebExtensions] let anyone extend and customize their web browser, such as blocking ads on every website they visit. This is an exciting time for the API because it’s now possible to write a single extension that works in both Firefox, [https://developer.chrome.com/extensions Chrome], [https://dev.opera.com/extensions/ Opera], and soon IE. At Mozilla we provide several tools and resources to make developing extensions fun and easy but we’d like to make this development experience even better.

The participant would improve the productivity of WebExtension developers in the following ways. Most of these tasks involve changing the [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext web-ext] command line tool but others may involve writing documentation or example code.

* Utilize common web developer tools when building extensions
** Craft examples that show how to use [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import ES6 imports] and other features that typically require code transpilation with [http://babeljs.io/ babel] or [http://rollupjs.org/ rollup]
* Automatically keep the web-ext tool up to date to avoid bugs
** Alert the developer if their version of web-ext is out of date
* Offer extension “linting” in code editors
** Integrate web-ext's existing [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext#Checking_for_code_lint lint checking feature] into popular editors such as [https://atom.io/ Atom], [http://www.vim.org/ Vim], and [https://www.gnu.org/software/emacs/ Emacs]
* Add a new web-ext command that lays out a directory structure for an extension
** This command would automatically generate a manifest.json file and other common files to help the developer get started on a new extension
* Build a mock WebExtension API for use in automated tests
* Invent a JavaScript library that developers can use to execute tests for their extension without having to launch a web browser

Contributing to WebExtensions is a great opportunity to empower those who are extending the web!

Desired technical skills:
* Intermediate experience with JavaScript, preferably with some ES6 experience
* Familiarity with the command line environment for [https://nodejs.org/en/ NodeJS] development
* Ability to communicate in English, primarily in written form

How to familiarize yourself with the project:
* Try out the [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext web-ext] tool and file a bug if you find one
* Look through [https://github.com/mdn/webextensions-examples WebExtension examples] and try them out with [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext#Testing_out_an_extension web-ext run]
* Search for [https://github.com/mozilla/web-ext/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22 good first bugs] in the web-ext repository and submit a patch
* Search for [https://github.com/mozilla/sign-addon/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22 good first bugs] in the sign-addon repository and submit a patch

====Build a Library of Inclusion Best Practices and Case Studies====
* Mentor: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro]

This project is a community research project to identify and document examples of successful inclusive teams and communities within Mozilla, in order to amplify successes and highlight bright spots. The Outreachy participant will assess programs for suitability, and then interview participants, and then document case studies, referencing appropriate research and industry/community best practices. This is a great opportunity for a person interested in Diversity and Inclusion, Community Building, or User/Community research.

Skills learned in this project will include effective interviewing, case study development, awareness of research in best practices in inclusion across cultures and other diversity dimensions, and wiki markup/editing.

Your work sample should be a short written case study of a program or project you have done as a volunteer or as a new employee, technical or non, and should describe exactly how this program or project included you and failed to include you. Specific examples, connections to research, and detail are appreciated. It should be a several paragraph document.

====Improving user experience of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your software engineering skills will assist in the following:

Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows.

Improving the verification rate and speed of new users signing up for Firefox Accounts.

Skill requirements for this project: Git, JavaScript.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

====Improving server-side components of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

This project is part of improving the server components of Firefox Accounts. You will be involved in improving the security, APIs, and measuring success of certain features. Detailed projects:

Improving Firefox Sync and Firefox Accounts integration.
Improving device management and OAuth APIs.

Skill requirements for this project: Git, Node.js.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

==== User Impact of XSS Filters within Web Browsers ====
* Mentors: [https://mozillians.org/en-US/u/ckerschbaumer/ Christoph Kerschbaumer] & [https://mozillians.org/en-US/u/freddyb/ Frederik Braun]

Cross Site Scripting (XSS) consistently ranks highest in the list of the most prevalent software vulnerabilities.
Using XSS, hackers can gain access to confidential user data and conduct transactions on behalf of the user.
Many browsers provide a built-in XSS filter to protect the majority of users from XSS issues. Such heuristic based filters also trigger false positives. This may downgrade a user's experience on a benign site. Even worse, such filters might even introduce new vulnerabilities.

To the end of the project we expect you to

* implement an XSS filter within Firefox
* measure user impact based on false positive rate
* measure performance
* co-produce a white paper with the mentors that summarizes the outcome of this project.
* (Pro Tip: This might qualify as a term paper or even grow into a thesis for your studies).

How you can prepare for the program:

* Familiarize yourself with the problem by reading literature on XSS-Filters:
** Introduction of the Chrome/Webkit filter called XSS Auditor in "Regular expressions considered harmful in client-side XSS filters"
** Security vulnerabilities introduced though XSS filters in IE8: https://blog.c22.cc/2010/04/15/blackhat-europe-universal-xss-via-ie8s-xss-filters-2/
** Bypassing XSS filters: (http://www.thespanner.co.uk/2015/02/10/xss-auditor-bypass/, http://brutelogic.com.br/blog/chrome-xss-bypass/)
* Familiarize yourself with the state of the art of implementing an XSS filter
** Browse the source code of NoScript, XSSAuditor in WebKit, or also the source of Internet Explorer (which can be inspected by looking into mshtml.dll)
** Compare approaches of these filters to answer questions like: where do their approaches overlap, which differences exist in their threat models, etc.
* Prepare yourself for implementing a filter within Firefox
** Outline the advantages and disadvantages of existing approaches Sketch out details for the actual implementation

We would be thrilled if you have a

* a deep understanding of Web Security and XSS
* a fundamental understanding of browser architecture
* solid experience in developing C/C++ applications
* the ability to work with a geographically distributed development team
* experience in learning, building and being effective with a large code base

We at Mozilla Security Engineering give you the opportunity to improve Firefox. We are an equal opportunity employer and value diversity. We do not discriminate on the basis of race, religion, color, national origin, gender, sexual orientation, age, marital status, veteran status, or disability status.

==== taskcluster-cli go implementation [No longer taking applicants] ====

* Mentors: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] & [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]

===== Background =====

Mozilla is a company that is strongly committed to inclusion and diversity.
The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in, like NSS. Taskcluster is built
using distributed 'cloud' computing services where possible. Taskcluster
developers and users often need to do some tasks manually, like craft, inspect
and kill tasks; roles and users management; download artifacts, etc.
taskcluster-cli is a generic command line tool to interact with Taskcluster,
built by and for shell command lovers. We have a long live
[https://github.com/taskcluster/taskcluster-cli Javascript implementation],
and are starting a
[https://github.com/taskcluster/taskcluster-cli/tree/go-tc-cli new version] completely
rewritten in [https://golang.org/ Golang].

===== Project =====

The goal of this project is to implement the main features to the new
Golang based taskcluster-cli, including task creation, task groups scheduling,
users management, and so on. We want someone that is keen to learn and
engaged on making taskcluster-cli a great tool. You should know basics of
Go (Go is a simple language and the basics can be learned during application
process). The advanced skills on the language can be acquired during internship
with help from project mentors. Some knowledge of Javascript (ES6 is a plus) is
desired but not required (although you may expect reading some modern Javascript
code from time to time), as well as some general concepts of Web APIs.

Required skills:

* Go programming language (you can learn during application process)
* Basic git and github workflow
* Desire to learn
* Engagement

Desired skills:

* Javascript
* ES6
* Web APIs

Getting started: https://public.etherpad-mozilla.org/p/taskcluster-cli-applicants-getting-started

==== Add support for OpenAPI to Kinto ====

* Mentors: [https://mozillians.org/en-US/u/ethan.glasser.camp/ Ethan Glasser-Camp] (glasserc on IRC) and Rémy Hubscher (natim on IRC)

Kinto has a fairly comprehensive set of documentation that describes its API. However, the cool new thing is OpenAPIs (formerly known as Swagger). Documenting our API using this specification would facilitate the implementation of client libraries in other languages as well as open the door to lots of other projects, including "interactive" documentation which has buttons that launch requests against a live server.

The Kinto team is seeking an intern to work on developing OpenAPI support in Kinto. This project is ideal for an Outreachy intern because it is self-contained and doesn't require understanding a complicated ecosystem of services (unlike our previous "Push Notifications" project).

We have structured the project to have multiple tasks. We do not expect any intern to finish every task; instead, we can draw tasks from this reservoir according to your momentum. These tasks are:

* Document the existing API by writing an OpenAPI specification. This will involve reading the existing documentation and experimenting with the Kinto server.
* Add runnable examples to the documentation. This will involve comparative analyses of available tools as well as working with our Sphinx-based documentation.
* Add an automated test that detects when the spec is out-of-date. This would involve working with our py.test-based unit testing suite.
* Write a mechanism to generate an OpenAPI specification from the Kinto source code. This would require writing Python code that hooks into the server code to identify APIs.
* Investigate the use of the OpenAPI specification to do fuzz-testing against the Kinto server. This would require an investigation of fuzzing tools and learning how to use them in a customized way.

Interns should understand back-end REST services and be skilled in reading and writing Python. You should be able to use Git and run Python code.

You can learn more about Kinto at [http://kinto.readthedocs.io/en/stable/ the Kinto Readthedocs page] and [https://github.com/Kinto/kinto its Github page].
If you need a "small contribution" for your application, some suggestions are at [https://github.com/Kinto/kinto/issues?q=is%3Aopen+is%3Aissue+label%3Aeasy-pick Kinto easy-pick bugs] and [https://github.com/Kinto/kinto-http.py/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy-pick kinto-http.py easy-pick bugs].
You can find us in #kinto on Freenode or on Slack at https://kinto.slack.com/ .

==== Azure Blob Storage client library ====

* Mentors: [https://mozillians.org/en-US/u/jhford/ John Ford] (jhford on IRC)

Background:

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Taskcluster is a built
using distributed 'cloud' computing services where possible. We use the Azure
Storage framework for storing a lot of things. This library has Queue storage,
Table Storage. We have a wrapper that we like a lot called [https://www.npmjs.com/package/azure-entities 'azure-entities'] in NPM.

Project:

The goal of this project is to write a library to wrap the Azure Blob Storage
service. A preliminary effort has [https://github.com/taskcluster/aws-provisioner/blob/master/src/container.js already been done]. What we're looking
for is someone to take this work and extend it to cover the majority of the
[https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs/ Blob Storage API]. We specifically would like to have the following:

1. All Rest API endpoints [https://msdn.microsoft.com/library/dd135733.aspx implemented] using input validation to ensure that only valid data makes it to the API. [http://json-schema.org/ JSON Schema] is a great tool for this
2. Ability to specify a JSON Schema to validate objects that we'll store or append to blobs, and also that we read out from them
3. Ability to use [https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/ Shared Access Secrets (SAS)] as authentication
4. Stretch goal of adding SAS for Blob storage to our [https://github.com/taskcluster/taskcluster-auth authorization service]

What you'll learn and use:

* Javascript language
* Node.js environment
* JSON
* Yaml
* JSON-Schema
* Azure Cloud APIs, specifically Blob Storage
* Babel -- Javascript compiler
* ESLint -- Javascript linter
* Javascript Promises and the Async/Await pattern

You should have some experience with Javascript or a similar dynamic language
(Ruby, Python, etc). It's not important that you know all of the tools,
but you should be willing to learn. You should be available to have meetings
at some point in the time window of 9.00h CEST/CET through 17.00h CEST/CET

==== Improve Template Logic for Taskcluster-Github ====

Mentor: Brian Stack (bstack on IRC), [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] (dustin on IRC)

Background:

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Many of these projects
are developed on Github, and the Taskcluster-Github service acts as
the interface
between the two systems, creating tasks in response to Github events and
posting status updates back to Github. As other Mozillians have started using
Taskcluster-Github, they have identified some issues and missing features
in the service. With those fixed, more Mozillians can use TaskCluster
to improve
the web.

Project:

This project involves addressing some of the more pressing
user-identified issues
with TaskCluster. It is a collection of smaller projects:

1. Add support for creating tasks in response to new Git tags. This
would allow users to run "release" tasks when they push a new version
tag, for example.

2. Make the repository enrollment process "self-serve". Currently, if
a team wants to use Taskcluster-Github, they must ask a person on the
Taskcluster team to set that up for them. That can be slow and
discourages experimentation. With this project completed, users can
set up a new repository with a few clicks.

3. Add "build shields", similar to http://shields.io/ that will show
the latest status of a Taskcluster-Github build or test run.

As a collection of smaller projects, there is plenty of flexibility to
add or remove projects during the internship. You are encouraged to
talk to other teams in Mozilla and, if you find a feature that will
help them use Taskcluster more effectively, implement that feature
instead.

What you'll learn and use:

* Javascript (mostly server-side, using node)
* Github Webhooks and APIs
* Taskcluster APIs

Previous Experience:

You should be familiar with Javascript, although it is OK if that is
limited to scripts that run in the browser. You should be familiar
with Github, including making pull requests and using continuous
integration tools like Travis-CI or CircleCI. Ideally, you would have
some experience working with other people on an open-source project,
modifying existing code and getting feedback in reviews.

==== Collaboration Tools for Open Source Participation and Productivity ====

Mentor: [https://mozillians.org/en-US/u/dmarti/ Don Marti]

We are interested in pushing the limits of what automation can do to help de-stress open source projects, especially low-profile ones that put a lot of work onto an individual maintainer or small team. Interested in writing bots to help maintainers with the routine tasks of software development, bots that can help coach new contributors to get productive, or both? If you have an idea for a collaborative tool that would help you, and you're interested in coding it and seeing if it can help others, please consider joining us. Helpful skills to have

* HTTP client development
* Use of web APIs (GitHub, Twitter...)
* git
* Empathy for new and time-crunched developers

None of these are hard requirements -- We're prepared to collaborate with you and your bot(s) to learn and gather data.

==== Help drive the Nightly Reboot on Firefox Desktop/Mobile ====
Mentor: [https://mozillians.org/en-US/u/marcia/ Marcia Knous] (marcia on IRC)

This project involves helping the Release Management team and the Mozilla community drive the "Nightly Reboot" on Firefox Desktop and Mobile. You can read more about it here: https://blog.nightly.mozilla.org/2016/07/01/a-firefox-nightly-blog/. Here are some of the things you will work on as part of this internship:

Bug and Crash triage

*Help the team identify and triage Nightly bugs
*Identify and investigate crashes in the Nightly project
*Organize Test Days specific to Firefox Nightly

Applicants should have:

*Experience using the Firefox browser and an understanding of what the Firefox Nightly Channel is
*Strong organizational abilities
*Inquisitive nature
*Comfortable working in Bugzilla
*Bonus if you have experience doing QA

Applicants will gain skills in:
* Investigative analysis
* Problem solving

This should be a fun experience, especially for those who love working on solving problems and making the Firefox experience better for everyone!

==Outreachy Program Cohort: Round 12 (May-August 2016)==
===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]
* Participant: [https://mozillians.org/en-US/u/anaribeiro/ Ana Ribero]
* [http://outreachy.anaplusplus.com/ Participant Blog]

Inclusive culture is essential to building all kinds of diversity and making diverse people feel welcome in open source projects. We have many groups working on this topic all around Mozilla and other open source communities. This Outreachy participant will engage in community research, documenting best practices and case studies in the development of open inclusive culture.

The participant will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

===Make Firefox look great on desktop!===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]
*Participant: [https://mozillians.org/en-US/u/Rakhi/ Rakhi Sharma]
* [http://rakhish.wordpress.com/ Participant Blog]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, the participant will help to address a number of styling problems where Firefox does not currently look its best.

===Project SmartHome prototyping===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
* Participant: [https://mozillians.org/en-US/u/Mermi/ Manel Rahem]
* Participant Blog: https://mermi.github.io

The participant will be involved with Project SmartHome, working on assisting active and ongoing prototyping, integrating logging and metrics into SmartHome work with the collaboration of the metrics team, and helping with user research testing analysis and results.

===Webcompat.com Web Application Engineer===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
*Participant: [https://mozillians.org/en-US/u/venkid/ Deepthi Venkitaramanan]
*[http://venkid.com/portfolio.html#Outreachy Participant Blog]

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

In this Outreachy project, the participant will contribute to one or more of the following projects to help us succeed from a few different angles.
* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

===Convert Mozmill tests to Marionette===
*Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC
*Participant: [https://mozillians.org/en-US/u/bennyjr35/ Benjamin "Benny" Forehand, Jr.]
*Participant Blog: https://www.bennyjr.xyz/blog and https://benjaminfjr.blogspot.com/

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
*Participant: [https://mozillians.org/en-US/u/ipsha21/ Ipsha Bhidonia]
*[https://ipsha218.wordpress.com/feed/ Participant Blog]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
* Participant: [https://mozillians.org/en-US/u/vakila/ Anjana Vakil]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

===Improving user experience of Firefox Accounts===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
* Participant: [https://mozillians.org/en-US/u/Rutuja/ Rutuja Surve]
* [https://rutujasurveblog.wordpress.com/2016/05/17/outreachy-2016-my-first-post/ Participant Blog]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

===Taskcluster tools UI/UX improvements===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
* Participant: [https://mozillians.org/en-US/u/andreadelrio/ Andrea Del Rio Lazo]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack]
* Participant: [https://mozillians.org/en-US/u/kt/ Kristel Teng]

Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
* Participant: [https://mozillians.org/en-US/u/kbroida/ Katie Broida]
* [http://blog.katiebroida.com/ Participant Blog]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
*Participant: [https://mozillians.org/en-US/u/deckycoss/ Decky Coss]
*Participant Blogs: http://cosstropolis.com/blog and http://cosstropolis.com/blog/feed.xml

"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

===Prototype new Firefox features with the Test Pilot team===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)
* Participant: [https://mozillians.org/en-US/u/kaganjd/ Jen Kagan]
* Participant blog

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what the participant will be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

= For Future Applicants =
* Next Outreachy round is Winter 2016-17. Keep in touch by reading here or on gnome.org/outreachy to learn application deadlines.

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 13.
Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

=Past Outreachy/OPW internships=

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-09-16T06:34:11Z

Wcosta: /* Add git requirement and Getting started link */

Mozilla has participated in the Outreachy program for several years. The goals of the program are to increase participation from under-represented groups in free and open source software. Participation is open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer three month paid contribution opportunities twice a year.

==Useful links for More Information==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]
==Applications for Round 13 (Dec 2016-March 2017) open Monday September 12==
===Project List===

====Make WebExtension Development More Awesome====
* Mentor: [https://mozillians.org/en-US/u/kumar/ Kumar McMillan] (kumar on IRC)

[https://developer.mozilla.org/en-US/Add-ons/WebExtensions WebExtensions] let anyone extend and customize their web browser, such as blocking ads on every website they visit. This is an exciting time for the API because it’s now possible to write a single extension that works in both Firefox, [https://developer.chrome.com/extensions Chrome], [https://dev.opera.com/extensions/ Opera], and soon IE. At Mozilla we provide several tools and resources to make developing extensions fun and easy but we’d like to make this development experience even better.

The participant would improve the productivity of WebExtension developers in the following ways. Most of these tasks involve changing the [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext web-ext] command line tool but others may involve writing documentation or example code.

* Utilize common web developer tools when building extensions
** Craft examples that show how to use [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import ES6 imports] and other features that typically require code transpilation with [http://babeljs.io/ babel] or [http://rollupjs.org/ rollup]
* Automatically keep the web-ext tool up to date to avoid bugs
** Alert the developer if their version of web-ext is out of date
* Offer extension “linting” in code editors
** Integrate web-ext's existing [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext#Checking_for_code_lint lint checking feature] into popular editors such as [https://atom.io/ Atom], [http://www.vim.org/ Vim], and [https://www.gnu.org/software/emacs/ Emacs]
* Add a new web-ext command that lays out a directory structure for an extension
** This command would automatically generate a manifest.json file and other common files to help the developer get started on a new extension
* Build a mock WebExtension API for use in automated tests
* Invent a JavaScript library that developers can use to execute tests for their extension without having to launch a web browser

Contributing to WebExtensions is a great opportunity to empower those who are extending the web!

Desired technical skills:
* Intermediate experience with JavaScript, preferably with some ES6 experience
* Familiarity with the command line environment for [https://nodejs.org/en/ NodeJS] development
* Ability to communicate in English, primarily in written form

How to familiarize yourself with the project:
* Try out the [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext web-ext] tool and file a bug if you find one
* Look through [https://github.com/mdn/webextensions-examples WebExtension examples] and try them out with [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext#Testing_out_an_extension web-ext run]
* Search for [https://github.com/mozilla/web-ext/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22 good first bugs] in the web-ext repository and submit a patch
* Search for [https://github.com/mozilla/sign-addon/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22 good first bugs] in the sign-addon repository and submit a patch

====Build a Library of Inclusion Best Practices and Case Studies====
* Mentor: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro]

This project is a community research project to identify and document examples of successful inclusive teams and communities within Mozilla, in order to amplify successes and highlight bright spots. The Outreachy participant will assess programs for suitability, and then interview participants, and then document case studies, referencing appropriate research and industry/community best practices. This is a great opportunity for a person interested in Diversity and Inclusion, Community Building, or User/Community research.

Skills learned in this project will include effective interviewing, case study development, awareness of research in best practices in inclusion across cultures and other diversity dimensions, and wiki markup/editing.

Your work sample should be a short written case study of a program or project you have done as a volunteer or as a new employee, technical or non, and should describe exactly how this program or project included you and failed to include you. Specific examples, connections to research, and detail are appreciated. It should be a several paragraph document.

====Improving user experience of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your software engineering skills will assist in the following:

Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows.

Improving the verification rate and speed of new users signing up for Firefox Accounts.

Skill requirements for this project: Git, JavaScript.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

====Improving server-side components of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

This project is part of improving the server components of Firefox Accounts. You will be involved in improving the security, APIs, and measuring success of certain features. Detailed projects:

Improving Firefox Sync and Firefox Accounts integration.
Improving device management and OAuth APIs.

Skill requirements for this project: Git, Node.js.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

==== User Impact of XSS Filters within Web Browsers ====
* Mentors: [https://mozillians.org/en-US/u/ckerschbaumer/ Christoph Kerschbaumer] & [https://mozillians.org/en-US/u/freddyb/ Frederik Braun]

Cross Site Scripting (XSS) consistently ranks highest in the list of the most prevalent software vulnerabilities.
Using XSS, hackers can gain access to confidential user data and conduct transactions on behalf of the user.
Many browsers provide a built-in XSS filter to protect the majority of users from XSS issues. Such heuristic based filters also trigger false positives. This may downgrade a user's experience on a benign site. Even worse, such filters might even introduce new vulnerabilities.

To the end of the project we expect you to

* implement an XSS filter within Firefox
* measure user impact based on false positive rate
* measure performance
* co-produce a white paper with the mentors that summarizes the outcome of this project.
* (Pro Tip: This might qualify as a term paper or even grow into a thesis for your studies).

How you can prepare for the program:

* Familiarize yourself with the problem by reading literature on XSS-Filters:
** Introduction of the Chrome/Webkit filter called XSS Auditor in "Regular expressions considered harmful in client-side XSS filters"
** Security vulnerabilities introduced though XSS filters in IE8: https://blog.c22.cc/2010/04/15/blackhat-europe-universal-xss-via-ie8s-xss-filters-2/
** Bypassing XSS filters: (http://www.thespanner.co.uk/2015/02/10/xss-auditor-bypass/, http://brutelogic.com.br/blog/chrome-xss-bypass/)
* Familiarize yourself with the state of the art of implementing an XSS filter
** Browse the source code of NoScript, XSSAuditor in WebKit, or also the source of Internet Explorer (which can be inspected by looking into mshtml.dll)
** Compare approaches of these filters to answer questions like: where do their approaches overlap, which differences exist in their threat models, etc.
* Prepare yourself for implementing a filter within Firefox
** Outline the advantages and disadvantages of existing approaches Sketch out details for the actual implementation

We would be thrilled if you have a

* a deep understanding of Web Security and XSS
* a fundamental understanding of browser architecture
* solid experience in developing C/C++ applications
* the ability to work with a geographically distributed development team
* experience in learning, building and being effective with a large code base

We at Mozilla Security Engineering give you the opportunity to improve Firefox. We are an equal opportunity employer and value diversity. We do not discriminate on the basis of race, religion, color, national origin, gender, sexual orientation, age, marital status, veteran status, or disability status.

==== taskcluster-cli go implementation ====

* Mentors: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] & [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]

===== Background =====

Mozilla is a company that is strongly committed to inclusion and diversity.
The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in, like NSS. Taskcluster is built
using distributed 'cloud' computing services where possible. Taskcluster
developers and users often need to do some tasks manually, like craft, inspect
and kill tasks; roles and users management; download artifacts, etc.
taskcluster-cli is a generic command line tool to interact with Taskcluster,
built by and for shell command lovers. We have a long live
[https://github.com/taskcluster/taskcluster-cli Javascript implementation],
and are starting a
[https://github.com/taskcluster/taskcluster-cli/tree/go-tc-cli new version] completely
rewritten in [https://golang.org/ Golang].

===== Project =====

The goal of this project is to implement the main features to the new
Golang based taskcluster-cli, including task creation, task groups scheduling,
users management, and so on. We want someone that is keen to learn and
engaged on making taskcluster-cli a great tool. You should know basics of
Go (Go is a simple language and the basics can be learned during application
process). The advanced skills on the language can be acquired during internship
with help from project mentors. Some knowledge of Javascript (ES6 is a plus) is
desired but not required (although you may expect reading some modern Javascript
code from time to time), as well as some general concepts of Web APIs.

Required skills:

* Go programming language (you can learn during application process)
* Basic git and github workflow
* Desire to learn
* Engagement

Desired skills:

* Javascript
* ES6
* Web APIs

Getting started: https://public.etherpad-mozilla.org/p/taskcluster-cli-applicants-getting-started

==== Add support for OpenAPI to Kinto ====

* Mentors: [https://mozillians.org/en-US/u/ethan.glasser.camp/ Ethan Glasser-Camp] (glasserc on IRC) and Rémy Hubscher (natim on IRC)

Kinto has a fairly comprehensive set of documentation that describes its API. However, the cool new thing is OpenAPIs (formerly known as Swagger). Documenting our API using this specification would facilitate the implementation of client libraries in other languages as well as open the door to lots of other projects, including "interactive" documentation which has buttons that launch requests against a live server.

The Kinto team is seeking an intern to work on developing OpenAPI support in Kinto. This project is ideal for an Outreachy intern because it is self-contained and doesn't require understanding a complicated ecosystem of services (unlike our previous "Push Notifications" project).

We have structured the project to have multiple tasks. We do not expect any intern to finish every task; instead, we can draw tasks from this reservoir according to your momentum. These tasks are:

* Document the existing API by writing an OpenAPI specification. This will involve reading the existing documentation and experimenting with the Kinto server.
* Add runnable examples to the documentation. This will involve comparative analyses of available tools as well as working with our Sphinx-based documentation.
* Add an automated test that detects when the spec is out-of-date. This would involve working with our py.test-based unit testing suite.
* Write a mechanism to generate an OpenAPI specification from the Kinto source code. This would require writing Python code that hooks into the server code to identify APIs.
* Investigate the use of the OpenAPI specification to do fuzz-testing against the Kinto server. This would require an investigation of fuzzing tools and learning how to use them in a customized way.

Interns should understand back-end REST services and be skilled in reading and writing Python. You should be able to use Git and run Python code.

You can learn more about Kinto at [http://kinto.readthedocs.io/en/stable/ the Kinto Readthedocs page] and [https://github.com/Kinto/kinto its Github page].
If you need a "small contribution" for your application, some suggestions are at [https://github.com/Kinto/kinto/issues?q=is%3Aopen+is%3Aissue+label%3Aeasy-pick Kinto easy-pick bugs] and [https://github.com/Kinto/kinto-http.py/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy-pick kinto-http.py easy-pick bugs].
You can find us in #kinto on Freenode or on Slack at https://kinto.slack.com/ .

==== Azure Blob Storage client library ====

* Mentors: [https://mozillians.org/en-US/u/jhford/ John Ford] (jhford on IRC)

Background:

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Taskcluster is a built
using distributed 'cloud' computing services where possible. We use the Azure
Storage framework for storing a lot of things. This library has Queue storage,
Table Storage. We have a wrapper that we like a lot called [https://www.npmjs.com/package/azure-entities 'azure-entities'] in NPM.

Project:

The goal of this project is to write a library to wrap the Azure Blob Storage
service. A preliminary effort has [https://github.com/taskcluster/aws-provisioner/blob/master/src/container.js already been done]. What we're looking
for is someone to take this work and extend it to cover the majority of the
[https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs/ Blob Storage API]. We specifically would like to have the following:

1. All Rest API endpoints [https://msdn.microsoft.com/library/dd135733.aspx implemented] using input validation to ensure that only valid data makes it to the API. [http://json-schema.org/ JSON Schema] is a great tool for this
2. Ability to specify a JSON Schema to validate objects that we'll store or append to blobs, and also that we read out from them
3. Ability to use [https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/ Shared Access Secrets (SAS)] as authentication
4. Stretch goal of adding SAS for Blob storage to our [https://github.com/taskcluster/taskcluster-auth authorization service]

What you'll learn and use:

* Javascript language
* Node.js environment
* JSON
* Yaml
* JSON-Schema
* Azure Cloud APIs, specifically Blob Storage
* Babel -- Javascript compiler
* ESLint -- Javascript linter
* Javascript Promises and the Async/Await pattern

You should have some experience with Javascript or a similar dynamic language
(Ruby, Python, etc). It's not important that you know all of the tools,
but you should be willing to learn. You should be available to have meetings
at some point in the time window of 9.00h CEST/CET through 17.00h CEST/CET

==== Improve Template Logic for Taskcluster-Github ====

Mentor: Brian Stack (bstack on IRC), [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] (dustin on IRC)

Background:

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Many of these projects
are developed on Github, and the Taskcluster-Github service acts as
the interface
between the two systems, creating tasks in response to Github events and
posting status updates back to Github. As other Mozillians have started using
Taskcluster-Github, they have identified some issues and missing features
in the service. With those fixed, more Mozillians can use TaskCluster
to improve
the web.

Project:

This project involves addressing some of the more pressing
user-identified issues
with TaskCluster. It is a collection of smaller projects:

1. Add support for creating tasks in response to new Git tags. This
would allow users to run "release" tasks when they push a new version
tag, for example.

2. Make the repository enrollment process "self-serve". Currently, if
a team wants to use Taskcluster-Github, they must ask a person on the
Taskcluster team to set that up for them. That can be slow and
discourages experimentation. With this project completed, users can
set up a new repository with a few clicks.

3. Add "build shields", similar to http://shields.io/ that will show
the latest status of a Taskcluster-Github build or test run.

As a collection of smaller projects, there is plenty of flexibility to
add or remove projects during the internship. You are encouraged to
talk to other teams in Mozilla and, if you find a feature that will
help them use Taskcluster more effectively, implement that feature
instead.

What you'll learn and use:

* Javascript (mostly server-side, using node)
* Github Webhooks and APIs
* Taskcluster APIs

Previous Experience:

You should be familiar with Javascript, although it is OK if that is
limited to scripts that run in the browser. You should be familiar
with Github, including making pull requests and using continuous
integration tools like Travis-CI or CircleCI. Ideally, you would have
some experience working with other people on an open-source project,
modifying existing code and getting feedback in reviews.

==== Collaboration Tools for Open Source Participation and Productivity ====

Mentor: [https://mozillians.org/en-US/u/dmarti/ Don Marti]

We are interested in pushing the limits of what automation can do to help de-stress open source projects, especially low-profile ones that put a lot of work onto an individual maintainer or small team. Interested in writing bots to help maintainers with the routine tasks of software development, bots that can help coach new contributors to get productive, or both? If you have an idea for a collaborative tool that would help you, and you're interested in coding it and seeing if it can help others, please consider joining us. Helpful skills to have

* HTTP client development
* Use of web APIs (GitHub, Twitter...)
* git
* Empathy for new and time-crunched developers

None of these are hard requirements -- We're prepared to collaborate with you and your bot(s) to learn and gather data.

==== Help drive the Nightly Reboot on Firefox Desktop/Mobile ====
Mentor: [https://mozillians.org/en-US/u/marcia/ Marcia Knous] (marcia on IRC)

This project involves helping the Release Management team and the Mozilla community drive the "Nightly Reboot" on Firefox Desktop and Mobile. You can read more about it here: https://blog.nightly.mozilla.org/2016/07/01/a-firefox-nightly-blog/. Here are some of the things you will work on as part of this internship:

Bug and Crash triage

*Help the team identify and triage Nightly bugs
*Identify and investigate crashes in the Nightly project
*Organize Test Days specific to Firefox Nightly

Applicants should have:

*Experience using the Firefox browser and an understanding of what the Firefox Nightly Channel is
*Strong organizational abilities
*Inquisitive nature
*Comfortable working in Bugzilla
*Bonus if you have experience doing QA

Applicants will gain skills in:
* Investigative analysis
* Problem solving

This should be a fun experience, especially for those who love working on solving problems and making the Firefox experience better for everyone!

==Outreachy Program Cohort: Round 12 (May-August 2016)==
===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]
* Participant: [https://mozillians.org/en-US/u/anaribeiro/ Ana Ribero]
* [http://outreachy.anaplusplus.com/ Participant Blog]

Inclusive culture is essential to building all kinds of diversity and making diverse people feel welcome in open source projects. We have many groups working on this topic all around Mozilla and other open source communities. This Outreachy participant will engage in community research, documenting best practices and case studies in the development of open inclusive culture.

The participant will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

===Make Firefox look great on desktop!===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]
*Participant: [https://mozillians.org/en-US/u/Rakhi/ Rakhi Sharma]
* [http://rakhish.wordpress.com/ Participant Blog]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, the participant will help to address a number of styling problems where Firefox does not currently look its best.

===Project SmartHome prototyping===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
* Participant: [https://mozillians.org/en-US/u/Mermi/ Manel Rahem]
* Participant Blog: https://mermi.github.io

The participant will be involved with Project SmartHome, working on assisting active and ongoing prototyping, integrating logging and metrics into SmartHome work with the collaboration of the metrics team, and helping with user research testing analysis and results.

===Webcompat.com Web Application Engineer===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
*Participant: [https://mozillians.org/en-US/u/venkid/ Deepthi Venkitaramanan]
*[http://venkid.com/portfolio.html#Outreachy Participant Blog]

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

In this Outreachy project, the participant will contribute to one or more of the following projects to help us succeed from a few different angles.
* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

===Convert Mozmill tests to Marionette===
*Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC
*Participant: [https://mozillians.org/en-US/u/bennyjr35/ Benjamin "Benny" Forehand, Jr.]
*Participant Blog: https://www.bennyjr.xyz/blog and https://benjaminfjr.blogspot.com/

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
*Participant: [https://mozillians.org/en-US/u/ipsha21/ Ipsha Bhidonia]
*[https://ipsha218.wordpress.com/feed/ Participant Blog]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
* Participant: [https://mozillians.org/en-US/u/vakila/ Anjana Vakil]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

===Improving user experience of Firefox Accounts===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
* Participant: [https://mozillians.org/en-US/u/Rutuja/ Rutuja Surve]
* [https://rutujasurveblog.wordpress.com/2016/05/17/outreachy-2016-my-first-post/ Participant Blog]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

===Taskcluster tools UI/UX improvements===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
* Participant: [https://mozillians.org/en-US/u/andreadelrio/ Andrea Del Rio Lazo]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack]
* Participant: [https://mozillians.org/en-US/u/kt/ Kristel Teng]

Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
* Participant: [https://mozillians.org/en-US/u/kbroida/ Katie Broida]
* [http://blog.katiebroida.com/ Participant Blog]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
*Participant: [https://mozillians.org/en-US/u/deckycoss/ Decky Coss]
*Participant Blogs: http://cosstropolis.com/blog and http://cosstropolis.com/blog/feed.xml

"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

===Prototype new Firefox features with the Test Pilot team===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)
* Participant: [https://mozillians.org/en-US/u/kaganjd/ Jen Kagan]
* Participant blog

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what the participant will be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

= For Future Applicants =
* Next Outreachy round is Winter 2016-17. Keep in touch by reading here or on gnome.org/outreachy to learn application deadlines.

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 13.
Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

=Past Outreachy/OPW internships=

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-09-12T18:35:33Z

Wcosta: /* Add taskcluster-cli project */

Mozilla has participated in the Outreachy program for several years. The goals of the program are to increase participation from under-represented groups in free and open source software. Participation is open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer three month paid contribution opportunities twice a year.

==Useful links for More Information==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]
==Applications for Round 13 (Dec 2016-March 2017) open Monday September 12==
===Project List===
====Build a Library of Inclusion Best Practices and Case Studies====
* Mentor: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro]

This project is a community research project to identify and document examples of successful inclusive teams and communities within Mozilla, in order to amplify successes and highlight bright spots. The Outreachy participant will assess programs for suitability, and then interview participants, and then document case studies, referencing appropriate research and industry/community best practices. This is a great opportunity for a person interested in Diversity and Inclusion, Community Building, or User/Community research.

Skills learned in this project will include effective interviewing, case study development, awareness of research in best practices in inclusion across cultures and other diversity dimensions, and wiki markup/editing.

Your work sample should be a short written case study of a program or project you have done as a volunteer or as a new employee, technical or non, and should describe exactly how this program or project included you and failed to include you. Specific examples, connections to research, and detail are appreciated. It should be a several paragraph document.

====Improving user experience of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your software engineering skills will assist in the following:

Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows.

Improving the verification rate and speed of new users signing up for Firefox Accounts.

Skill requirements for this project: Git, JavaScript.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

====Improving server-side components of Firefox Accounts====
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

This project is part of improving the server components of Firefox Accounts. You will be involved in improving the security, APIs, and measuring success of certain features. Detailed projects:

Improving Firefox Sync and Firefox Accounts integration.
Improving device management and OAuth APIs.

Skill requirements for this project: Git, Node.js.
Software requirements: Mac OS or Linux.
As part of your application please try to fix a ‘good first bug’ at:
[https://waffle.io/mozilla/fxa?label=good-first-bug waffle.io/mozilla/fxa?label=good-first-bug]

To get started with Firefox Accounts please visit: [https://github.com/mozilla/fxa-content-server#quick-start github.com/mozilla/fxa-content-server#quick-start]

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

==== User Impact of XSS Filters within Web Browsers ====
* Mentors: [https://mozillians.org/en-US/u/ckerschbaumer/ Christoph Kerschbaumer] & [https://mozillians.org/en-US/u/freddyb/ Frederik Braun]

Cross Site Scripting (XSS) consistently ranks highest in the list of the most prevalent software vulnerabilities.
Using XSS, hackers can gain access to confidential user data and conduct transactions on behalf of the user.
Many browsers provide a built-in XSS filter to protect the majority of users from XSS issues. Such heuristic based filters also trigger false positives. This may downgrade a user's experience on a benign site. Even worse, such filters might even introduce new vulnerabilities.

To the end of the project we expect you to

* implement an XSS filter within Firefox
* measure user impact based on false positive rate
* measure performance
* co-produce a white paper with the mentors that summarizes the outcome of this project.
* (Pro Tip: This might qualify as a term paper or even grow into a thesis for your studies).

How you can prepare for the program:

* Familiarize yourself with the problem by reading literature on XSS-Filters:
** Introduction of the Chrome/Webkit filter called XSS Auditor in "Regular expressions considered harmful in client-side XSS filters"
** Security vulnerabilities introduced though XSS filters in IE8: https://blog.c22.cc/2010/04/15/blackhat-europe-universal-xss-via-ie8s-xss-filters-2/
** Bypassing XSS filters: (http://www.thespanner.co.uk/2015/02/10/xss-auditor-bypass/, http://brutelogic.com.br/blog/chrome-xss-bypass/)
* Familiarize yourself with the state of the art of implementing an XSS filter
** Browse the source code of NoScript, XSSAuditor in WebKit, or also the source of Internet Explorer (which can be inspected by looking into mshtml.dll)
** Compare approaches of these filters to answer questions like: where do their approaches overlap, which differences exist in their threat models, etc.
* Prepare yourself for implementing a filter within Firefox
** Outline the advantages and disadvantages of existing approaches Sketch out details for the actual implementation

We would be thrilled if you have a

* a deep understanding of Web Security and XSS
* a fundamental understanding of browser architecture
* solid experience in developing C/C++ applications
* the ability to work with a geographically distributed development team
* experience in learning, building and being effective with a large code base

We at Mozilla Security Engineering give you the opportunity to improve Firefox. We are an equal opportunity employer and value diversity. We do not discriminate on the basis of race, religion, color, national origin, gender, sexual orientation, age, marital status, veteran status, or disability status.

=== taskcluster-cli go implementation ===

* Mentors: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] & [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]

==== Background ====

Mozilla is a company that is strongly committed to inclusion and diversity.
The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in, like NSS. Taskcluster is built
using distributed 'cloud' computing services where possible. Taskcluster
developers and users often need to do some tasks manually, like craft, inspect
and kill tasks; roles and users management; download artifacts, etc.
taskcluster-cli is a generic command line tool to interact with Taskcluster,
built by and for shell command lovers. We have a long live
[https://github.com/taskcluster/taskcluster-cli Javascript implementation],
and are starting a
[https://github.com/taskcluster/taskcluster-cli/tree/go-tc-cli new version] completely
rewritten in [https://golang.org/ Golang].

==== Project ====

The goal of this project is to implement the main features to the new
Golang based taskcluster-cli, including task creation, task groups scheduling,
users management, and so on. We want someone that is keen to learn and
engaged on making taskcluster-cli a great tool. You should know basics of
Go (Go is a simple language and the basics can be learned during application
process). The advanced skills on the language can be acquired during internship
with help from project mentors. Some knowledge of Javascript (ES6 is a plus) is
desired but not required (although you may expect reading some modern Javascript
code from time to time), as well as some general concepts of Web APIs.

Required skills:

* Go programming language (you can learn during application process)
* Desire to learn
* Engagement

Desired skills:

* Javascript
* ES6
* Web APIs

==Outreachy Program Cohort: Round 12 (May-August 2016)==
===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]
* Participant: [https://mozillians.org/en-US/u/anaribeiro/ Ana Ribero]
* [http://outreachy.anaplusplus.com/ Participant Blog]

Inclusive culture is essential to building all kinds of diversity and making diverse people feel welcome in open source projects. We have many groups working on this topic all around Mozilla and other open source communities. This Outreachy participant will engage in community research, documenting best practices and case studies in the development of open inclusive culture.

The participant will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

===Make Firefox look great on desktop!===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]
*Participant: [https://mozillians.org/en-US/u/Rakhi/ Rakhi Sharma]
* [http://rakhish.wordpress.com/ Participant Blog]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, the participant will help to address a number of styling problems where Firefox does not currently look its best.

===Project SmartHome prototyping===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
* Participant: [https://mozillians.org/en-US/u/Mermi/ Manel Rahem]
* Participant Blog: https://mermi.github.io

The participant will be involved with Project SmartHome, working on assisting active and ongoing prototyping, integrating logging and metrics into SmartHome work with the collaboration of the metrics team, and helping with user research testing analysis and results.

===Webcompat.com Web Application Engineer===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
*Participant: [https://mozillians.org/en-US/u/venkid/ Deepthi Venkitaramanan]
*[http://venkid.com/portfolio.html#Outreachy Participant Blog]

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

In this Outreachy project, the participant will contribute to one or more of the following projects to help us succeed from a few different angles.
* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

===Convert Mozmill tests to Marionette===
*Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC
*Participant: [https://mozillians.org/en-US/u/bennyjr35/ Benjamin "Benny" Forehand, Jr.]
*Participant Blog: https://www.bennyjr.xyz/blog and https://benjaminfjr.blogspot.com/

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
*Participant: [https://mozillians.org/en-US/u/ipsha21/ Ipsha Bhidonia]
*[https://ipsha218.wordpress.com/feed/ Participant Blog]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
* Participant: [https://mozillians.org/en-US/u/vakila/ Anjana Vakil]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

===Improving user experience of Firefox Accounts===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
* Participant: [https://mozillians.org/en-US/u/Rutuja/ Rutuja Surve]
* [https://rutujasurveblog.wordpress.com/2016/05/17/outreachy-2016-my-first-post/ Participant Blog]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

===Taskcluster tools UI/UX improvements===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
* Participant: [https://mozillians.org/en-US/u/andreadelrio/ Andrea Del Rio Lazo]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack]
* Participant: [https://mozillians.org/en-US/u/kt/ Kristel Teng]

Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
* Participant: [https://mozillians.org/en-US/u/kbroida/ Katie Broida]
* [http://blog.katiebroida.com/ Participant Blog]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
*Participant: [https://mozillians.org/en-US/u/deckycoss/ Decky Coss]
*Participant Blogs: http://cosstropolis.com/blog and http://cosstropolis.com/blog/feed.xml

"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

===Prototype new Firefox features with the Test Pilot team===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)
* Participant: [https://mozillians.org/en-US/u/kaganjd/ Jen Kagan]
* Participant blog

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what the participant will be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

= For Future Applicants =
* Next Outreachy round is Winter 2016-17. Keep in touch by reading here or on gnome.org/outreachy to learn application deadlines.

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 13.
Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

=Past Outreachy/OPW internships=

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-31T13:07:42Z

Wcosta: /* Add robust AMI management to the TaskCluster AWS Provisioner [No longer taking applications] */

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12. Each project and its mentor are below.

Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===Convert Mozmill tests to Marionette [No longer taking applications]===
Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner [No longer taking applications]===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience.

To get involved:
* Try out the [https://github.com/mozilla/fxa-local-dev mozilla/fxa-local-dev] repository to get a local copy of Firefox Accounts.
* Read through some of past and future UX projects: [https://github.com/mozilla/fxa/tree/master/features/shipped/FxA-33-choose-what-to-sync Choose What to Sync], [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md Show Password], [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md Mailcheck].
* See if you can fix an [https://github.com/mozilla/fxa-content-server/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-bug easy bug in the Firefox Accounts front-end].
* Ask a question in '''#fxa''' channel on Mozilla IRC.
* Read general docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer [no longer taking applicants]===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

Note: Issues with a "outreachy-project" label are intended to be possible projects for the Outreachy intern. Good to look at and think about - but not ready to work on just yet. :)

===Content Process Management Tool [No longer taking applications] ===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani [No longer taking applications] ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements [No longer taking applications]===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface [No longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop! [no longer taking applicants] ===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://public.etherpad-mozilla.org/p/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team [no longer taking applicants]===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-25T14:06:02Z

Wcosta: /* Taskcluster tools UI/UX improvements [No longer taking applicants] */

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12. Each project and its mentor are below.

Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===Convert Mozmill tests to Marionette [No longer taking applications]===
Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience.

To get involved:
* Try out the [https://github.com/mozilla/fxa-local-dev mozilla/fxa-local-dev] repository to get a local copy of Firefox Accounts.
* Read through some of past and future UX projects: [https://github.com/mozilla/fxa/tree/master/features/shipped/FxA-33-choose-what-to-sync Choose What to Sync], [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md Show Password], [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md Mailcheck].
* See if you can fix an [https://github.com/mozilla/fxa-content-server/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-bug easy bug in the Firefox Accounts front-end].
* Ask a question in '''#fxa''' channel on Mozilla IRC.
* Read general docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer [no longer taking applicants]===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

Note: Issues with a "outreachy-project" label are intended to be possible projects for the Outreachy intern. Good to look at and think about - but not ready to work on just yet. :)

===Content Process Management Tool [No longer taking applications] ===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani [No longer taking applications] ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements [No longer taking applications]===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop! [no longer taking applicants] ===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team [no longer taking applicants]===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-25T14:05:31Z

Wcosta: /* Taskcluster tools UI/UX improvements */

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12. Each project and its mentor are below.

Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===Convert Mozmill tests to Marionette [No longer taking applications]===
Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience.

To get involved:
* Try out the [https://github.com/mozilla/fxa-local-dev mozilla/fxa-local-dev] repository to get a local copy of Firefox Accounts.
* Read through some of past and future UX projects: [https://github.com/mozilla/fxa/tree/master/features/shipped/FxA-33-choose-what-to-sync Choose What to Sync], [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md Show Password], [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md Mailcheck].
* See if you can fix an [https://github.com/mozilla/fxa-content-server/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-bug easy bug in the Firefox Accounts front-end].
* Ask a question in '''#fxa''' channel on Mozilla IRC.
* Read general docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer [no longer taking applicants]===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

Note: Issues with a "outreachy-project" label are intended to be possible projects for the Outreachy intern. Good to look at and think about - but not ready to work on just yet. :)

===Content Process Management Tool [No longer taking applications] ===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani [No longer taking applications] ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements [No longer taking applicants]===

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop! [no longer taking applicants] ===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team [no longer taking applicants]===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-23T21:15:06Z

Wcosta: /* Taskcluster tools UI/UX improvements is no longer taking applicants*/

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12. Each project and its mentor are below.

Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===Convert Mozmill tests to Marionette [No longer taking applications]===
Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI.
Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts [no longer taking applicants]===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience.

To get involved:
* Try out the [https://github.com/mozilla/fxa-local-dev mozilla/fxa-local-dev] repository to get a local copy of Firefox Accounts.
* Read through some of past and future UX projects: [https://github.com/mozilla/fxa/tree/master/features/shipped/FxA-33-choose-what-to-sync Choose What to Sync], [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md Show Password], [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md Mailcheck].
* See if you can fix an [https://github.com/mozilla/fxa-content-server/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-bug easy bug in the Firefox Accounts front-end].
* Ask a question in '''#fxa''' channel on Mozilla IRC.
* Read general docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer [no longer taking applicants]===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

Note: Issues with a "outreachy-project" label are intended to be possible projects for the Outreachy intern. Good to look at and think about - but not ready to work on just yet. :)

===Content Process Management Tool [No longer taking applications] ===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani [No longer taking applications] ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements===

'''No longer taking applicants'''

* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop! [no longer taking applicants] ===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team [no longer taking applicants]===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-21T09:28:41Z

Wcosta: /* Taskcluster tools UI/UX improvements */ Remove vacaction info

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12. Each project and its mentor are below.

Got Questions? Ask:

Outreachy Coordinator:
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===Convert Mozmill tests to Marionette===
Mentor: John Dorlus <jdorlus@mozilla.com>

This project involves reading and writing code in both Python and Javascript. Mozmill is one of Mozilla’s older automated testing frameworks; tests written in Mozmill are being ported to Marionette, which is an implementation of the Webdriver standard, capable of interacting with both web content and browser UI. Applicants should have a strong knowledge of Python and at least some exposure to Javascript. The starting point (and main focus) for this project will be the work outlined in Bug 1132680; there is other work in the same area that can be done if that bug gets finished early.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] (vladikoff on IRC)

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and [https://accounts.firefox.com Firefox Accounts]. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

* Developing new application improvements to reduce the number of user errors on password reset, [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md password change], and [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md sign up flows]. This will give you developer experience working with the Firefox Accounts UX team.
* Experimenting with [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md “Show Password” UX]. Determining which design is more effective in terms of speed and popularity.
*Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience.

To get involved:
* Try out the [https://github.com/mozilla/fxa-local-dev mozilla/fxa-local-dev] repository to get a local copy of Firefox Accounts.
* Read through some of past and future UX projects: [https://github.com/mozilla/fxa/tree/master/features/shipped/FxA-33-choose-what-to-sync Choose What to Sync], [https://github.com/mozilla/fxa/blob/rfeeley/eye-password-experiment/features/FxA-80-eye-password-experiment/README.md Show Password], [https://github.com/mozilla/fxa/blob/feature-mailcheck-part-two/features/proposed/FxA-79-mailcheck-part-2/README.md Mailcheck].
* See if you can fix an [https://github.com/mozilla/fxa-content-server/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-bug easy bug in the Firefox Accounts front-end].
* Ask a question in '''#fxa''' channel on Mozilla IRC.
* Read general docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer ===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

'''Note: Mike is going to be on PTO from March 10th through March 18th, but hallvors and karlcow should be able to give guidance in #webcompat. Feel free to email miketaylr@gmail.com with any specific questions (but give 24 hours for a reply ^_^)'''

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements===
* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop! [no longer taking applicants] ===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Outreachy

2016-03-12T15:58:24Z

Wcosta: /* Taskcluster tools UI/UX improvements */ Add Dustin as co-mentor and add pto info

Mozilla has participated in the GNOME-OPW program for several years. Originally called GNOME-OPW (GNOME Outreach Program for Women), this program is now called Outreachy and has a broadened scope. The goals of the program are to increase participation from under-represented groups in free and open source software. Internships are open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12 are being posted as they are approved, through February 28. As projects become available they will be listed here and advertised via social media.

Got Questions? Ask:

Outreachy Coordinators:
* [https://mozillians.org/en-US/u/jfinette/ Jane Finette], Executive Program Manager
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier] (teoli on IRC, feel free to ping me)
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

'''For more information, see the project's [https://github.com/davehunt/pytest-html#outreachy Outreachy help].'''

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
[https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette's] Python Test Runner is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have you help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of your role will be to write more of these tests. While writing tests, you will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by "test-driven refactoring". Other tasks might include:
* Making the test results more informative and easy to read on [https://treeherder.mozilla.org Treeherder's] log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are need:
* programming in Python or other object-oriented language: you have written small, stand-alone projects yourself from scratch and you have used concepts like inheritance
* some very basic experience with using command-line tools and any version control system
* motivation and patience to read/understand lots of messy code/documentation and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, you will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

'''To get started, please follow these [[User:Mjzffr/New Contributors|instructions]].
'''

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov]

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

- Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows. This will give you developer experience working with the Firefox Accounts UX team.

- Experimenting with “Show Password” UX. Determining which design is more effective in terms of speed and popularity.

- Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience. You can get involved by trying out the fxa-local-dev (https://github.com/mozilla/fxa-local-dev) repository and check out the docs at http://fxa.readthedocs.org.

===Webcompat.com Web Application Engineer ===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.

In this Outreachy project, you will contribute to one or more of the following projects to help us succeed from a few different angles (depending on your interest).

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server
* Migrate webcompat.com front-end to use ES6 modules (likely powered by something like Babel)

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

To be successful in this Outreachy project, you should be comfortable with Python and relational databases -- we talk to SQLite via an ORM called SQLAlchemy. The more experience with JavaScript and CSS the better, but most important is the willingness to jump and in learn.

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel (and ask questions if you get stuck!)

If you find yourself wanting to work on some other issues or area of the codebase, check out the ""good-next-patch"" label as well!

'''Note: Mike is going to be on PTO from March 10th through March 18th, but hallvors and karlcow should be able to give guidance in #webcompat. Feel free to email miketaylr@gmail.com with any specific questions (but give 24 hours for a reply ^_^)'''

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for Project Vaani ===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects, specifically [https://wiki.mozilla.org/Vaani Project Vaani].

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements===
* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] Vacation until 2016/03/21, contact Dustin.
* Co-Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]

[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Fixing some papercuts in the Firefox desktop user interface===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
* Improving entering and exiting of Reader Mode
* Cleaning up the styling of our getting-started tour
* Improving shadows of the dropdowns for the URL and search box
* Increasing legibility of the menubar on Windows 8
* Researching and improving the Windows 10 Start Menu tile for Firefox
* Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful. To gauge your JS and CSS skills, you should be able to comfortably explain how JavaScript's prototype inheritance works, the difference between a capturing and a bubbling event listener, and how the CSS box model works.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop!===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the JS, CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox Browser Toolbox] to have a look around a regular install of Firefox for our CSS and markup;
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build set up the source tree] and [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds create an "artifact build" of Firefox] so you can quickly change CSS, test it and submit patches;
* submit patches for one of the [https://mzl.la/1WWxOcZ outreachy 'easy' theme bugs].

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

===Prototype new Firefox features with the Test Pilot team===
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC)

The Mozilla Test Pilot team is seeking someone to join a small, enthusiastic team focused around rapidly testing new features in Firefox. The team's process is built around getting feedback frequently and directly from an active user base which allows rapid iteration of the feature design.

In this program, you will participate in a well-documented four step process:
* Lo-Fi Validation: Sketches, ideation, paper prototypes, and user research.
* Prelaunch: Define and build a minimum viable product, establish your testing protocols, and validate the research.
* Active Testing: Launch and test your prototype, collect metrics and feedback, evolve and re-test.
* Sunsetting: Analyze the tests and determine release platforms.

As this program is about rapidly evaluating potential new features, the specifics of what you’ll be developing this summer haven't been settled yet--but ideas are floating around security, privacy, tracking protection, and file transfer. Below are some examples of what the team is currently prototyping as of February 2016:

* Universal Search: adding recommendations from sources around the internet directly into the Awesome Bar.
* Tab Center: rethinking tab management by moving tabs to the side of the browser and making them easier to search.
* Better 404s: Using the Internet Archive's Wayback Machine to replace 404 pages with an older version of the page.
* Page Shot: Enabling smarter sharing of screenshots by copying DOM content as well.

Most of our development work involves writing Firefox add-ons, so you should be familiar with JavaScript, CSS, and HTML. Intellectual curiosity, enthusiasm, and interest in the Open Web matters more than your past experience.

Find out more and get in touch with us at https://wiki.mozilla.org/Test_Pilot

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

WeeklyUpdates/2016-03-14

2016-03-11T21:38:11Z

Wcosta: /* Speakers */ Taskcluster try jobs

{{WeeklyUpdateNav}}
* Every Monday @ 11:00am Pacific Time (19:00 UTC)
* http://air.mozilla.org/ to watch and listen
* join irc.mozilla.org #airmozilla for backchannel discussion
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak.
{{conf|8600}}
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.

__TOC__

= All-hands Status Meeting Agenda =

Items in this section will be shared during the live all-hand status meeting.

== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==

== Upcoming Events ==

=== This Week ===

=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===

=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===

=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===

=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===

=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===

=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===

=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===

=== Next Week ===

== Project Status Updates (voice updates) ==

=== Firefox and Cloud Services ===
''Speaker Location:''

=== Connected Devices ===
''Speaker Location:''

=== CTO Update ===
''Speaker Location:''

=== Mozilla Communities ===
''Speaker Location:''

== Speakers ==

The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.

{| class="fullwidth-table wikitable"
|-
! [https://mozillians.org/u/USERNAME Presenter]
! Title
! Topic
! Location
! Sharing
! Media
! More Details
|-
| Who Are You?
| What Do You Do?
| What are you going to talk about?
| Where are you presenting from? (Moz Space, your house, space)
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)
| Links to slides or images you want displayed on screen
| Link to where audience can find out more information
|-
| Wander Costa (wcosta)
| Taskcluster
| Adding Taskcluster tasks to try
| Brazil (remote)
| no
| Airmozilla
| [https://air.mozilla.org/how-to-add-taskcluster-tasks-to-try-server/ Presentation video] (the talk is this video)
|-
|}

= Welcome! =

Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

== Introducing New Volunteers ==
{| class="fullwidth-table wikitable"
|-
! [https://mozillians.org/u/USERNAME New Volunteer]
! [https://mozillians.org/u/USERNAME Introduced by]
! Speaker location
! New Volunteer location
! Will be working on
|-
| ''Who is the new volunteer?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be contributing from?''
| ''What will the new person be working on?''
|-

|-
|}

== Introducing New Hires ==
{| class="fullwidth-table wikitable"
|-
! New Hire
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new hire?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-

|-
|}

== Introducing New Interns ==
{| class="fullwidth-table wikitable"
|-
! New Intern
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new intern?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-

|-
|}

= <meta> =

Notes and non-voice status updates that aren't part of the live meeting go here.

== Status Updates By Team (*non-voice* updates) ==

=== Firefox ===

=== Platform ===

=== Cloud Services ===

=== Messaging ===

=== Mobile ===

=== IT ===

=== Release Engineering ===

=== QA ===

==== Test Execution ====

==== Web QA ====

==== QA Community ====

=== Engineering Productivity (Automation & Tools) ===

=== Security ===

=== Engagement ===

* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1X5kUBkEAicEe2unDaaLGTYzAJbphWFoaJYBTasHrcHQ/edit#gid=1764494528 Engagement's Active Project Dashboard]

==== PR ====

==== Events ====

==== Social Support ====

[[Category:Weekly Updates]]
[[Category:Meeting Notes]]

WeeklyUpdates/2016-03-07

2016-03-07T18:05:24Z

Wcosta: /* Speakers */

{{WeeklyUpdateNav}}
* Every Monday @ 11:00am Pacific Time (19:00 UTC)
* http://air.mozilla.org/ to watch and listen
* join irc.mozilla.org #airmozilla for backchannel discussion
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak.
{{conf|8600}}
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.

__TOC__

= All-hands Status Meeting Agenda =

Items in this section will be shared during the live all-hand status meeting.

== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==

== Upcoming Events ==

=== This Week ===

=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===

=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===

=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===

=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===

=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===

=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===

=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===

=== Next Week ===

== Project Status Updates (voice updates) ==

=== Firefox and Cloud Services ===
''Speaker Location:''

=== Connected Devices ===
''Speaker Location:''

=== CTO Update ===
''Speaker Location:''

=== Mozilla Communities ===
''Speaker Location:''

== Speakers ==

The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.

{| class="fullwidth-table wikitable"
|-
! [https://mozillians.org/u/USERNAME Presenter]
! Title
! Topic
! Location
! Sharing
! Media
! More Details
|-
| Who Are You?
| What Do You Do?
| What are you going to talk about?
| Where are you presenting from? (Moz Space, your house, space)
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)
| Links to slides or images you want displayed on screen
| Link to where audience can find out more information
|-
|-
| Jordan Lund (jlund)
| Release Engineering
| Release Promotion
| Vancouver
| yes
| I'll provide via sharing
| [https://docs.google.com/presentation/d/1t0Y4xUSppMkySqlbKb3GOEDjOZYnc1e3G1kkjGX5PM8/edit#slide=id.p slides]
|-
| Jorge Villalobos
| Add-ons
| Breakthroughs in the Add-on Review Queues
| Costa Rica (remote)
| no
| [https://blog.mozilla.org/addons/2016/03/04/breakthroughs-in-the-add-on-review-queues/ Blog post]
|
|-
| Wander Costa (wcosta)
| Taskcluster
| Adding Taskcluster tasks to try
| Brazil (remote)
| no
| Airmozilla
| [https://air.mozilla.org/how-to-add-taskcluster-tasks-to-try-server/ Presentation video]
|-
|}

= Welcome! =

Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

== Introducing New Volunteers ==
{| class="fullwidth-table wikitable"
|-
! [https://mozillians.org/u/USERNAME New Volunteer]
! [https://mozillians.org/u/USERNAME Introduced by]
! Speaker location
! New Volunteer location
! Will be working on
|-
| ''Who is the new volunteer?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be contributing from?''
| ''What will the new person be working on?''
|-

|-
|}

== Introducing New Hires ==
{| class="fullwidth-table wikitable"
|-
! New Hire
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new hire?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-
| Grisha Kruglov
| Margaret Leibovic
| Toronto
| Vancouver
| Firefox for Android
|-

|-
|}

== Introducing New Interns ==
{| class="fullwidth-table wikitable"
|-
! New Intern
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new intern?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-

|-
|}

= <meta> =

Notes and non-voice status updates that aren't part of the live meeting go here.

== Status Updates By Team (*non-voice* updates) ==

=== Firefox ===

=== Platform ===

=== Cloud Services ===

=== Messaging ===

=== Mobile ===

=== IT ===

=== Release Engineering ===

=== QA ===

==== Test Execution ====

==== Web QA ====

==== QA Community ====

=== Engineering Productivity (Automation & Tools) ===

=== Security ===

=== Engagement ===

* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1X5kUBkEAicEe2unDaaLGTYzAJbphWFoaJYBTasHrcHQ/edit#gid=1764494528 Engagement's Active Project Dashboard]

==== PR ====

==== Events ====
'''Developer events''': Interested in giving a technical talk at a regional tech conference or developer event? This public calendar maintained by the Developer Relations team lists developer events based on the closing date of their calls for papers. Want to add events? Please ping Havi:
*CFP (Call-for-Proposals) calendar [http://bit.ly/mozdevrel-cfps developer events - embed view]
**ical view - CFP (Call-for-Proposals) calendar [http://bit.ly/moz-cfps-ical developer events]

==== Social Support ====

[[Category:Weekly Updates]]
[[Category:Meeting Notes]]

Outreachy

2016-02-29T15:22:57Z

Wcosta: /* Taskcluster tools UI/UX improvements */

Mozilla has participated in the GNOME-OPW program for several years.

The Outreach Program for Women (OPW) helps women (cis and trans) and genderqueer get involved in free and open source software. We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

==Useful links==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Upcoming Outreachy Program: Round 12 (June-August 2016)==

== Key Dates ==
* February 22 Applications are open!
* February 28 Mentor applications close
* March 22 Participant Applications due

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

Please look at the projects and consider your options and join the #outreachy IRC room to chat with mentors. You need to make a small contribution to the area you wish to apply for.

==Projects to Apply for==
There will be several Mozilla Outreachy projects for Round 12 are being posted as they are approved, through February 28. As projects become available they will be listed here and advertised via social media.

===SVG Reference Documentation===
* Mentor: [https://mozillians.org/en-US/u/teoli/ Jean-Yves Perrier]
*The participant will have to perform the following tasks:
** Write a reference page for each SVG-related interface.
** Create a code sample showing the use of each interface.
** Write a reference page for each property and method, adapting the code sample of the relevant interface for displaying the usage of the specific entity.
** Adapt the SVG tutorial to the newly written reference documentation.

* The following skills are needed:
** fair knowledge of HTML and SVG
** basic knowledge of JavaScript and DOM, ability to create and access nodes of the DOM tree.
** ability to write fluently in English (English as a native language is NOT required)
** ability to write basic code samples (10-20 lines of code each)
** familiarity with a wiki and/or github is a plus.

===Realtime Push Notifications for Kinto===
*Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
Kinto is the Mozilla storage solution to backup and sync Firefox Account Users data. It is currently used as a backend for Firefox OS applications and for Firefox and Fennec updates in the Go Faster projects.
https://kinto.readthedocs.org

Today a notification system allow us to notify Firefox and Fennec users for them to come and get updates.

The participant would extend the notification system to implement realtime updates between devices.

* On the server side we are using Pyramid and Python with a bit of AsyncIO
* On the client side this will involve JavaScript and Websocket management.

===Enhancements to Python testing tool plugin for generation of HTML reports===
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]

The successful candidate will be responsible for developing enhancements to pytest-html - a plugin based on the popular Python testing tool pytest, which generates a HTML report based on test results.

The desired enhancements include: gracefully degrading when JavaScript is not available; saving CSS, images, and other resources as additional files rather than embedding in a single file; grouping results by package/module/class; and including test docstrings in the report.

Any new enhancements to the plugin must also be accompanied with tests, which will ensure that these new features work in all expected environments, and reduce the chances of regression.

It would be advantageous for potential candidates to have experience in creating simple HTML pages using JavaScript and CSS, however this is not essential. It would also help if the candidate has experience with Python or pytest, but again this is not essential so long as the candidate is willing and able to learn these skills during the internship.

===Test-driven Refactoring of Marionette's Python Test Runner===
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
Marionette's Python Test Runner (a.k.a marionette-client) is slated to become the canonical harness for running most new automated tests for Firefox, but it needs to be lovingly cleaned up and stabilized first. We've already started this work and we're excited to have an intern help us continue.

We want it to be easy and safe for teams around Mozilla to customize the Test Runner for their needs, so we're writing a suite of tests for the Test Runner itself to prevent breaking any existing automation infrastructure -- i.e. we're testing the thing that runs Firefox tests. Part of the intern's role is to write more of these tests. While writing tests, the intern will naturally find areas in the Test Runner code that need to be improved or reorganized in order to be testable in the first place. This is what we mean by ""test-driven refactoring"". Other tasks might include:
* Making the test results more informative and easy to read on Treeherder's log viewer.
* Making the tests more convenient to run locally with mach.

In order to participate, the following skills are needed:
* programming in Python or other object-oriented language: intern has written small, stand-alone projects themselves from scratch and is familiar with concepts like inheritance
* some basic experience with using command-line tools
* some basic experience with any version control system
* motivation and patience to read/understand lots of messy code and to ask lots of thoughtful questions about it

Aside from general Mozilla-contribution skills, the intern will learn:
* More Python as well as Python libraries related to testing and logging
* How Mozilla's release cycle and giant automation infrastructure work
* How to write good tests and write modular, testable code

===Add robust AMI management to the TaskCluster AWS Provisioner===
* Mentor: [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell]
TaskCluster (https://tools.taskcluster.net) is a distributed task execution system Mozilla uses to build, test, and release Firefox. The AWS provisioner is the component responsible for managing the AWS EC2 instances that execute tasks. The project is to improve its management of AMIs, making them easier to create, deploy, and clean up.

For this project, you should have some programming experience in JavaScript, and be ready to learn more. You should know a thing or two about communicating with web services via HTTP APIs. And you should be familiar with Amazon's EC2 service (work through a tutorial or two if you haven't already).

Everything we do is open-source, and we love to see open-source contributions, so improve your chances with a link to your github account or highlight a pull request you are proud of. We would also love to see code (in any language) to talk to an HTTP API (for example, the Github API). Contributing to one of the projects under https://github.com/taskcluster will send your application to the top of the pile!"

===Improving user experience of Firefox Accounts by using experiments and the metrics pipeline===
* Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov]

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project you will be involved in improving user interaction, running experiments, and measuring success of certain features. Your engineering skills will assist in the following:

- Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows. This will give you developer experience working with the Firefox Accounts UX team.

- Experimenting with “Show Password” UX. Determining which design is more effective in terms of speed and popularity.

- Improving the verification rate and speed of new users signing up for Firefox Accounts.

We have existing metrics infrastructure that will assist you in this task. You need strong skills and experience working with front-end JavaScript and CSS projects. It is good to have some node.js, git and Backbone.js experience. You can get involved by trying out the fxa-local-dev (https://github.com/mozilla/fxa-local-dev) repository.

===Webcompat.com Web Application Engineer ===
*Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
"Webcompat.com Web Application Engineer

Mozilla's Web Compatibility team builds and maintains a web application called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

What is Web Compatibility?

Web compatibility is about making sure web sites work consistently across all browsers and devices. Sometimes, sites have bugs or policies that prevent them from working well in every browser. We work to help web developers and site owners identify and fix such issues. And when Firefox is missing crucial standards features that sites rely on, we help communicate this back to the Gecko Platform.
In this Outreachy project, you will contribute to a number of improvements to help us succeed from a few different angles.

* Design and implement a system that allows site owners and developers to register for notifications (i.e., RSS, E-mail) for issues related to a given domain
* Design and build a user interface that allows bug reporters to identify possible duplicate problems
* Use cutting edge features like Service Workers to enable offline and sync capabilities between the client and server

Skills you will use (or develop!):

* Python + Flask
* SQLite
* JS - both on the frontend and Node.js for tooling
* CSS
* UX and UI prototyping

What you can do to get involved:

* Clone the webcopmat.com repo at https://github.com/webcompat/webcompat.com/
* Follow the instructions at CONTRIBUTING.md to set up a local build
* Find a bug labeled ""good-first-patch"" and use it to familiarize yourself with the code base
* Introduce yourself in the #webcompat IRC channel"

===Content Process Management Tool===
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
"With multi-process Firefox going out the door in the very near future, we're looking at scaling up and tuning the number of content processes that Firefox starts and uses.

Memory usage is something we want to keep an eye on while we do this, so this project is about building a Content Process Management tool that can track real-time memory usage across each process. We might increase the number of uses of the management tool over time, but we'll start with memory management.

To be successful, this participant should be very comfortable with JavaScript, HTML and CSS. XUL experience would definitely be an asset, but is not required. Comfort with C++ would be useful as well - at least, the ability to read it and to learn what some C++ is doing, and to not be overwhelmed by it."

===Develop REST/API automation tests for a voice interface for a Connected Devices project===
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
The participant would be involved with developing robust automation suites for existing and emerging Connected Devices projects.

Skills needed:
*Basic proficiency in JavaScript
*Basic proficiency in Java
*Basic proficiency in C++
*Familiar with Open Hab
*Familiarity working with Raspberry Pi
*Natural Language Processing testing methodologies
*Understanding of black box testing and white box testing
*Understanding of Webdriver 2/Selenium
*Interest in learning more about Continuous Integration

===Taskcluster tools UI/UX improvements===
* Mentor: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa]
[https://docs.taskcluster.net Taskcluster] is the new Mozilla CI that will in future be responsible to run every build and test for Firefox, Firefox TV, rust and other Mozilla projects. We are a small and passionate team engaged to make Taskcluster the best CI ever.

[https://tools.taskcluster.net taskcluster-tools] is a modern frontend for several tools and services provided by Taskcluster. If you are passionate about web frontend, this project is for you. During your internship, you will have a lot of fun hacking into the tools [https://github.com/taskcluster/taskcluster-tools codebase] to make a lot of UI/UX improvements.

The applicant must have good HTML, CSS and Javascript skills. Knowledge of React js is desired, but not required.

===Automation of Taskcluster Documentation===
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen]
Our task execution platform TaskCluster consists of many small services.
We would like a system to which each component can upload its documentation in a reference format markdown for text, JSON for API references, etc. From the uploaded references we would then generate the entire documentation site.

By uploading documentation and reference files from the services, we can have it automatically update when we deploy new features.
Services already uploads some formal JSON references, but this needs more structure.

Technically speaking:
- A node.js module for uploading a directory of JSON files + a manifest
- A service generating a static documentation site from uploaded documentation.
Useful skills:
- node.js
- HTML/CSS/JS (react.js would be nice to have)
- Some graphical design skills

This is not a project about writing documentation, most of it already exists. It needs automatic deployment and structure.

===Improving Core Qualities of Firefox Desktop ===
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
Firefox for desktop is used by hundreds of millions of people every day. We control how it works and what it looks like using CSS, XUL (a markup language that's a bit like HTML), and JavaScript. There's also a small amount of C++ here and there.

Some of the work will cover:
- Improving entering and exiting of Reader Mode
- Cleaning up the styling of our getting-started tour
- Improving shadows of the dropdowns for the URL and search box
- Increasing legibility of the menubar on Windows 8
- Researching and improving the Windows 10 Start Menu tile for Firefox
- Showing the Windows 10 accent color in the Firefox title bar

You'd mostly be writing JS and CSS, though being comfortable with some of the other technologies we use will be helpful.

To get a feel for things before the project begins, you can open up the Browser Toolbox and ""inspect"" the UI of the browser. From there you can use MXR (http://mxr.mozilla.org/) to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

===Make Firefox look great on desktop!===
*Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]

"Firefox for desktop is used by hundreds of millions of people every day. We control what it looks like using CSS, XUL (a markup language that's a bit like HTML), and sprinklings of JavaScript. There's also a small amount of C++ here and there.

For this project, we'd like your help to address a number of styling problems where Firefox does not currently look its best. First we would show you around the codebase we have. We'd show you how the CSS and UI is organized, and some of the different configurations in which people use Firefox. You would then be responsible for things like:
* Making sure the separators between Firefox's tabs look good and appear in the right places;
* Fixing arrow panels to appear at a consistent distance from their anchor points;
* Improving our support for Windows' High Contrast themes;
* Adjusting the styling of complex toolbar buttons such as the bookmarks button;
* Creating better-looking <select> popups in Firefox with process separation;

You'd mostly be writing CSS, though being comfortable with some of the other technologies we use will be helpful.

Want to get started? You can:
* use the Browser Toolbox to have a look around a regular install of Firefox for our CSS and markup;
* set up the source tree and create an ""artifact build"" of Firefox so you can quickly change CSS, test it and submit patches;
* submit patches for one of the outreachy 'easy' theme bugs [link tbc]"

===Web Platform Test Crime Scene Investigation===
*Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
"We run a lot of automated tests against each revision to Firefox’s code, and we verify that code changes do not cause tests to stop passing. One group of tests, called Web Platform Tests, is shared among all major web browsers, and we have only begun running them recently. As a result, we imported thousands of tests and marked some of them as currently failing, and they have languished in that state. Some of these failures are caused by Firefox not correctly implementing an edge case, while others may be very important problems - as things stand, it's hard to figure out which ones are which. We need your help cleaning up this mess!

In this project, you will:
* identify the failures reported for a test file by running it and reading through the output, and perhaps investigating Firefox's behaviour using your favourite debugging strategies
* file an issue in Bugzilla tracking this information in an appropriate component
* either fix the failure or add useful information about the test failure to the bug and move on to a new test, with guidance from the mentors
* repeat!

You will read lots of existing tests written in JavaScript (using the [testharness.js](http://testthewebforward.org/docs/testharness.html) framework), while fixing the failures will require prior experience writing C++. Use of a debugger (like gdb or lldb) is strongly encouraged when investigating the cause of test failures. The goal of this work is to understand the nature of our existing test failures, and solve the ones which are not too complicated and do not require any prior experience. Your work will allow other developers to focus on the complex failures in the future, and increase Firefox's conformance with web standards today! Additionally, you will gain experience with a number of the APIs that make up the Web platform.

What you can do to get involved:
* Set up a local Firefox build ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )
* Claim an unclaimed failing test to investigate from https://etherpad.mozilla.org/wpt-csi-starter-tests
* Figure out precisely what's failing, file a bug describing your results, and await further suggestions on how to fix it (alternatively seek out help on IRC (https://wiki.mozilla.org/IRC ) in #introduction)"

Got Questions? Ask:

Outreachy Coordinators:
* [https://mozillians.org/en-US/u/jfinette/ Jane Finette], Executive Program Manager
* [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro], Sr Program Manager, Diversity and Inclusion
IRC: #outreachy

==Past Outreachy/OPW internships==

{{#subpages:}}

== Complete List of Participants ==

=== ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Snappy Symbolication Server

2015-08-17T13:51:38Z

Wcosta:

The Snappy Symbolication Server is a Web server for symbolicating Firefox stacks. It matches PC addresses to modules in memory and looks up the corresponding function names in server-side symbol files (.SYM files).

== Running ==

The source code for Snappy lives in the [https://github.com/mozilla/Snappy-Symbolication-Server Mozilla Github repository]. Snappy runs at [http://www.python.org Python] 2.7 and depends on [http://www.tornadoweb.org Tornado] and
[https://pypi.python.org/pypi/futures concurrent.futures] packages. The best way to install them is through [https://pip.pypa.io pip]:

:<code>pip install tornado futures</code>

To run snappy on your machine, just type:

:<code>python symbolicationWebService.py <configuration-file></code>

The snappy repository contains two sample configuration files for Linux and Windows. Here is a summary for the config fields:

{| class="wikitable"
! Section !! colspan=2 | Fields
|-
! !! Field !! Description
|-
| rowspan=6 | General || hostname || Server address or name
|-
| portNumber || Server port number
|-
| remoteSymbolServer || The address of a secondary remote server to forward requests to
|-
| maxCacheEntries || Number of entries for RAM symbol cache
|-
| mruSymbolStateFile || Json file with RAM cache info
|-
| maxMRUSymbolPersist || Maximum number of symbols for cache
|-
| rowspan=2 | DiskCache || cachePath || Path to cached symbol files
|-
| maxCacheFiles || Maximum number of files in the cache dir
|-
| rowspan=4 | Log || MaxFiles || Maximum number of log files
|-
| maxFileSize || Maximum size for a log file
|-
| logPath || Path to log files
|-
| logLevel || NOTSET, DEBUG, INFO, WARNING, ERROR, CRITICAL
|-
| SymbolPaths || || Each entry represents a path to search for symbols in the local disk
|-
| SymbolURLs || || Each entry represents a remote path to search for symbols
|}

== Contributing ==

It is a [https://github.com Github ] project, just fork it and send a PR. If you want to ask something, you can find people involved with Snappy Server in the #perf channel at irc.mozilla.org.

== Project ideas ==
* Snappy parses symbol files in another process (which we informally call "Symbolication Process") due to the well known [https://www.youtube.com/watch?v=Obt-vMVdM8s GIL problems]. We could have a Symbolication Process per CPU core, but we have a tricky problem here. The Symbolication Process maintains a in memory symbols cache, with the most recently used symbols. The problem is how we handle this, we could have a single shared cache among all Symbolication Processes, which would bring contention, hurting the code parallelism. Other approach is that each Symbolication Process could have its own memory cache, but we potentially could waste memory due to duplicated symbols among all processes, and we could duplicate work because all subprocesses would parse the same symbol file in case of several similar symbolication requests. One good solution is to maintain the memory cache in the parent process.

* The Symbolication Process requests symbol files from S3. This is a I/O bound task, so this should happen in the main process, and then Snappy would use asynchronous I/O for that. The problem is that we have to send the symbol file to the Symbolication Process through IPC. The IPC overhead could kill the performance gain with asynchronous requests. We need performance numbers here to make a decision on what's the best approach.

* Too bad we don't have unit tests.

== Regressions tests ==

Some regressions tests to perform before sending a PR:

* Perform a get request to the server
* Check if the IP in X-Forward-For is logged
* Test requests with /gecko-profiler/ path
* Test for /debug and /nodebug special paths
* Test with compressed symbols files
* Exiting with Control-C should kill the server smoothly
* Check if the host handles ill-formed requests
* Check if symbol server can forward requests
* Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
* Check if the server writes logs to files
* Test requests forward

Snappy Symbolication Server

2015-08-17T11:25:57Z

Wcosta:

PerfTerminology

2015-08-13T15:11:24Z

Wcosta: /* Performance terminology */

=Terminology=

; Main Thread : A browser generally runs all its things sequentially on a single thread, which is typically referred to as '''the main thread'''. This means that Javascript can change stuff which affects the screen, and Javascript code will not continue before the screen reflects the requested changes, or other changes. This is a big bottleneck since it's hard to run things in parallel.

; [http://www.techhive.com/article/229024/geek101_vsync.html v-sync] : Vertical synchronization to the monitor's ''beam reset''. It's used at contexts of animations, where in order to achieve 100% smoothness of animation, each frame should be sent to the display such that it matches the v-sync timing.

; [https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositing OMTC] : Off main thread composition. When rendering graphics in Firefox, this means that the main thread just ''prepares'' the rendering for each frame, but then a heavy chunk of the rendering (''composition'') happens on a different thread. This allows to have more free time on the main thread, which in turn means it can run more Javascript stuff on each frame. BenWa's [http://benoitgirard.wordpress.com/2012/05/15/off-main-thread-compositing-omtc-and-why-it-matters/ blog post] explains OMTC in details.

; [https://wiki.mozilla.org/Platform/GFX/APZ APZ] : Async Pan Zoom (Controller) - technique which browsers sometimes use to zoom and/or pan (move the page up/down/left/right) on a thread which isn't the main thread, therefore allowing longer Javascript calculations on the main thread without affecting the responsiveness for certain operations (specifically - pan and zoom).

; [https://wiki.mozilla.org/Project_Silk Project Silk] : Project to unify and improve animation in Firefox by using global v-sync timing. Before silk, the timing was done at the "refresh driver" using timeouts, where on each such iteration it would run everything the browser needs to run for a single frame. With silk, there's an external module which generates events synchronized to v-sync, which hopefully improves animation smoothness. Check [http://www.masonchang.com/blog/2015/1/22/project-silk this mchang's blog post] for an overview of Project Silk and [https://github.com/changm/SilkDocs/blob/master/silk.md this document] for Project Silk architecture.

Performance

2015-08-13T15:10:33Z

Wcosta:

=Performance=
Mozilla's desktop performance team focuses on improvements to the Gecko platform and desktop Firefox.
You can find us on the #perf channel of irc.mozilla.org or email perf@mozilla.com

'''The team:'''
* Vladan Djeric, :vladan on IRC, [http://blog.mozilla.org/vdjeric/ blog]
* Aaron Klotz :aklotz, [http://dblohm7.ca/ blog]
* Roberto Vitillo :rvitillo, [http://ravitillo.wordpress.com/category/mozilla/ blog]
* Avi Halachmi :avih, [http://avih.github.io/ blog]
* David Teller :Yoric, [http://dutherenverseauborddelatable.wordpress.com/ blog]
* David Major :dmajor

==Current Projects==

* Weekly status reports: [http://benjamin.smedbergs.us/weekly-updates.fcgi/project/perf Mozilla Status Board]

* In Q2, half the team will be working on [[Firefox/Content_Performance_Program|improving web content performance.]]
* [https://wiki.mozilla.org/Platform/2015-Q1-Goals#Perf Our Q1 2015 goals]
* [https://wiki.mozilla.org/Platform/2014-Q4-Goals#Perf Q4 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q3-Goals#Perf Q3 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q2-Goals#Perf Q2 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q1-Goals#Perf Q1 2014 goals]

==Measuring & improving Firefox performance==

===Write-ups===
* [https://developer.mozilla.org/en-US/docs/Mozilla/Performance| Firefox performance knowledge-base]
* [[Performance/Evaluating_Performance_of_New_Features|How to evaluate the performance of your new feature]]
* Information on Talos automatic performance tests:
** [[Buildbot/Talos/RegressionBugsHandling|What to do when your check-in causes a Talos regression]]
** [[Buildbot/Talos/Sheriffing|Additional reading: How the Automation Team does performance sheriffing]]
* [[Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature|Avoid SQLite in your next Firefox feature]]

===Tools===

* [[Telemetry|Telemetry]]:
** [http://telemetry.mozilla.org/ Telemetry dashboard]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe Adding a new Telemetry probe]
** The "More Dashboards" sidebar in the [http://telemetry.mozilla.org/ main dash] has links to all our dashes
** [http://mozilla.github.io/cerberus/dashboard/ Cerberus]: Automated regression detection for Telemetry
*** Set the "alert_mails" field in your histogram declaration to get [https://groups.google.com/forum/#!forum/mozilla.dev.telemetry-alerts automatic email notifications] of regressions
** You can do custom Telemetry analyses using [http://mreid-moz.github.io/blog/2013/11/06/current-state-of-telemetry-analysis/ MapReduce] or [http://robertovitillo.com/2015/01/16/next-gen-data-analysis-framework-for-telemetry/ Spark]
* [https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler SPS Gecko Profiler]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem Reporting a Performance problem]
* [[Buildbot/Talos]]
** [http://graphs.mozilla.org graphs.mozilla.org]: for visualizing past Talos test results
** Joel Maher maintains a [http://alertmanager.allizom.org:8080/alerts.html?showAll=1 dashboard] of current Talos regressions & improvements
* [[Using_XPerf| xperf]]
** [[Tracing VirtualAlloc With Xperf]]

==Archive (Delete soon) ==

Old progress reports:
* June 2014 [[Performance/2014-12-06|Meeting Minutes]], [[Performance/Report-2014-06|Report]]
* February 2014 [[Performance/2014-02-13|Meeting Minutes]], [[Performance/Report-2014-02|Report]]
* December 2013 [[Performance/2013-12-05|Meeting Minutes]], [[Performance/Report-2013-12|Report]]
* November 2013 [[Performance/2013-11-07|Meeting Minutes]], [[Performance/Report-2013-11|Report]]
* September 2013 [[Performance/2013-09-12|Meeting Minutes]], [[Performance/Report-2013-09|Report]]
* August 2013 [[Performance/2013-08-01|Meeting Minutes]], [[Performance/Report-2013-08|Report]]
* [[Performance/2013-07-11|July 2013 Meeting Minutes]]
* [[Performance/2013-06-06|June 2013 Meeting Minutes]]
* [[Performance/2013-05-02|May 2013 Meeting Minutes]]

Old Projects
* [[Firefox/Projects/Mobile_Startup_Shrink|Mobile Startup Shrink]]
* [[Firefox/Projects/Startup_Time_Improvements|Startup Performance]]
* [[Firefox:FrontEndPerformance|Front-end Performance]] (i.e., responsiveness)
* [[Performance/Addons|Add-on Performance]]
* [[Performance/Snappy|Snappy]]
* [[Mobile/Performance|Mobile Performance Info]]

Tools:
* [[Codesighs]] - a tool which analyzes code and data size.
* [[Performance:Tools]]. For measuring performance. Tip o' the propeller-cap to [mailto:zuperdee@penguinpowered.com Daniel Roberts] (zuperdee@penguinpowered.com) for the pointers.
* [[Performance:Probes]]. Project to integrate a system of performance probes into Gecko.

Old Documentation and Presentations:
* Code Footprint [[Performance:Footprint_Reduction_Techniques]] explains common bad patterns and how to correct them.
* [[Performance:Profiling_JuJu]]. Things you should know about doing profiling. Tips and tricks for some of the tools, and lots of other Good Things To Know.
* [http://www.mozilla.org/performance/mac-performance.html Profiling and leak analysis] on the Mac.
* [[Performance:Footprint_Tools]]. Presentation on footprint tools
* [[Performance:Startup]] [http://www.mozilla.org/performance/perf-intro/slide1.xml slides] Presentation on general performance tools
* [[Performance:Leak_Tools]]. Presentation on memory leaks detection tools
* [http://www.mozilla.org/performance/mac-performance.html Mac Performance Tools] Presentation on performance tools that work on Mac

Performance

2015-08-13T13:56:49Z

Wcosta: /* Graphics terminology */

=Performance=
Mozilla's desktop performance team focuses on improvements to the Gecko platform and desktop Firefox.
You can find us on the #perf channel of irc.mozilla.org or email perf@mozilla.com

'''The team:'''
* Vladan Djeric, :vladan on IRC, [http://blog.mozilla.org/vdjeric/ blog]
* Aaron Klotz :aklotz, [http://dblohm7.ca/ blog]
* Roberto Vitillo :rvitillo, [http://ravitillo.wordpress.com/category/mozilla/ blog]
* Avi Halachmi :avih, [http://avih.github.io/ blog]
* David Teller :Yoric, [http://dutherenverseauborddelatable.wordpress.com/ blog]
* David Major :dmajor

==Current Projects==

* Weekly status reports: [http://benjamin.smedbergs.us/weekly-updates.fcgi/project/perf Mozilla Status Board]

* In Q2, half the team will be working on [[Firefox/Content_Performance_Program|improving web content performance.]]
* [https://wiki.mozilla.org/Platform/2015-Q1-Goals#Perf Our Q1 2015 goals]
* [https://wiki.mozilla.org/Platform/2014-Q4-Goals#Perf Q4 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q3-Goals#Perf Q3 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q2-Goals#Perf Q2 2014 goals]
* [https://wiki.mozilla.org/Platform/2014-Q1-Goals#Perf Q1 2014 goals]

==Measuring & improving Firefox performance==

===Write-ups===
* [https://developer.mozilla.org/en-US/docs/Mozilla/Performance| Firefox performance knowledge-base]
* [[Performance/Evaluating_Performance_of_New_Features|How to evaluate the performance of your new feature]]
* Information on Talos automatic performance tests:
** [[Buildbot/Talos/RegressionBugsHandling|What to do when your check-in causes a Talos regression]]
** [[Buildbot/Talos/Sheriffing|Additional reading: How the Automation Team does performance sheriffing]]
* [[Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature|Avoid SQLite in your next Firefox feature]]

===Tools===

* [[Telemetry|Telemetry]]:
** [http://telemetry.mozilla.org/ Telemetry dashboard]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe Adding a new Telemetry probe]
** The "More Dashboards" sidebar in the [http://telemetry.mozilla.org/ main dash] has links to all our dashes
** [http://mozilla.github.io/cerberus/dashboard/ Cerberus]: Automated regression detection for Telemetry
*** Set the "alert_mails" field in your histogram declaration to get [https://groups.google.com/forum/#!forum/mozilla.dev.telemetry-alerts automatic email notifications] of regressions
** You can do custom Telemetry analyses using [http://mreid-moz.github.io/blog/2013/11/06/current-state-of-telemetry-analysis/ MapReduce] or [http://robertovitillo.com/2015/01/16/next-gen-data-analysis-framework-for-telemetry/ Spark]
* [https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler SPS Gecko Profiler]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem Reporting a Performance problem]
* [[Buildbot/Talos]]
** [http://graphs.mozilla.org graphs.mozilla.org]: for visualizing past Talos test results
** Joel Maher maintains a [http://alertmanager.allizom.org:8080/alerts.html?showAll=1 dashboard] of current Talos regressions & improvements
* [[Using_XPerf| xperf]]
** [[Tracing VirtualAlloc With Xperf]]

==Terminology==

; Main Thread : A browser generally runs all its things sequentially on a single thread, which is typically referred to as '''the main thread'''. This means that Javascript can change stuff which affects the screen, and Javascript code will not continue before the screen reflects the requested changes, or other changes. This is a big bottleneck since it's hard to run things in parallel.

; [http://www.techhive.com/article/229024/geek101_vsync.html v-sync] : Vertical synchronization to the monitor's ''beam reset''. It's used at contexts of animations, where in order to achieve 100% smoothness of animation, each frame should be sent to the display such that it matches the v-sync timing.

; [https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositing OMTC] : Off main thread composition. When rendering graphics in Firefox, this means that the main thread just ''prepares'' the rendering for each frame, but then a heavy chunk of the rendering (''composition'') happens on a different thread. This allows to have more free time on the main thread, which in turn means it can run more Javascript stuff on each frame. BenWa's [http://benoitgirard.wordpress.com/2012/05/15/off-main-thread-compositing-omtc-and-why-it-matters/ blog post] explains OMTC in details.

; [https://wiki.mozilla.org/Platform/GFX/APZ APZ] : Async Pan Zoom (Controller) - technique which browsers sometimes use to zoom and/or pan (move the page up/down/left/right) on a thread which isn't the main thread, therefore allowing longer Javascript calculations on the main thread without affecting the responsiveness for certain operations (specifically - pan and zoom).

; [https://wiki.mozilla.org/Project_Silk Project Silk] : Project to unify and improve animation in Firefox by using global v-sync timing. Before silk, the timing was done at the "refresh driver" using timeouts, where on each such iteration it would run everything the browser needs to run for a single frame. With silk, there's an external module which generates events synchronized to v-sync, which hopefully improves animation smoothness. Check [http://www.masonchang.com/blog/2015/1/22/project-silk this mchang's blog post] for an overview of Project Silk and [https://github.com/changm/SilkDocs/blob/master/silk.md this document] for Project Silk architecture.

==Archive (Delete soon) ==

Old progress reports:
* June 2014 [[Performance/2014-12-06|Meeting Minutes]], [[Performance/Report-2014-06|Report]]
* February 2014 [[Performance/2014-02-13|Meeting Minutes]], [[Performance/Report-2014-02|Report]]
* December 2013 [[Performance/2013-12-05|Meeting Minutes]], [[Performance/Report-2013-12|Report]]
* November 2013 [[Performance/2013-11-07|Meeting Minutes]], [[Performance/Report-2013-11|Report]]
* September 2013 [[Performance/2013-09-12|Meeting Minutes]], [[Performance/Report-2013-09|Report]]
* August 2013 [[Performance/2013-08-01|Meeting Minutes]], [[Performance/Report-2013-08|Report]]
* [[Performance/2013-07-11|July 2013 Meeting Minutes]]
* [[Performance/2013-06-06|June 2013 Meeting Minutes]]
* [[Performance/2013-05-02|May 2013 Meeting Minutes]]

Old Projects
* [[Firefox/Projects/Mobile_Startup_Shrink|Mobile Startup Shrink]]
* [[Firefox/Projects/Startup_Time_Improvements|Startup Performance]]
* [[Firefox:FrontEndPerformance|Front-end Performance]] (i.e., responsiveness)
* [[Performance/Addons|Add-on Performance]]
* [[Performance/Snappy|Snappy]]
* [[Mobile/Performance|Mobile Performance Info]]

Tools:
* [[Codesighs]] - a tool which analyzes code and data size.
* [[Performance:Tools]]. For measuring performance. Tip o' the propeller-cap to [mailto:zuperdee@penguinpowered.com Daniel Roberts] (zuperdee@penguinpowered.com) for the pointers.
* [[Performance:Probes]]. Project to integrate a system of performance probes into Gecko.

Old Documentation and Presentations:
* Code Footprint [[Performance:Footprint_Reduction_Techniques]] explains common bad patterns and how to correct them.
* [[Performance:Profiling_JuJu]]. Things you should know about doing profiling. Tips and tricks for some of the tools, and lots of other Good Things To Know.
* [http://www.mozilla.org/performance/mac-performance.html Profiling and leak analysis] on the Mac.
* [[Performance:Footprint_Tools]]. Presentation on footprint tools
* [[Performance:Startup]] [http://www.mozilla.org/performance/perf-intro/slide1.xml slides] Presentation on general performance tools
* [[Performance:Leak_Tools]]. Presentation on memory leaks detection tools
* [http://www.mozilla.org/performance/mac-performance.html Mac Performance Tools] Presentation on performance tools that work on Mac

Snappy Symbolication Server

2015-07-31T19:39:33Z

Wcosta: /* Symbol file cache proposal */

The Snappy Symbolication Server is a Web server for symbolicating Firefox stacks. It matches PC addresses to modules in memory and looks up the corresponding function names in server-side symbol files (.SYM files).

== Running ==

The source code for Snappy lives in the [https://github.com/mozilla/Snappy-Symbolication-Server Mozilla Github repository]. Snappy runs at [http://www.python.org Python] 2.7 and depends on [http://www.tornadoweb.org Tornado] and
[https://pypi.python.org/pypi/futures concurrent.futures] packages. The best way to install them is through [https://pip.pypa.io pip]:

:<code>pip install tornado futures</code>

To run snappy on your machine, just type:

:<code>python symbolicationWebService.py <configuration-file></code>

The snappy repository contains two sample configuration files for Linux and Windows. Here is a summary for the config fields:

{| class="wikitable"
! Section !! colspan=2 | Fields
|-
! !! Field !! Description
|-
| rowspan=6 | General || hostname || Server address or name
|-
| portNumber || Server port number
|-
| remoteSymbolServer || The address of a secondary remote server to forward requests to
|-
| maxCacheEntries || Number of entries for RAM symbol cache
|-
| mruSymbolStateFile || Json file with RAM cache info
|-
| maxMRUSymbolPersist || Maximum number of symbols for cache
|-
| rowspan=2 | DiskCache || cachePath || Path to cached symbol files
|-
| maxCacheFiles || Maximum number of files in the cache dir
|-
| rowspan=4 | Log || MaxFiles || Maximum number of log files
|-
| maxFileSize || Maximum size for a log file
|-
| logPath || Path to log files
|-
| logLevel || NOTSET, DEBUG, INFO, WARNING, ERROR, CRITICAL
|-
| SymbolPaths || || Each entry represents a path to search for symbols in the local disk
|-
| SymbolURLs || || Each entry represents a remote path to search for symbols
|}

== Contributing ==

It is a [https://github.com Github ] project, just fork it and send a PR. If you want to ask something, you can find people involved with Snappy Server in the #perf channel at irc.mozilla.org.

== Project ideas ==
* Snappy parses symbol files in another process (which we informally call "Symbolication Process") due to the well known [https://www.youtube.com/watch?v=Obt-vMVdM8s GIL problems]. We could have a Symbolication Process per CPU core, but we have a tricky problem here. The Symbolication Process maintains a in memory symbols cache, with the most recently used symbols. The problem is how we handle this, we could have a single shared cache among all Symbolication Processes, which would bring contention, hurting the code parallelism. Other approach is that each Symbolication Process could have its own memory cache, but we potentially could waste memory due to duplicated symbols among all processes, and we could duplicate work because all subprocesses would parse the same symbol file in case of several similar symbolication requests. One good solution is to maintain the memory cache in the parent process.

* The Symbolication Process requests symbol files from S3. This is a I/O bound task, so this should happen in the main process, and then Snappy would use asynchronous I/O for that. The problem is that we have to send the symbol file to the Symbolication Process through IPC. The IPC overhead could kill the performance gain with asynchronous requests. We need performance numbers here to make a decision on what's the best approach.

* Too bad we don't have unit tests.

=== Symbol file cache proposal ===

Snappy searches for symbol files on S3 when it doesn't find them locally. The proposal is to cache these files locally, with a LRU eviction policy. Instead of storing them in the original sym file, we store in the parsed format using [https://docs.python.org/2/library/pickle.html Pickle] module.

The cache size is counted by the number of files stored, and must be accounted to keep some extra free space, since the eviction code runs in a timely fashion. Here is some pseudo Python code for file cache:

<code>
def Initialize():
:for each file in the cache directory:
::accessTime = AccessTime(filePath)
::ListofFiles.append(FilePath)
:LRU = ListOfFiles reverse sorted by access time
</code>

<code>
def StoreCache(SymbolData, path):
:writeFile(SymbolData, path)
:LRU.append(path)
</code>

<code>
def FetchCache(path):
:SymbolData = readFile(path)
:LRU.remove(path)
:LRU.append(path)
</code>

<code>
def Evict():
:lruSize = len(LRU)
:idealSize = maxSize * 0.6
:while lruSize >= idealSize:
::path = LRU.popleft()
::removeFile(path)
</code>

== Regressions tests ==

Some regressions tests to perform before sending a PR:

* Perform a get request to the server
* Check if the IP in X-Forward-For is logged
* Test requests with /gecko-profiler/ path
* Test for /debug and /nodebug special paths
* Test with compressed symbols files
* Exiting with Control-C should kill the server smoothly
* Check if the host handles ill-formed requests
* Check if symbol server can forward requests
* Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
* Check if the server writes logs to files

Snappy Symbolication Server

2015-07-31T19:39:03Z

Wcosta: /* File cache proposal */

The Snappy Symbolication Server is a Web server for symbolicating Firefox stacks. It matches PC addresses to modules in memory and looks up the corresponding function names in server-side symbol files (.SYM files).

== Running ==

The source code for Snappy lives in the [https://github.com/mozilla/Snappy-Symbolication-Server Mozilla Github repository]. Snappy runs at [http://www.python.org Python] 2.7 and depends on [http://www.tornadoweb.org Tornado] and
[https://pypi.python.org/pypi/futures concurrent.futures] packages. The best way to install them is through [https://pip.pypa.io pip]:

:<code>pip install tornado futures</code>

To run snappy on your machine, just type:

:<code>python symbolicationWebService.py <configuration-file></code>

The snappy repository contains two sample configuration files for Linux and Windows. Here is a summary for the config fields:

{| class="wikitable"
! Section !! colspan=2 | Fields
|-
! !! Field !! Description
|-
| rowspan=6 | General || hostname || Server address or name
|-
| portNumber || Server port number
|-
| remoteSymbolServer || The address of a secondary remote server to forward requests to
|-
| maxCacheEntries || Number of entries for RAM symbol cache
|-
| mruSymbolStateFile || Json file with RAM cache info
|-
| maxMRUSymbolPersist || Maximum number of symbols for cache
|-
| rowspan=2 | DiskCache || cachePath || Path to cached symbol files
|-
| maxCacheFiles || Maximum number of files in the cache dir
|-
| rowspan=4 | Log || MaxFiles || Maximum number of log files
|-
| maxFileSize || Maximum size for a log file
|-
| logPath || Path to log files
|-
| logLevel || NOTSET, DEBUG, INFO, WARNING, ERROR, CRITICAL
|-
| SymbolPaths || || Each entry represents a path to search for symbols in the local disk
|-
| SymbolURLs || || Each entry represents a remote path to search for symbols
|}

== Contributing ==

It is a [https://github.com Github ] project, just fork it and send a PR. If you want to ask something, you can find people involved with Snappy Server in the #perf channel at irc.mozilla.org.

== Project ideas ==
* Snappy parses symbol files in another process (which we informally call "Symbolication Process") due to the well known [https://www.youtube.com/watch?v=Obt-vMVdM8s GIL problems]. We could have a Symbolication Process per CPU core, but we have a tricky problem here. The Symbolication Process maintains a in memory symbols cache, with the most recently used symbols. The problem is how we handle this, we could have a single shared cache among all Symbolication Processes, which would bring contention, hurting the code parallelism. Other approach is that each Symbolication Process could have its own memory cache, but we potentially could waste memory due to duplicated symbols among all processes, and we could duplicate work because all subprocesses would parse the same symbol file in case of several similar symbolication requests. One good solution is to maintain the memory cache in the parent process.

* The Symbolication Process requests symbol files from S3. This is a I/O bound task, so this should happen in the main process, and then Snappy would use asynchronous I/O for that. The problem is that we have to send the symbol file to the Symbolication Process through IPC. The IPC overhead could kill the performance gain with asynchronous requests. We need performance numbers here to make a decision on what's the best approach.

* Too bad we don't have unit tests.

= Symbol file cache proposal =

Snappy searches for symbol files on S3 when it doesn't find them locally. The proposal is to cache these files locally, with a LRU eviction policy. Instead of storing them in the original sym file, we store in the parsed format using [https://docs.python.org/2/library/pickle.html Pickle] module.

The cache size is counted by the number of files stored, and must be accounted to keep some extra free space, since the eviction code runs in a timely fashion. Here is some pseudo Python code for file cache:

<code>
def Initialize():
:for each file in the cache directory:
::accessTime = AccessTime(filePath)
::ListofFiles.append(FilePath)
:LRU = ListOfFiles reverse sorted by access time
</code>

<code>
def StoreCache(SymbolData, path):
:writeFile(SymbolData, path)
:LRU.append(path)
</code>

<code>
def FetchCache(path):
:SymbolData = readFile(path)
:LRU.remove(path)
:LRU.append(path)
</code>

<code>
def Evict():
:lruSize = len(LRU)
:idealSize = maxSize * 0.6
:while lruSize >= idealSize:
::path = LRU.popleft()
::removeFile(path)
</code>

== Regressions tests ==

Some regressions tests to perform before sending a PR:

* Perform a get request to the server
* Check if the IP in X-Forward-For is logged
* Test requests with /gecko-profiler/ path
* Test for /debug and /nodebug special paths
* Test with compressed symbols files
* Exiting with Control-C should kill the server smoothly
* Check if the host handles ill-formed requests
* Check if symbol server can forward requests
* Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
* Check if the server writes logs to files

Snappy Symbolication Server

2015-07-30T11:41:17Z

Wcosta: /* Project ideas */

Snappy Symbolication Server

2015-07-30T11:39:34Z

Wcosta: /* Project ideas */

The Snappy Symbolication Server is a Web server for symbolicating Firefox stacks. It matches PC addresses to modules in memory and looks up the corresponding function names in server-side symbol files (.SYM files).

== Running ==

The source code for Snappy lives in the [https://github.com/mozilla/Snappy-Symbolication-Server Mozilla Github repository]. Snappy runs at [http://www.python.org Python] 2.7 and depends on [http://www.tornadoweb.org Tornado] and
[https://pypi.python.org/pypi/futures concurrent.futures] packages. The best way to install them is through [https://pip.pypa.io pip]:

:<code>pip install tornado futures</code>

To run snappy on your machine, just type:

:<code>python symbolicationWebService.py <configuration-file></code>

The snappy repository contains two sample configuration files for Linux and Windows. Here is a summary for the config fields:

{| class="wikitable"
! Section !! colspan=2 | Fields
|-
! !! Field !! Description
|-
| rowspan=6 | General || hostname || Server address or name
|-
| portNumber || Server port number
|-
| remoteSymbolServer || The address of a secondary remote server to forward requests to
|-
| maxCacheEntries || Number of entries for RAM symbol cache
|-
| mruSymbolStateFile || Json file with RAM cache info
|-
| maxMRUSymbolPersist || Maximum number of symbols for cache
|-
| rowspan=2 | DiskCache || cachePath || Path to cached symbol files
|-
| maxCacheFiles || Maximum number of files in the cache dir
|-
| rowspan=4 | Log || MaxFiles || Maximum number of log files
|-
| maxFileSize || Maximum size for a log file
|-
| logPath || Path to log files
|-
| logLevel || NOTSET, DEBUG, INFO, WARNING, ERROR, CRITICAL
|-
| SymbolPaths || || Each entry represents a path to search for symbols in the local disk
|-
| SymbolURLs || || Each entry represents a remote path to search for symbols
|}

== Contributing ==

It is a [https://github.com Github ] project, just fork it and send a PR. If you want to ask something, you can find people involved with Snappy Server in the #perf channel at irc.mozilla.org.

== Project ideas ==
* Snappy parses symbol files in another process (which we informally call "Symbolication Process") due to the well known [https://www.youtube.com/watch?v=Obt-vMVdM8s GIL problems].
We could have a Symbolication Process per CPU core, but we have a tricky problem here. The Symbolication Process maintains a in memory symbols cache, with the most recently used
symbols. The problem is how we handle this, we could have a single shared cache among all Symbolication Processes, which would bring contention, hurting the code parallelism.
Other approach is that each Symbolication Process could have its own memory cache, but we potentially could waste memory due to duplicated symbols among all processes, and we could
duplicate work because all subprocesses would parse the same symbol file in case of several similar symbolication requests. One good solution is to maintain the memory cache in the parent process.

* The Symbolication Process requests symbol files from S3. This is a I/O bound task, so this should happen in the main process, and then Snappy would use asynchronous I/O for that.
The problem is that we have to send the symbol file to the Symbolication Process through IPC. The IPC overhead could kill the performance gain with asynchronous requests. We need performance
numbers here to make a decision on what's the best approach.

* Too bad we don't have unit tests.

== Regressions tests ==

Some regressions tests to perform before sending a PR:

* Perform a get request to the server
* Check if the IP in X-Forward-For is logged
* Test requests with /gecko-profiler/ path
* Test for /debug and /nodebug special paths
* Test with compressed symbols files
* Exiting with Control-C should kill the server smoothly
* Check if the host handles ill-formed requests
* Check if symbol server can forward requests
* Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
* Check if the server writes logs to files

Snappy Symbolication Server

2015-07-29T20:37:10Z

Wcosta: Rewritten page for updated information

Snappy Symbolication Server

2015-07-28T18:55:12Z

Wcosta: Snappy regression tests

{{FeatureStatus
|Feature name=Snappy Symbolication Server
|Feature stage=Feature Inbox
|Feature status=In progress
|Feature version=Nightly 14
|Feature health=OK
}}
{{FeatureTeam
|Feature feature manager=bsmedberg
|Feature lead engineer=vladan
|Feature additional members=benwa, ehsan
}}
{{FeaturePageBody
|Feature overview=In nightly profiling builds (and perhaps later in regular nightlies and aurora) we want to give users the ability to profile their own slowness via an about:snappy page. We also want to submit significant chrome hangs to telemetry.
|Feature users and use cases=In order to make this useful, the reports need to be able to map stack traces to symbols, similarly to how crash-stats does this. However, we're not taking full minidumps for privacy reasons, so we want to expose a webservice based on crash-stats symbol data that can convert address/offset information to a symbolicated name.

There will be two users of this data:

1) the telemetry server will use this to convert numeric stacks into symbols
2) the client page about:snappy will use this to convert numeric stacks into symbols
|Feature functional spec=Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.

|Feature implementation plan=
# get a VM for experimentation/development with access to the symbol data and node COMPLETE
# develop the webservice behind the firewall INITIAL CODE COMPLETE, NEEDS REVISION FOR DIRECT SYMBOL ACCESS - The code is currently hosted at https://github.com/bgirard/ProfilerSymbolServer
# After development is complete, open up the webservice via a public URL

Note that the plan has changed and the server has now been rewritten in Python with extended functionality: https://github.com/vdjeric/Snappy-Symbolication-Server/

|Feature security review=
Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data.
https://wiki.mozilla.org/Security/Reviews/SnappySymbolSrv

|Feature privacy review=
No private information will be processed.
https://wiki.mozilla.org/Privacy/Reviews/SnappySymbolicServer
}}
{{FeatureInfo
|Feature priority=Unprioritized
|Feature theme=Performance
|Feature roadmap=Platform
|Feature list=Platform
|Feature project=Responsiveness
}}
{{FeatureTeamStatus
|Feature security status=sec-review-sched
|Feature security notes=2012.03.02
}}

== Regressions tests ==

* Perform a get request to the server
* Check if the IP in X-Forward-For is logged
* Test requests with /gecko-profiler/ path
* Test for /debug and /nodebug special paths
* Test with compressed symbols files
* Exiting with Control-C should kill the server smoothly
* Check if the host handles ill-formed requests
* Check if symbol server can forward requests
* Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
* Check if the server writes logs to files

EngineeringProductivity/Projects/Treeherder

2015-07-02T11:15:21Z

Wcosta: /* Source and Docs */

== About ==
[https://treeherder.mozilla.org/ Treeherder] is a reporting dashboard for checkins to Mozilla projects (for example, [https://developer.mozilla.org/en-US/docs/mozilla-central mozilla-central] or [[Gaia]]). It allows users to see the results of automatic builds and their respective tests. Treeherder also provides a rich set of APIs that can be used by other projects interested in this information.

Treeherder is the successor to [[Sheriffing/TBPL|TBPL]].

For tracking performance data, see Treeherder's sister project, [[Auto-tools/Projects/Perfherder|Perfherder]].

== Contributing ==
To make UI changes, in many cases you only need to perform a very simple setup running a local webserver pointing at the production instance, described [https://treeherder.readthedocs.org/ui/installation.html here]. If you wish to hack on the backend, or the UI and backend together, you will instead need to set up a Vagrant environment, using [https://treeherder.readthedocs.org/installation.html these steps].

* [https://ateam-bootcamp.readthedocs.org/en/latest/ A-Team Bootcamp]: Best practices for working on A-Team projects (of which Treeherder is one), including valuable information on using Git and Bugzilla. If you're new to Mozilla or the A-Team, please read this guide thoroughly before proceeding.
* Good first bugs for new developers: [http://www.joshmatthews.net/bugsahoy/?reporting=1&unowned=1 Bugs Ahoy]
* Issue tracker: [https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree+Management&component=Treeherder Report a bug] / [https://bugzilla.mozilla.org/query.cgi?query_format=advanced&product=Tree+Management&f1=component&o1=substring&v1=Treeherder&resolution=--- search open bugs] / [[Auto-tools/Projects/Treeherder/Bug_Triage|bug triage]]
* Mozilla Treeherder instances: [https://treeherder.allizom.org Staging] / [https://treeherder.mozilla.org Production] ([https://mana.mozilla.org/wiki/display/websites/treeherder.mozilla.org mana page])

== Source and Docs ==
* UI & backend: [https://github.com/mozilla/treeherder Source] / [https://treeherder.readthedocs.org Docs]
* Treeherder data submission clients:
** Python: [https://github.com/mozilla/treeherder/tree/master/treeherder/client Source] / [http://treeherder.readthedocs.org/en/latest/submitting_data.html docs]
** NodeJS: [https://github.com/mozilla/treeherder-node Source] / [https://github.com/mozilla/treeherder-node/blob/master/README.md README]

== Getting in touch ==
* Chat on IRC: [irc://irc.mozilla.org/treeherder #treeherder] / [[IRC|learn about IRC]] / [http://logs.glob.uno/?c=treeherder channel logs]
* Mailing list: [https://lists.mozilla.org/listinfo/dev-tree-management dev.tree-management] (or [https://groups.google.com/forum/#!forum/mozilla.dev.tree-management via Google groups])
* Weekly meetings: [[Auto-tools/Projects/Treeherder/Meetings|Notes & dial-in details]]

== What we're working on ==
Assigned Treeherder bugs.
[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Atreeherder+-assignee%3Anobody%40mozilla.org View on Bugzilla]
<bugzilla>
{
"component": "Treeherder", "component_type": "contains",
"resolution": "---",
"email1": "nobody@mozilla.org", "email1_type": "not_equals", "email1_assigned_to": "1",
"include_fields": "id,priority,component,summary,assigned_to",
"order": "priority,assigned_to"
}
</bugzilla>

== Recent changes ==
Bugs fixed in the last 14 days.
[https://bugzilla.mozilla.org/buglist.cgi?order=Bug%20Number&resolution=FIXED&chfieldto=Now&chfield=resolution&chfieldfrom=-14d&chfieldvalue=FIXED&f1=component&v1=Treeherder&o1=substring View on Bugzilla]
<bugzilla>
{
"component": "Treeherder", "component_type": "contains",
"resolution": "FIXED",
"changed_after": "-14d",
"changed_before": "Now",
"changed_field": "resolution",
"changed_field_to": "FIXED",
"include_fields": "id,component,summary,assigned_to",
"order": "assigned_to,id"
}
</bugzilla>

Taskcluster

2015-06-02T22:38:55Z

Wcosta: /* FxOS Automation Hang Out */

= TaskCluster =

== Description ==

Taskcluster is a generic "task" execution service this page documents mostly administrative things such as who owns which components and when the team meets.

For detailed documentation on the API's and capabilities please see [http://docs.taskcluster.net docs.taskcluster.net].

Find us on #taskcluster on mozilla IRC.

== Availability ==

TaskCluster is a critical piece of to what goes on in Try and the other related CI tools that interact with gecko branches (mozilla-central, inbound(s), etc...).

If something goes wrong or you ''think'' something has gone wrong and wish to contact us here is a table of which hours we are available and what the irc nicks are (as always
you can try #taskcluster on IRC too)

{| class="wikitable"
|-
! UTC Hour !! IRC Nick
|-
| 0 || lightsofapollo (pst), jonasfj (pdt),
|-
| 1 || lightsofapollo (pst), jonasfj (pdt),
|-
| 2 ||
|-
| 3 ||
|-
| 4 ||
|-
| 5 ||
|-
| 6 ||
|-
| 7 ||
|-
| 8 ||
|-
| 9 ||
|-
| 10 ||
|-
| 11 || wcosta (brt),
|-
| 12 || wcosta (brt),
|-
| 13 || wcosta (brt),
|-
| 14 || wcosta (brt),
|-
| 15 || wcosta (brt),
|-
| 16 || wcosta (brt),
|-
| 17 || lightsofapollo (pst), jonasfj (pdt), wcosta (brt),
|-
| 18 || lightsofapollo (pst), jonasfj (pdt), wcosta (brt),
|-
| 19 || lightsofapollo (pst), jonasfj (pdt), wcosta (brt),
|-
| 20 || lightsofapollo (pst), jonasfj (pdt), wcosta (brt),
|-
| 21 || lightsofapollo (pst), jonasfj (pdt), wcosta (brt),
|-
| 22 || lightsofapollo (pst), jonasfj (pdt),
|-
| 23 || lightsofapollo (pst), jonasfj (pdt),
|}

If you cannot find some one on IRC and need to escalate quickly please contact James Lal (and failing that Jonas Finnemann Jensen)

== Meetings ==

=== TaskCluster Meeting ===

'''When''': Tuesday 8am PST<br />
'''Where''': James Lal's Room<br/>
'''Agenda''': https://etherpad.mozilla.org/fxos-automation<br/>

This meeting is to discuss new ideas/critical issues/etc... This meeting is required for owners
of modules (but open to all) and may be cancelled if there is no Agenda.

=== FxOS Automation Hang Out ===

'''When''': Thursday 8am PST<br />
'''Where''': James Lal's Room<br />

Totally arbitrary meeting usually just an hour for people to hack together (completely optional time reserved for calendaring purposes)

== Components ==

Our team follows a simple version of the usual "module ownership" pattern seen all over Mozilla... Each owner is responsible for
the health (which is defined as uptime/code quality/decisions) made in each component owned. The ideal is we collaborate through our weekly
meetings but each owner is ultimately responsible for yes/no decisions. Owners are _not_ for life and the team may elect new owners as
time goes on.

This is a list of components which as a whole make up TaskCluster... Please contact the owners and visit the github pages for full context:

* [https://github.com/taskcluster/aws-provisioner aws-provisioner] - jhford
* [https://github.com/taskcluster/taskcluster-queue queue] - jonasfj
* [https://github.com/taskcluster/task-graph-scheduler scheduler] - jonasfj
* [https://github.com/taskcluster/taskcluster-auth auth] - jonasfj
* [https://github.com/taskcluster/taskcluster-index index] - jonasfj
* [https://github.com/taskcluster/taskcluster-events events] - jonasfj
* [https://github.com/taskcluster/taskcluster-tools tools] - jonasfj
* [https://github.com/taskcluster/s3-copy-proxy s3-copy-proxy] - james
* [https://github.com/taskcluster/mozilla-taskcluster mozilla-taskcluster] - james
* [https://github.com/taskcluster/docker-worker docker-worker] - garndt
* [https://github.com/petemoore/generic-worker generic-worker] - pmoore
* [https://github.com/petemoore/taskcluster-client-go taskcluster-client-go] - pmoore
* [https://github.com/petemoore/taskcluster-client.py taskcluster-client-py] - jhford
* [https://github.com/taskcluster/taskcluster-client taskcluster-cli] - garndt

Taskcluster

2015-06-02T22:22:34Z

Wcosta: /* Availability */

= TaskCluster =

== Description ==

Taskcluster is a generic "task" execution service this page documents mostly administrative things such as who owns which components and when the team meets.

For detailed documentation on the API's and capabilities please see see [http://docs.taskcluster.net docs.taskcluster.net].

Find us on #taskcluster on mozilla IRC.

== Availability ==

TaskCluster is a critical piece of to what goes on in Try and the other related CI tools that interact with gecko branches (mozilla-central, inbound(s), etc...).

If something goes wrong or you _think_ something has gone wrong and wish to contact us here is a table of which hours we are available and what the irc nicks are (as always
you can try #taskcluster on IRC too)

{| class="wikitable"
|-
! UTC Hour !! IRC Nick
|-
| 0 || lightsofapollo (pst),
|-
| 1 || lightsofapollo (pst),
|-
| 2 ||
|-
| 3 ||
|-
| 4 ||
|-
| 5 ||
|-
| 6 ||
|-
| 7 ||
|-
| 8 ||
|-
| 9 ||
|-
| 10 ||
|-
| 11 || wcosta (brt),
|-
| 12 || wcosta (brt),
|-
| 13 || wcosta (brt),
|-
| 14 || wcosta (brt),
|-
| 15 || wcosta (brt),
|-
| 16 || wcosta (brt),
|-
| 17 || lightsofapollo (pst), wcosta (brt),
|-
| 18 || lightsofapollo (pst), wcosta (brt),
|-
| 19 || lightsofapollo (pst), wcosta (brt),
|-
| 20 || lightsofapollo (pst), wcosta (brt),
|-
| 21 || lightsofapollo (pst), wcosta (brt),
|-
| 22 || lightsofapollo (pst),
|-
| 23 || lightsofapollo (pst),
|}

If you cannot find some one on IRC and need to escalate quickly please contact James Lal (and failing that Jonas Finnemann Jensen)

== Meetings ==

=== TaskCluster Meeting ===

'''When''': Tuesday 8am PST<br />
'''Where''': James Lal's Room<br/>
'''Agenda''': https://etherpad.mozilla.org/fxos-automation<br/>

This meeting is to discuss new ideas/critical issues/etc... This meeting is required for owners
of modules (but open to all) and may be cancelled if there is no Agenda.

=== FxOS Automation Hang Out ===

'''When''': Tuesday 8am PST<br />
'''Where''': James Lal's Room<br />

Totally arbitrary meeting usually just an hour for people to hack together (completely optional time reserved for calendaring purposes)

== Components ==

Our team follows a simple version of the usual "module ownership" pattern seen all over Mozilla... Each owner is responsible for
the health (which is defined as uptime/code quality/decisions) made in each component owned. The ideal is we collaborate through our weekly
meetings but each owner is ultimately responsible for yes/no decisions. Owners are _not_ for life and the team may elect new owners as
time goes on.

This is a list of components which as a whole make up TaskCluster... Please contact the owners and visit the github pages for full context:

* [https://github.com/taskcluster/aws-provisioner aws-provisioner] - jhford
* [https://github.com/taskcluster/taskcluster-queue queue] - jonasfj
* [https://github.com/taskcluster/task-graph-scheduler scheduler] - jonasfj
* [https://github.com/taskcluster/taskcluster-auth auth] - jonasfj
* [https://github.com/taskcluster/taskcluster-index index] - jonasfj
* [https://github.com/taskcluster/taskcluster-events events] - jonasfj
* [https://github.com/taskcluster/taskcluster-tools tools] - jonasfj
* [https://github.com/taskcluster/s3-copy-proxy s3-copy-proxy] - james
* [https://github.com/taskcluster/mozilla-taskcluster mozilla-taskcluster] - james
* [https://github.com/taskcluster/docker-worker docker-worker] - garndt
* [https://github.com/petemoore/generic-worker generic-worker] - pmoore
* [https://github.com/petemoore/taskcluster-client-go taskcluster-client-go] - pmoore
* [https://github.com/petemoore/taskcluster-client.py taskcluster-client-py] - jhford
* [https://github.com/taskcluster/taskcluster-client taskcluster-cli] - garndt

ReleaseEngineering/TryServer

2014-09-14T15:40:14Z

Wcosta: /* Using a custom gonk-misc */

= Try Server =
The [https://tbpl.mozilla.org/ try server] is an easy way to test a patch without actually checking the patch into the core repository. Your code will go through the same tests as a mozilla-central push, and you'll be able to download builds if you wish.

To use try server, you need a [http://www.mozilla.org/hacking/committer/ Mozilla hg account] ([http://www.mozilla.org/hacking/commit-access-policy/ level 1] is sufficient).

== How to push to try ==
=== Running a subset of builds/test/talos available to Try===
You must use [[Build:TryChooser]] to choose which builds, tests, and talos you would like run on your push to try. Make sure you place the try chooser text in your ''topmost commit''. The [http://trychooser.pub.build.mozilla.org/ TryChooser] web page can help you build a commit message for custom requests, so can the [https://bitbucket.org/sfink/trychooser mercurial extension]

<pre>
% hg qref --message "try: <your-computed-syntax-here>"
% hg push -f try
</pre>

Where the computed syntax will be something like <code>-b d -p linux64 -u all -t none</code>. Please note that running all tests on all platforms is very expensive (at least 300 compute-hours), and probably overkill.

=== Pushing to try ===

To submit your changes to the try server (assuming they're modifications to mozilla-central or a similar branch, e.g. tracemonkey), you have a few options:
* <code>hg push -f ssh://hg.mozilla.org/try/</code>, or
* <code>hg push -f ssh://<username@host>@hg.mozilla.org/try/</code> <strike>?</strike>, or
* <code>hg push -f ssh://hg.mozilla.org/try/ -e 'ssh -l <username@host></code>

==== Creating an alias ====
To save yourself some typing, you can add an alias to your hgrc:
<pre>[paths]
try = ssh://hg.mozilla.org/try
</pre>
and then push with
<pre>hg push -f try</pre>

==== ~/.ssh/config ====
ssh host settings to make life easier

<pre>
Host hg.mozilla.org
User <commit_user_email_address>
IdentityFile ~/.ssh/private_key_file
</pre>

=== Viewing the results ===

You can see the results of your tryserver build in a number of ways:

* You'll get an email on a successful push with a link to tbpl for your revision as well as emails on any non-successful build/test/talos results (this setting can be adjusted using [[Build:TryChooser]] args for email notification)
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)
* Look for your changeset on [http://tbpl.mozilla.org/?tree=Try Try TBPL]. You can add '''&pusher=YOUR.EMAIL''' to only see your pushes.
* Compare Talos perf numbers using Pike's [http://github.com/Pike/talos-node talos-node] or mconnor's [http://perf.snarkfest.net/compare-talos/ compare-talos].
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].

If you're using [https://developer.mozilla.org/en/Mercurial_Queues Mercurial queues], the <code>push -f</code> command pushes any patches that are currently applied, and the Try server will build the result. (This is an awesome feature, not a bug!)

You don’t need to clone or pull from the <code>try</code> repo, and you probably don’t want to. You’d get every half-baked changeset anybody ever tested.

See [http://blog.mozilla.com/jorendorff/2008/08/18/push-to-try/ Jorendorff's blog] for more details.

== Using a custom mozconfig ==

The mozconfigs for recent mozilla-central clones are located in the browser/config/mozconfigs directory. Edit those as you please.

If you want to apply the same mozconfig changes to multiple platforms, you can edit <tt>build/mozconfig.common.override</tt> instead. This file is included at the end of each of the in-tree mozconfig files.

Android mozconfigs are in mobile/android/config/mozconfigs.

Note:
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.

== Using a custom Gaia ==

For Gaia-related tests on B2G desktop builds, you can use an arbitrary branch on any github Gaia fork in your try job. To do this, you need to modify $src/b2g/config/gaia.json to point to your repo. Normally, gaia.json looks something like this:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central"
}

You should edit this file to include some additional fields:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central",
"git": {
"remote": "",
"branch": "",
"git_revision": ""
}
}

You must specify remote, and can specify either branch or revision. If you specify both, revision will be used and branch ignored. For example:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central",
"git": {
"remote": "https://github.com/jonallengriffin/gaia.git",
"branch": "gaia_unit_crash",
"git_revision": ""
}
}

When the 'git' dict in gaia.json is populated in this way, the hg attributes for revision and repo_path will be ignored, and the Gaia will be cloned from the given remote and used to run the tests.

== Using a custom gonk-misc ==

You can also specify a custom gonk-misc repository for tests. To do this, you need to edit the file $src/b2g/config/<target>/sources.xml and then add your remote, for example:

<remote fetch="https://github.com/walac" name="walac"/>

After that, you have to modify the gonk-misc project line to point to your repository and the desired revision:

<project name="gonk-misc" path="gonk-misc" remote="walac" revision="b8fd88760316cbcef261830f4031992fa6c379c6"/>

You then need to commit these changes and push to the try server.

== Getting debug symbols ==

By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.

=== Debugging with debug symbols ===

* Windows
** Unzip the crashreporter-symbols-full.zip package somewhere, let's call it c:\try_symbols
** Set your symbol path to <tt>cache*c:\symcache;SRV*http://msdl.microsoft.com/download/symbols;SRV*c:\try_symbols</tt> where <tt>c:\symcache</tt> is a writable directory where the debugger can store symbols.
*** If using WinDBG, you can type <tt>.sympath ...</tt> with the above path in the command window.
*** If using Visual Studio, you can set the <tt>_NT_SYMBOL_PATH</tt> environment variable to the above.
* Linux
** TODO
* Mac
** TODO

== Server Status ==

* Try server load can be seen at https://secure.pub.build.mozilla.org/builddata/reports/pending/try.html
* Pending builds by revision are at https://secure.pub.build.mozilla.org/buildapi/pending
* In-progress builds by revision are are https://secure.pub.build.mozilla.org/buildapi/running

== Other Notes ==
* Finished builds will live in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/<your_ldap_email>-<revision> for 14 days before deletion
* Try repo may be reset <s>every 6 weeks to avoid it slowing down with thousands of heads</s> if needed. You can use links like https://tbpl.mozilla.org/?tree=Try&rev=<revision> to reach your results even after a reset (subject to TBPL data retention).
* TBPL data for try repos is purged after 30 days. After that, the trick above will no longer work.
* If you have any problems please [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Release%20Engineering&status_whiteboard=tryserver file a bug]

* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]] or file a blocking bug against {{bug|try_enhancements}}

=== HOWTO: Preserve a commit message between try pushes ===
Simply create a new patch in your queue for the try attempt commit message.
Future pushes can simply push/pop the try patch onto the applied queue when needed.

<pre>
% hg qref --message "bug xxx - a spell/patch of improvements"
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>

If you know that your patches commit message is correct you can simply use:

<pre>
% hg qref
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>

== Other Mozilla Try Servers ==
* [[ReleaseEngineering/ThunderbirdTryServer|Thunderbird Try Server]] for the comm-central repository

* You can push b2g18 to the regular Firefox tryserver, but you will get a lot of oranges. There is currently no work-around. It's possible to eke out some useful information from such a try push -- ask a sheriff, who should be familiar with the expected failures, or otherwise push your qtip rev to try and compare the results to the patched version. Good luck.

== Problem Diagnosis ==
=== Can not access try server ===
Test your account & configuration
* <code>ssh hg.mozilla.org</code>, response: "No Interactive shells allowed here!"
* <code>ssh hg.mozilla.org clone invalid_sandbox</code>, response: menu display and interactive prompting.

<div id="long_try_push"></div>
=== Pushes to try take a very long time ===
Note: if a fellow developer cancelled their try push, they have saddled you with the cost of rebuilding the cache. (See [http://dtor.com/halfire/2014/07/02/2014_06_try_server_update.html#caching caching] details.)

If you're experiencing excessive wait times (> 45min) pushing to try, please file a bug asking IT to reset the try repository using [https://bugzilla.mozilla.org/enter_bug.cgi?comment=please%20schedule%20a%20reset%20of%20the%20try%20repository%20ASAP%20with%20sheriffs%20%26%20releng.&component=WebOps%3A%20Source%20Control&op_sys=All&product=Infrastructure%20%26%20Operations&rep_platform=All&short_desc=Push%20to%20try%20taking%20XXX%20minutes this template] (please include specifics of your experience). They will coordinate with sheriffs and release engineering as needed.

=== Waiting for Lock ===
If you get a message similar to:
remote: waiting for lock on repository /repo/hg/mozilla/try/ held by 'hgssh1.dmz.scl3.mozilla.com:23974'
remote: abort: repository /repo/hg/mozilla/try/: timed out waiting for lock held by hgssh1.dmz.scl3.mozilla.com:30549
It means several developers are trying to push to try at the same time. In the case above, nothing appears to be wrong, as the PID changes between the messages.

=== Waiting for Lock multiple times with the same pid ===
Similar to the above case, but with the same pid when you retry over and over again.

Please retry your push. If you see messages indicating the same process has been pushing for more than 15 minutes, treat as [[#long_try_push|above]].

== Buildduty issues ==
=== How do I trigger additional talos/test runs for a given try build? ===
If your trychooser syntax included the tests you'd like more of, then select the job you want on TBPL and use the + button.

For test suites you didn't request originally you can ask Release Engineering to [[ReleaseEngineering/How_To/Trigger_Talos_Jobs |do a sendchange']], look for someone who is <person>|buildduty in #releng on IRC. Alternatively you can push again with a different try syntax.

=== How do I cancel existing jobs? ===
For individual jobs, select the relevant one on TBPL and use the red X icon. To cancel all jobs, hover on the left side the push list on TBPL and click on the dim red X icon.

=== TryChooser ===
See the [[ReleaseEngineering/TryChooser#Buildduty_Issues|TryChooser]] wiki page.

== See Also ==
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* http://trychooser.pub.build.mozilla.org/
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/Build:TryChooser
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html Scoreboard]

ReleaseEngineering/TryServer

2014-09-14T15:21:24Z

Wcosta: /* Try Server */

= Try Server =
The [https://tbpl.mozilla.org/ try server] is an easy way to test a patch without actually checking the patch into the core repository. Your code will go through the same tests as a mozilla-central push, and you'll be able to download builds if you wish.

To use try server, you need a [http://www.mozilla.org/hacking/committer/ Mozilla hg account] ([http://www.mozilla.org/hacking/commit-access-policy/ level 1] is sufficient).

== How to push to try ==
=== Running a subset of builds/test/talos available to Try===
You must use [[Build:TryChooser]] to choose which builds, tests, and talos you would like run on your push to try. Make sure you place the try chooser text in your ''topmost commit''. The [http://trychooser.pub.build.mozilla.org/ TryChooser] web page can help you build a commit message for custom requests, so can the [https://bitbucket.org/sfink/trychooser mercurial extension]

<pre>
% hg qref --message "try: <your-computed-syntax-here>"
% hg push -f try
</pre>

Where the computed syntax will be something like <code>-b d -p linux64 -u all -t none</code>. Please note that running all tests on all platforms is very expensive (at least 300 compute-hours), and probably overkill.

=== Pushing to try ===

To submit your changes to the try server (assuming they're modifications to mozilla-central or a similar branch, e.g. tracemonkey), you have a few options:
* <code>hg push -f ssh://hg.mozilla.org/try/</code>, or
* <code>hg push -f ssh://<username@host>@hg.mozilla.org/try/</code> <strike>?</strike>, or
* <code>hg push -f ssh://hg.mozilla.org/try/ -e 'ssh -l <username@host></code>

==== Creating an alias ====
To save yourself some typing, you can add an alias to your hgrc:
<pre>[paths]
try = ssh://hg.mozilla.org/try
</pre>
and then push with
<pre>hg push -f try</pre>

==== ~/.ssh/config ====
ssh host settings to make life easier

<pre>
Host hg.mozilla.org
User <commit_user_email_address>
IdentityFile ~/.ssh/private_key_file
</pre>

=== Viewing the results ===

You can see the results of your tryserver build in a number of ways:

* You'll get an email on a successful push with a link to tbpl for your revision as well as emails on any non-successful build/test/talos results (this setting can be adjusted using [[Build:TryChooser]] args for email notification)
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)
* Look for your changeset on [http://tbpl.mozilla.org/?tree=Try Try TBPL]. You can add '''&pusher=YOUR.EMAIL''' to only see your pushes.
* Compare Talos perf numbers using Pike's [http://github.com/Pike/talos-node talos-node] or mconnor's [http://perf.snarkfest.net/compare-talos/ compare-talos].
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].

If you're using [https://developer.mozilla.org/en/Mercurial_Queues Mercurial queues], the <code>push -f</code> command pushes any patches that are currently applied, and the Try server will build the result. (This is an awesome feature, not a bug!)

You don’t need to clone or pull from the <code>try</code> repo, and you probably don’t want to. You’d get every half-baked changeset anybody ever tested.

See [http://blog.mozilla.com/jorendorff/2008/08/18/push-to-try/ Jorendorff's blog] for more details.

== Using a custom mozconfig ==

The mozconfigs for recent mozilla-central clones are located in the browser/config/mozconfigs directory. Edit those as you please.

If you want to apply the same mozconfig changes to multiple platforms, you can edit <tt>build/mozconfig.common.override</tt> instead. This file is included at the end of each of the in-tree mozconfig files.

Android mozconfigs are in mobile/android/config/mozconfigs.

Note:
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.

== Using a custom Gaia ==

For Gaia-related tests on B2G desktop builds, you can use an arbitrary branch on any github Gaia fork in your try job. To do this, you need to modify $src/b2g/config/gaia.json to point to your repo. Normally, gaia.json looks something like this:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central"
}

You should edit this file to include some additional fields:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central",
"git": {
"remote": "",
"branch": "",
"git_revision": ""
}
}

You must specify remote, and can specify either branch or revision. If you specify both, revision will be used and branch ignored. For example:

{
"revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4",
"repo_path": "/integration/gaia-central",
"git": {
"remote": "https://github.com/jonallengriffin/gaia.git",
"branch": "gaia_unit_crash",
"git_revision": ""
}
}

When the 'git' dict in gaia.json is populated in this way, the hg attributes for revision and repo_path will be ignored, and the Gaia will be cloned from the given remote and used to run the tests.

== Using a custom gonk-misc ==

You can also specify a custom gonk-misc repository for tests. To do this, you need to edit the file $src/b2g/config/<target>/sources.xml and then add your remote, for example:

<remote fetch="https://github.com/walac" name"=walac"/>

After that, you have to modify the gonk-misc project line to point to your repository and the desired revision:

<project name="gonk-misc" path="gonk-misc" remote="walac" revision="b8fd88760316cbcef261830f4031992fa6c379c6"/>

You then need to commit these changes and push to the try server.

== Getting debug symbols ==

By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.

=== Debugging with debug symbols ===

* Windows
** Unzip the crashreporter-symbols-full.zip package somewhere, let's call it c:\try_symbols
** Set your symbol path to <tt>cache*c:\symcache;SRV*http://msdl.microsoft.com/download/symbols;SRV*c:\try_symbols</tt> where <tt>c:\symcache</tt> is a writable directory where the debugger can store symbols.
*** If using WinDBG, you can type <tt>.sympath ...</tt> with the above path in the command window.
*** If using Visual Studio, you can set the <tt>_NT_SYMBOL_PATH</tt> environment variable to the above.
* Linux
** TODO
* Mac
** TODO

== Server Status ==

* Try server load can be seen at https://secure.pub.build.mozilla.org/builddata/reports/pending/try.html
* Pending builds by revision are at https://secure.pub.build.mozilla.org/buildapi/pending
* In-progress builds by revision are are https://secure.pub.build.mozilla.org/buildapi/running

== Other Notes ==
* Finished builds will live in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/<your_ldap_email>-<revision> for 14 days before deletion
* Try repo may be reset <s>every 6 weeks to avoid it slowing down with thousands of heads</s> if needed. You can use links like https://tbpl.mozilla.org/?tree=Try&rev=<revision> to reach your results even after a reset (subject to TBPL data retention).
* TBPL data for try repos is purged after 30 days. After that, the trick above will no longer work.
* If you have any problems please [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Release%20Engineering&status_whiteboard=tryserver file a bug]

* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]] or file a blocking bug against {{bug|try_enhancements}}

=== HOWTO: Preserve a commit message between try pushes ===
Simply create a new patch in your queue for the try attempt commit message.
Future pushes can simply push/pop the try patch onto the applied queue when needed.

<pre>
% hg qref --message "bug xxx - a spell/patch of improvements"
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>

If you know that your patches commit message is correct you can simply use:

<pre>
% hg qref
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>

== Other Mozilla Try Servers ==
* [[ReleaseEngineering/ThunderbirdTryServer|Thunderbird Try Server]] for the comm-central repository

* You can push b2g18 to the regular Firefox tryserver, but you will get a lot of oranges. There is currently no work-around. It's possible to eke out some useful information from such a try push -- ask a sheriff, who should be familiar with the expected failures, or otherwise push your qtip rev to try and compare the results to the patched version. Good luck.

== Problem Diagnosis ==
=== Can not access try server ===
Test your account & configuration
* <code>ssh hg.mozilla.org</code>, response: "No Interactive shells allowed here!"
* <code>ssh hg.mozilla.org clone invalid_sandbox</code>, response: menu display and interactive prompting.

<div id="long_try_push"></div>
=== Pushes to try take a very long time ===
Note: if a fellow developer cancelled their try push, they have saddled you with the cost of rebuilding the cache. (See [http://dtor.com/halfire/2014/07/02/2014_06_try_server_update.html#caching caching] details.)

If you're experiencing excessive wait times (> 45min) pushing to try, please file a bug asking IT to reset the try repository using [https://bugzilla.mozilla.org/enter_bug.cgi?comment=please%20schedule%20a%20reset%20of%20the%20try%20repository%20ASAP%20with%20sheriffs%20%26%20releng.&component=WebOps%3A%20Source%20Control&op_sys=All&product=Infrastructure%20%26%20Operations&rep_platform=All&short_desc=Push%20to%20try%20taking%20XXX%20minutes this template] (please include specifics of your experience). They will coordinate with sheriffs and release engineering as needed.

=== Waiting for Lock ===
If you get a message similar to:
remote: waiting for lock on repository /repo/hg/mozilla/try/ held by 'hgssh1.dmz.scl3.mozilla.com:23974'
remote: abort: repository /repo/hg/mozilla/try/: timed out waiting for lock held by hgssh1.dmz.scl3.mozilla.com:30549
It means several developers are trying to push to try at the same time. In the case above, nothing appears to be wrong, as the PID changes between the messages.

=== Waiting for Lock multiple times with the same pid ===
Similar to the above case, but with the same pid when you retry over and over again.

Please retry your push. If you see messages indicating the same process has been pushing for more than 15 minutes, treat as [[#long_try_push|above]].

== Buildduty issues ==
=== How do I trigger additional talos/test runs for a given try build? ===
If your trychooser syntax included the tests you'd like more of, then select the job you want on TBPL and use the + button.

For test suites you didn't request originally you can ask Release Engineering to [[ReleaseEngineering/How_To/Trigger_Talos_Jobs |do a sendchange']], look for someone who is <person>|buildduty in #releng on IRC. Alternatively you can push again with a different try syntax.

=== How do I cancel existing jobs? ===
For individual jobs, select the relevant one on TBPL and use the red X icon. To cancel all jobs, hover on the left side the push list on TBPL and click on the dim red X icon.

=== TryChooser ===
See the [[ReleaseEngineering/TryChooser#Buildduty_Issues|TryChooser]] wiki page.

== See Also ==
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* http://trychooser.pub.build.mozilla.org/
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/Build:TryChooser
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html Scoreboard]

Firefox OS/Performance/Automation/Memory Consumption

2014-08-14T14:29:03Z

Wcosta: /* Memory Consumption */

= Memory Consumption =

== Summary ==

Measures memory consumption in several test scenarios to detect abnormal memory usage patterns.

* '''Lead:''' Wander Lairson Costa

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

== Test cases ==

=== Startup Memory Consumption ===

* '''Tracking Bug:''' [http://bugzilla.mozilla.org/show_bug.cgi?id=1044297 1044297]

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process. Below you can see a flowchart of the test case:

[[File:Moz-app-load-mem-test.jpg|600x600px|framed|center|Flowchart of the startup memory test]]

==== Common Setup ====

# Set up workload
# Restart B2G process
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Homescreen memory performance ===

* '''Tracking Bug:''' [https://bugzilla.mozilla.org/show_bug.cgi?id=1048443 1048443]

TBD

=== Identify apps memory leaks ===

* '''Tracking Bug:''' [https://bugzilla.mozilla.org/show_bug.cgi?id=1041668 1041668]

TBD

== References ==

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-08-14T12:15:17Z

Wcosta: /* Memory Consumption */

= Memory Consumption =

== Summary ==

Measures memory consumption in several test scenarios to detect abnormal memory usage patterns.

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

== Test cases ==

=== Startup Memory Consumption ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' [http://bugzilla.mozilla.org/show_bug.cgi?id=1044297 1044297]

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process. Below you can see a flowchart of the test case:

[[File:Moz-app-load-mem-test.jpg|600x600px|framed|center|Flowchart of the startup memory test]]

==== Precision ====

TBD

==== How to Run On-Demand ====

TBD

==== Published Results ====

TBD

== Development ==

=== Design ===

==== Common Setup ====

# Set up workload
# Restart B2G process

==== All Cases ====
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Results ===

TBD

=== Project Roadmap ===

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

== References ==

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

File:Moz-app-load-mem-test.jpg

2014-08-14T12:08:37Z

Wcosta: Flowchart of memory startup test.

Flowchart of memory startup test.

Firefox OS/Performance/Automation/Memory Consumption

2014-08-04T16:00:33Z

Wcosta: /* Project Roadmap */

Firefox OS/Performance/Automation/Memory Consumption

2014-07-31T17:36:11Z

Wcosta: /* Project Roadmap */

= Memory Consumption =

== Summary ==

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

# Set up workload
# Restart B2G process

==== All Cases ====
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Results ===

TBD

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' [http://bugzilla.mozilla.org/show_bug.cgi?id=1044297 1044297]

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-31T17:35:43Z

Wcosta: /* Project Roadmap */

= Memory Consumption =

== Summary ==

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

# Set up workload
# Restart B2G process

==== All Cases ====
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Results ===

TBD

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' 1044297

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-31T17:18:09Z

Wcosta: /* Results */

= Memory Consumption =

== Summary ==

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

# Set up workload
# Restart B2G process

==== All Cases ====
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Results ===

TBD

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-31T15:14:25Z

Wcosta: /* Design */

= Memory Consumption =

== Summary ==

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

# Set up workload
# Restart B2G process

==== All Cases ====
# Invoke launch programmatically
# Inject the Performance Helper
# App instrumentation throws timeline events at appropriate times
# Performance helper observes events
# After moz-app-loaded event grab memory usage parameters for the app and b2g process

==== Results ====
* Result is the memory usage summary for app and b2g process.

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-31T15:09:45Z

Wcosta: /* Summary */

= Memory Consumption =

== Summary ==

Measures memory consumption of the application and b2g process after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

TDB

==== Case 1 ====
* Setup
# TDB

* Test
# TDB

* Teardown
# TDB

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T17:39:32Z

Wcosta: /* Design */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

==== Memory usage parameters ====

{| border="1"
|-
!Parameter !! Description
|-
| VSS || Virtual set size
|-
| RSS || Resident set size
|-
| USS || Unique set size
|-
| PSS || Proportional set size
|-
|}

==== Common Setup ====

TDB

==== Case 1 ====
* Setup
# TDB

* Test
# TDB

* Teardown
# TDB

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T16:58:47Z

Wcosta: /* Test Cases */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event, for both the app and b2g process.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T15:08:09Z

Wcosta: /* Test Cases */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

Launch each of the following apps:

* Browser
* Calendar
* Camera
* Clock
* Contacts
* Dialer
* Email
* FM Radio
* Gallery
* Marketplace
* Music
* Settings
* SMS
* Template
* Usage
* Video

For each app, report the the memory usage after the moz-app-loaded event.

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T12:18:51Z

Wcosta: /* Summary */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines moz-app-loaded event].

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T12:02:12Z

Wcosta: /* Project Roadmap */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines startup events] in the same way it does for [https://wiki.mozilla.org/FirefoxOS/Performance/Automation/Launch_Latency launch latency].

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

{| class="wikitable"
! width="120px" |
! colspan="2" | Milestone 1: Design
|-
!
! Test Design
! Validity Review
|-
| '''All Cases''' || Bug || Bug
|-
|}

{| class="wikitable"
! width="120px" |
!
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Browser''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Calendar''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Camera''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Clock''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Contacts''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Dialer''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Email''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''FM Radio''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Gallery''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Marketplace''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Music''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Settings''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''SMS''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Template''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Usage''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Video''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Memory_Consumption]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T11:54:25Z

Wcosta: /* Published Results */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines startup events] in the same way it does for [https://wiki.mozilla.org/FirefoxOS/Performance/Automation/Launch_Latency launch latency].

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

''REMOVEME: This indexes bugs and progress for each step of the test case creation from design to publication. Modify the tables to factor out common designs, remove the instrumentation columns, or whatever is appropriate. The "Availability" column should either be "ETA <release>", "release" for delivered items, or "TBD"''

{| class="wikitable"
! width="120px" |
!
! colspan="2" | Milestone 1: Design
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Test Design
! Validity Review
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Case 1''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Case 2''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Test_Template template]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T11:26:45Z

Wcosta: /* Memory Consumption */

= Memory Consumption =

== Summary ==

Measures memory consumption of an application after [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines startup events] in the same way it does for [https://wiki.mozilla.org/FirefoxOS/Performance/Automation/Launch_Latency launch latency].

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

TBD

=== How to Run On-Demand ===

TBD

=== Published Results ===

TBD

==== Branch 1 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

==== Branch 2 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

=== References ===

* [http://www.akkadia.org/drepper/cpumemory.pdf What every programmer should know about memory]
* [http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Why mobile web apps are slow]
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Firefox OS App Responsiveness Guidelines]

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

''REMOVEME: This indexes bugs and progress for each step of the test case creation from design to publication. Modify the tables to factor out common designs, remove the instrumentation columns, or whatever is appropriate. The "Availability" column should either be "ETA <release>", "release" for delivered items, or "TBD"''

{| class="wikitable"
! width="120px" |
!
! colspan="2" | Milestone 1: Design
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Test Design
! Validity Review
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Case 1''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Case 2''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Test_Template template]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-29T10:56:39Z

Wcosta: /* Project Roadmap */

= Memory Consumption =
''REMOVEME: This is a fluid format. Anything that doesn't fit the metric at hand should be removed or changed. Try to include some version of all this information, if it would otherwise be appropriate.''

== Summary ==

''REPLACEME: with a general summary of the metric''

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

''REPLACEME: with information about the generally expected precision of the measurements. This determines how much of a change in results should be considered significant.''

=== How to Run On-Demand ===

''REPLACEME: with information on how a developer can run the cases on-demand from command line or otherwise''

=== Published Results ===

''REMOVEME: Add links to the dashboards or areas where the results of tests are published''

==== Branch 1 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

==== Branch 2 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

=== References ===

* Reference 1
* Reference 2

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' Wander Lairson Costa
* '''Tracking Bug:''' TBD

''REMOVEME: This indexes bugs and progress for each step of the test case creation from design to publication. Modify the tables to factor out common designs, remove the instrumentation columns, or whatever is appropriate. The "Availability" column should either be "ETA <release>", "release" for delivered items, or "TBD"''

{| class="wikitable"
! width="120px" |
!
! colspan="2" | Milestone 1: Design
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Test Design
! Validity Review
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Case 1''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Case 2''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Test_Template template]</small>

Firefox OS/Performance/Automation/Memory Consumption

2014-07-28T21:47:24Z

Wcosta: /* Memory Consumption */

= Memory Consumption =
''REMOVEME: This is a fluid format. Anything that doesn't fit the metric at hand should be removed or changed. Try to include some version of all this information, if it would otherwise be appropriate.''

== Summary ==

''REPLACEME: with a general summary of the metric''

== Usage ==

=== Test Cases ===

''REMOVEME: Add names and high-level descriptions of available cases''

; Case 1 : Description
; Case 2 : Description

=== Precision ===

''REPLACEME: with information about the generally expected precision of the measurements. This determines how much of a change in results should be considered significant.''

=== How to Run On-Demand ===

''REPLACEME: with information on how a developer can run the cases on-demand from command line or otherwise''

=== Published Results ===

''REMOVEME: Add links to the dashboards or areas where the results of tests are published''

==== Branch 1 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

==== Branch 2 ====

{| class="wikitable"
!
! Device 1
! Device 2
|-
| '''Case 1''' || [http://www.example.com Datazilla] || N/A
|-
| '''Case 2''' || [http://www.example.com Eideticker] || N/A
|-
|}

=== References ===

* Reference 1
* Reference 2

== Development ==

=== Design ===

''REMOVEME: This section is documentation of the steps a case goes through, at enough detail to review or duplicate them. Delete any unneeded setup/teardown sections. These can also be links into [https://moztrap.mozilla.org/results/runs/ MozTrap], if the tests are documented there.

==== Common Setup ====
# Step 1
# Step 2

==== Case 1 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

==== Case 2 ====
* Setup
*# Step 1
*# Step 2

* Test
*# Step 1
*# Step 2

* Teardown
*# Step 1
*# Step 2

=== Results ===

* Repetition, results, etc.

==== Common Teardown ====
# Step 1
# Step 2

=== Project Roadmap ===

* '''Lead:''' TBD
* '''Tracking Bug:''' TBD

''REMOVEME: This indexes bugs and progress for each step of the test case creation from design to publication. Modify the tables to factor out common designs, remove the instrumentation columns, or whatever is appropriate. The "Availability" column should either be "ETA <release>", "release" for delivered items, or "TBD"''

{| class="wikitable"
! width="120px" |
!
! colspan="2" | Milestone 1: Design
! colspan="4" | Milestone 2: Test
! colspan="2" | Milestone 3: Publication
|-
!
! Availability
! Test Design
! Validity Review
! Instrumentation
! Workload
! On-Demand Test
! Results Review
! Published Results
! Documentation
|-
| '''Case 1''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
| '''Case 2''' || TBD || Bug || Bug || Bug || Bug || Bug || Bug || Bug || Bug
|-
|}

<small>[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Test_Template template]</small>

Performance/MemShrink/DMD

2014-07-28T14:35:00Z

Wcosta: /* Building and Running */

DMD (short for "dark matter detector") is a tool that tracks which heap blocks have been reported by memory reporters. It helps us reduce the "heap-unclassified" value in Firefox's about:memory page. It also detects if any heap blocks are reported twice.

== Building and Running ==

=== Desktop Firefox (Linux) ===

==== Build ====

Build with these options:

ac_add_options --enable-dmd

If building via try server, modify
<code>browser/config/mozconfigs/linux64/common-opt</code> or a similar file
before pushing.

==== Launch ====

From a Bourne-style shell, do this:

LD_PRELOAD=$OBJDIR/dist/lib/libdmd.so \
LD_LIBRARY_PATH=$OBJDIR/dist/lib/ \
DMD=1 \ # or replace the '1' with one or more DMD options (see below)
<command>

If you want to run under gdb, do this:

LD_PRELOAD=$OBJDIR/dist/lib/libdmd.so \
LD_LIBRARY_PATH=$OBJDIR/dist/lib/ \
DMD=1 \ # or replace the '1' with one or more DMD options (see below)
gdb --args <command>

==== Trigger ====

If you are on a sufficiently recent build (post-{{bug|1013652}}), visit about:memory and click the "DMD" button. (The button won't be present in non-DMD builds, and will be grayed out in DMD builds if DMD isn't enabled at start-up.)

If you are on an older build, visit about:memory, open the web console (with ctrl-shift-k) and in the prompt at the very bottom enter:

DMDReportAndDump('out.dmd')

Both actions invoke all the memory reporters and then DMD analyzes the reports, printing this commentary:

DMD: running reporters...
DMD[11420] Dump 1 {
DMD[11420] gathering stack trace records...
DMD[11420] creating and sorting twice-reported stack trace record array...
DMD[11420] creating and sorting unreported stack trace record array...
DMD[11420] printing unreported stack trace record array...
DMD[11420] creating and sorting once-reported stack trace record array...
DMD[11420] printing once-reported stack trace record array...
DMD[11420] }

The output be written to a file called <code>out.dmd</code> in the current working directory.

==== Post-process ====

Post-process the output file using <tt>tools/rb/fix-linux-stack.pl</tt>, which
reads from <tt>stdin</tt> and writes to <tt>stdout</tt>. This step is slow, and
can take 2 minutes or more.

=== Desktop Firefox (Mac) ===

==== Build ====

Build with these options:

ac_add_options --enable-debug
ac_add_options --enable-dmd

''Note: non-debug DMD builds do not currently work on Mac. see {{bug|995443}}.''

If building via try server, modify
<code>browser/config/mozconfigs/macosx64/common-opt</code> or a similar file
before pushing.

==== Launch ====

Start the browser like this:

DYLD_INSERT_LIBRARIES=$OBJDIR/dist/lib/libdmd.dylib \
LD_LIBRARY_PATH=$OBJDIR/dist/lib/ \
DMD=1 \ # or replace the '1' with one or more DMD options (see below)
<command>

If you want to run under lldb, do this:

DYLD_INSERT_LIBRARIES=$OBJDIR/dist/lib/libdmd.dylib \
LD_LIBRARY_PATH=$OBJDIR/dist/lib/ \
DMD=1 \ # or replace the '1' with one or more DMD options (see below)
lldb -- <command>

==== Trigger ====

Follow the [[#Trigger|Trigger instructions for Linux]]. Note that on Mac this step can
take 30+ seconds.

==== Post-process ====

Post-process the output file using <tt>tools/rb/fix_macosx_stack.py</tt>, which
reads from <tt>stdin</tt> and writes to <tt>stdout</tt>. This step is slow, and
can take 30 seconds or more.

If your build does not contain symbols, for example because you did not compile with <tt>--enable-profiling</tt>, this may not get you proper stacks. However, if you have crash reporter symbols for your build (tryserver builds do!), you can use [https://github.com/mstange/analyze-tryserver-profiles/blob/master/resymbolicate_dmd.py this script] instead - clone the whole repo, edit the paths at the top of <tt>resymbolicate_dmd.py</tt> and run it.

=== Desktop Firefox (Windows) ===

==== Build ====

Build with these options:

ac_add_options --enable-dmd
ac_add_options --enable-profiling

If building via try server, modify
<code>browser/config/mozconfigs/win32/common-opt</code>. Also, add this line to
<tt>build/mozconfig.common</tt>:

MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1

==== Launch ====

On a local build, start the browser like this:

set MOZ_REPLACE_MALLOC_LIB=path\to\dmd.dll
set DMD=1 # or replace the '1' with one or more DMD options (see below)
<command>

On a build done by the try server, follow [https://bugzilla.mozilla.org/show_bug.cgi?id=936784#c69 these instructions] instead.

==== Trigger ====

Follow the [[#Trigger|Trigger instructions for Linux]].

=== B2G ===

==== Build ====

'''First, update your B2G checkout''' with <tt>git pull</tt> or <tt>git fetch && git merge origin/master</tt>. <tt>./repo sync</tt> is not sufficient! You must git pull to get the latest version of the relevant tools.

For B2G device builds, we don't usually modify the mozconfig (although you can; it's hiding under gonk-misc/default-gecko-config). Instead, modify your .userconfig and add

export MOZ_DMD=1

You probably need to clobber your objdir (rm -rf objdir-gecko). Then build normally.

==== Launch ====

Your build will then automatically launch with DMD enabled. (The <tt>b2g.sh</tt> script figures out whether to enable DMD by checking for the presence of <tt>libdmd.so</tt> in <tt>/system/b2g</tt>.) You'll see a message in logcat when a process starts up:

I/DMD ( 305): $DMD = '1'
I/DMD ( 305): DMD is enabled

The <tt>run-gdb.sh</tt> script also knows to start DMD builds with DMD enabled, so you don't need to do anything special.

If you want to run B2G on a device with non-default options, you'll need to modify the value of <tt>DMD</tt> in the <tt>gonk-misc/b2g.sh</tt> script and then push it to the device like so:

adb shell stop b2g
adb remount
adb push b2g.sh /system/bin
adb shell chmod 0755 /system/bin/b2g.sh
adb shell start b2g

If you want to run B2G on the device under GDB with non-default options, modify the run-gdb.sh script. You don't need to push anything.

==== Trigger ====

When you want to analyze the contents of memory, run <tt>tools/get_about_memory.py</tt>. You should see output like the following:

$ ./get_about_memory.py
Got 3/3 files.
Pulled files into about-memory-18.
Got 3 DMD dump(s).
[...]
Done processing DMD files. Have a look in about-memory-18.

'''Note:''' If you are not using the default <tt>GECKO_OBJDIR</tt> you'll need to pass that into <tt>get_about_memory.py</tt>
$ ./get_about_memory.py --gecko-objdir $OBJDIR

<tt>get_about_memory.py</tt> invokes <tt>fix_b2g_stack.py</tt> to post-process stack traces, so you shouldn't need to run it yourself, but it's there in case you need it.

See <tt>get_about_memory.py --help</tt> for more options, but you probably won't need anything other than the defaults.

=== B2G Desktop Client ===

==== Build ====

[https://developer.mozilla.org/en-US/Firefox_OS/Building_the_B2G_desktop_client Build the B2G Desktop Client], adding these options to the
[https://developer.mozilla.org/en/docs/Configuring_Build_Options mozconfig] file:

ac_add_options --enable-debug
ac_add_options --enable-dmd

==== Launch ====

Start b2g like this:

LD_PRELOAD=$OBJDIR/dist/lib/libdmd.so \
LD_LIBRARY_PATH=$OBJDIR/dist/lib/ \
DMD=1 \ # or replace the '1' with one or more DMD options (see below)
$OBJDIR/dist/bin/b2g -profile $GAIA/profile-debug

==== Trigger ====

[https://wiki.mozilla.org/FirefoxOS/Performance/Debugging_OOMs#Step_2.2C_option_4:_Run_B2G_on_your_desktop Send signal 34 to the b2g process]:

$ killall -34 b2g

The dmd gzipped log is located at ''/tmp'' directory:

$ ls /tmp/dmd*
/tmp/dmd-1406557150-14443.txt.gz

Unzip the dmd log and run the ''fix-linux-stack.pl'' script:

$ gunzip /tmp/dmd-1406557150-14443.txt.gz
$ mozilla-central/tools/rb/fix-linux-stack.pl /tmp/dmd-1406557150-14443.tx > dmd-b2g.txt

If you running a Mac OSX, you should use the ''fix_macosx_stack.py'' tool.

=== Fennec ===

'''Due to [https://bugzilla.mozilla.org/show_bug.cgi?id=823354 bug 823354], you may get empty stack traces on Fennec, rendering DMD's output largely unhelpful. Sorry.'''

==== Build ====

Build with these options:

ac_add_options --enable-dmd

==== Launch ====

Launch with the following commands (be sure to replace "org.mozilla.fennec" with the app identifier as appropriate; this will usually be org.mozilla.fennec_$USERNAME for a local build).

adb push $OBJDIR/dist/lib/libdmd.so /sdcard/
adb shell am start -n org.mozilla.fennec/.App \
--es env0 MOZ_REPLACE_MALLOC_LIB=/sdcard/libdmd.so \
--es env1 DMD=1 # or replace the '1' with one or more DMD options (see below)

The commentary on Fennec goes to logcat, and looks like this:

I/DMD (27314): $DMD = '1'
I/DMD (27314): DMD is enabled

The number in the parentheses is the process ID.

==== Trigger ====

Use the existing memory-report dumping hook:

adb shell am broadcast -a org.mozilla.gecko.MEMORY_DUMP

In logcat, you should see output similar to this:

E/GeckoConsole (27314): nsIMemoryInfoDumper dumped reports to /data/data/org.mozilla.fennec_kats/app_tmp/memory-report-default-27314.json.gz

The path (should always be /data/data/$APPID/app_tmp/) is where the memory reports and DMD reports get dumped to. You can pull them like so:

adb pull /data/data/org.mozilla.fennec_kats/app_tmp/memory-report-default-27314.json.gz
adb pull /data/data/org.mozilla.fennec_kats/app_tmp/dmd-default-27314.txt.gz

== Interpreting the output ==

DMD's output is broken into multiple sections.

# "Invocation". This tells you how DMD was invoked, i.e. what options were used.
# "Twice-reported stack trace records". This tells you which heap blocks were reported twice or more. The presence of any such records indicates bugs in one or more memory reporters.
# "Unreported stack trace records". This tells you which heap blocks were not reported, which indicate where additional memory reporters would be most helpful.
# "Once-reported stack trace records": like the "Unreported stack trace records" section, but for blocks reported once.
# "Summary": gives measurements of the total heap, and the unreported/once-reported/twice-reported portions of it.
# "Execution measurements": gives some statistics about DMD's execution, which are mostly of interest to DMD's developers.

The "Twice-reported stack trace records" and "Unreported stack trace records" sections are the most important, because they indicate ways in which the memory reporters can be improved.

Here's an example stack trace record from the "Unreported stack trace records" section.

Unreported: 3 blocks in stack trace record 209 of 1,891
36,864 bytes (26,184 requested / 10,680 slop)
0.03% of the heap (64.55% cumulative); 0.04% of unreported (86.78% cumulative)
Allocated at
malloc (/home/njn/moz/mi2/memory/build/replace_malloc.c:151) 0x417170
PR_Malloc (/home/njn/moz/mi2/nsprpub/pr/src/malloc/prmem.c:435) 0x7f68650f423c
PL_ArenaAllocate (/home/njn/moz/mi2/nsprpub/lib/ds/plarena.c:200) 0x7f68652463e1
nsFixedSizeAllocator::Alloc(unsigned long) (/home/njn/moz/mi2/xpcom/ds/nsFixedSizeAllocator.cpp:95) 0x7f6860f528dc
nsNodeInfo::Create(nsIAtom*, nsIAtom*, int, unsigned short, nsIAtom*, nsNodeInfoManager*) (/home/njn/moz/mi2/content/base/src/nsNodeInfo.cpp:64) 0x7f685f640933
nsNodeInfoManager::GetNodeInfo(nsIAtom*, nsIAtom*, int, unsigned short, nsIAtom*) (/home/njn/moz/mi2/content/base/src/nsNodeInfoManager.cpp:225) 0x7f685f642d05
mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/home/njn/moz/mi2/content/base/src/Element.cpp:1862) 0x7f685f60ad87
mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/home/njn/moz/mi2/content/base/src/Element.cpp:1778) 0x7f685f60a9b3
nsXMLContentSink::AddAttributes(unsigned short const**, nsIContent*) (/home/njn/moz/mi2/content/xml/document/src/nsXMLContentSink.cpp:1464) 0x7f685fa76c5c
nsXBLContentSink::AddAttributes(unsigned short const**, nsIContent*) (/home/njn/moz/mi2/content/xbl/src/nsXBLContentSink.cpp:882) 0x7f685fb3ad42
nsXMLContentSink::HandleStartElement(unsigned short const*, unsigned short const**, unsigned int, int, unsigned int, bool) (/home/njn/moz/mi2/content/xml/document/src/nsXMLContentSink.cpp:1018) 0x7f685fa73db5
nsXMLContentSink::HandleStartElement(unsigned short const*, unsigned short const**, unsigned int, int, unsigned int) (/home/njn/moz/mi2/content/xml/document/src/nsXMLContentSink.cpp:947) 0x7f685fa7370a
nsXBLContentSink::HandleStartElement(unsigned short const*, unsigned short const**, unsigned int, int, unsigned int) (/home/njn/moz/mi2/content/xbl/src/nsXBLContentSink.cpp:258) 0x7f685fb37cc0

It tells you that there were 3 heap blocks that were allocated from the program point indicated by the "Allocated at" stack trace, that these blocks took up 36,864 bytes, and that 10,680 of those bytes were "slop" (wasted space caused by the heap allocator rounding up request sizes). It also indicates what percentage of the total heap size and the unreported portion of the heap these blocks represent.

Within each section, records are listed from largest to smallest.

Once-reported and twice-reported stack trace records also have stack traces for the report point(s). For example:

Reported at
mozilla::dmd::Report(void const*) (/home/njn/moz/mi2/memory/replace/dmd/DMD.cpp:1740) 0x7f68652581ca
CycleCollectorMallocSizeOf(void const*) (/home/njn/moz/mi2/xpcom/base/nsCycleCollector.cpp:3008) 0x7f6860fdfe02
nsPurpleBuffer::SizeOfExcludingThis(unsigned long (*)(void const*)) const (/home/njn/moz/mi2/xpcom/base/nsCycleCollector.cpp:933) 0x7f6860fdb7af
nsCycleCollector::SizeOfIncludingThis(unsigned long (*)(void const*), unsigned long*, unsigned long*, unsigned long*, unsigned long*, unsigned long*) const (/home/njn/moz/mi2/xpcom/base/nsCycleCollector.cpp:3029) 0x7f6860fdb6b1
CycleCollectorMultiReporter::CollectReports(nsIMemoryMultiReporterCallback*, nsISupports*) (/home/njn/moz/mi2/xpcom/base/nsCycleCollector.cpp:3075) 0x7f6860fde432
nsMemoryInfoDumper::DumpMemoryReportsToFileImpl(nsAString_internal const&) (/home/njn/moz/mi2/xpcom/base/nsMemoryInfoDumper.cpp:626) 0x7f6860fece79
nsMemoryInfoDumper::DumpMemoryReportsToFile(nsAString_internal const&, bool, bool) (/home/njn/moz/mi2/xpcom/base/nsMemoryInfoDumper.cpp:344) 0x7f6860febaf9
mozilla::(anonymous namespace)::DumpMemoryReportsRunnable::Run() (/home/njn/moz/mi2/xpcom/base/nsMemoryInfoDumper.cpp:58) 0x7f6860fefe03

You can tell which memory reporter made the report by the name of the MallocSizeOf function near the top of the stack trace. In this case it was the cycle collector's reporter.

By default, DMD measures heap blocks above a certain size precisely, but uses sampling to measure blocks below that size. Any measurements that involve sampled blocks (even if combined with non-sampled measurements) are approximate, and this is indicated by a preceding '~'. For example:

Unreported: ~273 blocks in block group 17 of 14,611
~1,125,590 bytes (~1,117,936 requested / ~7,654 slop)
0.07% of the heap (2.58% cumulative); 0.43% of unreported (16.36% cumulative)

The sampling threshold can be adjusted with an option (see below). This will affect the precision of the output and the speed at which Firefox+DMD runs.

== Options ==

Setting the <tt>DMD</tt> environment variable to <tt>1</tt> gives default options. But you can also specify non-default options by setting <tt>DMD</tt> to a whitespace separated list of <tt>--option=val</tt> entries.

==== --sample-below=<1..n> ====

By default, DMD samples blocks with a sample-below size of 4093. I.e. it ignores some small allocations in order to run (much) faster.

If you want DMD to record all allocations precisely, pass <tt>--sample-below=1</tt>. Otherwise, you should probably leave it unchanged. If you do pick a different value, prime numbers work best.

==== --max-frames=<1..24> ====

By default, DMD stack traces do not exceed 24 frames. You can reduce this.

==== --max-records=<1..1000000> ====

By default, DMD will print 1000 stack trace records of each kind. You can
increase or decrease this.

==== --mode=<normal|test|stress> ====

<tt>--mode=<normal|test|stress></tt> can be used to invoke "test" or "stress" mode, which are useful if you're hacking on DMD. The default is normal mode.

"test" and "stress" modes set their own <tt>--sample-below</tt> values, so you
should never have to specify both <tt>--sample-below</tt> and <tt>--mode</tt>.

To run the tests, specify <tt>--mode=test</tt> and start Firefox. It will print out some stuff and very quickly exit. Then run the following command from the top of your source directory.

memory/replace/dmd/check_test_output.py . test.dmd

(If you invoked Firefox from a different directory to your source directory, you might need to specify the path to <tt>test.dmd</tt>.)

This script checks the output produced by the previous step, and will indicate if the test passed or failed. It should work on Linux and Mac, but is unreliable on Windows.

== Which heap blocks are reported? ==

At this stage you might wonder how DMD knows which allocations have been reported and which haven't. DMD only knows about heap blocks that are measured via a function created with one of the following two macros:

MOZ_DEFINE_MALLOC_SIZE_OF
MOZ_DEFINE_MALLOC_SIZE_OF_ON_ALLOC

Fortunately, most of the existing memory reporters do this. See [[Platform/Memory_Reporting]] for more details about how memory reporters are written.

== Troubleshooting ==

Contact Nick Nethercote ("njn" on IRC) or Nathan Froyd ("froydnj" on IRC).