I agree with that aspect of it and am much more convinced with the updated proposal. Fully in agreement with all your points and I think the commenting that you're working on something is a good solution to the duplicate work issue. It's a +1 from me on the proposal.
-- Regards, Aritra Basu On Mon, 16 Feb 2026, 8:53 pm Jarek Potiuk, <[email protected]> wrote: > > 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. > > > > > >
