[SciPy-Dev] Using more functionalities from GitHub?

[Pamphile Roy]

> On 27.02.2021, at 17:25, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> 
> The most related GitHub feature is CODEOWNERS: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners <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?

Thanks for pointing out CODEOWNERS, I didn’t know about this! I agree with you, this looks like a good idea and would bring more value than just grouping members by tags.
This would also not prevent to also have, if needed, some grouping for convenience, like maintainer team, review team, build team, etc.

So, I vote in favor of this solution.

> 
> 
> 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?


Thanks for the clarification.

Currently, what I am personally missing is a way to easily understand the project directions. Why we do some things, where the project is going, why the roadmap is like this, etc.
So something a bit more detailed than the roadmap. Meeting minutes of such zoom calls could be relevant. But that’s some work to do… That’s why I suggested something like
project as it’s fairly quick to update and follow.

But I am a new player here, so I am just suggesting as you (the maintainers) will have to do most of the work here.

Cheers,
Pamphile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210228/20d01f11/attachment.html>