Usability of GitHub projects for triagers

In another thread, we discussed using GitHub Projects (beta) for organizing issues. There are lots of advantages, but the experience is not perfect. The discussion was moved here.

It seems it is possible to set per-team permissions for projects.

With that, a GitHub project full of issues closed as “not planned” sounds like a reasonable solution.

7 Likes

Looks like it has to be configured for each and every project, but that’s fine in this instance.

And we already have a triage team, so let’s give it a try! :slight_smile:

Picking a GitHub admin, @brettcannon please could you create a project and add the triage team? Instructions in Petr’s post.

Looks like I can do it; could you check if you have access to this? https://github.com/orgs/python/projects/27/views/1
(For any details that need changing, feel free to DM me so we don’t spam here)

I just managed to add an issue (as a triager) – looks good!

It’s working, although not entirely as expected.

I (a triager) added the _curses one here:

image

I had to add it via the project itself, as there’s no option via the issue sidebar:

image

2 Likes

For me the Projects heading is clickable; is your version inert?

I’ve just checked and it isn’t clickable (just two plain <div>s – note for us (triagers) there’s no ‘settings cog’ similar to milestones/labels on the screen. We also can’t link issues and PRs (the “Development” heading).

A

Do you want to “Give Feedback” to GitHub using the link on the project page? Assuming you have that link.
I can do it if you don’t want to, but it’s probably better from a triager in case they need to follow up.


(FWIW, I’ve asked Discourse moderators to move the “GH Projects vs. triagers” tangent, so we can focus on unsupported platforms again.)

2 Likes

(Replying so that this comment gets dragged out along with the others in the thread split)

There’s some additional context on this core-worklow issue, and three threads on the same feedback repository that the ‘give feedback’ link points to. Hugo and I at least have voted in support of the linked feedback issues (primarily this thread) – I’m not sure if the best approach would be to open a new one, or comment on an existing one. None of them have any comments by a GitHub staff member, though.

A

2 Likes

There might be a way to give triagers, or at least trusted triagers, this feature and the others we’ve been asking for without giving them any ability to push, merge to or otherwise modify any branches on the repo, without waiting (potentially forever) for GitHub to add each of them—use branch protect to restrict creating, pushing and merging for all branches to only teams that currently have write access (so there’s no change for them), and then grant triagers (or a sub-team of trusted triagers) the “write” role, which allows them to use these various GitHub UI features without being able to actually modify anything on the repo itself. See my comments on the issue for more.

5 Likes

This was split from the original thread and got a bit lost. Unless this was meant merely as an experiment to test permissions, it should be updated and advertised in the other thread.

I created a PR to automatically add issues/PRs to projects when they are created/labeled:

3 Likes