Activity
Activity counts and lists your team’s work in GitHub or GitLab. Use it to find work that needs you, to prepare a record of your recent work, or to compare work across the workspace. Every workspace member can use it.
The two activity pages
- Activity, under You, is your own page.
- Workspace activity, under Workspace, shows everyone with work in the workspace or in one team.
Every workspace has both pages. They show work in the repositories of the workspace to everyone with a workspace role, regardless of their own GitHub or GitLab access. On GitLab, the pages say merge request where this page says pull request.
Activity only reads work. Pull requests and issues open on GitHub or GitLab, where you act on them. The only thing that you can start here is a practice review of your own work, with Request review.
Find work that needs you
- Under You, select Activity.
- Read Needs you for the work that waits for you.
- Optional: To see work where someone else acts next, open Waiting on others.
Waiting on others starts collapsed. Assigned issues lists the open issues assigned to you. Each list shows the most recently updated work, and a line under it says how many it shows when more exist.
Needs you
| Group | What is in it |
|---|---|
| Review requested | Pull requests that ask for your review and that nobody has settled |
| 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, with a mark for each review state: approved, changes requested, commented, or requested. When no work waits for you, the section says Nothing needs you.
Waiting on others
- Waiting for review: your pull requests that no reviewer has reviewed.
- Drafts: your draft pull requests.
- Covered by other reviewers: requests for your review that the decision of another reviewer settles for now.
- Requested from your team: requests for review from one of your teams, but not from you.
- Reviewed by you: merge requests that list you after you approved them or requested changes.
A request is covered when another reviewer requested changes, or when another reviewer approved and GitHub or GitLab counts the pull request as approved. Your own review never covers your request. The request returns to Review requested when the covering approval or request for changes is gone.
Requested from your team names the team. It leaves out work that you opened, drafts, and work that you approved or requested changes on. A request that also asks you appears under Review requested. Only GitHub has team reviewers, so GitLab workspaces never show this group.
Request a review
In a workspace with practice reviews, your own open pull requests and your assigned issues have Request review. A pull request that only asks for your review has no button, because it is the work of someone else.
- Find your pull request or issue on Activity.
- Select Request review.
A message says that the review started, or explains why it did not. After the review records an observation about your work, it appears in Reviews of your work. Request another review lists the other ways to ask.
See your work over a time range
- Choose 30 days, 90 days, 12 months, or All time. For other days, select Custom range.
- For a custom range, select the first and the last day. Then select Apply.
- Optional: Open a tile to see its work in detail.
- Optional: Select Show as table to list the same numbers for each week.
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 |
Each tile compares its number with the previous period of the same length, such as 4 more than the previous 30 days. All time has no previous period. Bars show the number for each week of the range. A week starts on Monday in UTC. Each tile has its own scale, so compare bars only within one tile. When your work is in more than one repository, Repositories shows your counts in each one.
Who receives a count
- A merge, or a close without a merge, counts for the author of the pull request, whoever selected the button.
- A closed issue counts for the author of the issue, whoever closed it.
- A review of your own pull request does not count. Your comments on it count as comments.
- Bots do not count.
Planning, pairing, and help in chat do not appear here.
Copy your timeline as Markdown
Timeline lists your work in the range, newest first and grouped by day. Each pull request or issue has one row with its events, such as Merged, Approved, or your number of comments. Its rows for a range add up to the tiles.
- Choose the range.
- Select Copy as Markdown.
- Paste the result into a standup note, a 1:1 document, or a work record.
The copy holds the whole timeline for the range, not only the visible rows. It has a heading with the range and one line for each pull request or issue, with its link and events.
Compare work across the workspace
- Under Workspace, select Workspace activity.
- In the team list, select Everyone or one team.
- Choose the range, as on your own page.
- Optional: To count only some repositories, select them under Repository.
- Optional: In People, select a column heading to sort the table. Select it again to change the direction.
- Optional: Open a person to see their tiles, repositories, and timeline.
- Optional: Select Timeline to see the work of everyone in the view, with Copy as Markdown.
The list includes people without a workspace role who worked in the repositories of the workspace. A team includes its sub-teams and counts the repositories that its settings include. If a team filters reviews by label, it counts only reviews of pull requests with one of those labels.
Below the title, the page says how far back the counts are complete, such as History since 3 March 2024 for 12 of 14 repositories.
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 range. Merges and comments are not in the total, and 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 that this page counts, comments included |
| Weekly | A small chart of contributions in each week |
Point to a figure to read what it counts. A dash means none. A New badge marks a first contribution to the workspace in the range. It appears only when Hephaestus has the complete history of the selected repositories. The address of the page keeps the view, so you can share it.
Bot accounts never count as people. They appear under Automation with a Bot badge. An account that a workspace admin counts as automation shows Treated as automation.
For workspace admins
Count an account as automation
Workspace admins can count a machine user account as automation.
- On Workspace activity, open the account from the table.
- Select Treat as automation.
The account moves under Automation. To undo this, open the account under Automation, and select Count as a person. A bot account from GitHub or GitLab always stays automation.
Hide a person from workspace activity
Workspace admins can hide a member under Members, or a team under Team setup. A person without a membership has no setting of their own. To hide such a person when they ask:
- On Workspace activity, open the person.
- Select Hide from activity.
- Select Hide to confirm.
The person leaves Workspace activity, its totals, and the public activity page. To bring them back at once, select Undo in the message. Later, select Show again under Hidden people in Workspace settings.
Hiding changes Workspace activity, the public activity page, and the counts on Practices across the workspace. A hidden member’s own Activity page stays unchanged. A hidden team does not appear in the team list and does not count toward its parent team. Requests to a hidden team appear under Requested from your team for its members.
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 incomplete.
A request is in the wrong group
GitHub and GitLab decide when a pull request counts as approved, and these rules move a request between groups:
- On GitHub, and on GitLab before 16.11, your earlier approval counts toward the decision. On GitLab 16.11 and later, a new request for your review removes it.
- Without a decision, only a request for changes covers a request. GitHub gives no decision where a branch needs no review. GitLab gives none until Hephaestus reads the approvals of the merge request.
- GitLab keeps a reviewer listed after their decision, so the merge request moves to Reviewed by you. A review with comments only leaves it under Review requested.
- A new request from the author moves a merge request back to Review requested. On GitLab before 18.6, this can wait until Hephaestus next reads the merge request.
- Requests for changes on merge requests need GitLab Premium. Without it, requests for changes do not count.
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.