Contributing

The first step to contributing to Chapel is to familiarize yourself with the language itself. The Learning Chapel page is a great resource for getting started with this. It is preferred that you start by learning about the language before diving into the compiler or runtime code. This will generally be a more rewarding experience, and will provide opportunities for tractable contributions to the project. Below are some examples of ways to contribute to Chapel while learning.

Note

Before submitting any pull requests to Chapel, be sure to fill out and send us a contributor agreement. We won’t be able to accept your pull requests without it.

Coding Challenges and Idioms

Tackle some popular coding challenges or programming idioms in Chapel. Show off your progress in a public repository. Ask for feedback from fellow Chapel developers and users. This is a chance to learn about and utilize Chapel’s unique features and strengths in productive parallel programming. Depending on the quality of the implementations, the code could be featured on Chapel’s website as a coding sample or even added to the examples directory in subsequent releases.

Some programming challenge sites:

• Project Euler
• Sphere Online Judge
• Google Code Jam

Some programming idiom sites:

• Rosetta Code
• Programming-Idioms
• Exercism.io
  • See the existing checklist.

Code currently featured in Chapel’s release:

• Examples Directory
• Patterns Directory (work in progress, idioms can be contributed here)

Ports

Port a small application, library, or benchmark to Chapel. Take advantage of the chpldoc tool to generate HTML documentation for your code. This is a great way to get started if you are interested in pursuing a Libraries and Applications project. If a benchmark is unique or important enough, a performance version of the test may be added to the test suite to track its performance across releases.

Some example benchmarks:

• IMSuite
  • Existing IMSuite Implementations
• PRK
  • Existing PRK Implementations
• Julia Benchmarks

Existing benchmarks and performance tracking in Chapel:

• Chapel CLBG Entries
  • CLBG Website
  • CLBG Performance
• Some of Chapel’s Benchmarks
• Performance Overview
• Performance Tracking Benchmarks

Bugs

Identifying bugs in code is nearly half the battle. By working on any of the other introductory tasks, you may cross paths with a bug or two. Reporting these bugs as GitHub issues is incredibly helpful to the project. See the Reporting Chapel Bugs page for more details.

In addition to reporting the bug, you can take it one step further by characterizing the bug with a small reproducible test, and contributing it to the repository in the test/ directory. These types of tests are referred to as future tests on the Chapel team. See the Test System best practices for more information about how we track bugs in the testing system.

Once familiar with the testing system, the bug reporting system, and an area of the project (such as compiler, runtime, or the language itself), tackling an issue labeled easy is a great way to contribute early on.

Documentation

If you find something unclear, or can’t find it at all, it is extremely helpful to the project to bring it to the attention of developers through a GitHub issue and/or improve the documentation by opening a pull request.

All of the online documentation is generated as a Sphinx project. Module documentation is written as block comments in the module code and converted into restructured text (reST) via chpldoc. All other documentation is written natively as reST and contained within the doc/ directory.