New maintainers – and more needed

[thibaudcolas]

As a follow-up to #248 – the repository has been transferred from https://github.com/praekelt/django-recaptcha to https://github.com/torchbox/django-recaptcha.

edit: As of November 2023, we are now at https://github.com/django-recaptcha/django-recaptcha.

We got in touch with Praekelt to offer our help with maintenance, as people who were initially maintaining this package there had moved on. @tbrlpld and I are looking after the transfer (still in progress), and we’ll share more concrete plans for future maintenance once this is complete.

At this stage we are looking for more maintainers who would want to get involved with this project – please reply to this thread if you’re interested!

[thibaudcolas]

Here is the current maintainers’ roster:

(edit: updated)

• me (@thibaudcolas)
• @tbrlpld
• @Stormheg
• @atodorov
• @rgs258
• @Andrew-Chen-Wang

The people from Praekelt who helped us with the transfer have confirmed they didn’t want to be involved at this stage. I’ve reached out to one other person previously involved with the project to check what they’re expecting.

@rh0dium @atodorov I see you had volunteered to help with maintenance in other discussions – are you still up for it?

[atodorov]

@thibaudcolas yes, I can help b/c we still use this package. I am atodorov on both GitHub/PyPI depending on how you decide to setup the permissions.

[Andrew-Chen-Wang]

I think it would be great to include a GitHub tag release action to release to PyPi like at https://github.com/noripyt/django-cachalot

[thibaudcolas]

You should have all received an invite to the repository which you can accept at https://github.com/torchbox/django-recaptcha/invitations.

For releases I’m not too clear on what would be most sensible. On #248 I mentioned Jazzband, which I gather has quite a specific release process? @Andrew-Chen-Wang do you know how that compares with the "release to PyPI action from cachalot"? That’s based on GitHub releases – does that mean we trust all maintainers to create a release, with the safety that releases always match what’s on GitHub?

[Andrew-Chen-Wang]

The difference is that Jazzband has people who can specifically make releases. Anyone in a Jazzband team can merge and accept PRs, but only a designated few "release" makers can actually push to PyPi.

Somethin similar that can be done here is to allow only certain people to have release perms but all to have push perms. Another thing that Jazzband does that I personally don't like is the "you need another reviewer to merge your own changes" in open source context, but that's up to you to setup.

And yes typically a release from GitHub will say "verified" in the GitHub release meaning it was created online (usually).

[tbrlpld]

Another thing that Jazzband does that I personally don't like is the "you need another reviewer to merge your own changes" in open source context, but that's up to you to setup.

I think that actually makes sense when you give a bunch of people merge access.

[Andrew-Chen-Wang]

It makes logical sense, but there’ve been plenty of repos there (like SimpleJWT and oauth toolkit) that just go dormant with a single maintainer unable to do anything. Again, it’s personal opinion, so please set this up however you’d like in terms of security.

…

On Thu, Jan 27, 2022 at 9:17 AM Tibor Leupold ***@***.***> wrote: Another thing that Jazzband does that I personally don't like is the "you need another reviewer to merge your own changes" in open source context, but that's up to you to setup. I think that actually makes sense when you give a bunch of people merge access. — Reply to this email directly, view it on GitHub <#249 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLG4VXGZPJGPJFZBWECDDTUYFHYPANCNFSM5M3SF4UA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[cblignaut]

@thibaudcolas Thanks for taking this over. Please add me as a Collaborator again. One day I might get time for this project again.

[thibaudcolas]

👍 done! We did completely lose the list of who had access in GitHub during the transfer, if you know others we should invite please let us know.

[matthiask]

Thanks for taking over maintenance. There are quite a few unreviewed open pull requests here https://github.com/torchbox/django-recaptcha/pulls

As an open source maintainer myself I totally understand that there's never enough time for everything. I wonder if there's something I can do to help?

[Andrew-Chen-Wang]

would appreciate reviews from everyone! makes it easier when there are more eyes on PRs:) Thanks for your reviews so far:)

[Stormheg]

+1 to reviews from everyone.

Honestly, I've been intending - for some time now - to review some open PRs but somehow haven't found any time to do so :(

[john-parton]

I would love is this pull request could be rebased and merged in: #216

Or another similar fix. I have to have a manual workaround on my dev machine currently

[Andrew-Chen-Wang]

It would be great to have this only if Django is in DEBUG mode. I highly recommend instead that we create a new setting that has its default set to django debug rather than using DEBUG itself.

[thibaudcolas]

With @Stormheg now involved more and more with maintenance of this package, we’d like to take things a step further:

1. Find even more maintainers outside the torchbox organization. Though Torchbox uses this package, we’re not the initial authors, and don’t necessarily want any special ownership over it.
2. Move the package to a separate django-recaptcha organization, so people outside Torchbox can have more control over the package as needed (for example using GitHub teams).

How does that sound to people? Is there anyone who has been contributing and would be interested in becoming a maintainer?

[Andrew-Chen-Wang]

happy to be a maintainer rather than owner. I think I'll always find a new for this package:)

Agree on making a new org. Just to chip in again on why not to move over to Jazzband is that there's only one Jazzband roadie, so communicating ownership needs is effectively non-existent (i.e. if the package is abandoned, a new releaser won't be added for a long time).

[tbrlpld]

Though I did not have much time in the past for proper contributions, I'd be happy to stay involved, regardless of the organization which will own the package.

[thibaudcolas]

Thanks both :) re Jazzband, yes, We need more roadies in jazzband #196 made me hesitant a year ago and essentially nothing has changed since. So unless there were drastic changes with the direction of Jazzband, I personally wouldn’t count on it as a viable option.

[koutoftimer]

I may help from time to time.

[thibaudcolas]

From people’s feedback here – it seems like we’re heading to https://github.com/django-recaptcha. I’ve not tried it in a while but I believe GitHub will be able to set up redirects so most activities on the project shouldn’t be too impacted by the change in GitHub org "namespace".

I thought I’d give a heads’up about this one last time before I initiate the transfer :)

[Stormheg]

Thanks Thibaud!

Here's a little checklist of chores surrounding moving this package to a new org

• Fix references to github.com/torchbox/django-recaptcha in files
• Change the Trusted Publisher on PyPI to the new repository

If these tasks could be completed soon after the move, the disruption should be minimised.

[alanverresen]

I'll try to contribute as well. For now, I'll mainly focus on trying to resolve long-standing issues and get the amount of open issues as close to 0 as possible; feedback is always welcome. If help is needed with improving tests, documentation, cleaning up/improving CI/CD, etc., I can probably also help as well.

[Stormheg]

Great! I'd love contributions in the form of PRs or code reviews. Given your record of PRs and responses on issues, I'll set you up with commiter access.

[thibaudcolas]

I believe I have largely completed the move to the new @django-recaptcha organization. Here’s my first draft as to how I’d expect things to work from then on, though you’re very welcome to disagree or make changes.

There is a risk of this feeling like a pecking order of sorts. I want to be very clear that our goal here is to collectively make sure this package keeps being useful to its users, and so far, the biggest threat to this has been the lack of people with enough permissions to do basic maintenance. So for the lack of a better model, our goal here is to have a meritocratic system in place where people have a clear path from being an unknown user of the package to a trusted co-owner of the package’s future. So we want to find a nice setup where people feel empowered contributing to the package with just the right level of permissions to get shit done, without giving everyone access to everything right away either.

To help with building trust and knowing what people are up to,

1. We now have an Introductions thread in GitHub Discussions. Please consider giving this a go :) It’s a fun way to know more about people.
2. I’ve asked if we could get a channel on the Django Discord. The answer is "yes if we use it". Come join, and if enough people are there, we’ll have our own little chat space.
3. We now have a ADOPTERS.md file, where people who feel like it can add their projects / organizations / websites where they use the package.
4. We now have a way to add people to the organization with very little rights to reward contributions of any kinds.

Teams

I’ve kept it as simple as possible – we now have one team per repository role in GitHub:

Team	Role	Description
@django-recaptcha/contributors	Read	Recommended for non-code contributors who want to view or discuss your project
@django-recaptcha/triagers	Triage	Recommended for contributors who need to proactively manage issues, discussions, and pull requests without write access
@django-recaptcha/committers	Write	Recommended for contributors who actively push to your project
@django-recaptcha/maintainers	Maintain	Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
@django-recaptcha/admins	Admin	Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository

In practice, this is how I see it working:

• Anyone who contributes or is interested to the project can be added to contributors. This doesn’t grant any particular rights currently, but does mean in GitHub you will appear as member of this organization within issues and discussions. Contributors (and any organization member) can also choose to show their affiliation on their GitHub profile (go to People and change your Organization visibility).
• People who are active in issues / PRs / discussions but don’t otherwise code can be added as triagers. They’re then able to help keep the discussions flowing and well-organized.
• People who code on a regular basis can have write access to the repository as committers. They also automatically get triagers rights.
• People who have proved themselves as triagers or committers can get maintainer access – which is all of the above plus access to some GitHub settings.
• People who have proved themselves as maintainers can get admin access – which allows you to do anything with the project.
• Finally people can be owner at the organization level, which doesn’t really grant much additional rights compared to admin, but helps further reduce the bus factor.

Members

I have removed everyone as "Outside collaborator" and invited everyone as members of the organization.

• @thibaudcolas I’m org owner
• @tbrlpld you’re org owner
• @Stormheg you’re org owner
• @atodorov I have moved you from "Write" access to the "Triagers" team, as I don’t think we’ve heard from you since your last comment here. If you want write access back please let us know.
• @rgs258 I have moved you from "Write" access to the "Maintainers" team, seeing that you’re active here.
• @Andrew-Chen-Wang I have moved you from "Write" access to the "Maintainers" team, since you’re very active.
• @cblignaut I have moved you from "Write" access to the "Triagers" team, as I don’t think we’ve heard from you since your last comment here. If you want write access back please let us know.

---

Everyone else – I have to switch to something else for today, but will add more people later.

[thibaudcolas]

@alanverresen I see you got an invite from Storm as a committer :)

@koutoftimer I’ve just sent you an invite as a committer as well.

@matthiask you had offered to help back in Feburary, would you want to formally join as a contributor / triager / committer as well?

---

I believe that’s it for people that have offered to help. Does anyone have thoughts on how many people would be needed to guarantee the long-term health of the package? How much / how to document the above setup to make it clear how and when to go about managing contributions in the future?

What do people think of the ADOPTERS file and introductions?

[matthiask]

@thibaudcolas Thanks for asking! I generally prefer not using recaptcha but sometimes I have to, and then I'm happy to know that there's a well maintained package around. So, I am ready to help if there's a need for it, but if there isn't I'd rather spend time on other packages, for example the debug toolbar.

[thibaudcolas]

Fair enough :) I think we’re ok for now, though I don’t know exactly "how much" maintainers is enough (let’s see what others think?). Maybe we’ll ask again if we see a need, and in the meantime you can let us know if you see room for improvement?