1. Create a separate organization

Our strong recommendation is to create a separate GitHub organization that you connect to Reviewly.

If your organization is “Acme”, you could create a new organization like “Acme HR” or “Acme Hiring” and connect it to Reviewly instead.

There are a few reasons for this:

• We’re going to create many repositories—one for each candidate and one for reviewers—so a separate organization keeps them from cluttering your working organization.
• Each candidate will be invited to their own repository as an external collaborator. If you’re currently on a paid GitHub plan, you’ll be charged for those candidates while they complete their work. By creating a separate organization, you can keep it on the free plan and avoid being charged for them.
• By using a separate organization, you can set stricter repository access controls. This allows you to disable access unless a user is invited and reduces reviewers’ ability to discover a candidate’s identity before submitting their reviews.

2. Reduce bias during reviews

We do our best to hide who the candidate is to the reviewer until they have submitted their review.

To prevent reviewers from accessing the original candidate repository, consider setting stricter organization permissions for repositories on GitHub (i.e., “No permissions”). Consider having a separate organization for Reviewly, as suggested above.

3. Permissions that we require

Security is top of mind for us: we encrypt all personal data, request only the permissions we need, and use expiring tokens to access your organization.

Sometimes, company policies won’t allow admin access to external apps (we need it to invite candidates and reviewers as external collaborators to repositories), so having a separate organization might make it easier to start using Reviewly.

These are the permissions we need and why:

• Administration: We need this to create repositories and invite candidates and reviewers to them.
• Contents: We replicate your take-home project to brand-new repositories for candidates and reviewers, and we need to create commits in them.
• Issues: We replicate not only the code but also any issues the repository contains.
• Pull requests: As with issues, we also replicate pull requests.
• Workflows: GitHub requires this permission if the repository contains any workflow files.

Questions?

Reach out to us at [email protected]. We’re always happy to help and answer any questions you might have.