Triage instructions

Thank you for volunteering to help the Certbot team triage incoming issues and pull requests. As a small team, your time spent helps us immensely.

Below is guidance and tips for how to triage effectively. If you have any questions, feel free to talk to a team member.

The steps

On Certbot's repositories:

• Tag any incoming issues.
• Tag and assign any incoming PRs.
• Respond to any new mentions or messages to certbot-devs.
• Check the state of the PRs you have assigned to you. This could include a nice ping (“I’ll get to this later!”) just to let the other party know you haven’t abandoned it.
• Check the state of any issues you have assigned to you.

You can find all unlabeled and unassigned issues and PRs on Certbot's repositories at https://github.com/issues?q=is%3Aopen+no%3Alabel+no%3Aassignee+user%3Acertbot+repo%3AEFForg%2Fsphinx_rtd_theme.

On the Certbot repository, issues and pull requests should be given a priority label.

When assigning, assign yourself (as an arbiter of the conversation) and if you have @'ed anyone for feedback, and they are on the Certbot team, assign them as well.

Responding to issues

If the person simply needs help using Certbot on their system and doesn’t have a bug, feature request, etc., you should politely redirect them to Let’s Encrypt’s community forum at https://community.letsencrypt.org/ and close the issue. There is a larger and more active community there of people able to help them out and they should get quicker responses.

Once you’ve responded to an issue, please continue doing so as you can until you’ve handed it off to someone else, the bug is reproducible, the requested feature is understood, or the issue is closed. We should try and get the relevant information from the user while they’re still active and engaged rather than trying to do so months later. You should not feel obligated to write a fix for an issue just because it is new. New issues are not always the most important thing for us to spend time fixing.

Responding to PRs

Once you’ve responded to a PR, please continue doing so as you can until you’ve handed it off to someone else, the PR is merged, or it is closed. You do not necessarily need to drop work on your own PRs which are likely higher priority, but it is important to communicate to the PR author if they should expect an immediate review. You may want to just thank them for the PR, but say that we don't have the resources to review it right now and we will when we can. This helps set expectations for the user and can allow other people on the Certbot team to offer to review if they have extra time.

When reviewing PRs, please be particularly careful around changes in behavior that isn’t a bug fix or changes to our code’s public API. We shouldn’t be making breaking changes to our interfaces and new ones must be supported for the foreseeable future. If you’re unsure about something, ask for help!

You should also know that changes to Certbot's DNS plugins currently require reviews from two different team members.

Asking for help

If you’re unsure about a particular issue or PR, please ask for help. Everyone on the team should be happy to help you and by asking for help we’re more likely to give an appropriate response. This also provides you an opportunity to learn more about an aspect of the project from someone more familiar with it.

With that in mind, I’d like to encourage everyone to get outside their comfort zone a little bit. You should also know there are components of the project that no one understands anymore and the only way for us to move forward is to dig into the code and figure it out. The rest of the team is here to help you though. You can ask someone for help or if they understand something without handing the issue or PR off to them if you wish. If you want to hand an issue/PR off to someone, make it clear you’re doing that, however, the only way you’ll really learn more about a piece of a project is by working on it!

Who to ask for help

• Erica knows Nginx, storage, and cert management best
• Will knows about packaging, tooling, and testing
• Adrien knows Windows, Docker, and our CI setup best
• Brad knows a bit about everything

Reviewing hosting providers requests

Some tips for reviewing updates to hosting_providers.json:

• Make sure they've filled out name, link, category, and reviewed.
• reviewed should be a date in format 2019.7.11
• link is usually a link to their main page; it's where clicking on the name will go
• for category, see descriptions here.
  • they have to provide evidence for full/partial in the link(s) they provide. you'll want to double-check these for accuracy.
  • only one of tutorial, announcement, plan will show up, in that order. partial should have tutorial. if full has tutorial, either research or ask the author if that's an error -- full providers shouldn't need a tutorial to turn on https. some have the link anyway, for example with instructions of what to do if something goes wrong and the automatic https doesn't work.
  • if they offer multiple products, they can either split into two entries or note it in the note field. I personally think if they're doing the latter it should go under the highest category, but use your discretion.
• the note field is good for things like noting which of their products have https, or that the site is available only in certain languages. it's not meant to advertise the hosting provider's site/offerings.
• all unused fields should be ""

Some potentially helpful form text:

• Hey @author! Looking at the link you provided, I see it says "When you click on Enable AutoSSL, ServerPilot will enable SSL for your app using an AutoSSL certificate." -- requiring a click to enable is what we define as "partial" https support. Have you considered enabling SSL certificates by default?