[RFC] Proposal to add more maintainers for long term project growth

[Enter-tainer]

Dear typst-lsp Maintainers and Contributors ,

Firstly, I would like to express my deepest respect and gratitude to the @nvarner . Your hard work has allowed typst-lsp to evolve into a tool that we all rely on and it is the infrastructure of the typst ecosystem.

I have noticed that, for various possible reasons, updates and maintenance of the project may not be as frequent as before. We fully understand that maintaining an open-source project requires a significant amount of time and effort, a contribution that cannot be measured in monetary terms. Therefore, I would like to propose a suggestion to help us collectively propel the development of typst-lsp.

With the growth of the project, we have seen some members who have been exceptionally active and professional in issue discussions, pull requests. To support the continuous development of typst-lsp, I suggest considering the expansion of maintainers.

For example here is a list of top5 contributors in the past 3 months: @PgBiel @Myriad-Dreamin @Enter-tainer @KillTheMule @astrale-sharp

I would like to ask for the community's and current maintainers' opinions:

1. Do we agree to invite more maintainers to join our team?
2. Regarding the mentioned community members, are there any other opinions or suggestions?

I hope hearing everyone's thoughts and am willing to participate in the discussion and implementation process.

[astrale-sharp]

Hey there, thanks for this proposal ❤️ If nvarner is okay with this, i would indeed love to be more invested in this project, i love ide stuff The project is really complex and i think there's a lot of stuff that only nvarner could give the final go to a change In the time we need to get experienced enough to decide what's possible to merge, we could have a board of maintainers where two of us or more review PR's or our own work to do most of the work before nvarner has to confirm.

[PgBiel]

I can certainly help here in some form or another (maybe not with active contributions, but maybe reviewing from time to time, or other organizational stuff?).

With that said, I gave this proposal some thought and I was thinking that this could perhaps link to the idea of a GitHub organization for active contributors in the Typst community, similar to nix-community. We could move some more important community projects to that organization and make it easier to shift projects' maintainers over time, given consent between all involved parties. (Regarding the name of such an organization, it seems that someone has already taken the typst-community name, so I'm not sure if they'd be willing to give it to us, but that's something to consider.)

OTOH, while that seems sort of "ideal", it's understandable that not every large project owner could want to "forfeit" ownership of their own project like that - even if they'd remain the sole maintainer, it's valid to worry about being subject to bad management from the organization and thus involuntarily lose control over their own project. Therefore, such an approach would have to be planned out very carefully in order to ensure that the whole process is voluntary, and nobody is taken away from their projects without consent. Exceptions could be added in that regard, such as bad behavior by a specific project's maintainer (e.g. intentional "malware" being pushed or being inactive for several years or something else), but that could also be controversial. We'd have to study how nix-community handles this.

(Perhaps a more viable alternative to the above is have a smaller-scale organization of specific Typst contributors, not aiming to be the sole organization of contributors. But I'm not sure!)

So, for the time being, maybe a smaller scale organization, such as one named just "typst-lsp", could be created with a handful of contributors, and the current project leader (@nvarner) would naturally be the leader of the organization. Or maybe some other approach is possible. But we'd definitely need feedback from them - maybe that's not what they desire at all, and that'd be 100% fine. We can always investigate other alternatives to help them - and each other - as much as possible. 🙂

[nvarner]

@Enter-tainer no need for the formality: you're entirely correct, and I really should have added some maintainers earlier. You or any of the people mentioned would be great.

For those interested, please leave a comment here.

@astrale-sharp you sound interested; to be explicit, would you like to be a maintainer?

[Enter-tainer]

thank you @nvarner I'm very glad to become a maintainer. I've go through lsp's code before and handled serveral typst version updates. I'm on work in weekdays but I have time in nights and weekends.

[Myriad-Dreamin]

I'm fine with being a maintainer.

But there is a question I'm not sure. It is that if there will be many maintainers, what's the best way of reviewing and accept PRs for lsp project? This should be determined by @nvarner.

[astrale-sharp]

I would love to be a maintainer (but I might need guidance at first)

[nvarner]

@Enter-tainer @Myriad-Dreamin @astrale-sharp thank you! I'll set you up as maintainers soon.

In terms of merging PRs, I'm not yet sure the best approach. For now, I'll leave the current settings on GH (pass CI, any maintainer can approve).

In general, I'm looking out for correctness and maintainability issues. Here are a few of my higher-level considerations:

• The ideal implementations of language services should use relevant Typst functions when appropriate. That ensures that our code can't be broken by Typst changes (eg new syntax), so the language server will still work, and we won't have to spend time figuring out how changes affect us.
• Generalizing the above, implementations should always use the highest level API they can. So, Typst language analysis functions are best, but if there isn't one, prefer to implement it via the syntax tree rather than the raw source code (eg semantic tokens replacing TextMate, though TM seems like it needs to come back in a small way).
• LSP functionality should be written to the spec. (It's worth noting that the spec is very closely tied to VS Code and can be vague. Some things are documented only in GH issues. VS Code tends to have very good support for LSP, but some things, including syntax highlighting and configuration, are poorly or strangely integrated. It may need special casing in the near future.)

For good PRs unlikely to be controversial or have major bugs (eg crashing, breaking existing functionality), it should be fine for anyone to merge on their own. More complex ones I'm not sure, but if at least 2 approve, it's probably fine.

In the worst case, we have until each release to easily roll back changes which caused unexpected problems.

[astrale-sharp]

Amazing :D