Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⚠️ The Gorilla Toolkit is Looking for a New Maintainer #659

Open
elithrar opened this issue Dec 12, 2021 · 28 comments
Open

⚠️ The Gorilla Toolkit is Looking for a New Maintainer #659

elithrar opened this issue Dec 12, 2021 · 28 comments

Comments

@elithrar
Copy link
Member

@elithrar elithrar commented Dec 12, 2021

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.

@amustaque97
Copy link

@amustaque97 amustaque97 commented Dec 12, 2021

Hi @elithrar 👋, 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 😄

@elithrar
Copy link
Member Author

@elithrar elithrar commented Dec 12, 2021

@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.

@tinyzimmer
Copy link

@tinyzimmer tinyzimmer commented Dec 13, 2021

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.

@asankov
Copy link

@asankov asankov commented Dec 13, 2021

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.

@gronsy
Copy link

@gronsy gronsy commented Dec 13, 2021

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.

@DKANomad
Copy link

@DKANomad DKANomad commented Dec 13, 2021

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!!

@codysnider
Copy link

@codysnider codysnider commented Dec 13, 2021

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.

@elithrar
Copy link
Member Author

@elithrar elithrar commented Dec 13, 2021

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.

@bluebrown
Copy link

@bluebrown bluebrown commented Dec 13, 2021

I'd be down to look into a few issues as well. I will see if I can find something to get started with. Would be sad to let this library die.

@juiceppe
Copy link

@juiceppe juiceppe commented Dec 13, 2021

Hi!
I’d be more than happy to look into issues and help!

@gorilla gorilla deleted a comment from christoofar Dec 14, 2021
@gorilla gorilla deleted a comment from jxsl13 Dec 14, 2021
@gorilla gorilla deleted a comment from christoofar Dec 14, 2021
@weex
Copy link

@weex weex commented Dec 14, 2021

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.

@elithrar
Copy link
Member Author

@elithrar elithrar commented Dec 14, 2021

@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.

@weex
Copy link

@weex weex commented Dec 14, 2021

@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.

@anthonygedeon
Copy link

@anthonygedeon anthonygedeon commented Dec 14, 2021

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.

@soundkitchen
Copy link

@soundkitchen soundkitchen commented Dec 15, 2021

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.

@alexellis
Copy link

@alexellis alexellis commented Dec 16, 2021

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?

@elithrar
Copy link
Member Author

@elithrar elithrar commented Dec 16, 2021

@alexellis I mention websocket in the opening post ;-)

@Joe8Bit
Copy link

@Joe8Bit Joe8Bit commented Dec 17, 2021

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.

@muhammednagy
Copy link

@muhammednagy muhammednagy commented Dec 26, 2021

Thank you so much for your work @elithrar
I Would love to volunteer :)

@truyetnm
Copy link

@truyetnm truyetnm commented Jan 4, 2022

I'm interested with gorilla toolkits, What am I doing to become a maintainer?

@amustaque97
Copy link

@amustaque97 amustaque97 commented Jan 4, 2022

👋 @truyetnm , please go through this comment. #659 (comment)

It explains everything. If still there is something. Feel free to ask.

@truyetnm
Copy link

@truyetnm truyetnm commented Jan 5, 2022

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.

@maczamora
Copy link

@maczamora maczamora commented Jan 5, 2022

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!

@zak905
Copy link

@zak905 zak905 commented Jan 9, 2022

Hello everyone, I have submitted a PR to the schema project gorilla/schema#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.

@shenqidebaozi
Copy link

@shenqidebaozi shenqidebaozi commented Jan 21, 2022

@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.

@shenqidebaozi
Copy link

@shenqidebaozi shenqidebaozi commented Jan 21, 2022

@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.

oglinuk added a commit to oglinuk/restful-go that referenced this issue Jan 22, 2022
After looking more into the issue I ran into with `mux.Vars` being empty
when testing, I came across [issue
659](gorilla/mux#659). Found a way to handle
path variables not being populated in
`internal/api/resources/book_test.go`. Test for `BookById` is now
working. Added test for router routes in
`internal/api/router/router_test.go`. Using the recommended base
middleware `RequestID`, `RealIP`, `Logger`, `Recoverer`, and `Timeout`.
@wubin1989
Copy link

@wubin1989 wubin1989 commented Jan 22, 2022

@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.

@elithrar
Copy link
Member Author

@elithrar elithrar commented Jan 22, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet