Outreachy/2014/December to March: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Ckoehler moved page GNOME OPW/2014/December to March to Outreachy/2014/December to March: GNOME OPW program has been re-named to Outreachy.)
(Redirected page to Outreachy/Round/7)
 
Line 1: Line 1:
=Outreach Program For Women 2013=
#REDIRECT [[Outreachy/Round/7]]
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 [https://live.gnome.org/OutreachProgramForWomen 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 [https://mozillians.org/en-US/u/tjc/ 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: [https://mozillians.org/en-US/u/tjc/ 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 [https://github.com/mozilla/rust/wiki/Note-development-policy code of conduct] to encourage inclusion and openness.
 
* [http://rust-lang.org/ Home page]
* [http://static.rust-lang.org/doc/master/tutorial.html Tutorial]
* [https://github.com/mozilla/rust/wiki 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 [https://mozillians.org/en-US/u/tjc/ emailing Tim directly]. We are also open to suggestions if you have a particular project in mind (for guidance, look at the [https://github.com/mozilla/rust/issues Rust issue tracker] and the [https://github.com/mozilla/rust/issues?labels=A-an-interesting-project&state=open 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 [http://llvm.org/ 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: [https://mozillians.org/en-US/u/lbergstrom/ Lars Bergstrom] and [https://mozillians.org/en-US/u/metajack/ Jack Moffitt] (and possibly other mentors to be determined)
 
Servo is a prototype Web browser engine currently being implemented in Rust by members of [http://mozilla.com/research 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: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro] (and possibly other mentors to be determined)
 
Background:
* [https://wiki.mozilla.org/Contribute/ 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: [https://mozillians.org/en-US/u/anaaktge/ 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 [http://wiki.mozilla.org/IRC 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.
* [https://mail.mozilla.org/listinfo/rust-dev rust-dev] is the mailing list for Rust discussion.
* [https://lists.mozilla.org/listinfo/dev-servo dev-servo] is the mailing list for Servo discussion.
* [https://mail.mozilla.org/listinfo/community-building 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 [http://mozillians.org/ Mozillians profile] (and a Persona)
* Get a [http://bugzilla.mozilla.org/ Bugzilla] account
* For Rust or Servo, please create a [https://github.com/ 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 [http://github.com/ Github]. If you've used other version control systems but not git, [http://geekchick77.dreamwidth.org/2360.html 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 [https://github.com/mozilla/rust/issues 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 [https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors guide for new contributors] and the [https://github.com/mozilla/rust/wiki/Note-development-policy 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 [https://github.com/mozilla/rust/issues?direction=asc&labels=E-easy&sort=updated&state=open 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====
* [https://github.com/mozilla/rust/issues/8767 #8767], improving an error message about defining methods on a non-existent type
* [https://github.com/mozilla/rust/issues/8763 #8763], similar to #8767
* [https://github.com/mozilla/rust/issues/1433 #1433], implementing hexadecimal floating-point literals
* [https://github.com/mozilla/rust/issues/2252 #2252], bounds checking for floating-point literals
* [https://github.com/mozilla/rust/issues/7743 #7743], make lifetime variables ```name```s and not ```ident```s
 
====Lint====
* [https://github.com/mozilla/rust/issues/1766 #1766], add warning about re-defining the names of built-in types
* [https://github.com/mozilla/rust/issues/6600 #6600], adding a warning pass for empty destructors and replacing existing code that uses empty destructors with the ```NonCopyable``` trait
* [https://github.com/mozilla/rust/issues/4639 #4639], adding a warning for patterns that bind variables that have the same name as an ```enum``` variant
====Libraries====
* [https://github.com/mozilla/rust/issues/2181 #2181], adding a method to return system hardware information
* [https://github.com/mozilla/rust/issues/6101 #6101], writing a version of ```std::os::glob``` that doesn't allocate memory
* [https://github.com/mozilla/rust/issues/8635 #8635], adding a hybrid unbounded integer type to the standard library
* [https://github.com/mozilla/rust/issues/6085 #6085], making standard library functions take Rust types instead of C types
* [https://github.com/mozilla/rust/issues/5283 #5283], making ```std::hashmap``` use ```TotalEq```
* [https://github.com/mozilla/rust/issues/5568 #5568], adding ```find_or_insert``` method for ```Map```s
* ''Larger project'': [https://github.com/mozilla/rust/issues/6220 #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====
* [https://github.com/mozilla/rust/issues/9694 #9694], adding benchmarks for ```std::path```
* [https://github.com/mozilla/rust/issues/3965 #3965], enabling Rust regression tests that are currently disabled (for this bug, pick 1 to 3 tests -- don't try to do them all!)
* [https://github.com/mozilla/rust/issues/2776 #2776], adding more shootout benchmarks (pick one)
 
===Contributions for Servo===
Similarly to Rust, [https://github.com/mozilla.servo Servo] is hosted on [http://github.com/ 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:
# [https://help.github.com/articles/set-up-git Create] a GitHub account
# [https://help.github.com/articles/fork-a-repo Fork] the Servo project
# Use git to clone the project locally, [https://github.com/mozilla/servo/blob/master/README.md build it], and verify that it works on your machine.
# Look at the list of issues marked [https://github.com/mozilla/servo/issues?labels=E-easy&page=1&state=open Easy] to see if anything appeals to your interests.
# Log in to #servo on [https://wiki.mozilla.org/IRC 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.
# Submit a [https://help.github.com/categories/63/articles Pull Request]! Per our [https://github.com/mozilla/servo/blob/master/CONTRIBUTING.md 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 [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro].
 
===Contributions for Firefox for Metro===
* Get a bugzilla account & irc program (the team runs on [https://wiki.mozilla.org/IRC irc.mozilla.org] )
* Sign into #windev (wave hi to :ally)
* Set up in general, [https://developer.mozilla.org/en-US/docs/Windows_8 set up], pull Mozilla Central, & build your copy of Firefox
* Set up  for metro, [https://wiki.mozilla.org/Firefox/Windows_8_Integration#Building_Locally 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.

Latest revision as of 21:10, 22 June 2018

Redirect to:

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