Outreachy

From MozillaWiki
Revision as of 23:35, 9 November 2017 by Enoonan (talk | contribs) (updated links to outreachy pages)
Jump to navigation Jump to search

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.

Outreachy Links


Outreachy Program Cohort: Round 15 (December 2017 - March 2018)

JSON-e Everywhere

Mentor: Dustin Mitchell
IRC:dustin

Project Description: Taskcluster is the task-execution platform which will soon handle all build, test, and release work for Mozilla projects. We are working to radically simplify how tasks are created to support the incredible diversity of projects we want to support.

As part of that work, we have developed a small templating language, JSON-e (https://taskcluster.github.io/json-e/) and we are working on using that language to define tasks across the platform. This project involves finishing that work, specifically:

  • Support JSON-e to define tasks in taskcluster-hooks
  • Support listening for pulse messages in taskcluster-hooks
  • Replace mozilla-taskcluster with per-repository hooks
  • Support JSON-e to define tasks in Github repositories
  • Lots of smaller updates, fixes, and new features

This project will involve work in Python and Javascript (server-side, not browser), using both Git and Mercurial repositories. You may even get a chance to make some changes to the Firefox source code itself. The tasks involve understanding how things work now, how we would like them to work, and how to get them there rather than deeply technical algorithm implementation. They will probably change as we learn more -- no plan survives breakfast. It turns out most of software engineering is like that!

Taskcluster involves its Outreachy participants as full members of the team. You will work with other Mozillians where your work overlaps with theirs, and you are encouraged to attend and participate in team meetings and irc conversations. We will provide you with all the help and support you need. You can see some of our community of contributors at https://docs.taskcluster.net/people.

Add-ons Linter (2 Spots)

Mentor: Christopher Grebs
IRC: cgrebs Email: cgrebs@mozilla.com

Project Descriptions The add-ons linter project aims to find common issues within with a web-extension both used as a development tool and as at the point of submission via https://addons.mozilla.org (AMO). It aims to guide Add-on developers to avoid common mistakes and potential security vulnerabilities.

The linter is written in JavaScript and runs under Node.js. A potential mentee should already have a good understanding of JavaScript and be familiar with ES2015+ syntax. The linter is heavily unit tested so it would be expected that all patches would maintain the current level of code-coverage.

This list contains suggestions issues that could be of interest. Each item is a discrete piece of work. The list features largest items first.

Project 1

Project 2

  • Migrate to Await/Async - the linter currently makes heavy use of promises. The newer Await/Async syntax makes code easier to read and understand. See the issues for additional details as to what is involved https://github.com/mozilla/addons-linter/issues/1536. This task requires a good understanding of promises and their various nuances.
  • Improving validation. There’s several areas where the validation the linter currently provides could be improved here’s a few suggested areas to start:
      1. Improve the feedback given to developers about icon usage: See 
         https://github.com/mozilla/addons-linter/labels/component%3A%20icons for more details.
      2. Permissions. The linter could do more to inform the developer of relevant information related to 
         the permissions they have asked for in the manifest.json. See this label for more information 
         https://github.com/mozilla/addons-linter/labels/component%3A%20permissions
      3. Improve issues related to schema validation. See 
         https://github.com/mozilla/addons-linter/labels/component%3A%20schema for more details.

Android WebExtensions

Mentors:Luca Greco with Sebastian Kaspari IRC: rpl

Project Description WebExtensions have been working on Android for many releases, but the API is a little bit behind the Desktop version of Firefox. We’d like to improve the API on Android so that we can get some great extensions on Android.

This is a cool opportunity to contribute to a mobile project that ships to millions of users.

The WebExtensions API are mostly written in JavaScript, but someone working on this might need to dive down into Java or C++ in some cases. The expectation is that any API would be fully unit tested, so they’ll need to be writing some unit tests.

The list of things that we’ll be looking for are being worked on by other contributors so we’d to interact with those. But they include:

  • browsingData - an API to remove data from the browser
  • contextMenus - an API to show context sensitive menus in Android
  • history - interaction with the users browser history
  • omnibox - shortcuts in the browser address bar

For more information about this project, please see the FAQs!

Treeherder

Mentor: Ed Morley and Cameron Dawson
IRC: #treeherder

Overview:

Treeherder is the web application for visualising continuous integration tasks used to build and test Firefox. Treeherder processes a lot of data everyday to be able to visualise this data. It's used by Firefox devs to check whether their new code works, and by release managers to decide whether to include a new feature in the next version of Firefox.

Inside this data we have a number of failures that occur and are intermittent making it difficult to track and reproduce. When a developer tests out code, they want to know "Did my code cause any regressions?". Currently this can be difficult to figure out.

We need to start building up metrics on these to help engineering teams know which intermittent failures are important and which are not.

You will be working on one of the following:

  1. Visualising intermittents and their regularity
    • Create a frontend to visual historical trends of failures with creative ways to browser and compare. This will be used by developers and sheriffs who are trying to fix these failures.
    • Building a user interface inside of Treeherder for annotating/matching failures
    • Create a backend for storing unique identifiers for failures which will be referenced by an auto classification engine, the frontend for annotating, and the historical view for finding trends
  2. Building out auto-classification tooling to be able to handle more types of intermittent failure types.
    • Create an engine that will automatically match failures and annotate them properly
    • Building a user interface inside of Treeherder for annotating/matching failures

You will need to know a little bit of the following and learn the rest as you go:

  • Python (for use with the Django/Django REST framework backend)
  • JavaScript (for use with the React/AngularJS frontend)
  • HTML/CSS

Outreachy Program Cohort: Round 14 (May 30 -Aug 30, 2017)

Page Shot / Firefox Screenshots

Note: Page Shot has been renamed Firefox Screenshots

Mentor: Ian Bicking
IRC: ianbicking (usually online 8am-3pm Pacific time)
IRC channel: #screenshots Status: it seems like we have quite a few potential applicants, you might want to consider looking at other projects

Project Description: Firefox Screenshots, a screenshot tool for Firefox, will be shipping with Firefox mid-June. Our small team's focus during the time of the internship will be running A/B tests on the product and refining the experience based on what we learn.

There's several areas that can be impactful to the project:

  • We are collecting behavioral data on how people use the tool, and plan to make changes through the summer based on what we learn. Someone with skills and interest in analyzing this kind of data (in our case Google Analytics and survey data) would be great. Some of what we want to learn from the data may require data analysis outside of Google Analytics.
  • We have many product goals. Firefox Screenshots is built as a WebExtension using pretty straight-forward JavaScript. The server is built with Node.js and React. Someone with knowledge of JavaScript together with HTML/CSS can get in and make positive changes quickly.
  • Our basic experience will be in place by the summer, but there will be many opportunities for optimizing the performance and size of the screenshots and pages that we're delivering, including offline access. In addition to development skills this will require research and experimentation to plan out the best approach.

If you are interested please check out the repository and try to follow the instructions. If you have problems that's okay! We want to make setup easy for everyone, but we still have work to do. Come to the IRC channel so we can help get you setup and improve the experience for future people. We have a list of good first bugs. If you want to start on one, please get your development environment setup first, and after that comment on a bug that you intend to work on it.

Note that the Firefox Screenshots developers work during the day, in timezones from UTC-8 to UTC-5. If an applicant can't work during many of those hours it is unlikely to be a good fit.

HTML+CSS demos of our new browser engine

Mentor:Lin Clark
IRC: linclark Email: lclark@mozilla.com

Project Description: At Mozilla, we're making our browser faster. This started as a research effort, building a next generation browser engine called Servo. Now parts of Servo are being merged into Firefox with Project Quantum.

The numbers are promising. For example, the new CSS style system (Stylo) can reduce the time it takes to render a page (like Barack Obama's wikipedia page) from 130ms to 30ms.

We want to show this off. In this internship, you'd be making demos that catch people's attention and show off these performance improvements.

For this internship, you will need HTML and CSS skills. We would love to see demos or prototypes you have created in the past that delight and surprise. An understanding of web page performance and how to analyze performance in the browser is preferred but not required.

Security audit of Firefox code

Mentor: Stéphanie Ouillon
IRC: arroway

Project Description: The Security Engineering team works on building and ensuring security into Firefox. Part of this work involves conducting security audits of the code shipped in Firefox. The candidate should be comfortable reading C++ and JavaScript Firefox code, and have an interest in learning about security engineering.

The scope of this project includes two main areas we're putting focus on:

1) Security auditing of third-party libraries used in Firefox Firefox relies on a vast amount of third-party Open Source libraries. Code review and security practices vary from one library to another, or new releases with security fixes might go unnoticed. We want to reduce the risk of including unsafe code in Firefox and auditing more thoroughly the most critical libraries we use.

Tasks include:

  • Identifying libraries with security concerns
  • Identifying code paths for additional fuzzing
  • Documenting the current process for using a new third-party library in mozilla-central
  • Setting security metrics (e.g number of security bugs related to the lib) to measure risk associated with a certain lib

2) Sandbox auditing Firefox is getting a security sandbox (https://wiki.mozilla.org/Security/Sandbox/Process_model). Hardening Firefox against attacks involves:

  • Checking IPC mechanisms are safe
  • Fuzzing IPC for bugs
  • Reviewing Firefox components with respect to sandbox controls

To get started, please visit this page: https://wiki.mozilla.org/SecOutreachy

Implement Telemetry health ping

Mentor: Georg Fritzsche
IRC: gfritzsche

Project Description Firefox Telemetry enables engineers and decision-makers to measure how Firefox behaves in the real world. As you use Firefox, Telemetry measures and collects non-personal information, such as performance, hardware, usage and customizations.

To more reliably monitor the quality of our incoming data and error conditions, we want to implement a small & minimal Telemetry health ping. This will be small enough to be sent without bandwidth concerns and include essential information about failures.

For this project, you will need:

  • JavaScript for the Firefox implementation
  • Python for processing and validating the incoming data using PySpark

This project will involve:

  • working with team members on the design of the health reporting
  • implementing the new design on the client, including test coverage
  • working with QA on a test plan for the reporting
  • validating incoming data
  • working with team members to make the data available in our re:dash instance

You can find more details on the project page.

Improve cross-browser and functional testing for webcompat.com

Mentor: Mike Taylor (Note: will be on PTO from March 9 - 19, but will check email sporadically. @karlcow has agreed to help with PRs and in issues).
IRC: miketaylr (I can be found in the #webcompat channel. If my nick is zz_miketaylr, I'm away but will get your messages when I come back!).

Project Description: webcompat.com is an open source project and website with the ambitious goal of making the web work for all users, in any browser. We want to improve our functional and cross-browser testing capabilities.

In this project, the Outreachy participant will work on the following:

  • Define a cross-browser testing matrix
  • Get functional tests running in non-Firefox browsers
  • Make improvements to BrowserStack - Travis CI Integration (this may or may not be done by the time this Outreachy round starts, we'll see!)
  • Create a working sub-set of tests for external contributors without access to authentication secrets.
  • Create a script to "bootstrap" a test repo to meet current functional test expectations
  • Improve test coverage (writing new functional tests, refactoring existing ones)
  • Implement a solution for mocking GitHub authentication
  • Investigate intermittent Intern failures
  • Explore unit testing with Intern

To be successful, the participant will need to be comfortable writing JavaScript and configuring 3rd party testing services. Some Python and Node.js experience will prove useful, but the rest can be learned!

To get started: 

 1. Clone the repo
 2. Set up a local development environment
 3. Get functional tests running locally
 4. Report any bugs or problems you ran into with that process, if any. 
 5. Send an email to miket@mozilla.com with a screenshot showing tests have completed locally. We'll talk about next contribution steps!
 (Note: it's OK if many of them are failing, as long as they all run!)

Site permission management UI

Mentor: Johann Hofmann
IRC: johannh

Project Description: "We would like to add a section to Firefox preferences that allows users to manage their saved site permissions (Geolocation, Camera, Microphone, ...). Our UX team is currently designing a nice-looking UI for this. Features include viewing and removing permissions and globally disabling access to a certain permission for all sites. Your task would be to implement this UI inside the Firefox preferences using JavaScript, HTML and CSS and wire up any missing pieces in the Firefox internals (moderate JavaScript experience is recommended).

You might enjoy this project if you like working on user interfaces, care about privacy and security and want to have a sizeable impact on the privacy and security of millions of Firefox users.

You can get started by solving any good first Firefox bug:

More details can be found in our contributing guide: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

It is highly recommended that you hop on IRC (https://wiki.mozilla.org/IRC) and join the #fx-team channel. Feel free to ask for help there (ping johannh).

CSS Layout Bug Squasher

Mentor: Josh Matthews
IRC: jdm

Project Description: Servo is a new, experimental web browser engine written in the Rust programming language (http://www.rust-lang.org/). It also has lots of bugs in its implementation of CSS layout. Some of these bugs are filed in the issue tracker with minimized test cases (https://github.com/servo/servo/issues/14947), while others have not been investigated yet (https://github.com/servo/servo/issues/15432). We’re looking for someone who is:

  • comfortable writing code in any programming language
  • experienced in reading and understanding the effects of CSS

We want to teach you how to write Rust code so you can channel that experience into squashing CSS layout implementation bugs in Servo. You will gain experience in:

  • reducing problems into minimal test cases
  • developing in a low-level programming language
  • using debugging strategies to determine the cause of problems in complex code
  • contributing to a large open-source project as part of a distributed team

To get involved:

Automate web accessibility testing

Mentor: Matt Brandt
IRC: mbrandt

Project Description: The internship entails researching how to test for web accessibility standards and then the application of that knowledge by reviewing several open source automated testing frameworks. Once they have chosen the framework that best suits our needs, that minimizes false positives, they will be responsible for codifying a suite of tests that are able to run within our Jenkins CI.

The project requires the intern to spend a short amount of time reading about web accessibility testing to help them gain domain knowledge. Prior experience with Javascript and Python is helpful but not required. Experience with an object oriented programing language is required, but can be gained by taking one of the many freely available online courses. An interest and aptitude in software engineering is encouraged.

As the intern pieces together a solution and implements the tests, they’ll help cleanup and update documentation. A willingness to reach out to members of the Firefox Test Engineering team as well as the Accessibility team for clarification will help round out the internship experience.

Rust: Web Assembly showcase

Mentor: Brian Anderson
IRC: brson

Project Description: Rust is a new systems programming language that is fast and memory safe. It is growing quickly, is pleasant to contribute to, and is in need of contributions in many areas!

In this project you will be developing a showcase application to demonstrate Rust compiled to WebAssembly, a new bytecode that runs in the web browser. With WebAssembly, authors can write software that runs on the web with near-native performance. It will unlock new capabilities for the web, and Rust, with it's focus on low-level performance, is one of the best-positioned languages to take advantage of WebAssembly.

This is a self-contained project where creativity and persistence will lead to success. Design and implement a client-side web application, written in Rust, that demonstrates the promise of running Rust software on the web, by compiling to WebAssembly. Publish and blog about the result.

This serves two important purposes: firstly, as a teaching tool, the project demonstrates two bleeding-edge technologies used successfully together. You will be at the forefront of this technology and people will be looking to your early experience as they try it themselves. Second, by writing a real application we will discover new bugs and other problems with the stack. You will report these bugs to their upstream projects, and even fix them yourself. This process of validating our products by actually using them is called "dogfooding", and it's an important part of product development.

At the end of this project you will have your own Rust-language web application, will have new experience with Rust, WebAssembly, JavaScript, and with collaboration in an active and friendly open source community.

The project will run in 3 phases: in the first weeks you will familiarize yourself with the tools: Rust, WebAssembly, emscripten, and their development environment in and out of the web browser. You'll work with your coach to identify a few key features that the project will demonstrate and plan how to create them. The second phase is where you will do planned implementation work. Finally, with a few weeks left to spare, we will evaluate our progress, decide how to present it most effectively, and then spend the remaining time polishing and documenting it for release.

Good candidates will have moderate programming experience, either in JavaScript or in a systems language like C, C++ or Rust. This work will involve investigating and even debugging new compiler and web browser features - much time will probably be spent examining the Rust compiler's WebAssembly output and comparing it to expectations. Interns will not be expected to fix bugs the Rust compiler itself on their own, though they are certainly welcome to - their task is to write an interesting web applications.

Unsafe Code Linting Tool for Rust

Mentor: Nicholas Matsakis
IRC: nmatsakis

Project Description: Rust is a new systems programming language that is fast and memory safe. It is growing quickly, is pleasant to contribute to, and is in need of contributions in many areas!

A crucial part of Rust's design is the ability for authors to use ""unsafe code"" to build up new abstractions and libraries. Unsafe code allows you to locally suspend some of the Rust type system rules, effectively giving you a lower-level language closer to C. The idea is that these lower-level details are encapsulated within a library that exports a safe interface. For example, the Rayon library exposes very convenient, simple primitives for writing threaded programs. If you stick to those primitives, your program will be free of data-races and other nasty parallel programming bugs. But internally the Rayon library makes use of traditional C-style threads to implement this abstraction.

At present, Rust doesn't give you very fine-grained tools for reasoning about unsafe code. Once you start writing an unsafely implemented library, it's entirely up to you to track whether a given pointer is safe to use and so forth. Just as when writing C code, this can easily go awry, particularly as code is updated. It could easily happen, for example, that an array index i is known to be in-bounds, and hence an unsafe array access (no bounds check) like vec[i] is safe. But as the program is updated, perhaps that assumption no longer holds -- now the array access could be out of bounds, leading to memory safety errors.

The goal with this internship is to develop a lint tool that would integrate with the rustc front-end to help improve the experience of writing unsafe code. This tool would allow unsafe code authors to write out and check more of their reasoning automatically: for example, they might document that why they believe that the variable i is in bounds (e.g., because it is compared against the length of the array, and the variable vec is not updated in the meantime). Then the tool can help check whether any of these assumptions stops being true (e.g., perhaps vec is changed to point to a different vector).

The project will involve both design and implementation. There is a general plan for how the linting tool should work, but part of the fun will be iterating on the tool once we try to put it to use and see how well it works. If all goes to plan, we can release the tool to the public.

Good candidates will have moderate programming experience in some language; experience with C, C++, or Rust specifically is not required. This work will primarily involve building a lint, which interfaces with the front-end of the Rust compiler, but will also involve learning a bit about the Rayon codebase (or some other suitable example of an unsafely implemented library).

Push Notifications for Signin Confirmation

Mentor: Sean McArthur
IRC: seanmonstar

Project Description: You will be implementing a form of 2FA in Firefox Accounts. Once completed, if a user has multiple devices connected to their Firefox Account, they will be able to receive a push notification to one of their other devices asking for confirmation when trying to log in to their Firefox Account.

Skills required: Git, JavaScript (node and browser)

As part of your application please try to fix a ‘good first bug’ at: https://waffle.io/mozilla/fxa?label=good-first-bug

To get started with Firefox Accounts servers please visit: https://github.com/mozilla/fxa-local-dev

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

bugzilla.mozilla.org improvements

Mentor: Emma Humphries
IRC: emceeaich

Project Description:

Participant would select from one of these projects:

1) [BMO RESKIN] Mozilla recently re-branded, and BMO doesn't match the new look. It would be nice to reskin it to look like the central Mozilla property it is.

Skills: CSS, HTML Templates, Perl

2) [TRIAGE VIEW] Build a supplemental bug editing view optimized for triaging bugs. This would afford the participant the chance to do rapid prototyping, test ideas with senior engineers, and help with an important workflow

Skills: JavaScript, CSS, HTML, Perl

See our list of Good First Bugs for bugs to attempt as part of application.

Upgrade ActiveData to use Elasticsearch v5+

Mentor: Kyle Lahnakoski
IRC: ekyle

LIVE DOCUMENT WITH ANSWERS

Project Description: About ActiveData
ActiveData is a publicly accessible data warehouse holding many billions of records, for some dozen+ datasets concerning Mozilla's testing infrastructure: This includes test results, job results, code coverage, and extracts from other systems. The ActiveData code itself is really only a stateless query translation layer; leaving the hard work of high speed filtering and aggregation to Elasticsearch.

Background
Elasticsearch is designed for text search, but can also serve as an extremely fast data warehouse. The speed comes from using [inverted indices](https://www.elastic.co/guide/en/elasticsearch/guide/current/inverted-index.html) to provide high performance data filtering and aggregation. Elasticsearch can index almost any JSON document, perform schema merging, and index all its properties, with almost no human intervention. By letting the machine manage the schema, we can query the JSON without transforming it

Elasticsearch does have a drawback: Its query language is designed for text search and is painful to use in a data warehouse context. Hence the need for ActiveData.

Problem
Elasticsearch 1.7.x was the last version that did a reasonable job of schema merging. Newer versions (2.0+) have disallowed schema merging, preventing ingestion of JSON documents that have a schema that conflicts with previous documents. We would like to use newer, faster, and more stable versions of Elasticsearch, but they can not handle varied data.

Solution
Build a translator will convert a variety of JSON formats into a single, strictly-typed, schema. The translator will use schema merging and property-renaming to perform a translation on documents before they go Elasticsearch.

Benefits
ElasticSearch's schema merging is great, but has always been incomplete: 1. It could not merge inner objects `{"a":{"b":1}}` with nested objects `{"a":[{"b":0}]}`, and 2. Merging numbers `{"a": 1}` with strings `{"b": "1"}` did not cause failure, but did leave the schema ambiguous, and made the queries clumsy. This upgrade will make ActiveData more flexible, improve service stability, and provide a step towards promoting this project to production.

Required Skills
Some particular experience will make this task easier (most important first):

  • Python
  • SQL and query languages
  • Database normalization and functional dependencies
  • Denormalization and data warehousing

References
1. Similar project for smaller data: [Mapping JSON to strict DB schema](https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md)
2. [ELT](https://en.wikipedia.org/wiki/Extract,_transform,_load) Links: [A](http://hexanika.com/why-shift-from-etl-to-elt/), [B](https://www.ironsidegroup.com/2015/03/01/etl-vs-elt-whats-the-big-difference/)
3. [data cubes](https://en.wikipedia.org/wiki/OLAP_cube)
4. [fact tables](https://en.wikipedia.org/wiki/Fact_table) in a [data warehouse](https://en.wikipedia.org/wiki/Data_warehouse).
5. [MDX](https://en.wikipedia.org/wiki/MultiDimensional_eXpressions).

Upgrade Lightbeam

Mentor: Paul Theriault IRC: pauljt

Project Description: The Mozilla Lightbeam extension is a key tool for Mozilla to educate the public about privacy and it’s due for an upgrade. It needs to be rewritten as a Web Extension and we will take this opportunity to investigate potential new features or integrations with Firefox. We are seeking a candidate with web development skills to work with the security engineering team to make this happen. We are looking for a front-end web developer who is passionate about privacy on the web. They should have an interest in design and visualization as the key part of this upgrade would be exploring how we can convey complex privacy & security concepts to the all Firefox users. Experience working with Web Extensions is a bonus but not required.

See the getting started guide here.

Improve DevTools Network Monitor

Mentor: Jan Odvarko
IRC: Honza

Project Description: "Firefox Developer tools can be used to intercept all HTTP requests and responses executed by a page. This feature is represented by a Network panel that shows list of all HTTP requests and related details (like e.g. headers, formatted response body, timings, etc.)

In order to improve value of the panel we'd like to connect the existing UI to other backends performing HTTP activity (for example, Chrome browser or NodeJS) and adapt our current remote protocol (RDP) to a new environment."

Outreachy Program Cohort: Round 13 (Dec 2016-March 2017)

Improve the first-run experience of Firefox's location bar

Mentor: Gijs Kruitbosch
Participant: Svetlana Orlik

Firefox's location bar currently uses your bookmarks, history and search engine to provide you with useful search results. When you're a new Firefox user, your bookmarks and history are empty, and so the initial experience can feel disorienting and unhelpful.

We'd like to provide users with an initial set of "autocompletion" results that provide domains that they are likely to navigate to. So that even when you're a new user, if you type in "face", we autocomplete to "facebook.com", and so on.

Make WebExtension Development More Awesome

Mentor: Kumar McMillan
Participants: Shubheksha Jalan and Elvina Valieva
Shubhesksha's Blog
Elvina's Blog

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, Chrome, 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 will improve the productivity of WebExtension developers in the following ways. Most of these tasks involve changing the web-ext command line tool but others may involve writing documentation or example code.

  • Utilize common web developer tools when building extensions.
  • 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. More info.
  • Offer extension “linting” in code editors
  • 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. More info.
  • 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. More info.

Build a Library of Inclusion Best Practices and Case Studies

Mentors: Larissa Shapiro and Lizz Noonan
Participants: Bee Padalkar, Kristi Progri, and Nasma Ahmed
Bee's Blog
Kristi's Website
Nasma's Website

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.

Improving user experience of Firefox Accounts

Mentor: Vlad Filippov
Participant: Divya Biyani
Divya's Website

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, the participant will be involved in improving user interaction, running experiments, and measuring success of certain features.

Her 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.

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

Add support for OpenAPI to Kinto

Mentors: Ethan Glasser-Camp and Rémy Hubscher
Participants: Mansimar Kaur and Gabriela Surita
Mansimar's Website

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's participants will work on developing OpenAPI support in Kinto. The reservoir of tasks includes:

  • 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.

Azure Blob Storage client library

Mentors: John Ford
Participant: Elena Solomon
Elena's Blog

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 'azure-entities' in NPM.

The goal of this project is to write a library to wrap the Azure Blob Storage service. A preliminary effort has already been done. This project's participants will take this work and extend it to cover the majority of the Blob Storage API.

We specifically would like to have the following:
1. All Rest API endpoints implemented using input validation to ensure that only valid data makes it to the API. 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 Shared Access Secrets (SAS) as authentication
4. Stretch goal of adding SAS for Blob storage to our authorization service

Improve Template Logic for Taskcluster-Github

Mentor: Brian Stack and Dustin Mitchell
Participant: Irene Storozhko

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.

This project involves addressing some of the more pressing user-identified issues with TaskCluster.

It is a collection of smaller projects:

  • 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.
  • 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.
  • Add "build shields", similar to http://shields.io/ that will show the latest status of a Taskcluster-Github build or test run.

Webcompat.com Content & Participation Experience Researcher

Mentor: Adam Stevenson
Participant: Mesha Lockett
Mesha's website

Mozilla's Web Compatibility team builds and maintains a website 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 commit to one or more of the following projects to help us improve our on-boarding process for new contributors:

  • Review & update web compatibility documentation
  • Identify and promote good features and bugs that need a contributor on social networks
  • Make creative assets to be used on webcompat.com
  • Review the user experience for contributors to webcompat.com
  • Help redesign the contributors page on webcompat.com
  • Create screencasts or scripts for screencasts that explain how to contribute to webcompat.com
  • Assess the current workflow and suggest areas for improvement

Make Treeherder faster with ReactJS

Mentor: Cameron Dawson
Participant: Casey Williams

Treeherder is growing. More people are using it every day. And the amount of data it displays is also growing. So we need to expand its ability to scale to more and more data. Treeherder is primarily written in AngularJS on the front-end. However, we display thousands of small objects on the main landing page. Using Angular’s ng-repeat for this proved unacceptably slow. It was converted to using JQuery and raw JavaScript DOM manipulation which has been acceptably fast for a while, but is harder to maintain. ReactJS has been used in other parts of the product to significantly improve performance and is easier to read and edit. The participant will convert the existing job matrix rendering to use ReactJS.

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 Outreachy Eligibility and Application Information page to learn more about applying for Outreachy.

First steps for applicants to Mozilla:

  1. Set up IRC.
  2. Set up a Bugzilla account and a 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.
  3. 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

Outreachy Round 13 applications have closed, but we encourage you to apply to the next round of projects in April.

Got Questions? Ask:

Past Outreachy/OPW internships

Complete List of Participants

ROUND 12

Ana Ribero

Rakhi Sharma

Manel Rhaiem

Deepthi Venkitaramanan

Benjamin "Benny" Forehand, Jr.

Ipsha Bhidonia

Anjana Vakil

Rutuja Surve

Andrea Del Rio Lazo

Kristel Teng

Katie Broida

Decky Coss

Jen Kagan

ROUND 11

Lauren Conrad

Participant: 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: SUMO - Build a tutorial or training tool for new technical writers

Project blog: www.laureneconrad.com

Roxana Ilie

Participant: Roxana Ilie

Based in: Bucharest, Romania

Mentor: 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: Battery Friendly Platform Networking Deadline Scheduler

Richa Rupela

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: 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: Contribute to the HTML Standard!

Shweta Oak

Based in: Mumbai, India

Mentor: 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."

Project: Kinto — Make instances discoverable

Jullie Utsch

Participant: Jullie Utsch

Based in: Belo Horizonte - MG Brazil

Mentor: 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: Visual Design with Research Data

Cynthia Anyango

Participant: Cynthia Anyango Based in: Nairobi , Kenya

Mentor: 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: Enumerate (and Dockerize) the tests! (Quality Assurance)

Nikki Bee

Participant: Nikki Bee

Based in: Alberta, Canada

Mentor: 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: Servo: Complete implementation of Fetch standard

My Lê

Based in: Paris - France

Mentor: Ricardo Vazquez

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

Project: 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

Retrieved from "https://wiki.allizom.org/index.php?title=Outreachy&oldid=1183830"