Outreachy/Round/15

From MozillaWiki
Jump to: navigation, search

Round 15 was from December 2017 - March 2018

Projects

JSON-e Everywhere

Mentor: Dustin Mitchell
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
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

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:Luca Greco with 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:

  • browsingData - an API to remove data from the browser
  • contextMenus - an API to show context sensitive menus in Android
  • history - interaction with the users browser history
  • omnibox - shortcuts in the browser address bar

For more information about this project, please see the FAQs!

Treeherder

Mentor: Ed Morley and Cameron Dawson
IRC: #treeherder

Overview:

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:

  1. 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
  2. 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
Retrieved from "https://wiki.mozilla.org/index.php?title=Outreachy/Round/15&oldid=1196031"