Outreachy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (→‎Treeherder: Clarifications & fix formatting)
 
(32 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Admon/note| Applications for Outreachy Winter 2017 are now open. Check out our Round 15 projects below. }} <br />
<div style="float: right">__TOC__</div>
Mozilla has participated in [https://outreachy.org the Outreachy program] since January 2013.  The goal of the program is to increase participation from under-represented groups in free and open source software. It is a project of the Software Freedom Conservancy.


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:
Mozilla hosts approximately 20 participants across two cohorts (summer and winter) each year.  Mozilla employees work 1:1 with participants for three months.   The program expressly invites women (both cis and trans), trans men, and genderqueer people to apply. It also expressly invites applications from residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. Anyone who faces under-representation, systemic bias, or discrimination in the technology industry of their country is invited to apply.                                                                                                                                                                                                                                                                                                           
* 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.
== Current Round ==


==Useful links for More Information==
[[Outreachy/Round/22|Round 22]] (May-August 2021) is the current round.
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]


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


==Outreachy Program Cohort: Round 15 (December 2017 - March 2018)==
Steps for applicants to Mozilla:
# Confirm your eligibility on the [https://www.outreachy.org/apply/ outreachy site]
# Look at the Mozilla projects available on the Outreachy site, consider your options, and if you have questions communicate with the project mentors. Of course, you are welcome to apply for non-Mozilla projects you find on the site as well!  You can communicate with other applicants, mentors, and coordinators in [https://chat.mozilla.org/#/room/#outreachy:mozilla.org #outreachy on chat.mozilla.org].
# Begin by contributing to the project. Most projects will describe how to make your first contribution.  As you make contributions, record them in the Outreachy site.  [https://codetribute.mozilla.org/ Codetribute] may help you find good tasks to work on.  ''For many applicants, this is the most valuable part of the experience!''
# Once you have made a few contributions, begin to write your application.  Ask the mentors to review the application before you submit it.


===JSON-e Everywhere===
== Participant Expectations ==
'''Mentor:''' [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] <br />
'''IRC:'''dustin


'''Project Description:'''
You will be working full-time on your project for three months.  You will meet with your mentor(s) frequently and participate in the open-source development process -- writing code, reviewing code, testing, and so on.  You will be expected to write a blog entry each week.
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,
== Mentor / Project Applications ==
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,
Mentors submit projects that they are willing to mentor. Here's what you need to know:
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
* The participant will be working full-time, spending 40 hours a week on their project for three months.  Participants will work remotely from home. Your project must be something the participant can do remotely and complete within those months. You will need to meet at least weekly with your participant, and be available for questions, code review, and so on throughout the internship.
team. You will work with other Mozillians where your work overlaps
* You will be heavily involved in the selection process for your mentee which will involve interviewing, reviewing code check-ins / bug reports / trial work.
with theirs, and you are encouraged to attend and participate in team
* During the application process, applicants will be expected to make contributions, so make sure you have established a system for new contributors to get involved and have enough good starter tasks for them.
meetings and irc conversations.  We will provide you with all the help
* Speak with your manager to check it’s OK for you to submit a project proposal.  Each participating organization will need to provide budget for the participant costs of $6500.  The Mozilla coordinators can help connect you with that budget.
and support you need. You can see some of our community of
* To maximize the number of applicants to your project, submit it as early in the process as possible.
contributors at https://docs.taskcluster.net/people.
* [https://www.outreachy.org/mentor/mentor-faq/ More FAQ's on the Outreachy Site]


===Add-ons Linter (2 Spots)===
== Help! ==
'''Mentor:''' Christopher Grebs <br />
'''IRC:''' cgrebs


'''Project Descriptions'''
Questions? Ask:
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.
* Mozilla Outreachy Coordinators: [mailto:outreachy-coordinators@mozilla.com outreachy-coordinators@mozilla.com]
* Mozilla Slack: #outreachy (staff only)
* [https://chat.mozilla.org/#/room/#outreachy:mozilla.org #outreachy on chat.mozilla.org]


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.
== Links ==
 
* [https://chat.mozilla.org/#/room/#outreachy:mozilla.org Outreachy on chat.mozilla.org]
This list contains suggestions issues that could be of interest. Each item is a discrete piece of work. The list features largest items first.
* [https://docs.google.com/document/d/1hR_JDDTihKXGK46NnueNpbpfat4PAZ7wiIvgYX47ZpY/edit# Project Proposal Guide] (staff only)
 
* https://www.outreachy.org/ -- main Outreachy site
====Project 1====
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]
* Localization: Add-on developers come from many different countries and regions. We’d like to setup the linter to be fully localized in the same list of countries as https://addons.mozilla.org (AMO). See the following issues for an idea for what’s involved https://github.com/mozilla/addons-linter/issues/1535
* [https://lists.outreachy.org/cgi-bin/mailman/listinfo/announce Outreachy announcement mailing list] (find out about upcoming rounds)
 
====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:'''[https://mozillians.org/en-US/u/luca/ Luca Greco] with [https://mozillians.org/en-US/u/sebastian.kaspari/ 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:
*[https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browsingData browsingData] - an API to remove data from the browser
*[https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextMenus/ contextMenus] - an API to show context sensitive menus in Android
*[https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history history] - interaction with the users browser history
*[https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/omnibox omnibox] - shortcuts in the browser address bar
 
=== Treeherder ===
 
'''Mentor:''' Ed Morley and Cameron Dawson <br />
'''IRC:''' #treeherder (emorley or camd)
 
'''Overview:'''
 
[[EngineeringProductivity/Projects/Treeherder|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:
 
# 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
 
# 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:''' [https://mozillians.org/en-US/u/ianbicking/ Ian Bicking] <br />
'''IRC:''' ianbicking (usually online 8am-3pm Pacific time) <br />
'''IRC channel:''' [https://kiwiirc.com/client/irc.mozilla.org/screenshots #screenshots]
'''Status:''' it seems like we have quite a few potential applicants, you might want to consider looking at other projects
 
'''Project Description:'''
[https://github.com/mozilla-services/screenshots/ 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 [https://github.com/mozilla-services/screenshots/ 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 [https://kiwiirc.com/client/irc.mozilla.org/screenshots IRC channel] so we can help get you setup and improve the experience for future people.  We have a [https://github.com/mozilla-services/screenshots/labels/good%20first%20bug 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:'''[https://mozillians.org/en-US/u/linclark/ Lin Clark] <br />
'''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:''' [https://mozillians.org/en-US/u/arroway/ Stéphanie Ouillon] <br />
'''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 https://wiki.mozilla.org/SecOutreachy]
 
====Implement Telemetry health ping====
'''Mentor:''' [https://mozillians.org/en-US/u/gfritzsche/ Georg Fritzsche] <br />
'''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 [[Telemetry/Outreachy:HealthPing|project page]].
 
====Improve cross-browser and functional testing for webcompat.com====
'''Mentor:''' [https://mozillians.org/en-US/u/miketaylr/ 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). <br />
'''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. [https://github.com/webcompat/webcompat.com/ Clone the repo]
  2. [https://github.com/webcompat/webcompat.com/blob/master/CONTRIBUTING.md Set up a local development environment]
  3. [https://github.com/webcompat/webcompat.com/blob/master/CONTRIBUTING.md#running-tests Get functional tests running locally]
  4. [http://github.com/webcompat/webcompat.com/issues/new 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:''' [https://mozillians.org/en-US/u/johannh/ Johann Hofmann] <br />
'''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:
* Get Firefox up and running (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build)
* Find a bug to work on (https://www.joshmatthews.net/bugsahoy/?ff=1&unowned=1&simple=1)
* Leave a comment that you want to be assigned and ask about anything that is unclear to you
* Submit your patch (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch)
 
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:''' [https://mozillians.org/en-US/u/jdm/ Josh Matthews] <br />
'''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:
 
*  clone and build the code (https://github.com/servo/servo/)
*  find an issue that looks interesting (https://starters.servo.org)
*  leave a comment stating that you're working on it, and ask any questions necessary to make progress
*  introduce yourself on IRC (https://wiki.mozilla.org/IRC in #servo) or on the mailing list (https://groups.google.com/forum/#!forum/mozilla.dev.servo)
 
====Automate web accessibility testing====
'''Mentor:''' [https://mozillians.org/en-US/u/mbrandt/ Matt Brandt] <br />
'''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:''' [https://mozillians.org/en-US/u/brson/ Brian Anderson] <br />
'''IRC:''' brson
 
'''Project Description:'''
[https://www.rust-lang.org 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 [http://webassembly.org/ 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:''' [https://mozillians.org/en-US/u/nmatsakis/ Nicholas Matsakis] <br />
'''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:''' [https://mozillians.org/en-US/u/seanmonstar/ Sean McArthur] <br />
'''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:''' [https://mozillians.org/en-US/u/emceeaich/ Emma Humphries] <br />
'''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
 
[https://bugzilla.mozilla.org/buglist.cgi?keywords=good-first-bug%2C%20&keywords_type=allwords&resolution=---&query_format=advanced&product=bugzilla.mozilla.org See our list of Good First Bugs for bugs to attempt as part of application].
 
====Upgrade ActiveData to use Elasticsearch v5+====
'''Mentor:''' [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski] <br />
'''IRC:''' ekyle
 
[https://github.com/klahnakoski/ActiveData/blob/dev/docs/Outreachy%20Proposal.md LIVE DOCUMENT WITH ANSWERS]<br />
 
'''Project Description:'''
''About ActiveData'' <br />
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'' <br />
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'' <br />
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''<br />
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''<br />
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''<br />
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''<br />
1. Similar project for smaller data: [Mapping JSON to strict DB schema](https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md) <br />
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/) <br />
3. [data cubes](https://en.wikipedia.org/wiki/OLAP_cube) <br />
4. [fact tables](https://en.wikipedia.org/wiki/Fact_table) in a [data warehouse](https://en.wikipedia.org/wiki/Data_warehouse).<br />
5. [MDX](https://en.wikipedia.org/wiki/MultiDimensional_eXpressions). <br/>
 
====Upgrade Lightbeam====
'''Mentor:''' [https://mozillians.org/en-US/u/pauljt/ 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.<br>
 
See the [[User:Ptheriault/Outreachy2017|getting started guide here.]]
 
====Improve DevTools Network Monitor====
'''Mentor:''' [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko] <br />
'''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: [https://mozillians.org/u/gijs/ Gijs Kruitbosch] <br />
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: [https://mozillians.org/en-US/u/kumar/ Kumar McMillan] <br />
Participants: [https://mozillians.org/en-US/u/sj/ Shubheksha Jalan] and Elvina Valieva <br />
[https://medium.com/@shubheksha Shubhesksha's Blog] <br />
[https://saintsebastian.github.io/ Elvina's Blog] <br />
 
[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 will 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]. [https://github.com/mdn/webextensions-examples/issues/97 More info].
* 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. [https://github.com/mozilla/web-ext/issues/142 More info].
* 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]. [https://github.com/mozilla/web-ext/issues/539 More info].
* 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. [https://github.com/mozilla/web-ext/issues/540 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. [https://github.com/mozilla/web-ext/issues/497 More info].
 
====Build a Library of Inclusion Best Practices and Case Studies====
Mentors: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro] and [https://mozillians.org/en-US/u/lmn/ Lizz Noonan] <br />
Participants: Bee Padalkar, [https://mozillians.org/en-US/u/kristi.progri/ Kristi Progri], and Nasma Ahmed <br />
[http://networksfordata.wordpress.com/ Bee's Blog] <br />
[http://kristiprogri.com/ Kristi's Website] <br />
[http://www.nasmaahmed.ca Nasma's Website] <br />
 
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: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] <br />
Participant: Divya Biyani <br />
[http://divyabiyani.strikingly.com/ Divya's Website] <br />
 
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: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]
 
==== Add support for OpenAPI to Kinto ====
 
Mentors: [https://mozillians.org/en-US/u/ethan.glasser.camp/ Ethan Glasser-Camp] and [https://mozillians.org/en-US/u/natim/ Rémy Hubscher] <br />
Participants: Mansimar Kaur and Gabriela Surita <br />
[http://mansimar.com Mansimar's Website] <br />
 
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: [https://mozillians.org/en-US/u/jhford/ John Ford] <br />
Participant: Elena Solomon <br />
[https://gabsurita.wordpress.com 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 [https://www.npmjs.com/package/azure-entities '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 [https://github.com/taskcluster/aws-provisioner/blob/master/src/container.js already been done].  This project's participants will 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]. 
<br />
 
We specifically would like to have the following:
<br />
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 <br />
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 <br />
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 <br />
4. Stretch goal of adding SAS for Blob storage to our [https://github.com/taskcluster/taskcluster-auth authorization service] <br />
 
==== Improve Template Logic for Taskcluster-Github ====
 
Mentor: [https://mozillians.org/en-US/u/bstack/ Brian Stack] and [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] <br />
Participant: [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko] <br />
 
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.  <br />
 
It is a collection of smaller projects:<br />
* 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. <br />
* 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. <br />
* 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: [https://mozillians.org/en-US/u/astevenson/ Adam Stevenson] <br />
Participant: Mesha Lockett <br />
[http://meshalockett.com/ Mesha's website]<br />
 
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: [https://mozillians.org/en-US/u/camd/ Cameron Dawson] <br />
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 [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==
Outreachy Round 13 applications have closed, but we encourage you to apply to the next round of projects in April. <br />
 
Got Questions? Ask:
* Outreachy Coordinator: [https://mozillians.org/en-US/u/lmn/ Lizz Noonan]
* IRC: #outreachy
 
=Past Outreachy/OPW internships=
 
{{#subpages:}}
 
==Complete List of Participants==
===ROUND 12===
====Ana Ribero====
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]
* Project: Enhancements to Python testing tool plugin for generation of HTML reports
* [https://mozillians.org/en-US/u/anaribeiro/ Mozillians Profile]
* [http://outreachy.anaplusplus.com/ Participant Blog]
 
====Rakhi Sharma====
* Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]
* Project: Make Firefox look great on desktop!
* [https://mozillians.org/en-US/u/Rakhi/ Mozillians Profile]
* [http://rakhish.wordpress.com/ Participant Blog]
 
====Manel Rhaiem====
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
* Project: Project SmartHome prototyping
* [https://mozillians.org/en-US/u/Mermi/ Mozillians Profile]
* [mermi.xyz Participant Blog]
 
====Deepthi Venkitaramanan====
* Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
* Project: Webcompat.com Web Application Engineer
* [https://mozillians.org/en-US/u/venkid/ Mozillians Profile]
* [http://venkid.com/portfolio.html#Outreachy Participant Blog]
 
====Benjamin "Benny" Forehand, Jr.====
* Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC
* Project: Convert Mozmill tests to Marionette
* [https://mozillians.org/en-US/u/bennyjr35/ Mozillians Profile]
* [https://www.bennyjr.xyz/blog and https://benjaminfjr.blogspot.com/ Participant Blog]
 
====Ipsha Bhidonia====
* Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
* Project: Realtime Push Notifications for Kinto
* [https://mozillians.org/en-US/u/ipsha21/ Mozillians Profile]
* [https://ipsha218.wordpress.com/feed/ Participant Blog]
 
====Anjana Vakil====
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
* Participant: Test-driven Refactoring of Marionette's Python Test Runner
* [https://mozillians.org/en-US/u/vakila/ Mozillians Profile]
 
====Rutuja Surve====
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
* Project: Content Process Management Tool
* [https://mozillians.org/en-US/u/Rutuja/ Mozillians Profile]
* [https://rutujasurveblog.wordpress.com/2016/05/17/outreachy-2016-my-first-post/ Participant Blog]
 
====Andrea Del Rio Lazo====
* Mentors: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] and [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell] <br />
* Project: Taskcluster tools UI/UX improvements
* [https://mozillians.org/en-US/u/andreadelrio/ Mozillians Profile]
 
====Kristel Teng====
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack] <br />
* Project: Automation of Taskcluster Documentation
* [https://mozillians.org/en-US/u/kt/ Mozillians Profile]
 
====Katie Broida====
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
* Project: Fixing some papercuts in the Firefox desktop user interface
* [https://mozillians.org/en-US/u/kbroida/ Mozillians Profile]
* [http://blog.katiebroida.com/ Participant Blog]
 
====Decky Coss====
* Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
* Project: Web Platform Test Crime Scene Investigation
* [https://mozillians.org/en-US/u/deckycoss/ Mozillians Profile]
* [http://cosstropolis.com/blog/ Participant Blog]
 
====Jen Kagan====
* 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) <br />
* Project: Prototype new Firefox features with the Test Pilot team
* [https://mozillians.org/en-US/u/kaganjd/ Mozillians Profile]
 
===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===
== Past Outreachy/OPW Rounds ==


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


Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk
{{#subpages:Outreachy/Round}}

Latest revision as of 20:22, 27 May 2021

Mozilla has participated in the Outreachy program since January 2013. The goal of the program is to increase participation from under-represented groups in free and open source software. It is a project of the Software Freedom Conservancy.

Mozilla hosts approximately 20 participants across two cohorts (summer and winter) each year. Mozilla employees work 1:1 with participants for three months. The program expressly invites women (both cis and trans), trans men, and genderqueer people to apply. It also expressly invites applications from residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. Anyone who faces under-representation, systemic bias, or discrimination in the technology industry of their country is invited to apply.

Current Round

Round 22 (May-August 2021) is the current round.

Participant Application Process

First, please review the Outreachy Eligibility and Application Information page to learn more about eligibility for Outreachy.

Steps for applicants to Mozilla:

  1. Confirm your eligibility on the outreachy site
  2. Look at the Mozilla projects available on the Outreachy site, consider your options, and if you have questions communicate with the project mentors. Of course, you are welcome to apply for non-Mozilla projects you find on the site as well! You can communicate with other applicants, mentors, and coordinators in #outreachy on chat.mozilla.org.
  3. Begin by contributing to the project. Most projects will describe how to make your first contribution. As you make contributions, record them in the Outreachy site. Codetribute may help you find good tasks to work on. For many applicants, this is the most valuable part of the experience!
  4. Once you have made a few contributions, begin to write your application. Ask the mentors to review the application before you submit it.

Participant Expectations

You will be working full-time on your project for three months. You will meet with your mentor(s) frequently and participate in the open-source development process -- writing code, reviewing code, testing, and so on. You will be expected to write a blog entry each week.

Mentor / Project Applications

Mentors submit projects that they are willing to mentor. Here's what you need to know:

  • The participant will be working full-time, spending 40 hours a week on their project for three months. Participants will work remotely from home. Your project must be something the participant can do remotely and complete within those months. You will need to meet at least weekly with your participant, and be available for questions, code review, and so on throughout the internship.
  • You will be heavily involved in the selection process for your mentee which will involve interviewing, reviewing code check-ins / bug reports / trial work.
  • During the application process, applicants will be expected to make contributions, so make sure you have established a system for new contributors to get involved and have enough good starter tasks for them.
  • Speak with your manager to check it’s OK for you to submit a project proposal. Each participating organization will need to provide budget for the participant costs of $6500. The Mozilla coordinators can help connect you with that budget.
  • To maximize the number of applicants to your project, submit it as early in the process as possible.
  • More FAQ's on the Outreachy Site

Help!

Questions? Ask:

Links

Past Outreachy/OPW Rounds

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