On Thu, Feb 25, 2021 at 12:55 PM Pamphile Roy <roy.pamphile@gmail.com> wrote:

Hi everyone,

I would like to propose to use more functionalities of GitHub. I could not find any reference showing this was discussed before, so I apologize if the following would not be relevant.

Thanks for asking Pamphile. We indeed haven't discussed this before, at least not in the last few years.

*Teams*

Currently there is just the *triage* team, but we could create other teams like one per submodule or for given skill sets. This could allow easier pinging of people on PR.

I agree it would be good to make some improvements here. The team has grown a lot, and many people don't know who are the experts/maintainers for some module. A long time ago we tried to keep a list manually in the repo (a MAINTAINERS.rst file), but that just went out of date and most people didn't know to look there anyway. A related problem: I have also stopped watching the repo, because the amount of notifications I was getting was starting to get a little overwhelming. Instead, I check in and browse new issues/PRs every few days to a week - but that means I may miss relevant stuff. There's currently not a good middle ground here. PyTorch has a useful system where you can subscribe to a label, and then once the label gets added a bot comes along and Cc's you on the issue. It does require running a bot, which would be another piece of machinery to maintain. The most related GitHub feature is CODEOWNERS: https://docs.github.com/en/github/creating-cloning-and-archiving-repositorie.... It can be used to automatically request PR reviews from individuals or from a team. So there's at least three approaches: 1. Teams per submodule and other area 2. A bot to subscribe to labels 3. Using CODEOWNERS The trouble with (1) is that it's a lot of overhead managing teams in the GitHub UI, and only people with owner/maintainer status can do it. My preference is (3) I think: it solves both problems to some extent, it's the most granular (you can get notifications for individual files as well as blog patterns), and it's a plain file in the repo that everyone can propose changes to via a PR. For pinging people outside of PRs, we can use the same file as documentation (just look at it, find the submodule/file of interest, and see who is subscribed to it to @-mention them). Should we try that?

*Project*

We have the roadmap and some issues are acting as meta-issues. But we could use, instead/on top, the integrated project management dashboard. It would be more convenient to keep track of what can be done, who is working on what area, etc.

My experience with GitHub Projects isn't great, it's more work than tracking issues to keep up to date, and is less integrated with the rest of the GitHub workflow. I'd be happy to give interested people the permissions to create new project boards for specific topics if that's how they like to work, but I'd like to keep it completely optional.

Also, this would clearly be in favor of openness and transparency with the management of the library.

There's actually very little management going on. There's zero hidden repositories or other content; the only thing is a very low-traffic private maintainer mailing list that is meant only for topics that aren't always good to discuss in public (mostly just deciding on giving someone more permissions). Maybe it's time to give regular community calls a go again - it's working quite well for NumPy. We tried it briefly a couple of years ago and it was useful but I dropped the ball on organizing at some point because I was too busy. Should we try that again? Maybe regular once a month Zoom calls open to anyone who wants to attend? Cheers, Ralf