Mason governance

[AdrienLemaire]

Hi @williamboman .
Mason registry PRs have been piling up for a few months, and I can't see any team of contributors helping you out with reviewing/approving PRs.

Have you defined governance rules for this project somewhere, or would be willing to ?
Hopefully my github foo isn't failing me and the discussion hasn't already been done elsewhere.

Pinging a random subset of people who might be interested by this discussion (sorry for the noise otherwise):
@SimonSchwendele @tristan957 @pinbraerts @akshay-ctxl @eratio08 @schlerp @mawkler @gorillamoe @Joelius300 @Conarius @chrisgrieser @cwrau @akarl

[gorillamoe]

I would like to help out if I can somehow. Just reach out to me here or on Discord.

[pinbraerts]

Dear William,

Your project has become an incredibly valuable tool for developers. Mason and utility plugins provide a solid yet flexible development environment. In just a few keystrokes, they enable the exploration and trial of tools that one might not have been able to discover and configure on it's own.

I would be delighted to contribute to this wonderful project, whether through reviewing, validating licensing information, or developing automation tools. I understand that we all have professional commitments and may sometimes be very busy or face personal challenges. However, the power of the community lies in our ability to tackle such difficulties together.

The project is truly important to us, and I would like to learn how we can assist in its further development. You can count on me as well

[tristan957]

I can help out, but I'm also not a prior Mason contributor. My understanding is that we could just fork the registry and tell people to point the plugin at the new registry. We can also fork the plugin to make that the default.

I think burnout when you have a whole community depending on you is all too common, so if we can democratize maintainership, the entire neovim community can win.

So, +1 from me. Perhaps we should start with collaborating on governance of the fork. What does organization look like. I think we can learn a lot from how linux distributions democratize package maintenance.

[gorillamoe]

I actually started something like this as a private project, when I saw the PRs piling up here, but I would refrain from forking this and pointing people to the new "source of truth".

I would like to help out with the already existing project, or start completely new without a fork, because I'm not that familiar with the licensing stuff that is going on here.

It's not MIT and that is the only license I really grasp. MIT, you can do whatever you want.

I quick glance at the private thingy:

But as I said, I would prefer to work on Mason.nvim and keep it alive.

[tristan957]

Yeah, I agree that a fork should be the last straw. It just depends if William can help bootstrap us with permissions and such.

Step 1 would be moving this repo to the mason-org organization, and then add some initial people with the proper permissions.

[Conarius]

I'd also like to help out, especially for the registry. Have been contributing a lot to the registry but it really takes a long time until things get merged.

[williamboman]

Hello and thanks for reaching out! I definitely could use help with the maintenance of the project, and is something I've been planning to do ever since the creation of the registry - so let's get that started!

I know there are a lot of open PRs in the registry at the moment. A few of the open PRs have already been adressed in another PR, then there's about 50 PRs from @Conarius that adds VSCode schema entries (I'll address these a bit further down). The rest are primarily additions of new packages. A few of these new packages are (or at least were at the creation of the PR) at least one of the following:

1. very new (weeks to a couple of months since inception)
2. low notability (some kind of social proof of their usage, e.g. stars, search hits, download stats)
3. have a problematic installation method that cannot be adressed in the PR itself (uses a 3rd party unaffiliated redistribution source etc.)

I've become increasingly more careful with what packages are added to the core registry for two reasons:

1. Mason has garnered a pretty significant user base. The Mason Registry API receives 4-5 million requests per month at this point. I'd like to add that the mason.nvim client isn't particularly chatty either, it's primarily requests related to checking for registry updates. I'm very mindful of the fact that the project has become a larger target for actors with bad intentions.
2. I get the impression that many distros are automatically installing (and later executing) packages via Mason. This is something I really don't like, and also the reason some requested features related to automating installations has not been added to mason.nvim even if they're relatively trivial to add. I've always wanted users to explicitly interact with mason.nvim and actually understand what they are installing and why. This is why a lot is centered around the UI and not so much programmatic interfaces, although Lua APIs exists for users who do want to automate things. I worry that once a package is added to the registry it doesn't take long before it starts getting downloaded and executed en masse without any explicit user interaction.

The above has led me to spend more and more effort auditing each new package request, including assessing potential demand, the author(s) behind it, the release pipelines, and source code. Much of this can, and should, be automated through various APIs (see for example https://socket.dev/). This has unfortunately also led to me missing PRs that should be merged much faster. I've also largely stopped engaging in discussions and turned off notifications because I don't have the capacity to constantly manage dozens of async discussions. When I do attend PRs I try to focus on the oldest ones first but I'm being outpaced by the amount of new ones, and I don't have the same amount of time to spend on this as I had previously.

As for me personally, I wouldn't mind being more liberal with package additions and also expand the scope of the project (for example including packages such as mason-org/mason-registry#5000), but the popularity of the project demands some discipline here, and the broad implementation of automagic package installations in distros has the potential to cause some fundamental issues (see mason-org/mason-registry#3872).

I've obviously not been able to find a good balance as the project has grown, and the backlog feels a bit insurmountable at the moment as I've had to spend more time on other commitments (I also didn't anticipate the volume of PRs would remain as high as it's been). I'd really like some help with the day-to-day maintenance but also receive input with regards to finding a sensible and robust approach to the concerns I outlined above. Please reply to this post if you'd be interested in helping out and I'll invite you to a @mason-org advisory team where we can continue discussions.

---

I'll also address the schema PRs from @Conarius here. The schema entry and the visualization of it in the Mason UI was primarily added for packages that actually provide an independent configuration schema (see pylsp). Unfortunately a lot of LSP implementations merge the VSCode plugin configuration schema with the LSP server schema, for which the vscode: prefix was added. These merged schemas are most of the time of low value and a net negative because they mostly include VSCode-specific settings. The packages that already have a vscode: schema are ones that I've manually reviewed and cross-checked (this is done manually by going through the LSP source code) to be of high enough value to warrant inclusion.

One of the original reasons for the schema property was to motivate LSP authors to start providing independent configuration schemas (the idea being that users or authors themselves would drive this effort), but it doesn't seem to have had much of an impact yet, and adding vscode: schemas sort of defeats this purpose.

I'm a bit stuck with your PRs because I don't want to abruptly close 50 PRs that you've spent a lot of time creating and I also don't have the time to review them properly.

[Conarius]

Thanks for the explanation!

From what I have read I think the first thing would be to have these standards documented so everyone know what will be accepted and why certain things will take some time. (It's also sometimes part of my job tbh).
Once all the necessary stuff is documented I think more maintainers can then be added as now everyone involved knows how to handle all these things.

[AdrienLemaire]

I'd love to help, but don't add to the advistory team people who can't even install the proper yq/jq version to test PRs locally 🤡

It will be nice to have some onboarding process to join the reviewer team. Maybe lay out what's expected from a reviewer (assessing potential demand, the author(s) behind it, the release pipelines, source code ...), ask the candidate to review a PR and write down his findings in a template, then have another reviewer (William at first) double-check to confirm the candidate is thorough enough.

[Conarius]

Small disclaimer for anyone subscribed to that discussion:
The signup for maintainers is over here