Outreachy/2016/December to March: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Tighten it up a bit.)
(Redirected page to Outreachy/Round/11)
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Projects for Outreachy December 2015 to March 2016 =
#REDIRECT [[Outreachy/Round/11]]
 
== Key Dates ==
* September 29 application process opens
* November 2 application deadline
* November 17 accepted applicants announced (Mozilla intends to announce earlier due to travel and hardware logistics)
* December 7 - March 7 internship dates
 
== Application Process ==
 
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.
 
== Projects ==
 
===Battery Friendly Platform Networking Deadline Scheduler===
 
Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]. Pat is the gecko networking module owner and has been hacking on the Firefox networking stack for the last 7 years. He believes that more diversity in our development ranks will help us be more creative about driving the web and Firefox forward.
 
====Details====
Battery performance for networking is strongly influenced by the number of times the radio is brought into a higher powered state for transmission. Data that is batched together minimizes the number of power-up events and extends battery life. Normally HTTP requests are dispatched as soon as possible, but by strategically delaying ones that do not have an impact on user interaction this batching can be achieved.
 
The Intern will add an optional deadline parameter to the Gecko networking interface. Callers that specify a deadline allow their transactions to be delayed for some period of time in order to coalesce and intelligently schedule it with other resource events. The navigator Beacon API is a an obvious candidate to use this functionality.
 
The intern needs to be familiar with C++ for the platform code, and some exposure to javascript for the test infrastructure would also be helpful.
 
To get started
* Build [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions firefox] for desktop
* Find the w3c [http://www.w3.org/TR/beacon/ beacon] [https://mxr.mozilla.org/mozilla-central/source/dom/base/Navigator.cpp#1195 code] in gecko
* Be prepared to talk about making a patch to that code using the [https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsIHttpChannelInternal.idl nsIHttpChannel] xpcom interface to print the beacon remote IP address that is used.
* ask questions on irc, either in #outreachy or #necko - the mentor's nick is mcmanus
 
===Enumerate (and Dockerize) the tests! (Quality Assurance) ===
 
Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen] has a knack for hanging around with people who are making the world a better place, so it's really no surprise that he wound up at the Mozilla. A colleague said of him once: "We were changing the world before changing the world was cool." From helping to provide the first free UNIX services to students at UC Berkeley, to bringing the most effective HIV-prevention programs in San Francisco to the Web, to assisting engineers in designing earthquake-proof buildings, Karl has a fierce commitment to using computers to improve (and sometimes save) the lives of people.
 
====Details====
Our intern would be responsible for helping the team create Dockerfiles and images for as many of the deployment/functional tests as possible, across all of the many repositories Cloud Services QA works with.  Along the way, the intern would help clean up and update documentation, and complete an inventory of all of our repositories and their status (deprecated, active, or healthy) based on how often the tests get run.
 
This project would require the intern to take a short tutorial in how Dockerfiles are prepared, but no previous Docker experience would be necessary.  The enumeration part would require the ability to navigate GitHub and a willingness to ask members of the team questions about how and when their tests are running.
 
Also, the intern may wish to run the tests as they are Dockerized, which would require some experience with Docker (and possibly AWS) and some software engineering inclination.
 
=== Kinto — Make instances discoverable ===
 
Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Métaireau]
 
==== Details ====
The [https://kinto.readthedocs.org Kinto project] aims to bring storage instances to everyone, attached to their [https://accounts.firefox.com Firefox Accounts]. It actually supports multiple authentication schemes, but FxA is integrated with it, and that is part of the solution we want to deliver.
 
Currently, Kinto is thought as a centralized server: there is one instance, and everyone authenticates on this instance. Items are shared between users of a same instance.
 
This doesn't resonates well with multiple goals we have: scalability is harder when there is one endpoint, and it's also not interoperable.
 
For instance, imagine Alice and Bob. Bob is using Mozilla's servers to store his data, whereas Alice deployed her own Kinto instance.
 
There are different use cases:
 
* Alice wants to use [https://github.com/leplatrem/routina Routina], an application that stores its data inside a Kinto instance. As such, Routina needs a way to discover where it should store its data, and send the requests to this server;
* Bob and Alice want to collaborate on a set of data (think about a shared expense webapp). There should be a way for Alice to host everything and grant access to Bob to her data. The webapp should be able to use the correct server.
 
Here are the different steps that could allow these scenarios:
 
* At the moment they authenticate, the client detects the email address used, and relies on the domain part to do a [https://tools.ietf.org/html/rfc7033 Web Finger] request on the domain (*) and for the specified user.
* In case the identified server doesn't support WebFinger, it uses a central repository to lookup where the Kinto server is located.
* Once the Kinto server located, all requests should be issued against this server.
 
(*) It is also possible to use the same mechanism to discover the FxA endpoints. But as FxA isn't a federated protocol, users from one FxA realm would need to be accepted explicitely by the Kinto server, in its configuration.
 
In terms of code changes, here is what it looks like (rough step by step):
 
* Update the [https://github.com/kinto/kinto.js Kinto.js client] to find the server location. It should first rely on WebFinger;
* Create a central repository of server locations. This could be contained in the FxA profile server or in a central Kinto collection;
* Update the Kinto.js client to fall-back to this central repository in case no Web Finger exists;
* Investigate on ways to store this information directly in the web browser. It could also be configurable by the JavaScript client (with
an UX that looks like [https://remotestorage.io/ what Remote Storage proposes]).
* Work on the first user experience: how can client learn they can chose which server to use?
* Ship it!
 
To get started on Kinto:
* Read [https://kinto.readthedocs.org the kinto documentation], especially tutorials
* Join us! Work through our [http://kinto.readthedocs.org/en/latest/contributing.html#communication-channels communication channels] chapter which includes joining the [https://mail.mozilla.org/listinfo/kinto Kinto development mailing list] and joining the #storage channel on irc.mozilla.org
 
 
===Open Source Designer, Mozilla Foundation===
 
Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]
 
Ricardo is a UI Designer working at the Mozilla Foundation. He is passionate about extending an open-source design culture to people outside of Mozilla. Ricardo started a YouTube [https://www.youtube.com/channel/UC9MJ2wGfJ_7mbLN6rXjWztA/videos live stream] series earlier this year where he designs with everyone as his audience. Through this pathway, he is able to open Mozilla's open design practice to people around the world. But forget about design, Ricardo is interested in how people think. Growing up around a family of musicians and artists, Ricardo decided to pursue meaning in art. Ricardo is interested in culture, design, aesthetic, wit, reality, existence, history, education, thought, and the happiness of pursuit. He spends his free time rowing in Ontario and hiking in British Columbia.
 
====Details====
At Mozilla Foundation, we spend a lot of our energy promoting web literacy. We’ve been hard at work the past year building innovative tools, supporting communities, teaching, learning, and shaping the environments in which the open web is made possible. We want everyone in the world to create, not just consume, the Web around them.
 
As an Open-Source Designer, the applicant will be immersed in the world of products such as Thimble and Webmaker for Android, communities such as Mozilla Learning Networks and Mozilla Hive groups, and initiatives such as Mozilla Advocacy and Fundraising.
 
The intern will:
 
* Approach design through an iterative process with our growing user base and community
* Design and implement interfaces and collateral work for our products and initiatives
* Illustrate collateral work for our products and initiatives
* Create and conduct user testing research to generate insights of our products
* Bridge the gap between the behaviour we want users to take and the interface that gets them there
* Prototype and implement work using HTML, CSS, and JavaScript
 
====To Get Started====
 
* Do you own an Android device? If so, go ahead and [https://play.google.com/store/apps/details?id=org.mozilla.webmaker download Webmaker]. Give it a spin!
* Head over to [http://thimble.mozilla.org/ Thimble] and create a project. This project can be about what you liked about using Webmaker, or it could also be about a hobby of your own.
* It would be great for you to include any design or illustrations on your Thimble project.
* Send the Thimble Project URL as well as your portfolio of your work to ricardo[at]mozillafoundation[dot]org
* Feel free to say hi on [http://wiki.mozilla.org/IRC IRC] (#foundation) or message me #ricardo
 
===SUMO - Build a tutorial or training tool for new technical writers===
 
Mentor: [https://mozillians.org/en-US/u/jsavage/ Joni Savage] is the content manager for support.mozilla.org (SUMO). Joni works with the community to create and organize support content to help people use Mozilla software successfully. Joni believes that diversity is important in creating useful, engaging and accessible content for all users.
 
====Details====
Mozilla’s Support site (SUMO) provides around-the-clock help for 30 million users a month through thousands of knowledge base articles. We rely on the community to keep the knowledge base up to date with each release. While there’s growing interest in contributing to the knowledge base, there’s also a learning curve. We have training documents, but they’re lengthy and a hassle to work with. Here’s where you come in.
 
About this project:
You will learn the ins-and-outs of writing for the knowledge base, then design materials or tools to motivate and train new contributors. You will work closely with the content manager to survey contributors, determine learning objectives, and research, design and test tools or materials. Depending on your interests, tasks can include: building a course, creating training videos, storyboarding, writing UX copy for tools, designing infographics, and any other ideas you may have. You’ll also learn technical writing fundamentals, wiki markup and search optimization along the way.
 
Skills needed to succeed:
*On the job or academic training in writing, design, marketing, video production, education, or a related field.
*English writing skills.
*Strong research and communication skills.
 
To get started:
#Write a short article or tutorial on how to use a tool of your choice.
#Send your tutorial to Joni Savage at jsavage [at] mozilla [dot] com.
 
=== Servo: Complete implementation of Fetch standard ===
Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]
 
Josh started contributing code to Firefox as a university student, and now helps lead parts of the Servo project. He's very interested in enabling new contributors with no prior web browser development experience to have a big impact on Servo!
 
==== Details ====
[https://github.com/servo/servo/ Servo] is a brand new web rendering engine written from the ground up in [https://rust-lang.org Rust]. This allows us to try implementing old web features in new ways, including the underlying model for performing network requests inside the browser. The [https://fetch.spec.whatwg.org/ Fetch standard] defines a series of steps to ensure proper security checks are  performed when necessary, and we want to try using it everywhere in Servo!
 
A partial implementation of this model already exists in Servo, but there are large pieces missing. You will be responsible for the following:
* integrating our [http://mxr.mozilla.org/servo/source/components/net/http_loader.rs#476 existing network request code] with the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch HTTP-network-or-cache-fetch step] (see [http://mxr.mozilla.org/servo/source/components/net/fetch/request.rs#392 prior art])
* moving [http://mxr.mozilla.org/servo/source/components/script/dom/xmlhttprequest.rs#194 cross-origin security checks] out of callers and into the fetch implementation
* converting existing code that makes network requests to use the new fetch APIs
* writing tests to ensure specification conformance
 
Servo is written almost entirely in Rust; besides some diversions into HTML  and JavaScript for reading and writing tests, this project will require you to work exclusively in the language. Do not fear! We regularly receive contributions from first-time Rust programmers, and it's a great motivator to gain experience in a new low-level language. There will be many opportunities to practice reading, understanding, and refactoring existing code, in addition to writing new implementations when necessary. Furthermore, you will gain proficiency in reading web specifications.
 
What you can do to get involved:
* Clone and build the [https://github.com/servo/servo/ code]
* Find an issue that looks interesting ([https://github.com/servo/servo/issues/ ones with the E-easy label  recommended as a first step])
* Leave a comment stating that you're working on it, then get to work
* Feel free to introduce yourself on [https://wiki.mozilla.org/IRC IRC] (#servo) or on the [https://groups.google.com/forum/#!forum/mozilla.dev.servo mailing list]
 
=== Contribute to the HTML Standard! ===
Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]. I've been working on web standards for a little over a decade and at Mozilla for well over two years. I want to help create a more diverse standards community as that will help us make better standards.
 
====Details====
Help fix bugs in the HTML Standard by editing HTML, reading the HTML standard, testing browsers, and using GitHub.
 
Learn how standards are created, how to resolve technical issues, and help converge implementations by improving the HTML standard.
 
To get started:
 
* Get the [https://github.com/whatwg/html HTML standard from GitHub].
* Get the [https://github.com/whatwg/html-build HTML standard build scripts from GitHub].
* Attempt building it.
* Try fixing one or more of the [https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&list_id=59317&product=WHATWG&status_whiteboard=%5Bgood%20first%20bug%5D&status_whiteboard_type=substring "good first bugs" on Bugzilla] or [https://github.com/whatwg/html/labels/good%20first%20bug "good first bugs" on GitHub]. (The HTML standard is slowly migrating towards GitHub, but many issues are still recorded only in Bugzilla.)
* Create a pull request for your change.
 
If you have any questions, feel free to ask them on [https://wiki.whatwg.org/wiki/IRC IRC (#whatwg, Freenode)]. You can also reach out directly to Anne via IRC or email.
 
===Visual Design with Research Data===
Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall] is a quantitative user researcher in the User Advocacy team. Just as it is necessary for the Advocacy team to listen to feedback from all sorts of users - not just the ones that are similar to us - it is important to include the point of view of diverse researchers with their own ideas, experience, and interests.
 
====Details====
We have a huge opportunity for a lot of unexplored data from various projects to be represented visually, both for research purposes and to be displayed in other parts of the organization. We have data on search, participation in heartbeat surveys, and months and months of telemetry that are rife for exploration. Our ideal candidate would have some coding experience and the desire/ability to learn javascript and the d3 visualization library. Someone with an element of design interest would also be preferred so that we can work on the most effective data vizzes possible. The intern would also have the ability to work on executive-facing work including infographics and slide decks.

Latest revision as of 21:14, 22 June 2018

Redirect to:

Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Outreachy/2016/December_to_March&oldid=1196047"