Being a maintainer of ScoopInstaller

[Lutra-Fs]

Hi everyone,

Following up on a previous discussion from 2021 ScoopInstaller/Scoop#4456 about the need for additional maintainers, I wanted to revisit this topic.

While many maintainers was added at that time, their focus may have been shifted since then. It seems the main ScoopInstaller/Scoop repository https://github.com/ScoopInstaller/Scoop/commits/develop/ is still facing a review bottleneck. The develop branch hasn't received the review coverage it needs to ensure timely merges and a healthy development pace.

Given this situation, I believe it's again time to actively seek additional maintainers who can contribute to reviewing pull requests, addressing issues, and helping to guide the future direction of Scoop.
To that end, I'd like to offer myself as a candidate. As an external maintainer of https://github.com/ScoopInstaller/UpdateTracker and based on my other contributions to the ScoopInstaller organization, I feel I could be a valuable addition to the current member of ScoopInstaller organization.

What are your thoughts, both on the general need for more maintainers and on my potential to contribute? What other steps can we take to identify and onboard new maintainers effectively?

Regards,
Lutra-Fs

[HUMORCE]

/cc @rasa @niheaven

[deevus]

I've added you to @ScoopInstaller/maintainers

Welcome to the team!

[rasa]

@Lutra-Fs Thank you for your support, and I would have added you when you posted your message, but I didn't see it until now, for some reason. My apologies.

[Lutra-Fs]

Thank you all for the warm welcome!
I’m excited to join the maintainer team and contribute more directly to Scoop!

[z-Fng]

Would it be possible to bring on more active maintainers?

The ScoopInstaller/Scoop repository is still moving quite slowly.

My PRs, even for minor changes, have also been stuck for a long time.

[z-Fng]

Thank you so much for trusting me with this opportunity~

I’ll start with some simple works and spare no effort to help!

[deevus]

Thanks mate. Don't burn yourself out. I think that's what has generally happened previously.

FYI I am not using a Windows machine anymore so I am not currently using Scoop. I am merely operating as a custodian.

[z-Fng]

Thanks mate. Don't burn yourself out. I think that's what has generally happened previously.

haha. Got it. Thanks for the reminder!

FYI I am not using a Windows machine anymore so I am not currently using Scoop. I am merely operating as a custodian.

Understood. Still really appreciate what you're doing.

[Lutra-Fs]

Welcome @z-Fng!

[z-Fng]

@Lutra-Fs Thanks~ ❤️

[cscnk52]

I also want to be a maintainer.

I have previously committed to Extras and Main bucket, and the extras/wechat package is maintained by my repo, and I have an own scoop bucket cetacea for scoop.

I'm a fan of scoop, and I want to make scoop better.

cc @rasa @deevus

[deevus]

Noted. Let me review and I'll get back to you.

[deevus]

To all @ScoopInstaller/maintainers please let me know if you are still active by replying to this message.

[deevus]

The majority of the burden is on manifest review IMO. You only have to look at some of the default bucket repositories to see that.

The admin team should be limited to those with years of built up trust. The recent drama with RubyGems has highlighted that for me.

The maintainers team serves a great purpose, however it might be worth considering another team for core. It's less about permissions and more about organisation.

Perhaps it doesn't make sense to others, but it would make it easier for me to help keep on top of making sure that we have enough people in each team (or role).

I don't want the confidence of users to wane because there's not enough manifest reviewers for example.

[chawyehsu]

Organization structuring often requires consideration of permissions.

If your intention is to create a new team for non-bucket/PowerShell-related repositories, then you may need to take into account write access for repositories not just Core, but also Install, GitHubActions, and others. However, members familiar with these repositories usually also maintain bucket repositories (just with relatively less time to do so). As such, this new team would not be suitable to name as Core/PowerShell-related. Such a sub-team would already overlap with the Admins team in composition. Unless you want to create separate teams for every single repository, which I believe is feasible but would make the organization complex. If the 2–3 people for non-bucket repositories are not enough, you can instead directly use the repository’s access roles to assign specific members - for example, granting write access individually to members active in the Core repository but who are currently in the Maintainers team. Though you can create an additional team, but still use repository access settings to grant specific permissions. This would be equivalent to team being used purely for tagging/classification - like /active and /alumni, which I think is good as past contributors may want to keep their org member status without having permissions preserved, and they deserve.

Every member of the Admins team has been trusted for years. Unless you intend to cut seats or people plan for retirement, it should indeed remain under controlled scope. A fun fact: I’m currently the only admin member without the owner role; back when the Admins team was created, the team creator seems to have mistakenly modified my role, resulting me unable to do org-wise maintainence such as team management.

But as you said, most of the workload right now is in manifest reviews. The Maintainers team already meets the demand of organization, it only needs new reviewers. Noted that some bucket repositories even have external collaborators who aren’t in any team.

[Lutra-Fs]

I believe one of the main challenges facing the Core repository is the lack of a clear roadmap and prioritisation framework like GitHub projects. There are longstanding issues—for example, with the persist field and with git history and for the bucket manifest's amounts concern—that have not seen substantive progress, while some very old PRs (dating back to 2020) remain neither merged nor closed with no clear status.

Additionally, the permission structure for maintainers could be revisited: providing maintainers with the ability to help manage (triage, label, or close) issues in Scoop repositories could be very valuable, without necessarily granting access to manage PRs or code, which remains a sensitive area.

Addressing these would help clarify development priorities and empower maintainers to contribute more effectively to repository hygiene and community responsiveness.

[rashil2000]

Hi all, I have not been active with the Scoop project for the past couple of years or so - I remember being burnt out at some point with the bucket maintenance and didn't get back to contributing properly after. I still daily drive PowerShell and so I'm comfortable with it - but I use it on my company-provided Mac most of the time and rarely touch my Windows laptop.

Scoop had been a passion project for me back in my college days and I'd spent countless hours trying to make it the go-to dev tool on Windows. I'm okay with any re-org that happens, but I would like to preserve my maintainer access for when I finally muster up enough will to contribute again to the Core.

[Calinou]

I'm still active on https://github.com/Calinou/scoop-games, reviewing new manifests and update PRs as they come. However, there's a backlog of old manifest PRs I haven't had the time to get to.