Issue Dashboard #207
Comments
|
I wrote this script: // Copyright 2023, University of Colorado Boulder
const buildLocal = require( '../../perennial-alias/js/common/buildLocal' );
const { Octokit } = require( 'octokit' ); // eslint-disable-line require-statement-match
const octokit = new Octokit( {
auth: buildLocal.phetDevGitHubAccessToken
} );
const getUsers = async () => {
const result = await octokit.request( 'GET /orgs/phetsims/members', {
org: 'phetsims',
per_page: 100
} );
// console.log( result.data.length );
const logins = result.data.map( member => member.login );
return logins;
};
// https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#list-users
( async () => {
const users = await getUsers();
for ( let i = 0; i < users.length; i++ ) {
const user = users[ i ];
const result = await octokit.request( 'GET /search/issues', {
accept: 'application/vnd.github+json',
q: `is:issue is:open label:status:ready-for-review assignee:${user} org:phetsims`,
per_page: 100,
page: 1
} );
// console.log( result.data.items.length );
// console.log( result.data.items );
console.log( `${user}: ${result.data.items.length}` );
}
} )();Running it showed this issue distribution (ready for review issues only): |
|
Played around with this tonight to use console.table and create a quick read out of relevant data. I'm worried about speed on this... It's a long time to wait for all these API calls, and I don't think it's going to be the most used tool if we have to wait that long to get results ( and this is with only getting results for open issues, and ready-for-review). We can keep going this route, but I'm worried it might not be our best option in the long run. |
|
It will be good to discuss in person, so we can cover questions like:
Jotting down one idea that may boost the speed significantly (if we decide to go in this direction): Run 40 queries to download all 3888 open issues, and persist them to disk as JSON. This will be a time-consuming step but only needs to be run once. To update it, run 1 query to get 100 issues sorted by "recently changed", and overwrite anything on the disk that has changed. (If more than 100 issues changed, then run successive queries.) Then all issue metadata is offline and we can run any query or visualization quickly. |
100%. And I think these are all great questions that may also need feedback from other debs. I know how I envision the tooling, but that may not align with what everyone else is imagining. We want to make sure that if we put time and effort into this it will be a tool that is actively used by the team to help us be better. |
|
At the dev meeting 5 days ago, @marlitas and @AgustinVallejo and I agreed to work on this issue: #207 which says: At today’s dev meeting, we agreed we need a dashboard that shows how many issues are assigned to each person, and additionally how many of those are high priority, top priority, ready for review or blocks publication or blocks-sim-publication. We started with a very productive conversation about the nature of our issues and assigments. To summarize:
We thought this was too much to jam in to Thursday’s retrospective, so we wanted to start discussing it now. Full details are in https://docs.google.com/document/d/1bAPEP1iUxQRuCSLHkrwjAH-948kB-sBN3hCC54g-8dc/edit |
|
@kathy-phet showed me that we can now create workflows in project boards to automatically add issues when criteria are met in repos we want to designate. The https://github.com/orgs/phetsims/projects/67/views/4 board shows how we can really leverage this to be a repo health check including: group by assignee, grouping by repo, burn up charts, etc. I think it might be worth putting our time here... |
|
^^^ Nevermind... upon further experimenting it limits us to adding up to 4 custom workflows |
|
Others are "runing their own GH Action" to sync their project with multiple repos. So looking at GH Actions for bringing all issues to a project board could be a good way to go. Then you get all that a project board has to offer. |
|
Up vote these 2 Github issues: |
|
There is a problem on CT because of the octokit dependency added for this issue. I tried typing "dependencies": {
"octokit": "^2.0.14"
}But it is also at version 2.0.14 and I see ~4.2.0 checked in. I tried to remove the |
|
My subteam is not focusing on this issue, so I'll self-unassign for now. |
|
Based on yesterday's conversation about issue management, I wanted to get a quick look at how many open issues are assigned to each member of the org: |
|
@samreid - Is there a way to print an open issues per repo table (similar to above but per repo)? |
|
The process above is not amenable to reporting per repo, it would probably take 30-60 minutes to write a script that uses the GitHub API to make a per repo table. |
|
Hey Sam, If that fits into your issues of choice, I think we would find that script useful as we work on approaches and any sort of sprints on addressing and reducing our open issues. |
|
@AgustinVallejo and I wrote a script that indicated assignees by repo (note that issues can be double counted if assigned to more than 1 person) |
|
More importantly, we used the octokit API to cache all open issue metadata locally (around 20MB), so it will be easy and fast to run other reports. |
|
Some amazing progress in visualizing issues over in https://github.com/phetsims/phet-io/issues/1914#issuecomment-1483313422 It made it easy to view issues across repos and see how they are assigned, labeled, etc. We considered a GitHub action to put all our common code issues on one project board, so we can use "insights" to visualize it all. Update: April 18, 2022 - Elaborating on the proposal
UPDATE: I saw a report that said a project board was capped at 1200 items. https://github.com/orgs/community/discussions/9678 That seems at odds with the 2500 cards/column note mentioned earlier. UPDATE: I also see there are some automations that don't need Actions, https://github.com/orgs/phetsims/projects/68/workflows |
At today's dev meeting, we agreed we need a dashboard that shows how many issues are assigned to each person, and additionally how many of those are high priority, top priority, ready for review or blocks publication or blocks-sim-publication. @samreid @marlitas and @AgustinVallejo agreed to collaborate on it.
The text was updated successfully, but these errors were encountered: