mikerkelly
commented
3 days ago According to this Honeycomb trace users have visited /staff/projects (ProjectList) 472 times in the past 60 days, and haven't visited the dashboards at all.
In this Slack message Catherine Stables notes she sometimes uses the dashboards.
According to the commit message that created ProjectsDashboard:
This is ostensibly identical to the copilots dashboard but doesn't exclude the Datalab or LSHTM orgs. We expect these dashboards to diverge over time, hence putting them on separate pages.
Perhaps it would be better to have parameterised the copiloting dashboard rather than forking the code.
There are three views on the staff pages that list projects, with overlapping functionality and duplicated code:
ProjectList(site link) is a simpleListViewwith filters by org and project name, and a link to create an interactive project.Copilotingdashboard (site link) displays a more sophisticated table that lists, sorts, and filters by name, org, co-pilot, project/repo status, workspaces, requests, first/last run, and files released.get_repos_with_status_and_urlto discover repo privacy.ProjectsDashboard(site link) lists, sorts, and filters similarly toCopilotingbut does not include project status, repo status (and therefore does not use GitHub) and last run.All three are intended to help staff locate project pages. Can we merge some or all to streamline the codebase?
Copilotingis the most comprehensive and likely the best candidate to keep.ProjectsDashboardwas forked from it, duplicating code and violating DRY principles.ProjectListtakes ~50ms to load wheras the dashboard ~8/900ms, perhaps this is acceptable on these rarely used pages. If full unification isn’t possible, could we refactor to share common code?CopilotingandProjectsDashboarddirectly share much of the same code. They have some implementation differences but nothing materials and perform basically the same job. Additionally,Copiloting's exclusion of specific orgs could likely be implemented as a filter.