Skip to content

Resolving issues

ohemorange edited this page Mar 9, 2022 · 4 revisions

This page is aimed primarily at helpful reminders for users with write access to the repo, though it may be useful for other contributors as well.

This guide is not meant to replace talking with the Certbot developers; you will save us both time by checking in on the mattermost before starting this process.

If you haven't already, please first familiarize yourself with the contents of https://certbot.eff.org/pages/contribute and follow any instructions there.

Selecting an issue

The most pressing issues will be in the current milestone. For best filtering, go to the issues page, then filter by the current milestone (the one with a non-zero minor version number in the dropdown). You can then either scroll down the list, or filter further. If someone is already assigned to the issue, it can usually be skipped (Assignee --> Assigned to nobody). You can also filter issues by priority label. Newer contributors may want to look for the "good first issue" label as well.

Claiming an issue

To claim an issue so others can easily see what still needs to be taken, assign yourself to the issue. At the top of the right-hand column of the issue page, there's the "Assignees" sections, where there's a helpful link to easily "assign yourself".

Working on an issue

  • Pull master git checkout master && git pull
  • Create a new branch git checkout -b branchname
  • Implement PR
  • Commit changes git add -A && git commit -m "commit_message"
  • Push new branch git push -u origin branchname

Commits will be squashed, so don't worry about keeping the commit log clean; you can always clean it manually when merging.

PRs should ideally be the minimum unit of change it is reasonable to make, as studies have shown that reviewers miss more bugs in longer PRs. Max 400 lines of changes is a reasonable rule of thumb. Besides, you'll get it approved faster the shorter it is, and who doesn't want that.

If you need to run the full test suite on the PR, create a new branch named test-branchname and push it.

Creating a PR

If you know who needs to review it, add them as a reviewer so they get notified. If you don't, don't add any labels or assign anyone, and it will be added the triage list so that whoever is free can take it.

If the PR is going to take some time in review, it may be helpful to others to add the "has pr" label to the issue.

Getting reviews

This process can be pretty flexible. You may want to assign and unassign people to the PR to keep track of who has the ball for longer PRs. Feel free to check in with people if they're taking too long to respond; they may have missed a notification.

If you're reviewing a PR from someone without write access and need to check out the branch, the following command will improve your QoL greatly: git fetch origin pull/NUMBER/head:local-branchname. You can then checkout the local branch named local-branchname and interact with it as usual.

Merging a PR

  • Click "Squash and merge" button.
  • Clean up the commit log if inspiration strikes.