Round 7 was December 2013 - March 2014

Outreach Program For Women 2013

This page contains all the information about the opportunity with Mozilla for the Outreach Program for Women internship that will take place from December 10, 2013-March 10, 2014. Please see the main program page for the general information about the program, such as timeline, background information, eligibility, requirements, and the application form.

We have several mentors this year for our third time participating as a project, and not just a sponsor, in this valuable program.

Requirements

Rust and Servo

Successful candidates for either Rust or Servo will need some previous programming experience. Code will be written primarily in Rust, but previous experience with Rust is not a requirement. Successful candidates will have at least beginner-level proficiency programming in C, as well as some exposure to systems programming (such as having taken an operating systems class in college or having equivalent familiarity from self-study). If you aren't sure whether you have the background we expect, please contact Tim as soon as possible. We'll be happy to talk with you about your background and interests.

OPW interns are expected to spend at least 40 hours a week on their projects. Thus, we cannot accept interns who have another job that will take more than 20 hours a week, or who are taking classes more than half-time. Moreover, interns who have other time commitments will be held to a higher standard in the application process. We think that interns who are able to devote most of their time to the internship will get the most out of it.

Community building

Successful candidates for the community building project will have some previous open source community experience. Familiarity with open source communication tools such as IRC, MediaWiki, and Bugzilla will be extremely helpful.

The ideal candidate will be:

• Enthusiastic about media & open source, with a love for the Web, Mozilla & Firefox
• Will possess exceptional communication & organizational skills
• Has a positive attitude, striving for quality with attention to detail, and willingness to learn
• Is a self-driven team-player, able to multi-task effectively in a fast-paced environment
• Must embrace an environment that is highly transparent and collaborative, with a highly diverse demographic and culture

Project 1: Rust

Mentor: Tim Chevalier (and possibly other mentors to be determined)

Background on Rust

Rust is a statically typed programming language that emphasizes high performance, memory safety, and concurrency. Mozilla is stewarding the development of a compiler, tools, and standard libraries for Rust, all of which are open-source. The Rust community consists of a small number of Mozilla staff engineers in addition to a large and vibrant community of volunteers. The Rust community has a code of conduct to encourage inclusion and openness.

• Home page
• Tutorial
• Rust wiki on github

Specific project ideas

The following are suggested projects related to Rust. We encourage you to discuss the projects with members of the Rust team (Tim - tjc on IRC - can suggest which person knows the most about a particular project), either on IRC or by emailing Tim directly. We are also open to suggestions if you have a particular project in mind (for guidance, look at the Rust issue tracker and the issues tagged as interesting projects).

Project A: Benchmarking for Rust:

https://github.com/mozilla/rust/issues/7532

Rust currently lacks benchmarks that are clearly focused on a single part of Rust's libraries or code generator. Writing benchmarks -- small programs designed to test the performance (primarily use of time and memory) of one component of the Rust toolchain -- is important for improving the performance of the code that the Rust compiler generates.

Rust already has a built-in benchmark runner, making this task easier to get started with. These benchmarks are intended to measure how Rust's performance changes over time -- they are not intended for comparing Rust to other programming languages.

An interested person could write benchmarks that measure any or all of the following: memory allocation with destructors, memory allocation in Rust's garbage-collected heap, pattern matching, numerics, data structures, string manipulation, methods, trait objects (dynamic dispatch).

Project B: Parallel profiling

https://github.com/mozilla/rust/issues/7233

One of Rust's design goals is to support parallel and concurrent programming that's simple and easy to reason about. One of the main reasons to write parallel code is performance: on the surface, it makes no sense to let available resources sit idle while unfinished work remains that they could be doing. But in practice, parallelism also comes with overhead, and it can also be hard to predict whether code that should run in parallel actually does.

Designing and implementing a profiler to assist in writing efficient parallel Rust code is a broad task, but in the near term, a step along the way would be to support "watching" particular tasks, and printing out when those tasks were active and what threads they were active on. This raw data could be processed by another tool to help the user understand how parallel the code actually was.

Project C: Randomized testing for Rust

https://github.com/mozilla/rust/issues/7232

QuickCheck ( http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck ) is a well-known library for Haskell that supports randomly generating many kinds of data structures for use in writing unit tests. (You don't have to have any familiarity with Haskell for this project, though it wouldn't hurt!) This approach has been ported to many other languages, and it would be very useful for Rust to become one of them.

Some previous work on this has been done ( https://github.com/dbp/rust-quickcheck and https://github.com/blake2-ppc/qc.rs ), but work would need to happen to bring it up to the latest version of Rust and to make it production-ready. Completing this project could potentially improve the quality of test coverage for Rust's standard libraries.

Project D: Systematic testing of Rust concurrency primitives

https://github.com/mozilla/rust/issues/6957

Rust has various low-level building blocks for concurrency, such as task spawning, scheduling, pipes, and automatically reference-counted data structures. There are various interesting approaches to testing concurrency libraries; one is to implement a system that systematically explores the state space of possible test executions (that is, combinations of choices that the task scheduler could make). This is an open-ended and research-level project. See the github issue for more details.

Project E: Disassembly and examination for compiled Rust libraries

https://github.com/mozilla/rust/issues/6912

On Unix-like systems, the binutils tools (e.g. ar, nm) are well-known, and Mac OS has objdump as an equivalent. We would find it useful to have versions of these tools that are specialized to libraries that were known to be compiled from Rust. These tools would be useful for compiler implementors trying to improve the performance of generated code. The project would probably involve taking advantage of existing libraries that are part of LLVM.

Project F: An efficient B-tree library for Rust

https://github.com/mozilla/rust/issues/4992

A B-tree is one kind of balanced binary tree. Some work has been done already on implementing a B-tree library for Rust, but the problem would involve making it production-ready, including writing unit tests and ideally, real benchmarks that use the B-tree.

Project G: Test coverage data

https://github.com/mozilla/rust/issues/690

Code coverage tools like gcov are helpful in understanding how many possible code execution paths a given test suite actually exercised. Rust currently has no integration with gcov or any other coverage tools. The project would involve modifying the Rust compiler to add a flag that, if it's enabled, means the compiler would insert special code into generated executables to record coverage information. Rust's debug info facilities have been improved a lot in the past few months, making this project easier to approach.

Project H: Fuzz testing with fault injection

https://github.com/mozilla/rust/issues/2736

Fuzz testing is the art of generating random input to find bugs in programs. The subtlety comes in when you try to generate the random inputs in a way that's distributed so as to find as many different bugs as possible.

Rust has a fuzz testing tool already, but it hasn't been maintained in quite some time and can't be used with modern Rust. The beginning of the project could involve resurrecting this tool and making it usable with Rust 0.9. Once that work was done, ideally the project would involve implementing fault injection in order to test how concurrency libraries handle task failure at arbitrary times.

Project I: Cross-language inlining

https://github.com/mozilla/rust/wiki/Mixed-language-link-time-optimization

Rust supports interoperability with C (and potentially C++) using its foreign function interface (FFI). Inlining is an important compiler optimization that involves replacing a function call with a copy of the body of the function. Typically, compilers only inline within code that's written in the same language. Because Rust uses LLVM as its back-end, it would be relatively straightforward to take advantage of some LLVM features to achieve inlining from code generated by the Rust compiler into C code, or vice versa. This is an example of link-time optimization.

LLVM implements much of what's needed already, so the project would consist of putting the pieces together, as well as writing relevant benchmarks and profiling the resulting code.

Project 2: Servo

Mentors: Lars Bergstrom and Jack Moffitt (and possibly other mentors to be determined)

Servo is a prototype Web browser engine currently being implemented in Rust by members of Mozilla Research, as well as volunteers. One of the goals of Servo is to explore how Web browsers can take advantage of modern multi-core computers.

Specific project ideas

Project J: Performance analysis against Firefox and Gecko

In Servo, we want to be able to compare the time it takes us to lay out and render a page against the Firefox engine, Gecko. To do that properly, we need to report the same events and timings in the same way. This project entails learning how to profile the display of web pages in Gecko, instrumenting Servo with similar reporting, and helping to generally build up the Servo performance infrastructure and benchmarking suite.

Project K: Multi-platform windowing system support

Currently Servo runs on Linux, OSX, and Android. We use both the new GLFW and old GLUT to access the windowing systems on these platforms, as GLFW does not yet fully support Android. This project would involve adding support to the GLFW project to target Android devices and integrate that support into the glfw-rs Rust bindings and ultimately Servo.

Project L: Fixed Positioning

We need support for the CSS `position: fixed` property which fixes elements relative to the viewport. This would entail created a new layer in the display list for the fixed elements, and then support in the compositor for placing the fixed layer in the viewport always as the other layers scroll.

Project M: Graphical Overlays for Debugging

It would be useful to have graphical overlay layers that showed debugging information. One example would be the current frames per second of the compositor. Another would be to demarcate tile boundaries. Yet another is to show how the flow tree relates to what is on screen. This would involve a little bit of graphics code to draw the overlay plus digging up useful information that we already have available and showing it.

Project 3: Community Building

Mentor: Larissa Shapiro (and possibly other mentors to be determined)

Background:

• Contribute Wiki

Details

Mozilla is a proudly non-profit organization dedicated to keeping the power of the Web in people’s hands. We’re a global community of users, contributors and developers working to innovate on your behalf. When you use Firefox, or any Mozilla product, you become a part of that community, helping us build a brighter future for the Web.

The Community Building Coordinator will be an integral part of Mozilla's community building strategy in 2013 as we build out the capabilities to support local community building efforts in strategic regions around the world.

Interns will gain experience working in a cross-functional team that touches all points of the organization and project. Interns will also gain experience with growing a world wide community of volunteers, creating scalable processes, and distributing knowledge in a decentralized and multilingual environment.

Specific work may include but is not limited to:

• Interviewing members of contributor communities
• Coordinate among stakeholders to capture, create, and organize supporting material
• Create a contribution funnel toolkit that may include documentation, templates, videos, design files, and other assets
• Promotion of guide to relevant audiences
• Research on contributor development strategies in other organizations

Project 4: Firefox for Metro

Mentor: Allison Naaktgeboren(Firefox Developer, :ally on irc)

• Firefox for Metro, the Windows 8 tablet UI, is the latest addition to the Firefox family and the first touch centric browser. Windows 8 is one of the fastest growing segments of the Firefox population.

Project A: Development

• Help us ship the 1.0 of Firefox for Metro!
• Ship a significant feature in the UI, such as:
  • Enable add-on support in Metro, a high visibility feature
  • Design & build a new bookmarks management, or new ways for users to save stuff for later
  • Implement Private Browsing
• Requires access to a Windows 8 machine

Project B: QA Engineering

• Help us ship a quality 1.0!
• Write test plans for new features
• Test, puzzle out, and break the latest features for the new browser
• Write automated tests & learn the ins & outs of different test suites
• Access what is missing in the current test coverage
  • and develop a plan to fix it
• Puzzle out bugs, pain points
• Requires access to a windows 8 machine

Communications

• #opw on irc.mozilla.org (please ping tjc with questions so we know you're there)
  • For more information on getting on IRC, check out this tutorial
• #rust on irc.mozilla.org is the general Rust development and discussion channel -- it's a friendly place!
• #servo on irc.mozilla.org is where the Servo developers are.
• #mozillians on irc.mozilla.org is where Community Builders talk.
• #windev is where the Metro/Windows team talks.
• rust-dev is the mailing list for Rust discussion.
• dev-servo is the mailing list for Servo discussion.
• community-building is the mailing list for Community Building discussion.
• metro@mozilla.org is the mailing list for Windows Metro discussion

First Contribution(s)

Start with these

• Create a Mozillians profile (and a Persona)
• Get a Bugzilla account
• For Rust or Servo, please create a Github account if you don't have one already.

Contributions for Rust

We use the git version control system for Rust, and Rust's code repository and issue tracker are hosted on Github. If you've used other version control systems but not git, this post may be helpful. If you've never used a version control system before, you will want to educate yourself about the basics of how they work.

For your first contribution, pick a bug from the issue tracker to work on, and fix it. Submitting a work in progress is fine, so long as it passes tests. You will want to read both the guide for new contributors and the development policy. The development policy explains the process for submitting a pull request.

All of these bugs were open and not being actively worked on when we made the list on October 16, 2013 -- however, if a bug shows up in Github as "closed" or if there is a recent comment from someone working on it, we recommend that you look for a different bug.

We don't recommend that you pick a bug at random, as some of them require a lot of knowledge about the compiler. We have compiled a list of easy bugs. Even the easy bugs may require a fair amount of knowledge, so we've made the following list of easy bugs that we especially recommend for a new contributor, sorted by category.

We suggest that you pick a bug you might like to work on, then ask on the #opw or #rust IRC channel for advice on how to proceed. Many of these bugs are not self-explanatory and we don't expect you to work on one entirely on your own! Please ask for help; we're happy to give it :-)

Front-end

• #8767, improving an error message about defining methods on a non-existent type
• #8763, similar to #8767
• #1433, implementing hexadecimal floating-point literals
• #2252, bounds checking for floating-point literals
• #7743, make lifetime variables ```name```s and not ```ident```s

Lint

• #1766, add warning about re-defining the names of built-in types
• #6600, adding a warning pass for empty destructors and replacing existing code that uses empty destructors with the ```NonCopyable``` trait
• #4639, adding a warning for patterns that bind variables that have the same name as an ```enum``` variant

Libraries

• #2181, adding a method to return system hardware information
• #6101, writing a version of ```std::os::glob``` that doesn't allocate memory
• #8635, adding a hybrid unbounded integer type to the standard library
• #6085, making standard library functions take Rust types instead of C types
• #5283, making ```std::hashmap``` use ```TotalEq```
• #5568, adding ```find_or_insert``` method for ```Map```s
• Larger project: #6220, implementing an API for converting between numbers and strings (This could be partially implemented, or it could become a project for the whole 3 months.)

Testing and benchmarking

• #9694, adding benchmarks for ```std::path```
• #3965, enabling Rust regression tests that are currently disabled (for this bug, pick 1 to 3 tests -- don't try to do them all!)
• #2776, adding more shootout benchmarks (pick one)

Contributions for Servo

Similarly to Rust, Servo is hosted on Github. In order to work on Servo, you will need to have either a Linux or Mac OSX computer - we do not currently support Windows. The steps for contributing to Servo are:

1. Create a GitHub account
2. Fork the Servo project
3. Use git to clone the project locally, build it, and verify that it works on your machine.
4. Look at the list of issues marked Easy to see if anything appeals to your interests.
5. Log in to #servo on irc.mozilla.org and ask for more clarification or data on a particular issue. The issues are often terse, but there are people available nearly all day who can clarify and help out if you are stuck.
6. Submit a Pull Request! Per our contributing guidelines, put an "@GITHUB-NAME" for the corresponding reviewer that you spoke with about this project in IRC.

Contributions for Community Building

Visit http://www.mozilla.org/contribute/ and go through the process that new volunteers go through, choose a project, and see what you find interesting. Write up your proposed new project area as though you were a new volunteer, and let us know what the challenges are for you as a hypothetical new volunteer. Submit your proposed project to Larissa Shapiro.

Contributions for Firefox for Metro

• Get a bugzilla account & irc program (the team runs on irc.mozilla.org )
• Sign into #windev (wave hi to :ally)
• Set up in general, set up, pull Mozilla Central, & build your copy of Firefox
• Set up for metro, local build
• Ping :ally or :mbrubeck or :mfinkle in #windev to let us know that you've made it through and talk about next steps.

Selected Projects

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