[SciPy-Dev] Using more functionalities from GitHub?

[Ralf Gommers]

On Thu, Feb 25, 2021 at 12:55 PM Pamphile Roy <roy.pamphile at 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-repositories/about-code-owners.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210227/225c3712/attachment.html>