Score completed project contributors#321
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a912d3023a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| displayName | ||
| } | ||
| } | ||
| issues(first: 50, filter: { state: { type: { in: ["completed"] } } }) { |
There was a problem hiding this comment.
Paginate completed issues before scoring contributors
For projects with more than 50 completed issues, this nested issues(first: 50, ...) connection only returns the first page, so any assignee who only appears on later pages is omitted from completedIssueAssignees and receives no 15pts/week despite contributing a completed issue. Since contributor scoring now depends entirely on this field, the issue connection needs pagination or a separate project-issue query that collects all completed assignees.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Summary
- Added a dedicated paginated Linear
issuesquery for completed project issue assignees, usingpageInfo.hasNextPage/endCursorto collect contributors beyond the first 50 completed issues. - Updated project normalization to populate
completedIssueAssigneesfrom the paginated per-project issue query when a project id is available, while preserving a fallback for preloaded issue nodes. - Removed the nested first-page-only completed issues connection from the project list query so contributor scoring no longer depends on an unpaginated nested field.
- Expanded the Linear projects unit test to cover project pagination plus multi-page completed issue assignee collection, including a contributor who appears only on the later issue page.
- Committed the changes with commit
ed41012and created the follow-up PR titled “Paginate completed project issue assignees.”
Testing
⚠️ source venv/bin/activate && python -m unittest tests.test_linear_projects— environment limitation: this checkout does not containvenv/bin/activate.- ✅
python -m unittest tests.test_linear_projects - ✅
ruff format linear/projects.py tests/test_linear_projects.py && ruff check linear/projects.py tests/test_linear_projects.py && python -m unittest discover -s tests -p 'test_*.py' - ✅
ruff format linear/projects.py && mypy . - ✅
ruff check .
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d1a829914
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if project_id: | ||
| project["completedIssueAssignees"] = _get_completed_project_issue_assignees(project_id) |
There was a problem hiding this comment.
Avoid fetching assignees for every project consumer
When get_projects() is used by /partials/team/content, /team/<slug>'s project section, post_project_updates(), or get_support_slugs(), those callers only read project metadata, leads, and members, but this line now performs a separate paginated Linear issues query for every project before returning. In workspaces with dozens of active/old projects, those pages/jobs turn from one projects request into N+1 GraphQL requests and can time out or fail on an unrelated project's issues fetch; consider making completed assignees opt-in for leaderboard scoring or fetching them only for completed projects.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Summary
- Made completed issue assignee collection opt-in on
get_projects(), so metadata-only consumers avoid the extra per-project Linear issues queries by default. - Restricted opt-in assignee fetching to completed projects; non-completed projects get an empty
completedIssueAssigneeslist only when the opt-in is requested. - Updated leaderboard project scoring to explicitly request completed issue assignees, preserving contributor-based scoring without affecting other project consumers.
- Added/updated tests to verify default project fetching only performs project pagination calls, while the opt-in path paginates completed issue assignees only for completed projects.
- Updated leaderboard tests to verify scoring requests the opt-in assignee data.
- Committed the changes with commit
49f39f1and created the follow-up PR titled “Make completed project assignee fetch opt-in.”
Testing
- ✅
python -m unittest tests.test_leaderboard tests.test_linear_projects - ✅
ruff check . - ✅
mypy . - ✅
python -m unittest discover -s tests -p 'test_*.py'
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 00ddbb446f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if project_id and _is_completed_project(project): | ||
| project["completedIssueAssignees"] = _get_completed_project_issue_assignees( | ||
| project_id |
There was a problem hiding this comment.
Filter stale projects before fetching issue assignees
When the leaderboard asks for include_completed_issue_assignees=True, this branch fetches completed issue assignees for every completed project returned by Linear before _calculate_cycle_project_points later discards projects whose target window is outside the requested days range. For a weekly leaderboard in a workspace with many old completed projects, the route/job still paginates all historical project issues even though none of those projects can score, which can make the leaderboard slow or fail on unrelated old projects; consider applying the scoring date/status filters before issuing these per-project issue queries.
Useful? React with 👍 / 👎.
Previously get_projects(include_completed_issue_assignees=True) made an extra paginated Linear issues query for every completed project, even ones whose target window fell entirely outside the leaderboard's days range. Move the assignee fetch into leaderboard.py so it only runs for projects that will actually score, eliminating the wasted N+1 on stale projects. Drop the now-unused parameter and the dead preloaded-issues fallback in linear/projects.py.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 483a9e41e4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| contributors = ( | ||
| { | ||
| contributor | ||
| for contributor in get_completed_project_issue_assignees(project_id) |
There was a problem hiding this comment.
Skip assignee pagination for lead-only scoring
When calculate_cycle_project_lead_points() is called, this shared helper still paginates completed issue assignees even though the returned lead score does not use them. I checked app.py:_build_leaderboard_entries and jobs.py:post_leaderboard; both call the lead wrapper and then the member wrapper, so every in-window completed project now performs the Linear issues pagination twice, and the lead-only call can fail or time out because of an unrelated assignee fetch. Consider only fetching contributors for member scoring or returning both maps from one public call and reusing the result.
Useful? React with 👍 / 👎.
Motivation
Description
projectsquery and normalize assignee display names intocompletedIssueAssigneesinlinear/projects.pyvia_normalize_project_participants.leaderboard.py(_calculate_cycle_project_points) to award the 15pt/week bonus tocompletedIssueAssignees(contributors) instead of thememberslist.app.pyandjobs.py, and clarify the constant comment inconstants.py.tests/test_leaderboard.pyandtests/test_linear_projects.pyto cover contributor-based scoring and project normalization of completed issue assignees.Testing
python -m ruff format ...andpython -m ruff check .which completed successfully.python -m unittest discover -s tests -p 'test_*.py'(67 tests) which passed (OK).python -m unittest tests.test_leaderboard tests.test_linear_projectswhich passed.python -m mypy .which completed without blocking errors.Codex Task