mux
mux copied to clipboard
gorilla
⚠️ The Gorilla Toolkit is Looking for a New Maintainer
The Gorilla Toolkit is looking for a new maintainer (or maintainers, plural). As the last standing maintainer of the project, I no longer have time to fully dedicate to maintaining the libraries across this project.
The major libraries — mux (https://github.com/gorilla/mux), schema (https://github.com/gorilla/schema), handlers (https://github.com/gorilla/handlers), and sessions (https://github.com/gorilla/sessions) — are all reasonably mature libraries, but ongoing stewardship around bug triage, feature enhancements, and potential "version 2.0s" are all possibilities.
The core asks of any new maintainers:
- Have a demonstrated history of OSS contributions. This is important, as you need to be trustworthy: no maintainer is better than an adversarial maintainer!
- Ideally, you actively contribute for 3-6 months, I merge after you review, and you gain the commit bit on the relevant repos after that period and/or active engagement on your part.
- I transition you to admin of the project.
Note: I don't expect this to be quick or easy - the websocket library, with 16k stars & 15k unique clones per week, has been looking for a new maintainer 3.5+ years, and has yet to have anyone reliably stick.
If I don't have any luck finding new maintainer(s) in the next 6 months or so, it's likely I'll mark these projects as in maintenance mode only and archive the repos.
Please keep the replies on-topic.
Hi @elithrar :wave:, I would love to volunteer here. Though I have not worked much on Go side but would love to quickly pull up my socks. I get enough time everyday to work on OSS. At least min 2 hours almost everyday. So I can plan accordingly.
If you have doubt that about me a stranger to this project. We can get this running for a couple of months. I will contribute and try to be regular and based on that you are free to take decision.
At last, my area of interest would be handlers and sessions.
Looking forward to hearing from you. Have a great day ahead :smile:
@amustaque97 - great! The best thing you can do is actively contribute - both repositories have a number of open issues that need review, as well as PRs that need review, rebasing, and/or in many cases, to incorporate comments.
Mark issues as "close this" (I will close them), and using GitHub's review tools and @-replying me to merge. I'm still expecting some sense of design review - if the goal was to just merge every PR, I would have done that already 😉
A note for others reading this: Others who are interested should still reply, or better: get actively involved! Unfortunately, I've yet to see "net new" maintainers stick it out - most projects survive through existing community members who were already engaged. This is not a reflection upon @amustaque97, but a very real observation.
I am "actively" (in quotes because my situation is similar to yours, yet I stilll have some free time) maintaining a project here that relies on the toolkit quite a bit. I had considered switching frameworks, but I can poke around and see if I am able to offer my services here and turn this into something mutually beneficial.
Hello, I am interested in being a maintainer of the libraries.
I have been working with Go full-time for more than 2 years. I have used the gorilla projects (namely mux and handlers) both in my personal projects (used directly) and in my job (using them via an wrapper, e.g. echo framework which uses gorilla/mux under the hood).
I am willing to take the necessary time to get more in-depth on-boarding with all projects and have my contributions reviewed by you in that time.
Hello, I'm interested in maintain the project. I've been working with go for last half a year actively in work where mux is one of main libraries. Although not sure if I'd be able to contribute in the next few weeks to a month because I'm in a middle of country move I'd want to do some contributions when I'm setup.
Hi, I am not volunteering. I just wanted to thank you for your time and effort thus far is maintaining gorilla.
I taught myself go during lockdown and one of the first packages I made use of in one of my toy projects was mux.
So thank you for the hard work and happy holidays!!
I'll volunteer. Maintainer or not, if someone else gets the job and wants to toss me a few bug tickets here and there, go for it. I've used this library a LOT and have no problem giving back to the community.
To re-state - the best way to contribute is to jump in!
I don't have the time to actively assign or triage issues. Folks interested in getting involved and getting a "commit bit" need to demonstrate by doing.
In the interest of helping the project find new maintainers, I would like to ask if it is possible to expand on the requirements and succession process perhaps codifying it into a protocol. There's a risk, whether perceived or real, that maintainer(s) might make contributions for 3-6 months but that for whatever reason the process stalls and the project is archived all the same.
This is a valuable opportunity to figure out how best situations like this can be handled to minimize disruption to users, developers and the broader open source community. Ideally, the project after this succession process is protected against a repeat and can be held up as an example of how to do it right.
@weex I specifically want to keep the barrier to entry low here: otherwise we risk finding no one at all. The most likely maintainer is someone who is already engaged in the project.
I am also stretched for time: I care a lot about this project, but don't have infinite time to define a protocol to validate a new maintainer against. If I did have the time, I probably wouldn't be looking for a maintainer.
Candidly, your response is absolutely one of the reasons being a maintainer is hard. The expectation that we here have a duty to define some long-lived protocol for finding and validating new maintainers that reaches across projects beyond this one, with the implication that not doing so disrupts users, looks reasonable at face value but is a pretty tall ask. That I'm trying to find a maintainer, and allowing several months to do so, should be enough.
@elithrar I fully appreciate the situation and did not want to single you or the project out or give the impression that any more work is expected. I'm interested in problems like this one because I feel it's not talked about enough and at the risk of going off topic, it's only during times like these that, people want to take the time. For anyone who's interested to discuss this more I've created a sort of meta-issue.
It seems there's been a good response but if none of the candidates pan out, there's a site called Adoptoposs that seems to be a matchmaker for maintainers and I think it would be neat if maintainer-swap arrangements became more common.
Hello @elithrar
I'm really interested in becoming a maintainer, specifically for @gorilla/mux. However, It seems I need to brush up on my Go skills since I've been out of touch with the language lately. Nonetheless, I can actively contribute and close issues periodically as I have a lot of time out of the day.
Hello @elithrar
I am interested in gorilla/mux maintainer. I usually use gorilla/mux to implement web server in golang, so I would be very happy if I can be of any help.
I'd like to start with code reading and checking issues and pull requests.
Thank you so much for mux. It's very widely used as you may know.
What's the story with your websockets library? Is it the same situation?
Thanks so much for all your contributions @elithrar!
When a new maintainer is found we'd be very happy to work with them and provide significant financial support for the maintainership, or even (if it makes sense for us both) to employ them full-time to maintain the toolkit. We're a fully remote company, headquartered in London, so location is very flexible.
I'm the CTO at Banked, we're a fintech who has a lot of interest in maintaining and expanding the gorilla eco-system.
This is obviously @elithrar's ball-game, but I'd really like to talk to anyone who takes over maintainership of the toolkit. We want to put our money where our mouth is and support the community.
Thank you so much for your work @elithrar I Would love to volunteer :)
I'm interested with gorilla toolkits, What am I doing to become a maintainer?
:wave: @truyetnm , please go through this comment. https://github.com/gorilla/mux/issues/659#issuecomment-991936970
It explains everything. If still there is something. Feel free to ask.
Hi @amustaque97,
I'm interesting with web server technology, somethings like mux, session, handler and websocket. Currently I'm working on go framework go-kratos, it used gorilla mux for http server so I want contribute gorilla toolkit to make it better.
Hi Folks, I wouldn't mind lending a hand on here a a few hours a week and help fix bugs or write tests for some GO code. I've been practicing and learning about GO and would like to get immersed a little more into OSS more. This seems like a great opportunity. I plan on actually trying to implement mux for personal use.
I will check back later for any responses and help out with any open issues.
Cheers!
Hello everyone, I have submitted a PR to the schema project https://github.com/gorilla/schema/pull/183 for a while now. Anybody would be interested to review and give feedback. This could be the opportunity to show project maintainers our collaboration, team skills, and maybe we could be chosen as project maintainers.
I am interested in schema project because it looks like approachable and likely to not very time consuming to maintain.
@elithrar Hi, brother, I am the maintainer of the micro service framework Kratos. In Kratos, transport/http is based on mux, and mux based HTTP declaration code can be generated through the proto-gen-go-http tool. The Kratos open source community is willing to participate in mux future maintenance tasks.
- https://github.com/go-kratos/kratos/tree/main/transport/http
- https://github.com/go-kratos/kratos/tree/main/cmd/protoc-gen-go-http
@elithrar mux is a very good project. If it can, it will be maintained by Kratos open source community, not myself. Drive project maintenance through the open source community.
@elithrar I am the author of go-doudou microservice framework. Its http part is heavily relying on gorilla/mux library. I love gorilla Toolkit and want to be its maintainer. It's my honor and dream. Here is go-doudou repo: https://github.com/unionj-cloud/go-doudou for your reference.
@wubin1989
To re-state - the best way to contribute is to jump in!
I don't have the time to actively assign or triage issues. Folks interested in getting involved and getting a "commit bit" need to demonstrate by doing.
@elithrar Hey, I just wanted to say 'thank you!' These packages have been around since nearly the beginning, and it's pleasure to see them in use because they're easy and fast to use. I personally don't have time to dedicate to being a maintainer or contributing in a serious way. I just want to reassure you and whoever else that does/will manage this collection of code that it is much appreciated. If there are ways to contribute that don't require a big time commitment, I'd love to help.
Hi, Please consider some help from my side, ... volunteering, of course. Not having plenty of time, but anyway :-)
Hi bro, first thanks for your time and project, I think I can’t match the requirement for the maintainer status, really in OSS since 1 months but I slice in 👀 and if any want help or support, I’m here !
Lot of my private project use mux, and my first OS project too, have a good day !
