User Tools

Site Tools


gsoc:google-code-in-2019

Google Code-In 2019

This is our info page for the Google Code-In program in 2019, the contest for 13-17-year-old pre-university students.

Dear students, if you want to participate in this year's Google Code-in, follow the Google's instructions to get registered and to pick up tasks. Read on on this page if you want to do work with on or more work groups of the Linux Foundation during the Google Code-in.

Especially note that the Linux Foundation is an umbrella organization, consisting of many different individual free software projects: The Linux Kernel, OpenPrinting, Automotive Grade Linux, LSB, … So there are very different tasks on offer and it is recommended to concentrate on one or two of these groups when working with the Linux Foundation. See the task examples below and also see the pages of the individual groups for contacting and getting involved with them and for their recommendations.

Dates

  • October 29, 2019 - The Linux Foundation did not get accepted as mentoring organization
  • December 2, 2019 - Contest opens for entries by the students
  • January 21, 2020 - Last day to take a task
  • January 23, 2020 - Contest ends
  • February 10, 2010 - Finalists and winners get announced

If you have questions

Do not hesitate to ask questions. Please use the contact info (e-mail, IRC) of the workgroup in which you want to do your task(s). You find it by following the links below. For general questions about participating as GCI student in projects of the Linux Foundation, join the #linuxfoundation-gsoc channel on Freenode.

Linux Foundation GCI Project groups

The Linux Foundation supports development in different areas. Each area will have a set of Google-Code-In tasks available for this year and you should contact the individual group where you want to work in for further questions about the tasks, mentors, community interaction, …

Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp.

Linux Standards Base (LSB)

Mailing list: lsb-discuss at lists dot linux-foundation dot org

IRC: #lsb on irc.freenode.net

Workgroup Resources

Code License: GPL/BSD, specs: GNU FDL

Mentors: Alexey Khoroshilov (alexey dot khoroshilov at gmail dot com), Jeff Licquia (licquia at linuxfoundation dot org), Vadim Mutilin, Denis Silakov (dsilakov at gmail dot com).

OpenPrinting

Making Printing Just Work

OpenPrinting works on the development of printing technology for Linux and Unix-style operating systems. We collaborate with IEEE-ISTO Printer Working Group(PWG), especially for Internet Printing Protocol(IPP) projects.

Web site: http://www.openprinting.org/

Mailing list: printing-architecture at lists dot linux-foundation dot org

IRC: #openprinting on Freenode

OpenPrinting GitHub

Code License: As the printing-related projects/code bases com from many different origins, there are many different licenses used, as for example (L)GPL, BSD, MIT, Apache, …. See project repositories (Openprinting's own ones on GitHub and/or task descriptions.

Automotive Grade Linux

What is Automotive Grade Linux?

Automotive Grade Linux is a collaborative open source project that is bringing together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies.

Website - www.automotivelinux.org

Wiki – http://wiki.automotivelinux.org

Git - gerrit.automotivelinux.org

Mailing Lists - http://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions

IRC channel - #automotive on freenode

Code Licenses: mostly Apache 2.0, MIT for own code, otherwise as upstream

Primary Mentor contact: jsmoeller (at) linuxfoundation (dot) org

Industrial I/O subsystem (IIO) driver

The main purpose of the Industrial I/O subsystem (IIO) is to provide support for devices that in some sense perform either analog-to-digital conversion (ADC) or digital-to-analog conversion (DAC) or both. The aim is to fill the gap between the somewhat similar hwmon and input subsystems. Hwmon is directed at low sample rate sensors used to monitor and control the system itself, like fan speed control or temperature measurement. Input is, as its name suggests, focused on human interaction input devices (keyboard, mouse, touchscreen). In some cases there is considerable overlap between these and IIO.

Devices that fall into this category include: analog to digital converters (ADCs), accelerometers, capacitance to digital converters (CDCs), digital to analog converters (DACs), gyroscopes, inertial measurement units (IMUs), color and light sensors, magnetometers, pressure sensors, proximity sensors, temperature sensors, etc.

Usually these sensors are connected via SPI or I2C. A common use case of the sensors devices is to have combined functionality (e.g. light plus proximity sensor).

Mentor: Dragos Bogdan dragos.bogdan@analog.com

Sound Open Firmware

Sound Open Firmware is an open source audio DSP firmware and SDK intended to provide a generic audio firmware infrastructure and development tools to the community. The firmware is BSD licensed and is platform and architecture independent.

(from Alsa Project)

Web site: https://www.sofproject.org

GitHub: https://github.com/thesofproject

Mail: sound-open-firmware at alsa-project dot org

Enabling Linux in Safety Applications (ELISA)

To use Linux in high-integrity regulated environment, such as safety-critical systems, security systems or systems subject to other regulatory norms, it requires to show evidences that Linux has a high software quality. High software quality is roughly assessed by two classes of measurements:

  • Observation, Measurement and Assessment of the Software Development Process and Practices
  • Verification, Analysis and Assessment of the Software Artefact

The Google Summer of Code Projects are activities that contribute to those two fields of work.

Primary mentoring contacts: Lukas Bulwahn, lukas.bulwahn at gmail.com; Julia Lawall, julia.lawall at lip6.fr; Nicholas Mc Guire, der.herr at hofr.at; Ralf Ramsauer, ralf.ramsauer at oth-regensburg.de

SPDX

SPDX Introduction
The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the licenses and copyrights for components of a software package.  The vision of SPDX is to achieve software license compliance with minimal cost across the software supply chain with a primary focus on compliance with open source licenses.

The SPDX Technical Team members develop open source tools to create, convert and validate SPDX documents.

SPDX Community
Website - www.spdx.org
Wiki – http://wiki.spdx.org
GitHub
    https://github.com/goneall/SPDX-Tools
    https://github.com/spdx-tools/fossology-spdx
Mailing Lists  
http://lists.spdx.org/mailman/listinfo
http://lists.spdx.org/mailman/listinfo/spdx-tech
IRC channel - #spdx on freenode
Code Licenses: Apache 2.0, BSD 2-Clause

CHAOSS

Community Health Analytics Open Source Software

Web site: https://chaoss.community/

GitHub: https://github.com/chaoss

Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/chaoss

Mentor: (more to come): Matt Germonprez (germonprez at gmail dot com)

Organization Administrators

The participation of the Linux Foundation in the Google Code-In is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com).

Example Tasks

This is a list of some example tasks to get a first impression of what we are offering. The complete range of tasks will appear in the task lists in Google's web app for the students.

OpenPrinting

1. Building and Modifying CUPS

Beginner Task

Categories: Coding, Documentation/Training

This task is to learn about the printing environment and to get familiar with the code.

  1. Build cups after downloading the code from cups.org.
  2. Add a log text in the cups code (prefer adding somewhere close to the entry point)
  3. Fire a print job and have the newly added text get logged in the error log file.

Deliverable: The error_log with the added log message.

2. Graceful/Consistent handling of zero-page jobs

Categories: Coding

cups-filters Issue #117

It does not make much sense to send a file in a printable format but consisting of zero pages to a printer, but such jobs can easily appear, for example using the “page-ranges” option to select certain pages but the input file does not contain enough pages so that not even one page gets selected (like “page-ranges=3-4” on a one-page input file). Also errors in handling a PDF file manipulation utility can produce a PDF file not containing a single page.

If you print such a job the most consistent behavior would be that nothing gets printed on the printer (it is zero pages, not one empty page) and the job is taken from the queue without error.

To achieve this, all filters of cups-filters must behave appropriately, meaning that if the input data has zero pages that the output data must be a valid zero-page file in the output format of the filter and no input data at all needs to be considered as zero pages of input, too. Also a filter which is capable of removing pages from the job, like pdftopdf (this filter implements the above-mentioned “page-ranges” option), needs to output a valid zero-page file if it removes all pages.

The student's task is to take one of the filters which need to get checked for that: rastertopdf, gstopdf, texttopdf, pdftopdf, pdftops, gstoraster, mupdftoraster, gstopxl, rasterto…, foomatic-rip, test them and see whether they behave correctly and fix them if needed.

Deliverable: In case of no fix needed, please comment on the issue report explaining why the filter of your choice behaves correctly, in case of a fix needed, post the fix as a Pull Request in the GutHub of cups-filters.

3. NewBrowsePollQueuesShared option for cups-browsed

Categories: Coding

cups-filters Issue #101

It would be useful to be able to re-export printers discovered by BrowsePoll lines in cups-browsed.conf.

Like for example in a CUPS server connected to various VPNs resharing their printers without specifying them one by one but instead relying on CUPS servers in each VPN having access and sharing the printers at that location automatically.

Maybe the more correct way would be to fiddle with Avahi though… but some “BrowsePoll” lines and a “NewBrowsePollQueuesShared Yes” option in cups-browsed.conf seems much easier.

Deliverable: A Pull Request on cups-filters with the implementation of this feature.

4. Printer Application for Ghostscript's built-in printer drivers

Categories: Coding

Based on and including Ghostscript, foomatic-db (all PPDs for Ghostscript-built-in drivers), and the Printer Application framework.

Deliverable: snapcraft.yaml and build instructions to build the Printer Application

5. Documenting format specification of 'application/vnd.cups-pdf-banner' and features of 'bannertopdf'

Categories: Documentation/Training

cups-filters Issue #77

CUPS on macOS uses a MIME type named application/vnd.cups-banner which is a simple text file format where a few simple keywords define what should be the contents of the banner. Then the filter cgbannertopdf converts that text file and generates a PDF banner page.

The original CUPS MIME type for banner textfiles uses '#CUPS-BANNER' on its first line for recognition.

CUPS provides the exact and complete specification for the format of its banner files here: https://www.cups.org/doc/spec-banner.html

OpenPrinting's cups-filters package does use the MIME type appliation/vnd.cups-pdf-banner and puts #PDF-BANNER into the text file as its first line and runs a filter called bannertopdf to do the conversion.

However, there is no specification of the banner text format used by cups-filters (not even in the README). This gap should be filled.

Deliverable: Provide the requested documentation as a Pull Request on the GitHub of cups-filters.

6. Documentation for the bannertopdf filter

Categories: Documentation/Training

The student's task is to create a documentation/help page for the “bannertopdf” filter. This filter is used to create banner pages and test pages using simple instructions. Due to lack of documentation, most users do not know about its functionality. The student needs to document all its options and the format of the instruction files which are used as input for the filter.

Deliverable: Markdown file to be included in the cups-filters package and also in the web site

7. Documentation for the pdftopdf filter

Categories: Documentation/Training

The student's task is to create a documentation/help page for the “pdftopdf” filter. This filter is the central filter for processing the pages according to page management options and also to take care that the page sizes can be printed on the printer. Due to lack of documentation, most users do not know about its functionality, especially not about all the available page management options (page selection, N-up, even/odd pages for manual duplex, scaling, booklet, …). The student needs to document all the options and functionality of the filter.

Deliverable: Markdown file to be included in the cups-filters package and also in the web site

8. Documentation for the rastertopdf/rastertopclm filter

Categories: Documentation/Training

The student's task is to create a documentation/help page for the “rastertopdf” filter which is also called as “rastertopclm” to generate PCLm output. In its PDF incarnation the filter allows accepting print jobs in raster format by CUPS using this filter to turn the incoming job into PDF. The PCLm output is used to make it possible to print on printers accepting PCLm as input format. Unfortunately, there is no complete documentation for the filter, telling how it is used and with which command line options it can be controlled. The student needs to write this missing documentation.

Deliverable: Markdown file to be included in the cups-filters package and also in the web site

9. Documentation for the pdftops filter

Categories: Documentation/Training

The student's task is to create a documentation/help page for the “pdftops” filter. The purpose of this filter is support for PostScript printers. It turns PDF to PostScript using the printer's PPD (PostScript Printer Description) file and command line options. Unfortunately, there is no complete documentation for the filter, telling how it is used and with which command line options it can be controlled. The student needs to write this missing documentation.

Deliverable: Markdown file to be included in the cups-filters package and also in the web site

10. Test and compare the filters to convert PDF to Raster

Categories: Outreach/Research, Quality Assurance

There are three filters supposed to fulfill the same task, converting PDF into CUPS Raster or PWG Raster, but they use different external utilities to render PDF. These filters are:

  • gstoraster
  • pdftoraster
  • mupdftoraster

The student's task is testing and comparing the above three filters and figuring out if they have the same output when they are called with the same options and also whether the filters support the same options.

Deliverable: In case that there are differences post an issue on the GitHub of cups-filters, describing the differences and asking for correcting the filters to make them behave the same as best as possible. If they actually behave all the same, write up how you did the tests and what you got out.

Depending on the outcome of this task, new tasks will get posted for fixing the discrepancies and documenting the filters.

11. Open Printing Website Search window is broken with Firefox under Windows 10

Categories: Coding

OpenPrinting Web site issue #65

On the OpenPrinting web site when visited from a Windows 10 machine with Firefox (with ad blocking disabled), the Search window is still broken.This should be fixed and also pressing Enter/Return does nothing. There should be an explicit Submit button added.

Deliverable: A pull request on the site's GitHub which solves the issue

12. About Brief History typo and omissions

Categories: Documentation/Training

OpenPrinting Web site issue #64

On the OpenPrinting web site Michael Sweet's first name is misspelled. Also, Glen Petrie and Norm Jacob's names should be added to the names of the original gang at FSG OpenPrinting.

Deliverable: A pull request on the site's GitHub which solves the issue

Categories: Coding, Documentation/Training

OpenPrinting Web site issue #63

On the OpenPrinting web site, on the home page there should be a tab leading to Driverless Printing. Currently, one can only navigate there via the menus Projects→Miscellaneous

Also, the IPP Everywhere logo should be on the main page of Driverless Printing (not just in the Standards sub-page).

Deliverable: A pull request on the site's GitHub which solves the issue

14. Let last three "News and Events" items appear on the front page of OpenPrinting web site

Categories: Coding

OpenPrinting Web site issue #62

On the OpenPrinting web site the latest news should be visible on the front page, especially since we have started posting news. They should appear similar to the “News and Events” page itself, but not only with title and excerpt but also with date and author's name.

Deliverable: A pull request on the site's GitHub which solves the issue

15. .htaccess file: Add rules to forward old URLs to the new pages of the OpenPrinting web site

Categories: Coding

OpenPrinting Web site issue #61

The .htaccess file (in the foomatic-web-app repository on the OpenPrinting GitHub) allows to carry any amount of rules to redirect URLs of the former web site (which could be linked from somewhere) to pages of the new site. The task is to find as many old links as possible and add forwarding rules to the appropriate pages of the new site, and also to report issues on the site's GitHub in case an important page is missing on the new site.

Deliverables: A pull request on the foomatic-web-app repository for adding the rules to .htaccess and issue reports on the site's repository for missing pages in the new site.

16. Write test cases for driverless printing

Categories: Quality Assurance

Write test cases for driverless printing. The test cases should be exhaustive enough so that they can be used by any printer manufacturer who plans to launch a driverless printer in the market. The printer manufacturer can use those test cases as a sort of checklist to test if their printer is working properly in the Linux environment.

Deliverables: Write-up of the series of test cases, for each test what has to be done and what result gets expected.

When this task is completed, new tasks will get posted for implementing the test cases as scripts.

17. Developer guide for Printer Applications

Categories: Documentation/Training

The student's task is to write a guide on how Printer Applications work and why they are used.

Deliverable: Markdown file to be included in the cups-filters package and also in the web site

18. Test and create documentation on how to use the ippserver utility

Categories: Documentation/Training

The student needs to document on how to use the ippserver utility as a printer simulator. This is very important for contributors in the printing space since not everyone has a printer and a simulator is very important to work.

Deliverable: Markdown file to be included in the ippsample package and also in the web site

19. Create documentation on how to use the ippeveprinter utility

Categories: Documentation/Training

The student needs to document on how to use the ippeveprinter utility as a printer simulator or as base for a Printer Application. This is needed by client software developers to have a printer simulation and for printer driver developers who want to provide their drivers as a Printer Application (program which emulates an IPP printer and passes jobs on to physical, non-IPP printer).

Deliverable: Markdown file to be included in the ippsample package, the CUPS package, and also in the web site

20. Create documentation on how to use the IPP tools of PWG's ippsample suite

Categories: Documentation/Training

The student needs to document on how to use the utilities of the PWG's ippsample suite for development and debugging tasks when working with IPP printing.

Deliverable: Markdown file to be included in the ippsample package, the CUPS package, and also in the web site

21. Shell scripts to capture print files automatically

Categories: Coding, Quality Assurance

When it comes to debugging while something in printing fails, a file containing the print job (what the client application sends to CUPS and also what CUPS sends to the printer) is one of the most important tools for a developer to have a first look into what has failed.

The student's task here is to write a shell (or Python) script which makes it easy to obtain such a file.

Deliverable: The script

22. Design a slider for the Open Printing Website homepage

Categories: Design, Coding

Currently the Open Printing home page has a fixed banner. That needs to be converted into a dynamic slider. The student's task here is to design a slider for the Open Printing Website homepage.

Deliverable: A pull request with the appropriate code to the GitHub of the OpenPrinting web site.

23. Create developer documentation on how to use the scp-dbus-service of system-config-printer for the functionality of discovering printers and creating print queues

Categories: Documentation/Training

in the printer setup tool project system-config-printer the part which makes the decisions about which of CUPS' results on printer discovery come from the same physical printer and which driver to use with a given printer (the AI so to say) are done in a module separate from the GUI, so that these parts can be also used by other printer setup tools. This part is implemented as a D-Bus service names scp-dbus-service.

The student's task here is to create developer documention on how to use the scp-dbus-service for the functionality of discovering printers, assigning drivers, and creating print queues, so that he can write a printer setup tool.

Deliverable: Markdown file to be included in the system-config-printer package, and also in the web site

24. Create developer documentation on how to use the Common Print Dialog Backends for a print dialog

Categories: Documentation/Training

To separate the development of GUIs and of the interaction with the different print technologies (CUPS, Google Could Print, Print to File, …) we have introduced the Common Print Dialog Backends (CPDB) framework. This way print dialog GUIs can be developed independent of actual print technology and stay usable even if the print technology changes. There are backends doing the communication with the print technologies and as they are developed independent of dialog GUI, they can get quickly changed in case something on the print technology changes or a backend added for a new technology appearing. Providers of network print services can even provide the backend for their service as a sandboxed package, like Snap.

Creating of new print dialogs and maintaining them gets much easier now as one only needs to use the frontend library of CPDB and call its functions to get a dialog which is always up-to-date with all print technologies.

The student's task is to create a developer documentation on how to use the Common Print Dialog Backends concept for writing a print dialog.

Deliverable: Markdown file to be included in the cpdb-libs package, and also in the web site

25. Crash in diagnostics wizard of system-config-printer

Categories: Coding

system-config-printer Issue #141

A user reported that the diagnostics wizard of system-config-printer crashes in certain cases and gives instructions how to reproduce the bug. The studen's task here is fixing the bug.

Deliverable: A pull request with the fix for this bug.

26. Create tutorials/quick-start guides for printing under Linux

Intermediate Task

Categories: Documentation/Training, Research/Outreach

Create tutorials or quick-start guides that will help people setup and configure CUPS and CUPS server in Linux for printing. You may write blog posts, or modify the documentation to include your tutorials or quick-start guides.

Deliverable: Link to a blog post or a Pull Request adding your guide, tutorials, etc. to the documentation.

Linux Standards Base (LSB)

1. Description of Linux kernel subsystems

Categories: Documentation/Training, Coding

Each Linux kernel subsystem provides an API for communication with the other parts of the kernel. The descriptions is available in different sources: books, like Linux Device Drivers, Essential Linux Device Drivers, kernel documentation, and source code.

The task is to reveal the valid scenarios of API usage in the form of automata models (state chart diagrams) describing possible states and transitions. Thus defining dependencies and correct order of functions. We could start from describing wireless network subsystems such as WiFi and file systems.

Requirements: Basic knowledge of operating systems functionality and Linux kernel in particular

Deliverable: Descriptions of valid subsystem scenarios in the form of automata models (state chart diagrams)

Sound Open Firmware

1. Sound Open Firmware cleanup documentation

Beginner Task

Categories: Documentation/Training

Look for spelling mistakes, typos, formatting issues inside the SOF project Documentation.

2. Sound Open Firmware good first contribution

Beginner Task

Categories: Coding, Documentation/Training

Post a Good First Issue on GitHub. Can be a bug report or a feature request.

3. Fix checkpatch.pl issues

Categories: Quality Assurance, Coding

checkpatch.pl is a static analysis tool that can report coding style problems. Apply it on the Sound Open Firmware source code.

4. Fix coccinelle issues

Categories: Quality Assurance, Coding

Coccinelle is a static analysis tool that starting from common bug patterns can find pieces of code which follow a previous bug/error pattern. Apply it on the Sound Open Firmware source code.

CHAOSS: Grimoire Lab

1. Create a metric for the evolution of number of comments in GitHub

Advanced Task

Categories: Coding

This task is to learn how to build evolution charts in Kibana/Kibiter. GrimoireLab Sigils project contains a set of dashboards covering different metrics over a set of different data sources, you can find some documentation on those dashboards online so you can have an idea of the final results you may achieve. You’ll need the link to the GrimoireLab dashboard already containing data ready to work with and the credentials to log-in, please ask the mentors for them. Login into Kibiter. Create a new horizontal bar chart visualization on top of GitHub Issues index. Add a date histogram based on ‘grimoire_creation_date’ on x-axis. Add the count of comments as a metric on the y-axis. Save the visualization following the format ‘<your_name>_comments_evolution_metric’ and export your results (Management → Saved Objects → Visualizations → Look for yours, select it and click on ‘export’).

Deliverable: exported JSON document with your visualization, a screenshot of your results and a link to the saved one (click on ‘share’ on the top menu to get the link).

2. Create a network visualization of contributors and repositories

Advanced Task

Categories: Coding

This task is to learn how to build network charts in Kibana/Kibiter. GrimoireLab Sigils project contains a set of dashboards covering different metrics over a set of different data sources, you can find some documentation on those dashboards online so you can have an idea of the final results you may achieve. You’ll need the link to the GrimoireLab dashboard already containing data ready to work with and the credentials to log-in, please ask the mentors for them. Login into Kibiter. Create a new network visualization on top of GitHub Issues index. Add authors and repository names as nodes. Set node size to number of contributions. Set edge size to number of contributions too. Save the visualization following the format ‘<your_name>_contributors_and_repos_network’ and export your results (Management → Saved Objects → Visualizations → Look for yours, select it and click on ‘export’).

Deliverable: exported JSON document with your visualization, a screenshot of your results and a link to the saved one (click on ‘share’ on the top menu to get the link).

3. Clone an existing GitHub Pull Requests dashboard using the new GitHub Pull Requests index

Advanced Task

Categories: Coding

This task is to learn how to build a dashboard in Kibana/Kibiter. GrimoireLab Sigils project contains a set of dashboards covering different metrics over a set of different data sources, you can find some documentation on those dashboards online so you can have an idea of the final results you may achieve. You’ll need the link to the GrimoireLab dashboard already containing data ready to work with and the credentials to log-in, please ask the mentors for them. Login into Kibiter. Start by creating the same visualizations you will find on ‘GitHub Pull Requests dashboard but based on the new GitHub Pull Requests index. Save them with new names. Create a new Dashboard. Add your saved visualizations to the dashboard. Modify the layout to match the old GitHub Pull Requests dashboard. Feel free to add new metrics not available in the old dashboard, especially those related to the new fields included in the new index. Save the dashboard following the format ‘<your_name>_github_pull_requests’ and export your results.

Deliverable: exported JSON document with your visualization, a screenshot of your results and a link to the saved one (click on ‘share’ on the top menu to get the link).

4. Introduction to Git

Beginner Task

Categories: Coding

This task is to learn how to use Git and GitHub Clone a GrimoireLab repository on GitHub under the CHAOSS organization (https://github.com/chaoss). List the last 10 commits using a Git command (https://git-scm.com/doc)

Deliverable: a screenshot of the last 10 commits or more.

5. Introduction to Git and GitHub workflow

Beginner Task

Categories: Coding

This task is for learning Git and GitHub workflows

Fork and clone a GrimoireLab repository on GitHub under the CHAOSS organization. Using git commands, create a new branch named `chaoss-gci` from `master` Open the CONTRIBUTORS file, add your name and then add and commit the changes. Using git commands, push your commits on the chaoss-gci branch to your fork. When done, open a pull request to the master branch of the repository using GitHub.

Deliverable: A pull request on the master branch of the repository from participant fork’s branch.

6. More pythonic code

Advanced Task

Categories: Coding

Pythonic is the way of writing Python code using idioms. The Pythonic code is easier to understand and more compact wrt the standard code. This task is about replacing any statement under the GrimoireLab repositories with their equivalent Pythonic versions. For instance, possible statements to change could be (i) if-then-else or (ii) for loops. Clone a GrimoireLab repository on GitHub under the CHAOSS organization (https://github.com/chaoss). Replace the code with the equivalent Pythonic version Submit a pull request without breaking the tests cases.

Deliverable: A PR that passes all automatic checks.

7. Install Grimoirelab following the tutorial

Intermediate Task

Categories: Documentation/Training

This task is about installing GrimoireLab and reporting feedback. Follow the instruction at https://github.com/chaoss/grimoirelab#using-docker-compose Add at least 5 repositories in the Git section of projects.json (https://github.com/chaoss/grimoirelab/blob/master/default-grimoirelab-settings/projects.json) Make a screenshot of the dashboard available at http://localhost:5601

Deliverable: A screenshot of the dashboard with your repositories analyzed.

8. File header mismatch

Beginner Task

Categories: Documentation/Training

Files including code generally start with a header that contains license, copyright and author information, however this information (and in particular the one related to authors) is generally not up-to-date. This task is about reporting the files having a discrepancy between the number of authors reported by GitHub with the ones listed in the file headers. Access any GrimoireLab repo on GitHub https://github.com/chaoss/ (for instance https://github.com/chaoss/grimoirelab-perceval ) Access any file in the target repo (for instance https://github.com/chaoss/grimoirelab-perceval/blob/master/perceval/archive.py) Check that there is a difference between the number of authors in the file header and the authors listed by GitHub for that file. For instance, in the file https://github.com/chaoss/grimoirelab-perceval/blob/master/perceval/archive.py#L18 we can see that 2 authors are listed in the file, but there are 3 contributors. Open an issue in the repository including the file. The issue title must follow the format “[file header] Author list is not updated”. The issue body must describe the problem and point to the file.

Deliverable: An issue referencing the file with the author mismatch.

9. Update author information in file headers

Intermediate Task

Categories: Code

Files including code generally start with a header that contains license, copyright and author information, however this information (and in particular the one related to authors) is generally not up-to-date. This task is about fixing the files having a discrepancy between the number of authors reported by GitHub with the ones listed in the file header. Find an issue starting with “[file header]” Clone the corresponding repository Use the git commands to find a commit of the missing author Update the author list in the file header with the name and email found in the commit Submit a PR which includes the file modified. The title of the PR must follow the format “[file header] Fix author list”. The PR body must describe the fix and point to the issue.

Deliverable: A PR fixing the author list and referencing the issue.

10. Introduction to PyCharm and Perceval

Intermediate Task

Categories: Documentation/Training

This task is about setting up Perceval to be executed from PyCharm IDE. Useful information about Perceval can be found at: https://github.com/chaoss/grimoirelab-perceval Download PyCharm: https://www.jetbrains.com/pycharm/ Clone Perceval repository https://github.com/chaoss/grimoirelab-perceval Open the Perceval project in PyCharm IDE In Run/debug configuration, create a configuration, select “Script path” as “bin/perceval” from the project repository Add Perceval parameters in “Parameters” tab Apply the changes and run the script

Deliverable: A gif/screenshot of Perceval executing within Pycharm

11. Introduction to PyCharm and Graal

Intermediate Task

Categories: Documentation/Training

This task is about setting up Graal to be executed from PyCharm IDE Download PyCharm: https://www.jetbrains.com/pycharm/ Clone Graal repository https://github.com/chaoss/grimoirelab-graal Open the Graal project in PyCharm IDE In Run/debug configuration, create a configuration, select “Script path” as “bin/graal” from the project repository Add Graal parameters in “Parameters” tab Apply the changes and run the script

Deliverable: A gif/screenshot of Graal executing within Pycharm

12. Running the Git Perceval backend via Python

Advanced Task

Categories: Coding

This task is about creating a Python script to execute the Git backend of Perceval via its Python interface. A good reference to achieve this task is available at: https://chaoss.github.io/grimoirelab-tutorial/perceval/git.html Install Perceval via pip or clone the repo https://github.com/chaoss/grimoirelab-perceval Write a simple Python script to analyze any Git repository, an example of script is available at: https://chaoss.github.io/grimoirelab-tutorial/perceval/git.html#using-perceval-as-a-python-module

Deliverable: A link to the script. The script must compile and execute.

13. Running the CoCom Graal backend via Python

Advanced Task

Categories: Coding

This task is about creating a Python script to execute the CoCom backend of Graal via its Python interface. A good reference to achieve this task is available at: https://chaoss.github.io/grimoirelab-tutorial/graal/cocom.html Install Graal via pip or clone the repo https://github.com/chaoss/grimoirelab-graal Write a simple Python script to analyze any Git repository, an example of script is available at: https://chaoss.github.io/grimoirelab-tutorial/graal/cocom.html#using-graal-as-a-python-script

Deliverable: A link to the script. The script must compile and execute.

14. Create a Python script to execute flake8 over all commits of a target Git repo

Advanced Task

Categories: Coding

This task is about creating a simple Python script to execute flake8 over all commits of https://github.com/chaoss/grimoirelab-toolkit . Flake8 is a tool for style guide enforcement (http://flake8.pycqa.org/en/latest/). After this task, you will know how to call some Git commands (git clone and checkout) and flake8 from Python. To help you in this task, a script that runs flake8 over a single commit is available at: https://gist.github.com/valeriocos/0c8f1a0f0dbe5dc5aa197e4c8896fdd9. You can make a copy of it and modify it to achieve the task. Note that you have to install flake8 on your system (for instance: https://www.howtoinstall.co/en/ubuntu/xenial/flake8 )

Deliverable: A link to the script. The script must compile and execute.

15. Create a Python script to execute cloc over all commits of a target Git repo

Advanced Task

Categories: Coding

This task is about creating a simple Python script to execute cloc over all commits of https://github.com/chaoss/grimoirelab-toolkit . Cloc is a tool that counts the lines of code, comments and other information of your source code (http://cloc.sourceforge.net/) After this task, you will know how to call some Git commands (git clone and checkout) and cloc from Python. To help you in this task, a script that runs flake8 over a single commit is available at: https://gist.github.com/valeriocos/0c8f1a0f0dbe5dc5aa197e4c8896fdd9. You can make a copy of it and modify it to achieve the task.

Note that you have to install cloc on your system (for instance: http://cloc.sourceforge.net/#apt-get )

Deliverable: A link to the script. The script must compile and execute.

16. Fetch repository data from the GitHub API

Advanced Task

Categories: Coding

This task is about creating a simple Python script to fetch the repository information of any GitHub repository. After this task, you will know how to collect data from the GitHub API using the endpoint https://developer.github.com/v3/repos/#get. To help you in this task, you can inspect the Client of the Perceval GitHub backend (https://github.com/chaoss/grimoirelab-perceval/blob/master/perceval/backends/core/github.py#L704) and copy the code in your script. The script must you the library request. Note that information/examples about how to query GitHub user data are available at: https://developer.github.com/v3/repos/

Deliverable: A link to the script. The script must compile and execute.

17. Fetch user data from the GitHub API

Advanced Task

Categories: Coding

This task is about creating a simple Python script to fetch the user information of any GitHub user. After this task, you will know how to collect data from the GitHub API using the endpoint https://developer.github.com/v3/users/#get-a-single-user. To help you in this task, you can inspect the Client of the Perceval GitHub backend (https://github.com/chaoss/grimoirelab-perceval/blob/master/perceval/backends/core/github.py#L766) and copy the code in your script. The script must you the library request.

Note that information/examples about how to query GitHub user data are available at: https://developer.github.com/v3/users/

Deliverable: A link to the script. The script must compile and execute.

CHAOSS: Augur

18. Install Augur locally

Beginner Task

Categories: Coding, Documentation/Training

Setup Augur locally on your PC. To set it up locally follow the following instructions: https://oss-augur.readthedocs.io/en/master/getting-started/installation.html

Feel free to reach out to the mentors if you have trouble setting up Augur or have any query.

Deliverable: A screenshot of the output you see after running `make dev`

19. Implement metrics in Augur

Advanced Task

Categories: Coding

In this task implement one or more of the unimplemented CHAOSS metrics specified by the various working groups (Evolution, Risk, Value) in Augur.

To implement a metric first select a metric specified by the various working groups that has not been implemented in Augur. [Metrics implemented in Augur can be found in `augur/metrics`] https://github.com/chaoss/wg-evolution#metrics https://github.com/chaoss/wg-value/tree/master/focus-areas https://github.com/chaoss/wg-risk/tree/master/metrics

Once you have selected the metric you want to implement, follow the following documentation to implement the metric https://oss-augur.readthedocs.io/en/master/getting-started/create-a-metric/create-a-metric-toc.html

Deliverable: A Pull Request consisting of the metric implementation.

20. Add default begin & end dates

Advanced Task

Categories: Coding

A majority of the metric implementations in Augur specify a default begin & end date. Currently each metric implementation sets these default values in a hard coded way. Your task is to create two variables in `augur.util`: DEFAULT_BEGIN_DATE DEFAULT_END_DATE After doing so replace the hard coded default begin & end dates in the metric implementations with DEFAULT_BEGIN_DATE & DEFAULT_END_DATE respectively.

Feel free to open an issue on https://github.com/chaoss/augur if you have any questions or want to discuss more about this task

Example metric that uses hard coded begin & end dates: https://github.com/chaoss/augur/blob/4aac60dfe16e175590527ff49cff3be95ec32fcc/augur/metrics/issue/issue.py#L23

Deliverable: A Pull Request with the requested changes.

21. Build frontend metric visualizations

Advanced Task

Categories: Coding, Design

In this task build one or more metric visualizations in the frontend. To add a metric visualization in the frontend checkout the following documentation https://oss-augur.readthedocs.io/en/master/architecture/frontend.html

Deliverable: A Pull Request with metrics visualization added to the frontend.

22. Improve Augur documentation

Beginner Task

Categories: Documentation/Training

Augur is an evolving project and requires frequent documentation upgrade. This sometimes results in broken links, typos, etc. In this task, fix any such documentation problems that you might come across. Augur documentation is hosted on Read the Docs and its source can be found here.

Deliverable: A Pull Request fixing a documentation typos, broken links, grammar, etc. or improving the documentation.

23. Create tutorials/quickstart for Augur

Intermediate Task

Categories: Documentation/Training, Outreach/Research

Create tutorials or quickstart guides that will help people setup Augur easily, implement metrics, collect data for their repositories, etc. You may write blog posts, or modify the documentation to include your tutorials or quickstart guides.

To be able to do this you should be able to setup Augur locally on your PC and should go through Augur’s getting started documentation: https://oss-augur.readthedocs.io/en/master/getting-started/getting-started-toc.html

Deliverable: Link to a blogpost or a Pull Request adding your guide, tutorials, etc. to the documentation.

gsoc/google-code-in-2019.txt · Last modified: 2019/11/06 18:23 by till