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