Migrating Maintenance

[dgrijalva]

See: #457

I haven't had time to maintain this project for quite a while. I originally made it just for myself, but it appears to have become quite popular. It seems like the best course of action would be to clone this into its own org and then set this repo up to mirror that one until users can fully migrate over. That's probably also a good opportunity to correctly implement go mod support.

Does anybody want to take over as maintainer? It looks like jwt-go already exists as a github org. Name ideas?

[ripienaar]

Pinging a few who were involved in earlier discussions: @camin-mccluskey @Waterdrips @mcoops @lggomez @adamchalmers @alexells @brianmay

[ripienaar]

I'd be happy to start an org and contribute, but I'd need at least 3 others to stand up and be willing to be co maintainers as this is quite a popular lib I think good coverage is needed.

In the absence I'd vote for:

• Merges for the recent security release and one final release from @dgrijalva if he has that much time
• README is updated with links to alternative
• The project get archived having at least the major security issue fixed, thus sending a clear signal that this is the end for this one.

[Waterdrips]

I haven't had time to maintain this project for quite a while. I originally made it just for myself, but it appears to have become quite popular.

Many thanks for your work on this project @dgrijalva.

I'd be happy to start an org and contribute, but I'd need at least 3 others to stand up and be willing to be co maintainers as this is quite a popular lib I think good coverage is needed.

Happy to be involved, under the same caveat of enough other co-maintainers

[mfridman]

Indeed, thank you for the implementation and maintaining it over the many years @dgrijalva

I'd be happy to start an org and contribute, but I'd need at least 3 others to stand up and be willing to be co maintainers as this is quite a popular lib I think good coverage is needed.

I echo this sentiment and would be happy to get involved (with the caveat there would be a few others). I think this is important for a few reasons:

1. I have (and am familiar with) many downstream projects that either wrap or use this library
2. It is so widely used in the Go ecosystem and deserves to be maintained
3. It'd be a shame to see fragmentation as libraries like this benefit from the collective usage of many

[lggomez]

Sorry for the delay in my response. Also glad to see that @dgrijalva is alive after all and was just a lack of time issue. I wouldn't mind lending a hand in the project, under the clarification that my availability may be bound to work and study (as I guess it does for most of you folks). Aside from the work I did to locally port the claims fix and perform a quick glance of the code base, I see there is a lot of work which is already done to process (as for the v4 branch and all of the open PRs)

[ripienaar]

Ok so it looks like we at least have a number of initially interested maintainers.

What should we call the org?

initial names for maintainers appear to be me, @Waterdrips @mfridman and @lggomez

I need to read a bit how to create an org that’s fully independent on GitHub but let’s see if we can agree on a name first

[Waterdrips]

go-jot or jot-go? names are hard. Using the spelling of the pronunciation of JWT instead of the acronym?

[lggomez]

go-jot or jot-go? names are hard. Using the spelling of the pronunciation of JWT instead of the acronym?

As long as it doesn't have got on its name I'm on board with any of both. I'd propose a more descriptive alternative maybe but the only one I can think of (it's 9 AM here 😪) would be the inverse of the package, go-jwt but it is already taken (and also is the package name, jwt-go.

Note that golang-jwt and jwt-golang seem to be available

Using the spelling of the pronunciation of JWT instead of the acronym?

Something on this route could work also

[mfridman]

I like the explicitness of golang-jwt and it's also good for search-ability, as most users would search "golang" + "jwt"

My vote is for golang-jwt or go-jot.

An alternative might be to approach existing community orgs with a focus on oss Go packages? E.g.,

https://github.com/pkg
https://github.com/friendsofgo
https://github.com/goware

---

I doubt this would get accepted into the go /x/ package, but that would be the ideal scenario whereby the community would have an "officially" supported JWT package that has some backing from the Go team.

[ripienaar]

Hmm, was not aware of those groups, definitely worth approaching ones with 3+ maintainers I think

[lggomez]

I like the explicitness of golang-jwt and it's also good for search-ability, as most users would search "golang" + "jwt"

My vote is for golang-jwt or go-jot.

An alternative might be to approach existing community orgs with a focus on oss Go packages? E.g.,

https://github.com/pkg
https://github.com/friendsofgo
https://github.com/goware

I doubt this would get accepted into the go /x/ package, but that would be the ideal scenario whereby the community would have an "officially" supported JWT package that has some backing from the Go team.

I would mention https://github.com/gofrs, which is a group composed of new maintainers of previously abandoned or deprecated projects such as https://github.com/gofrs/uuid

[ripienaar]

gofrs look pretty good, do any of us know any of the maintainers on these projects?

[mfridman]

gofrs is probably the best option. (they are in #gofrs on the gophers slack, if you're there)

Just want to throw out other alternatives, thoughts?

1. there appears to already be a maintained fork? https://github.com/form3tech-oss/jwt-go
2. keep this repo as-is but request maintainer access to a few folks on dgrijalva/jwt-go (not sure if @dgrijalva is comfortable with that)

[ripienaar]

The reason we mentioned 1 as not an option is because (I at least) felt a independantly maintained project is best rather than one associated with some company.

[mfridman]

Unless no objections, I'll submit an issue for gofrs by end of day.

https://github.com/gofrs/help-requests

EDIT: linking for brevity (another issue was already opened) at gofrs/help-requests#41

[mfridman]

In case we don't get any responses on gofrs/help-requests#41 I propose creating a separate repo among those interested within this thread.

golang-jwt/jwt or go-jot/jwt or other, any preferences?

...
What should we call the org?

initial names for maintainers appear to be me, @Waterdrips @mfridman and @lggomez

I need to read a bit how to create an org that’s fully independent on GitHub but let’s see if we can agree on a name first

EDIT: I'll give it another ~week or so, and if no response will setup a repo here and invite the others that were interested:

https://github.com/golang-jwt/jwt

[mcoops]

I'm a fan of golang-jwt/jwt

[oxisto]

In case we don't get any responses on gofrs/help-requests#41 I propose creating a separate repo among those interested within this thread.

golang-jwt/jwt or go-jot/jwt or other, any preferences?

...
What should we call the org?
initial names for maintainers appear to be me, @Waterdrips @mfridman and @lggomez
I need to read a bit how to create an org that’s fully independent on GitHub but let’s see if we can agree on a name first

EDIT: I'll give it another ~week or so, and if no response will setup a repo here and invite the others that were interested:

https://github.com/golang-jwt/jwt

Being a little late to the party… are you still looking for co-maintainers? I would be very interested and willing to help. Stemming from my professional work as a security researcher, this project is quite close to my heart. golang-jwt sounds reasonable to me.

[mfridman]

...It seems like the best course of action would be to clone this into its own org and then set this repo up to mirror that one until users can fully migrate over. That's probably also a good opportunity to correctly implement go mod support.

@dgrijalva A clone (not fork) was created here: https://github.com/golang-jwt/jwt

What is your preference ..

1. Transfer repository to the golang-jwt org, as described here?
2. Archive https://github.com/dgrijalva/jwt-go with a README pointing to the newly cloned repo, golang-jwt/jwt?

Or did you have another approach in mind?

[dgrijalva]

Hi! Sorry for the delay. It looks like we're moving in the direction of https://github.com/golang-jwt/jwt? I have no real preference other than wanting to be careful not to break things for people currently using the library. Ideally, that means this URL remains available (for a while) and includes instructions to help people migrate to the new location.

[dgrijalva]

There seems to be a few different approaches still on the table here. Can we get to a consensus on:

• who's going to raise their hand to be a maintainer (ideally a few people)
• where will the repository live?
• what steps will we take to migrate the project?
• what instructions will we provide to users of the library to keep their projects working?

A simple option to start might be to just give maintainer access to a few people right in place. That will allow us to get out updates and address major issues while the rest is sorted out. Does anybody know if there's a reason that might be a bad idea?

[mcoops]

A simple option to start might be to just give maintainer access to a few people right in place. That will allow us to get out updates and address major issues while the rest is sorted out. Does anybody know if there's a reason that might be a bad idea?

This is preferable and would allow the critical security issues to be addressed at least, I assume you mean on the new repo not this one?

who's going to raise their hand to be a maintainer (ideally a few people)

Whoever has said yes in this thread so far (including myself) I think to begin with.

where will the repository live?

It's done? https://github.com/golang-jwt/jwt

what instructions will we provide to users of the library to keep their projects working?

I think this will simply just be a notice on this repo advising people to start migrating over? Otherwise we might be able to do a github redirect, but I think that might be unclear then what's happening.