Making your first Atom contribution
Atom is a large open source project—it is made up of over 200 repos, and there are over 3400 open issues across all repos. As with most large open source projects, knowing where to start contributing can be overwhelming.
When initially digging in, you might have questions like: Which of those 200 repos even implements the functionality that I want to change? Which issues are a good first foray into Atom development? Hopefully this post can shed some light.
Atom is intentionally very modular. Nearly every non-editor UI element you interact with comes from a package, even seemingly core things like tabs and the status-bar. These packages are packages in the same way that packages in the package store are packages, with one difference: they are bundled into the default distribution.
Here’s a list of the big ones:
- atom/atom - Atom Core!
- tree-view - file and directory listing on the left of the UI
- fuzzy-finder - the quick file open chooser;
- find-and-replace - all find and replace functionality
- tabs - a display for the tabs of open editors
- status-bar - the status bar at the bottom of the UI
- markdown-preview - rendered markdown pane item
- settings-view - settings UI pane item
- autocomplete-plus - autocompletions while typing
- git-diff - git diff gutter colorization in the editor
There are many more, but this list should be a good starting point.
Where to start contributing
We’ve labeled a number of issues across the atom org with two labels:
beginner. Our goal with these is to provide a short-ish list of issues that are straightforward in what needs to be done. They may not all be easy but they hopefully are easy to grok, and clear in the desired end result.
beginner issues are a subset of
help-wanted. They should only require a few lines of code, and a test or two.
help-wanted issues not tagged
beginner will be a little more involved.
Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have.
Here are a couple tips to help you write a successful PR:
- Blend in - take a peek at other code in the codebase, read through the styleguide, and avoid adding new dependencies. When code isn’t in a similar style, there will be a lot of back and forth with the PR reviewer concerning little nits.
- Write specs (tests) - we only accept changes and new functionality covered by specs. So be sure to add a spec or two, otherwise the first thing we’ll ask you to do is add specs.
- See more tips in the contributing guide
Hopefully you have a better handle on where to start. If you find any of these issues lacking in clarity, feel free to ping us (or our Community Manager: @lee-dohm) and we’ll be happy to provide more info. We’re looking forward to seeing what you come up with!