Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
154 lines (108 sloc) 6.25 KB

Getting started for contributors

Thanks for wanting to help out with Bors-NG!

Answering support questions

If you've been using bors a lot, you can help other people use it by answering questions on the support forum. It's running on Discourse, the same app used by Elixir Forum and Rust Users.

Submitting bug reports

Go ahead and submit an issue report; we can't fix a problem if we don't know about it. Even if you're not sure if it's a bug, go ahead and submit it. If a lot of users think it's a problem, even if we don't think it's "really a bug," we'll probably try to figure out a way to fix it anyway. Bors needs to be useful, not just correct. Besides, that's why we call them "issue reports" instead of "bug reports."

If you get the chance, please use the search bar at the top of the issues list to see if somebody else already reported it. You don't have to do that, if you don't have time, or just can't think of what to search for. Think of it as extra credit. If we find a duplicate, we'll just leave a comment saying "Duplicate of #some-other-issue-number" (so that you know where the existing conversation is happening) and close it.

Filing an issue is as easy as going to the new issue page and filling out the fields.

Sending your change to us

The best way to send changes to Bors-NG is to fork our repo, then open a pull request. GitHub has a howto for the fork-pull system on their own website.

BTW, the hub CLI is really cool. With it, you can make a pull request that modifies this file by running these commands:

$ hub clone bors-ng/bors-ng
$ cd bors-ng
$ hub fork
$ git checkout -b fix_readme
$ vim
$ git commit
$ hub pull-request

You don't have to use anything like that if you don't want to, though.

Finding something to work on

If you're not sure what to work on, there's a list of easy-to-fix problems to get you started at After you pick an issue, you should mention that you're working on it in a GitHub comment (so that we can mark it as assigned and avoid duplicate work). If you're having trouble fixing the problem, go ahead and ask questions right in the issue's comments section, even if your question seems unrelated to the issue itself.

What do the tags in the issue tracker mean?

A: area tags

These refer to the component that the issue is in.

E: entry-level issues

If you want to get started hacking on Bors-NG, these are the issues to pick up. Whoever filed it knows how to fix it (they might've even already done it), and is willing to guide someone else through it. If you're working on it, and have a question, ask please. We want to help.

  • E-easy: Good first bugs. The filer should already know how to fix it; they may even have already fixed it in a private branch. Whichever it is, the point of working on a bug like this is to learn how to edit, deploy, and test an instance of bors-ng, and to file the pull request, get it reviewed, and merged. E-easy issues should be things that actually need done, but nothing is too easy for E-easy.
  • E-medium: This tag exists to provide a gradual path from "fixing typos and minor appearance glitches" to "taking an active role in the ongoing development in bors-ng." E-medium changes should be "good second bugs," meaning they require the contributor to learn how stuff works under the hood. As before, the filer should know how to fix it.
  • E-hard: The filer should have an idea about how it should be fixed, but an E-hard issue should require the contributor to know how bors-ng works.

C: do not work on this issue

C-tags are "partially closed"; either there's already somebody working on it, or it's not possible right now.

  • C-assigned: A contributor, who does not have write access to the repo itself, is working on the issue. This is not needed if it's assigned within GitHub itself (but that's not always possible, unfortunately).
  • C-blocked-on-external: Something else needs to change before this issue can be completed.
  • C-has-pr: There exists an open pull request for this issue.

I: issue description

I-tags describe the kind of issue.

L: language

The primary programming language this will need to be implemented in. If none is specified, it's Elixir.

S: pull request status

This is the only type of tag that is added to pull requests.

  • S-do-not-merge-yet: Do not merge this pull request.