> I'm a bit unconvinced with non assignment, though only slightly. I'd maybe prefer a solution with assignment and auto un-assignment if a issue isn't actively responded to in x number of days. I can foresee a lot of duplicate work for especially simpler issues (good first issues) where a lot of the folks looking to start contributing might try to raise PRs for the same issue and I feel it might discourage them from coming back if they have multiple prs that get rejected due to duplicate work.
I think this can be easily mitigated by modifying my proposal a bit and actually telling new contributors, that if they are convinced that they want to work on PR, they should just comment that they are "working on it", and we could tell contributors that before they do it, they should check if anyone has signed up and ask them if they want to avoid duplication. While that will add a bit more noise to my proposal, it does address accidental duplication - and it also leaves it entirely in the hands of those contributors (not us) if they want to avoid duplication. My goal is that maintainers should not be expected to take ANY action until PR is ready for review and green. They might watch watch is being discussed - but maintainers should not decide who is working on it by "assigning" things. That is also part of education for contributors - that it's entirely up to them to be self-sufficient and make right decisions on where to put their energy (and agents) as they wish, but that maintainers will only start being involved at the moment when there is a green PR from one of the people addressing the issue. Of course there might be some unclear things etc. which the author of the issue might want to address or leave up to the contributor to decide and propose a PR. We have to remember that PR is a proposal, and some of those discussions are far easier when you see proposed code rather than before so not all details need to be clarified before the PR is ready for review - review by maintainer is also part of the process, and even if it results in throwing out the entire code and starting from scratch, this is a good learning for contributor. We've always been thinking in terms of "PRs" not issues (even our changelogs have PR# not Issue #), so I would say that also stresses the fact that the role of maintainer starts at the moment when there is a green PR to review. Currently I feel with the assignment process we also assume the role of managers of those people who contribute and we are asked to decide "who is working on what". Which I think should not be part of the maintainer's role at all. We have no managers here, and people should also learn that they have to be self-sufficient here mostly. IMHO Maintainers reviewing the PRs should just judge if the code is good to merge and solve the problem it explains or links to - that's basically it. It should be more of a contributor's role to decide how and where they want to contribute - not ours, and we should describe it in the way that they can assume that responsibility. J, On Mon, Feb 16, 2026 at 3:49 PM Aritra Basu <[email protected]> wrote: > Hmm, > > I'm a bit unconvinced with non assignment, though only slightly. I'd maybe > prefer a solution with assignment and auto un-assignment if a issue isn't > actively responded to in x number of days. I can foresee a lot of duplicate > work for especially simpler issues (good first issues) where a lot of the > folks looking to start contributing might try to raise PRs for the same > issue and I feel it might discourage them from coming back if they have > multiple prs that get rejected due to duplicate work. > > While I do understand that with ai the effort that goes into "writing" the > code has gone down, I would assume it'd lead to fewer people coming back > due to the disappointment of having their efforts wasted. > > Open to hearing others thoughts. > > -- > Regards, > Aritra Basu > > On Mon, 16 Feb 2026, 8:02 pm Damian Shaw, <[email protected]> > wrote: > > > +1, we've had a lot of requests like this to pip also, even though we > > almost never assign issues. > > > > I will add something similar to our new contributor's guide. > > > > Damian > > ________________________________ > > From: Jarek Potiuk <[email protected]> > > Sent: Monday, February 16, 2026 9:10:36 AM > > To: [email protected] <[email protected]> > > Subject: [DISCUSS] Stop assigning unknown contributors to issues (AI-slop > > prevention) > > > > Hello here, > > > > After disconnecting a bit working on the 2.11.1 release (glad it's about > to > > be released finally) I caught up with some recent issues and I think the > > "assign" feature gets somewhat abused. > > > > There are a number of issues where new contributors ask to be assigned > and > > they either don't work on or what they submit is mostly AI slop. > > > > I think one of the reasons for that is "Assigning" might be seen by some > > people as a sign of trust and maybe they somehow bust their reputation by > > having issues assigned to them. > > > > Now, I think our "assignment" was always a bit broken - when issues had > > people assigned, it kinda blocked others from working on them - I've seen > > quite a few comments from people "I would like to work on some issue but > > there was someone already assigned". We did not actively clean the people > > who did not complete their "assignments" (and we do not want to spend > time > > on it either) - and some of the old issues that have people assigned are > > simply not touched by new contributors. > > > > Assignment has two roles - one is to maybe allow people to see issues > they > > are assigned to, and two - it's a kind of lock preventing more than one > > person from working on the same issue. Some people in the past complained > > that they were assigned - but someone else got a PR - so this is also how > > some people understand it. > > > > With the current AI-slop era and people signing up for many things they > > often have no idea how to do - trusting that agents will do it for them, > I > > think the 2nd role is quite broken. While in essence it was supposed to > > prevent two people working on the same thing, right now it might prevent > > people who know what they are doing to work on those issues. > > > > *Proposal:* > > > > I think we can "unbreak it" by changing a bit what "assignment" is and > > adapting our process. > > > > I believe we should start treating assignment as: > > > > ** "I know the person and I trust they will get it done or unassign > > themselves if they can't complete"* > > > > I think we should: > > > > - only assign issues to committers/trusted contributors who we trust > > will work on the issue and lead to completion, and that they un-assign > > themselves if they see they cannot complete it. We will actually > expect > > people to do this un-assignment in case they want to "free" the issue. > > > > > > - stop assigning unknown people when they ask and strongly > *DISCOURAGE* > > them > > from asking "can I take the issue". We should add in our contributing > > docs > > and repeat it if people do not read it that we are not assigning > issues > > to > > new contributors and they should just open PRs if they want to work on > > something without asking - this will hopefully cut a lot of noise from > > issue comments > > > > > > - describe that it is absolutely ok if an issue is not assigned and > > several people work on it - whoever gets good green, reviewed PR will > > win, > > others might also help to review other's PRs on the same issues if > they > > see > > other PRs are better. > > > > > > I think that will help a bit with issues being effectively blocked by > > people (or bots) who do not work on them, and cut the noise a bit on > > "asking" or "taking" issues - especially if we keep on reminding it to > > people; > > > > I am happy to do initial unassignment of current issues and to make a PR > > proposal for our contribution guide update. > > > > Let me know what you think - any comments are welcome as usual. > > > > J, > > ________________________________ > > Strike Technologies, LLC ("Strike") is part of the GTS family of > > companies. Strike is a technology solutions provider, and is not a broker > > or dealer and does not transact any securities related business directly > > whatsoever. This communication is the property of Strike and its > > affiliates, and does not constitute an offer to sell or the solicitation > of > > an offer to buy any security in any jurisdiction. It is intended only for > > the person to whom it is addressed and may contain information that is > > privileged, confidential, or otherwise protected from disclosure. > > Distribution or copying of this communication, or the information > contained > > herein, by anyone other than the intended recipient is prohibited. If you > > have received this communication in error, please immediately notify > Strike > > at [email protected], and delete and destroy any copies > hereof. > > ________________________________ > > CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments > > are intended solely for the addressee. This transmission is covered by > the > > Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The > > information contained in this transmission is confidential in nature and > > protected from further use or disclosure under U.S. Pub. L. 106-102, 113 > > U.S. Stat. 1338 (1999), and may be subject to attorney-client or other > > legal privilege. Your use or disclosure of this information for any > purpose > > other than that intended by its transmittal is strictly prohibited, and > may > > subject you to fines and/or penalties under federal and state law. If you > > are not the intended recipient of this transmission, please DESTROY ALL > > COPIES RECEIVED and confirm destruction to the sender via return > > transmittal. > > >
