Access and set-up

What you need

• A GitHub account. If you do not have one, GitHub's guide explains how to create an account.
• A web browser.

You do not need Git or any other software. Do not use AI tools for your review: see Review by hand.

Accept the invitation

@mmcky gives you write access to your edition's repository on GitHub. This usually comes as an invitation, which GitHub sends you by email.

1. Sign in to GitHub. Use the account that @mmcky invited.
2. Open the invitation. Use the link in the email from GitHub, or go to https://github.com/QuantEcon/REPOSITORY/invitations with your edition's repository in place of REPOSITORY. Languages lists each edition's repository.
3. Accept the invitation. You now have write access.

An invitation expires after seven days. If yours has expired, or you are not sure whether you already have access, ask @mmcky.

What write access is for

With write access, you can commit changes to the lecture on a review pull request, in your browser, if you prefer that to suggestions. See Or commit your changes. Your commits then appear in the pull request's preview. Write access also lets @mmcky assign review issues to you.

Write access includes the right to merge pull requests. During the initial translation, leave merging to @mmcky: see Who does what.

Find your work

@mmcky runs each edition as a project. Every lecture is a task: a review issue in your edition's repository, titled with the lecture's file, for example Review: python_by_example.md, and assigned to its reviewer. @mmcky keeps the tasks in order on a project tracker. You need only the issues assigned to you.

• Your review issues. The issues assigned to you are your list of work. github.com/issues/assigned lists them. Each review issue says where the lecture's review pull request is, and closes when that pull request is merged.
• Review requests. Pull requests that ask for your review are listed at github.com/pulls/review-requested.
• Notifications. GitHub notifies you when you are assigned to an issue, asked to review a pull request or mentioned. Notifications arrive in your inbox at github.com/notifications and, depending on your settings, by email. See GitHub's guide About notifications.

Previews

Each review pull request has a preview: the edition's website as it will look with the pull request's changes. An automated comment on the pull request links to the preview. In some editions, the comment also links each page that the pull request changes.

Read the lecture in the preview, where it looks as readers will see it, with its maths, figures and tables. The preview updates when new commits are added to the pull request.

Your edition's REVIEWING.md

An edition can keep a file called REVIEWING.md in its repository. It lists the lectures in the order they are reviewed, and who reviews each one. At present, only the Japanese edition has one: REVIEWING.md. It was written before this manual. Where the two differ, follow this manual.

Before your first lecture

The main terms and the house style for your language are settled before the first lecture is drafted. See Terms and house style.

Then read How a review round works and Reviewing on GitHub.