Outreachy/2015/December to March

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Note: This is the page for December 2014 through March 2015--not December 2015 through March 2016

The Outreachy session for this period has ended already.

Overview

APPLICATIONS ARE NOW CLOSED However, if you have an application submitted you can still continue to contribute. Mentors will make their decisions on October 25 and finalize it on October 31 which means you can still contribute and/or finish something you started but didn't have time to finish.

This is the landing page for the December 9, 2014 to March 9, 2015 round of FOSS OPW, organized by GNOME Foundation.

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

Important Dates

• Application deadline: 22 October 2014 at 19:00 UTC.
• Announcement of accepted applicants: 12 November 2014 at 19:00 UTC via the main program page.

Projects

(Mentors: add your projects below.

SUMO/Input Web Designer/Developer (SUMO/Input Engineering Team)

Mentor: Will Kahn-Greene

Details

SUMO is the support site for Mozilla products. It helps millions of users every week through a knowledge base and support forum. It also provides collaboration and localization tools for the contributors. It uses technology like Python, Django, MySQL, Redis, Memcached, Elasticsearch and more.

Input is one of several tools the Mozilla community uses to gather user sentiment on Mozilla products. This data helps us track down problems, guide new development and generally make Mozilla products better for users using them.

Work with the engineering team of both sites to make them better which in turn helps us serve Mozilla product users and contributors in the best way possible.

The two sites have similar architectures. They're both written primarily in Python/Django on the backend and JavaScript/HTML/CSS on the front end. We use MySQL and Elasticsearch for data storage. They both use GitHub for code management and version control and Bugzilla for issue tracking. They both use a variety of libraries which we contribute to as well.

You'll be working with Will, the primary developer on Input and one of the developers on SUMO to work on SUMO and Input. You'll be contributing code, reviewing pull requests, and working with developers. You'll be involved in our regular meetings and development cycle.

To get started on Input:

• Read the Input project page
• Join us! Work through our Join this project chapter which includes joining the Input development mailing list and joining the #input channel on irc.mozilla.org
• Check out Input and leave a piece of feedback
• Work through our Getting started guide which will walk you through setting up a Fjord development environment for Input development
• Pick a bug that you think you can do from the list on the bottom of our GetInvolved page and ask in the comments to have it be assigned to you

Kinto — Make instances discoverable

Mentor: Alexis Métaireau

Details

The Kinto project aims to bring storage instances to everyone, attached to their 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 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 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 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 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 the kinto documentation, especially tutorials
• Join us! Work through our communication channels chapter which includes joining the Kinto development mailing list and joining the #storage channel on irc.mozilla.org

SUMO - Work on a tutorial or training tool for new technical writers

Mentor: Joni Savage

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. Here’s where you come in.

SUMO is looking for someone with an interest in storytelling, teaching, writing, design or video to help us transform our lengthy training documents into fun, interactive and effective training tools to empower new contributors who have a wide range of skills.

You will work closely with Joni, the content manager, along with our community to brainstorm learning activities, create storyboards and outlines for training guides, design and research interactive and intuitive contributor tools, and write friendly and effective copy. Got additional ideas? We’d love to hear those too.

To get started:

1. Look through this page.
2. Get in the mindset of a new contributor. Pick out what you think is important information from the page in step #1 and turn it into a mini tutorial (or an outline for a tutorial). This can be an infographic, video, slideshow, storyboard or any format of your choice.
3. Send your tutorial or storyboard to Joni Savage along with an explanation.