# Activity

Activity counts and lists your team’s work in GitHub or GitLab. Use it to find work that needs you, or to prepare a record of your recent work.

## The two activity pages

The sidebar separates your activity from the workspace’s activity:

* **Activity** is your own page. A workspace without practice reviews opens here. A workspace with practice reviews opens on your [Practice profile](/user/practice-profile.md).
* **Workspace activity** shows everyone with work in the workspace or one team.

Every workspace has both pages, and no setting turns them on. They show work in the workspace’s repositories. Everyone with a workspace role sees it, regardless of their individual GitHub or GitLab access. On GitLab, the pages say *merge request* where this guide says *pull request*. They use GitLab’s own icons and colors.

Pull requests and issues open on GitHub or GitLab, where you act on them. Activity only reads that work. The only thing you can start here is a practice review of your own work, with [Request review](#request-a-review).

## Needs you

**Needs you** lists the open pull requests that wait for you, in three groups:

| Group                | What is in it                                                          |
| -------------------- | ---------------------------------------------------------------------- |
| **Review requested** | Pull requests that ask for your review and that nobody has settled yet |
| **Returned to you**  | Your pull requests with requested changes or failed checks             |
| **Approved**         | Your pull requests that reviewers approved                             |

Each pull request shows its reviewers as faces. A mark on each face shows the review state: approved, changes requested, commented, or still requested. When no work waits for you, the section says **Nothing needs you**.

**Waiting on others** holds pull requests where someone else must act next:

* **Waiting for review**: your pull requests that reviewers have not reviewed yet.
* **Drafts**: your draft pull requests.
* **Covered by other reviewers**: requests for your review that another reviewer’s decision settles for now.
* **Requested from your team**: requests for review from one of your teams, but not you.
* **Reviewed by you**: merge requests that still list you after you approved them or requested changes.

**Assigned issues** lists open issues assigned to you. Each list includes only the most recently updated work. When more work exists, a line below the list states how many it shows.

### Covered by other reviewers

A request is covered in two cases. Another reviewer requested changes, so the author acts first. Or another reviewer approved it, and GitHub or GitLab counts the pull request as approved. Your own review never covers your request. If the author asks you again, it stays under **Review requested** until another reviewer settles it. The request returns to **Review requested** when the covering approval or request for changes no longer stands.

### Requested from your team

The group names the team, such as a request through the payments team. Someone on the team handles it, so it never counts as your request. A request that also asks you appears under **Review requested**. The group excludes work you opened, drafts, and work you already approved or requested changes on. A review with comments only keeps it listed. Only GitHub has team reviewers, so GitLab workspaces never show this group.

### GitHub and GitLab rules

These rules decide whether a request is **Covered by other reviewers**:

* On GitHub, and GitLab before 16.11, your earlier approval still counts toward the pull request’s decision.
* On GitLab 16.11 and later, a new request for your review removes that approval.
* Without a decision, only a request for changes covers a pull request.
* GitHub gives no decision where a branch needs no review. GitLab gives none until Hephaestus reads the merge request’s approvals.

These rules apply to GitLab reviews:

* GitLab keeps a reviewer listed after their decision. That is why **Reviewed by you** exists. A review with comments only leaves the request under **Review requested**.
* A new request from the author moves a merge request from **Reviewed by you** back to **Review requested** automatically. On GitLab before 18.6, this may wait until Hephaestus next reads the merge request.
* Requests for changes on merge requests require GitLab Premium. Without it, GitLab work never shows changes requested, and requests for changes do not count.

## Your work over a time range

The page shows one tile for each kind of work:

| Tile              | Its number                                               | Also shown                                                            |
| ----------------- | -------------------------------------------------------- | --------------------------------------------------------------------- |
| **Pull requests** | Your merged pull requests                                | Pull requests you opened, and yours closed without a merge            |
| **Reviews**       | Other people’s pull requests you reviewed, each one once | Approvals, requests for changes, and reviews with comments only       |
| **Comments**      | Your comments                                            | Comments in pull request or issue conversations, and comments on code |
| **Issues**        | Issues you opened                                        | Your closed issues                                                    |

Below the number, each tile compares it with the previous period of the same length. For example, *4 more than the previous 30 days*. **All time** has no previous period, so it shows no comparison. Bars then show the number for each week of the range. A week starts on Monday in UTC. A custom range still counts only work within the local days you selected.

Every week has a faint track, so a week without work reads as zero. The busiest bar shows its number. Each tile has its own scale, so you can compare bars within one tile but not across tiles. The first and last week can cover only part of a week. A tile with no work in the range does not open.

The detail of a tile shows the total, the average per week, the busiest week, and the comparison with the previous period. It then shows a row of bars for each kind of work. For reviews, these are approved, changes requested, and commented. Rows share one scale, so their heights are comparable. The number above each row is the maximum value on its scale.

When your work is in more than one repository, **Repositories** shows your counts in each one.

### Who receives a count

* A merge counts for the pull request’s author, regardless of who selected the button. A close without a merge also counts for the author. A pull request with an unknown author counts for nobody.
* A closed issue counts for the issue’s author, regardless of who closed it.
* A review of your own pull request does not count. A review concerns another person’s work. Your comments on your own pull request do count as comments.
* Bots do not count.

Planning, pairing, and help in chat do not appear here.

## Timeline

**Timeline** lists your work in the range, newest first and grouped by day. Each pull request or issue has one row. The row shows its events, such as *Merged*, *Approved*, *Commented*, or your number of comments. Forty comments on one pull request produce one row with *40*, not forty rows. Older work loads as you scroll down.

Timeline counts and tile counts follow the same criteria, so the rows for a range add up to its tiles.

## Workspace activity

Workspace activity lists everyone with work in the range, one row for each person. Work includes comments, so a person with only comments has a row with 0 contributions. The list includes people without a workspace role who worked in the workspace’s repositories.

A team includes its sub-teams and counts activity in the repositories its settings include. If a team filters reviews by label, it counts only reviews of pull requests with one of those labels.

Below the page title, the page says how far back the counts are complete. For example, *History since 3 March 2024 for 12 of 14 repositories*. Counts for an earlier range can be lower than the real work.

### People

The table sorts by **Contributions**, most first. Contributions are the pull requests a person opened, the pull requests they reviewed, and the issues they opened. Each reviewed pull request counts once in the selected range. Merges and comments are excluded from the contribution total. A review of your own pull request does not count. No kind of work counts more than another.

| Column            | What it shows                                                             |
| ----------------- | ------------------------------------------------------------------------- |
| **Contributions** | The sum above                                                             |
| **Pull requests** | Pull requests opened, then pull requests merged in the range              |
| **Reviews**       | Pull requests reviewed, then how many people’s work these reviews were on |
| **Issues**        | Issues opened                                                             |
| **Weeks**         | Active weeks: weeks with any work this page counts, comments included     |
| **Weekly**        | A small chart of contributions in each week                               |

Each figure uses the icon and color that GitHub or GitLab gives it, such as the merge icon for merged pull requests. Point to a figure to read what it counts. A dash means none.

A **New** badge beside a name marks a first contribution to the workspace in the range. Hephaestus shows it only when it has the complete history of the selected repositories.

When the table sorts by a count, each row shows its position. People with the same count share a position, and the next position skips: 1, 2, 2, 4. People with the same count appear in name order. Search finds a person by name or username. It hides the other rows, but each row keeps its position. More rows appear as you scroll down.

The address of the page keeps the range, the team, the repositories, the sort, and the selected tab. Share it, and others see the same view.

### Workspace timeline

The **Timeline** tab lists the work of everyone in the view and who did it, with **Copy as Markdown**.

### Automation

Bot accounts never count as people. They appear under **Automation** with a **Bot** badge, in name order and without positions. A bot account from GitHub or GitLab always stays automation. An account that a workspace admin counts as automation shows **Treated as automation** instead. A workspace admin can count a machine user account as automation too, as [Count an account as automation](#count-an-account-as-automation) describes.

### Hidden people

A workspace admin can hide a member or team from workspace activity. A hidden member does not appear in the counts and lists on Workspace activity. A hidden team does not appear in **Team** and does not count toward its parent team. This changes only Workspace activity. The member’s own Activity page stays unchanged. Requests to a hidden team still appear under **Requested from your team** for its members.

## Find work that needs you

1. Under **You**, select **Activity**.
2. Read **Needs you** for the work that waits for you now.
3. To see work where someone else acts next, open **Waiting on others**.

**Waiting on others** starts collapsed, and it closes again when you leave the page.

## Request a review

In a workspace with practice reviews, your own open pull requests and your assigned issues have **Request review**. It requests an immediate review against the workspace’s practices. A pull request that only asks for your review has no button, because it is someone else’s work. Select **Request review** on your pull request or issue.

While Hephaestus receives the request, the button reads **Requesting review…**. A message then states that the review started or explains why it did not. After the review records an observation about your work, it appears under [Reviews of your work](/user/practice-profile.md#reviews-of-your-work). [Request another review](/user/ai-code-review.md#request-another-review) explains the other places to ask.

## See your work over a time range

1. Choose the last 30 days, 90 days, or 12 months, or **All time**. For other days, select **Custom range**.
2. For a custom range, select the first and the last day. Then select **Apply**.
3. Open a tile to see its work in detail.
4. Optional: Select **Show as table** to list the same numbers for each week.

Point to a bar to see the days it covers. When you change the range, the previous figures stay visible without their colors until the new figures arrive. If this takes more than a moment, **Updating…** appears beside the range.

## Copy your timeline as Markdown

**Copy as Markdown** copies the whole timeline for the range, not only visible rows.

1. Choose the range.
2. Select **Copy as Markdown**.
3. Paste the result into a standup note, a 1:1 document, or a work record.

The result has a heading with the range and one line per pull request or issue, with its link and events. A rich editor pastes a formatted list. A plain text field pastes Markdown.

## Compare work across the workspace

1. Under **Workspace**, select **Workspace activity**.
2. In the team list, select **Everyone** or one team. Type to find a team.
3. Choose the range, as on your own page.
4. Optional: To count only some repositories, select them under **Repository**.
5. In **People**, select a column heading to sort the table. Select it again to change the direction.
6. Open a person to see their tiles, repositories, and timeline.
7. Optional: Select **Timeline** to see everyone’s work in the same range and scope.

The table shows each person’s counts for the range, the team, and the repositories you chose.

## Count an account as automation

Workspace admins can count a machine user account as automation.

1. On **Workspace activity**, open the account from the table.
2. Select **Treat as automation**.

The account moves under **Automation**. To undo this, open the account under **Automation**, and select **Count as a person**.

## Hide a person from workspace activity

Workspace admins can hide a member under **Members**. A person who has no membership has no setting of their own. When such a person asks to be left out, a workspace admin can hide them:

1. On **Workspace activity**, open the person.
2. Select **Hide from activity**.
3. Select **Hide** to confirm.

A message says that the person is hidden from activity. The person leaves Workspace activity and the [public activity page](/user/public-activity.md). To bring them back at once, select **Undo** in that message. Later, select **Show again** under **Hidden by an admin** in Workspace settings.

## Troubleshooting

### Workspace activity counts look lower than the real work

The counts are complete only as far back as the line below the Workspace activity title says. Before any history is complete, the page says how many repositories are still incomplete, because all counts can be low.

### A row has no link

GitHub or GitLab removed the pull request or issue. Its row stays without a link, so the counts stay accurate.

### Older timeline work does not appear

Scroll down to load older work, or select **Show earlier activity**.