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
* https://www.outreachy.org/ -- main Outreachy site
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]
== Outreachy Rounds 16 and later ==
As of round 16, all Outreachy projects are tracked at [https://www.outreachy.org/ the Outreachy Site].
==Outreachy Program Cohort: Round 15 (December 2017 - March 2018)==
===JSON-e Everywhere===
'''Mentor:''' [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] <br />
'''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 <br />
'''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====
* 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
====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
'''
For more information about this project, please see the [https://github.com/rpl/contribute-firefox-webextensions-apis FAQs]!'''
=== Treeherder ===
'''Mentor:''' Ed Morley and Cameron Dawson <br />
'''IRC:''' #treeherder
'''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 ==
# 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.
* 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=== ===Rounds = Lauren Conrad ==== Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad] Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!) Mentor: Joni Savage "I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world." Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers] Project blog: [http://www.laureneconrad.com www.laureneconrad.com] ==== Roxana Ilie ====Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie] Based in: Bucharest, Romania Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus] "I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox." Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler] ==== Richa Rupela ==== Participant: Richa Rupela Based in: Bikaner, Rajasthan, India Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren] "Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!" Richa's project blog: https://richarupela.wordpress.com/ Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!] ==== Shweta Oak ====Based in: Mumbai, India Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau] "I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people." [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable] ==== Jullie Utsch ====Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch] Based in: Belo Horizonte - MG Brazil Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall] “What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)” Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data] ==== Cynthia Anyango ====Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]Based in: Nairobi , Kenya Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen] "I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better" Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)] ==== Nikki Bee ====Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee] Based in: Alberta, Canada Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews] "I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla." Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard] ==== My Lê ==== Based in: Paris - France Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez] "Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web." Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation] ===ROUND 10=== https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson ===ROUND 9=== https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene ===ROUND 8=== https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro ===ROUND 7=== https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia ===ROUND 6=== https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations coordinators: Selena Deckelmann and Liz Henry Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry ===ROUND 5=== https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations
Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk{{#subpages:Outreachy/Round}}
