[Bug][gh-copilot] DORA dashboard uses seat-assigning organization as organization adoption denominator
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
调研方向
首先,追踪随附的 github-copilot-dora-correlation 仪表板中的 27 个 MySQL 分母查询位置及其对应的 PostgreSQL 查询。然后检查 CollectCopilotSeatAssignments、copilotSeatResponse 和 ExtractSeats,以了解 enterprise seat 数据和组织归属。完成后应为当前和历史采用情况定义有效的组织范围许可用户总体,同时不得将 NULL 采用情况分类为 >75%。
由索引模型根据 Issue 内容生成。
描述
Search before asking
- I searched the issues and found no issue covering this organization attribution and denominator problem.
Related, but not duplicates:
- #8964 updates Copilot API endpoints and schemas.
- #8960 adds AI adoption phases/cohorts.
- #9002 implements parts of those changes.
What happened
The bundled github-copilot-dora-correlation dashboards calculate organization adoption as:
daily_active_users /
COUNT(_tool_copilot_seats WHERE organization = selected_scope.organization)
This assumes that Copilot seats assigned to members of an organization are also assigned by that organization.
GitHub explicitly supports assigning licenses through a central or "shell" organization. Its current attribution rules state that once a user has a Copilot seat anywhere in the enterprise, their usage is attributed to every organization in that enterprise where they are a member.
Therefore, an organization can have valid organization-scoped usage metrics while having zero seats assigned directly by that organization.
Observed result:
_tool_copilot_enterprise_daily_metricscontained daily active-user data for the selected organization scope._tool_copilot_seatscontained no seats attributed to that organization.- The dashboard denominator was zero, so adoption was
NULL. - Adoption trend, current adoption, correlation, and tier-based panels showed no or misleading data.
NULLadoption was classified as>75%by tier queries because theirCASEexpressions useELSE '>75%'.
The MySQL DORA dashboard currently contains this seat-denominator pattern in 27 query locations. The PostgreSQL version appears to use the same assumption.
There is also a plugin-level enterprise seat attribution concern:
CollectCopilotSeatAssignmentscorrectly calls the enterprise seats endpoint when an enterprise is configured.copilotSeatResponsedoes not parse the response'sorganizationfield.ExtractSeatssets every row'sOrganizationtoconnection.Organization.- The enterprise endpoint can return multiple seat rows for the same user when access is granted through multiple organizations or enterprise teams.
This means enterprise seat records cannot reliably represent organization membership or organization-level license eligibility.
GitHub documentation:
Relevant behavior from the documentation:
If licenses are assigned in a dedicated "shell" organization for administrative purposes within the enterprise, users still appear in the metrics for all other organizations in the enterprise they belong to.
What do you expect to happen
Organization-scoped dashboards should use an organization-scoped licensed-user population rather than filtering enterprise seats by their assigning organization.
How to reproduce
- Create an enterprise containing:
- a central organization used to assign Copilot seats
- a separate product organization
- Assign Copilot seats to users through the central organization.
- Make those users active members of the product organization.
- Enable GitHub Copilot usage metrics for the enterprise.
- Configure the DevLake
gh-copilotplugin with the enterprise and product organization. - Collect Copilot reports and seat assignments.
- Select the product organization in the bundled GitHub Copilot + DORA Correlation dashboard.
- Confirm that organization-scoped active-user metrics exist.
- Observe that the dashboard denominator is zero or otherwise incorrect because it filters seats by assigning organization.
- Observe that
NULLadoption weeks can be labeled>75%.
Diagnostic query:
SELECT
day,
daily_active_users
FROM _tool_copilot_enterprise_daily_metrics
WHERE connection_id = ?
AND scope_id = ?
ORDER BY day DESC;
Current denominator pattern:
SELECT COUNT(*)
FROM _tool_copilot_seats s
WHERE s.connection_id = ?
AND s.organization = ?;
The first query returns organization usage while the second returns no organization-assigned seats.
Anything else
Counting rows from _tool_copilot_user_daily_metrics is not a valid replacement denominator. Those reports represent daily user activity and produce weekday/weekend fluctuations rather than the complete licensed population.
The current-state seat table also cannot reconstruct historical weekly eligibility. A historical adoption trend needs either:
- a daily licensed-population snapshot, or
- an effective-dated license/membership source.
The dashboard should avoid silently applying today's seat state to historical dates.
Version
Observed with the gh-copilot plugin and bundled dashboard from the DevLake v1.0.3-beta10 generation. The same denominator pattern is present on the current main branch.
Are you willing to submit PR?
- Yes, I am willing to submit a PR.
Code of Conduct
- I agree to follow this project's Code of Conduct.
- 主要语言
- Go
- 星标
- 3.1k
- 派生
- 812
- 平均合并
- 2 天 9 小时
- 30 天内合并 PR
- 56
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/devlake 的其他 Issue
-
type/bug
难度 2/5 1-3 小时 新手友好度 82/100
-
难度 3/5 1-2 天 新手友好度 65/100
-
难度 5/5 一周以上 新手友好度 35/100
-
type/bug
难度 4/5 3-5 天 新手友好度 52/100
-
难度 5/5 一周以上 新手友好度 35/100
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 90/100
-
enhancement
难度 2/5 1-3 小时 新手友好度 65/100
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
santhosh-tekuri/jsonschema#276 ·