PyCQA/isort triage

[Helveg]

(crossposted on Discord as well)

Hi! I've opened PyCQA/isort#2283 and I've struggled to get traction on it for several months now. I'd like to volunteer to triage issues and contribute more PRs, given that there's someone I could tag to review/merge my PRs in a timely manner?

On top of that I've been involved in OpenSource communities for about 20 years now and wouldn't mind volunteering to maintain isort and help keep the PyCQA healthy and active.

[DanielNoord]

I can't really comment on whether we can/should add more maintainers to the project as I'm not sure who is the "owner" of the project, but I'm a an organization admin. I don't think people would mind if I did some reviews and merged PRs. The list of 56 PRs is a bit too long to sort through, but feel free to ping me on individual PRs that you'd like to get merged.

I can also do releases I think!

But, still: we should probably find more active maintainers. As I said, I'm not sure what the process for that should be though.

[Helveg]

Well it's great to hear back from someone within the organization either way :) Let's see how it goes for now just pinging you, and after a bit I might ask to revisit the maintenance topic.

Thanks!

[sigmavirus24]

@DanielNoord I tend to avoid merging things on projects in unfamiliar with. It can feel like a violation to project members when an owner steps in and maybe accepts something they're uncomfortable with.

[DanielNoord]

That's understandable but in this case the code was very small and also reviewed by others.

I don't intend to merge PRs like PyCQA/isort#2319 but making sure we can add support for 3.13 (PyCQA/isort#2306) for such a crucial package seems sensible. I believe that is the benefit that the PyCQA can offer: stepping in for small changes when maintainers don't have time themselves.

[sirosen]

In case it is useful, I volunteered to help out in the Discord as well (different channel from @Helveg, same basic message).
There is a community of developers with experience maintaining mature projects who are willing to step in and try to be responsible custodians of the project.

From the commit history, it seems that @staticdev was the sole and primary maintainer last year.
If he could share whether or not he intends to come back to the project, and his opinion on finding (and vetting?) new maintainers, I think that would help some of us looking to help out understand what we can and should do.

[sigmavirus24]

Without consent to make those changes, I'm not comfortable with adding folks or merging things.

---

No offense to either of you, but I'm wary of @DanielNoord merging things as is. We never had agreement that others would be able to merge things from isort maintainers. (This has happened with other projects but those haven't needed it.) We also never got agreement to add folks who haven't made many contributions before regardless of reputation or lack thereof.

I'm big on consent. I know @graingert was making attempts to reach people. I would believe he's been unsuccessful. And seeing as @DanielNoord was made an owner to help invite Pylint folks to teams and the org but Pylint has gone into their own org, I'm not sure there's much reason to keep him as owner as he hasn't bothered to receive anyone's consent. That's not the behavior I would expect.

[sirosen]

That's a fair starting point. We should also acknowledge the possibility that past maintainers won't come back to the projects. I'm prompted to think of the package reclamation process ( https://peps.python.org/pep-0541/#abandoned-projects ).¹

For my part, I won't try to contribute to the project without more clarity about what the right path forward is -- I have filed no issues and opened no PRs. As an outsider, I want the PyCQA members to decide what they feel is best, and I don't want to add to the workload or put improper pressure on people to act quickly.

If issue triage, bugfixing, or other work is agreed to be appropriate, my offer to help stands!

Footnotes

1. Not trying to say the PEP 541 process is perfect. But it's useful precedent and pertinent because this is the Python ecosystem. That framework suggests that the current stage of the process we're in is "no recent releases, are maintainers reachable?" ↩

[kurtmckee]

I've been triaging issues and reviewing PRs for isort this week, and Daniel's been responsive. At the beginning of the week there were 219 issues and 57 PRs. In the last five days that's dropped to 198 issues and 41 PRs.

However, it sounds like there's a standing administrative consent issue with the project. That is an important consideration, and I hope it can be resolved. In the meantime, I'll stop triaging until administrative issues are addressed.

[sigmavirus24]

@sirosen that's a good point. If the organization were more ... Organized, I'd start to get alignment around that. Mostly this is just a loose collection right now. Attempts at collaboration and sharing things between projects never made it past the discussion at the PyCon hallway track. I'll see if I can reach @staticdev out of band as we have collaborated on other projects as well. If he's okay with it, I'll at least add y'all as triage maintainers to help with the open issues/PRs. Given how widely used isort is, I would want to make sure releases are for a while a little more audited but I don't personally have that time.

[DanielNoord]

That's sad to hear, but I'll stop merging things then.

I get where you are coming from @sigmavirus24 but honestly in this case I don't really agree. With that position we're actively "hurting" users of isort and dividing the Python linting/formatting ecosystem further as people can't keep using it. Besides, while there might not have been consensus in this particular issue I got confirmation both through other channels and in the actual isort repository that people appreciated somebody stepping up and doing a little maintenance work.

This is not about me deciding on the future of the project or accepting features proposals, but about making sure the CI can run again (PyCQA/isort#2324), fixing issues with the dependency declarations (PyCQA/isort#2325), other fixes that at least make the project usable again (PyCQA/isort#2311) and fixing the integration with codecov that I did myself. I was explicitly not making any decisions about features or proposals (see PyCQA/isort#1531) as I didn't believe I was in a position to do so.

Nobody is getting any better by the project being unmaintained and I'd be a shame if somebody had to fork it just to make sure it usable on recent interpreter versions. I'd be a shame to not make use of the many offers of help of respected and experienced community members just because we can't reach people that have been unreachable for months.

I saw @staticdev works in The Netherlands as I do so I might try to reach them as on Monday, but I'd hope that this can be resolved even if we can't reach anyone.