maintainers/scripts/activity: review management tool

[bendlas]

Description of changes

Adding maintainers/script/activity/activity.bb, for performing maintenance tasks on issues, prs, as well as nixos maintainers themselves.

Right now it's mostly a dev environment for interacting with the github gql API, as well as maintainers-list.nix.

Currently implemented

There is functionality for querying github graphql and search apis with an access token, handling errors and displaying rate-limit credits. Besides its CLI, it has a REPL for developing and interacting with the data.

CLI tasks:

• Find latest issue/pr comment from user within NixOS
• Find latest contribution from user (as per profile page) within NixOS
• Find latest commit, PR or Issue created by user within NixOS
• Emit maintainer-list.nix as JSON
• Start a GraphiQL UI with the github API, for finding new and interesting queries

The find tasks may seem slightly random, but they represent three different methods for finding maintainer activity in the github API, and might be useful in different ways. Please refer to the *.gql files for a rough overview.

In reach

Before continuing with this, I'll need feedback on what would actually be useful to reviewers, who deal with many different issues and PRs.

A few things, that I could imagine to be straightforward to implement:

• Find open issues and PRs, that a maintainer participates in or has been pinged into
  • filter by whether another maintainer has responded?
  • for trivial search queries, just xdg-open a github search page into the browser
• Generalize queries, e.g. find all PRs to which no maintainer responded / in X time / despite continued user activity / ...?
• Create a standardized PR for retiring a maintainer from the list?
• ...

[bendlas]

This kind of came from the frustration, I felt in #337478 and I'm hoping this can be a more productive course.

I am interested in helping our bulk reviewers out and so I'm willing to spend a few hours per month to develop any tooling that would genuinely improve the situation.

@superherointj @thiagokokada @AndersonTorres @SuperSandro2000 what do you think would be the simplest function, that would make a tool like this worth having?

[SuperSandro2000]

I am not sure how much time I currently use on such topics.

If you would close all issues I was pinged in and never responded, we would probably close a 100 ones and a chunk of them would be: something Nvidia/prime not working. They are probably legit but most of them probably need to be taken upstream and I have no motivation to debug them.

Also for PRs: I have probably 10 where I need to implement reviews but didn't get around yet.

What I wanted in the past is, that I can get reminded about something in a week to merge or close it. A bit like manual stale bot.

Other than that I think the easiest to automate and most annoying tasks is in the linting area where people do the wrong patterns. nixf but for buildPythonPackage or missing meta, etc.

[thiagokokada]

In general I think this is a good first effort, but I think I would like to see this script run for all maintainers in all-maintainers.nix list and see the results for .e.g.: everyone that didn't contribute for the last 6 months.

Not because we should remove those people, but to test if the script is actually useful and correct. If it is correct, we could start an issue ping all of them to see if they're still interested in nixpkgs and cleanup the ones that aren't.

[bendlas]

I think I would like to see this script run for all maintainers in all-maintainers.nix list

Something like this should already get you most of the way there right now:

(set -euo pipefail; ./activity.bb maintainer names | jq -r ".[]" | while read NAME; do ./activity.bb gh latest-issue-comment-for "$NAME"; done | jq -n '[inputs]')

It's not as efficient with credits as it could be (no batching), but it should already sufficient to run tests.

everyone that didn't contribute for the last 6 months

Which of the three implemented methods (latest-issue-comment-for, latest-contributions-for, search-for), or combination thereof, would you base the activity determination on?

Do you see any other possibility for detecting activity, that I may have missed?

[bendlas]

What I wanted in the past is, that I can get reminded about something in a week to merge or close it. A bit like manual stale bot.

That's an interesting proposal. I've been thinking about a customized timer/reminder for personal use as well, time and again.

How would you like to consume such a timer/reminder?

• background service in your ~/.xprofile, pushing desktop notifications?
• webservice pushing browser notifications?
• just adding/managing entries to your calendar?

And how would you like to control it?

• auto-scanning your github activity?
• explicitly, via cli / zenity / web interface?

Other than that I think the easiest to automate and most annoying tasks is in the linting area where people do the wrong patterns. nixf but for buildPythonPackage or missing meta, etc.

How do you think this could be done? The script scanning PRs and running linters on the trees?

There seem to be already some checks for this, e.g. on this PR r/n https://github.com/NixOS/nixpkgs/actions/runs/10765737828/job/29850419122?pr=340663#step:6:91

Do you think it's sufficient to scan PRs for exisiting check results, or are you looking to support reviewers with running linters themselves, or are you looking to have new linters implemented / make it easier to implement custom linters?

Just for me to play around with: How would I lint a buildPythonPackage right now?

[bendlas]

Given the hostile reception, that I'm getting with this from the clique within nixos, that I was actually intending to help, I'm going to keep and develop this for my personal use, for now.

Please DM me if you're interested. It's time somebody started to watch the watchers!