Looking for maintainers

[tamasfe]

I had many plans with this project but it has become apparent that I currently cannot seem to dedicate any time to OSS and it's not clear when this will change.

I'm looking for maintainers to take over this repo, mainly to triage PRs and publish new versions.

[panekj]

I've been watching over the issues and PRs for some time now but I haven't been able to act on anything yet since I'm spread thin over different projects but I would like to help out and should be able to focus a little bit more on this project fairly soon
(My motivation is proper TOML support for https://github.com/lapce/lapce)

[ia0]

I don't want to commit just yet, but I'd like to co-maintain. Taplo is an important tool in my workflow providing considerable value. I'd like to keep it in good state.

[tamasfe]

Thank you @panekj and @ia0. I have invited you both as collaborators.

I'll somehow have to renew the vscode marketplace token, other than that releases should just work via github actions, so they are not blocked by my absence anymore.

[ia0]

Thanks @tamasfe !

@panekj How do you want to go through the backlog? I'd suggest those priorities:

1. Going through the continuous integration and make sure there is enough testing that we could be confident changing things without breaking too much. (For example, I didn't see much testing about LSP interactions.) Or at least be aware of which areas need particular attention because they are not as well tested as others.
2. Going through the pull requests: triaging and starting to merge the most simple ones (like dependabot PRs, which should also reenable it automatically because it's currently paused).
3. Going through the issues: mostly triaging.
4. Make a release if needed.

[panekj]

I would like to see #361 and #366 merged first and rest is best effort :)

[ia0]

I would like to see #361 and #366 merged first and rest is best effort :)

Sounds good. I've reviewed those 2 PRs. On my side, I'd like at least to merge all dependabot PRs and #354. Should I wait for your review on them or can I go ahead and merge if I'm satisfied with the PR state?

[ia0]

Ok, I went through all PRs and approved those that look good and commented on the other ones. How do you want to proceed regarding merging? Do you want to also review the PRs before merging or can I go ahead and merge them?

[panekj]

I think that the 2nd person that gives approval can merge them. I would like it to be coordinated and prevent any mistakes, so IMO, PRs should be reviewed by both of us, then someone can merge them.

[ia0]

I totally agree with the double-approval strategy. Thanks for having gone through the PRs! I'll do another round on those still unresolved.

[ia0]

I would also suggest another convention for merging PRs:

1. If the PR is not authored by us, then it should be approved by both of us and the second approver merges it.
2. NEW If the PR is authored by us, then it should be approved by the other person and the author merges it. The rational being that the author knows better if the PR is ready for merge or if additional work is needed.

[ia0]

(FYI: I'll be on vacations from 2023-05-21 to 2023-06-11 so might not be able to address anything during those 3 weeks.)

[JounQin]

Do you have active maintainers here? If no I'd like to take over although I'm still not a Rust specialist yet, but we're blocked by the current project status like #480.

If this package still remains such maintainac mode, we'll have to fork and release our own variant which we want to avoid very much.

Final words, if you agree to transfer the crates and npm permissions, please transfer the repository to @unrs.

Great thanks!

[ia0]

Thanks for volunteering! @tamasfe is the owner of this project and can answer your question. Currently @panekj and me do some passive maintenance (on my side, I'm only looking at Rust and TOML related issues, because I'm not familiar with VSCode and JavaScript).

[panekj]

From me, it's mostly experienced with Rust code and generally looking for editor integration via LSP, but I'm familiar with JS/TS and I'm (mostly) VSCode user so I can handle that part of project as well.

Final words, if you agree to transfer the crates and npm permissions, please transfer the repository to https://github.com/unrs.

I'm against any kind of transferring permissions to anyone as it would pose a threat to any user that is currently using the project and any future users too (especially those migrating from different TOML plugins) and I also think there is no need for such action, as releases can be handled purely by CI.

[JounQin]

@panekj Thanks for responding, if you guys can help to release new versions that will be no issues then. So, can you help to resolve #473 and #480?

[tamasfe]

Hi @JounQin and others, sorry about not replying here earlier I've only been following this repo passively for some time.

Apart from core code quality issues the main blockers of Javascript-specific releases are:

• exposing Rust to Javascript via WASM is fragile and limiting, the reason why the npm version of the cli has no lsp available is because i/o has to be manually bridged in Javascript and was too cumbersome to do so with the current approach.
• I've found no good way of maintaining and deploying multiple Javascript packages that depend on each other in a painless way, I'm sure there are tools (lerna, nx, and whatever the current trend is), but after a while I just gave up looking and went with the mostly manual approach.
• there are no tests for the lsp itself and the vscode extension, any regressions are likely to reach users and we have to revert some of the already infrequent releases

I'd be happy to add you as a collaborator (and also give access to deployment targets like npm) if you wish to help resolving any of these issues.

I'd rather not give up ownership as I still do development related to taplo privately from time to time (refactors, different approaches, fixes, features) that will eventually probably reach this repository.

I imagine the following scenarios regarding the project:

1. the project is passively maintained (fixes and small releases) forever or eventually dies
2. same as 1. but instead I pick it up again at some point to continue development
3. someone else picks it up and I eventually just stop caring
4. someone picks it up, it diverges from my plans and I'll eventually create a competing project with a very similar feature-set

I'd like to avoid 4. if possible, so I'd rather not give up ownership as long as there is even a slight chance that I'll come back to this.

The scenario where someone picks it up and the development aligns with the direction I'm planning is unfortunately not something I see currently as it would require dedicated time for planning and communication from my part which I cannot guarantee.

Of course if this answer is not satisfying, forking is always an option, the licenses allow just that and I'd hate to hold anyone back. I'm even happy to answer questions regarding the legacy code if I can.

[JounQin]

@tamasfe Thanks for responding and your great efforts on this tool.

I personally really want to help maintaining this repo actively. And it's great to hear that you still want to maintain it in long-term.

For collaboration, I have two proposals:

1. create a new org like @taplors
2. reuse @unrs add I invite you as a maintainer of the org or repo admin

The benefit of GitHub org is the collaboration workflow.

But of course, it's up to you. I also agree to only be a collaborator in your personal repository.

Finally, I still want to thank you for the hard work on the package. Your efforts are much appreciated. ❤️

[tamasfe]

Thank you, I've invited you as a collaborator, I'm not against turning taplo into an organization at some point though but I see little benefit right now. Ping me if you need additional access for deployments (e.g. tokens expired from CI).

[JounQin]

@tamasfe Let me try to resolve/finish #502 first ASAP.

[ia0]

@tamasfe Given that I'll soon be unable to continue contributing to this project and that we now found @JounQin, you can now remove any special permissions I have on this repository. I'll continue to follow up for a little while though. Thanks!