Provide standardized method for code owners to "block" contributors

While I absolutely dislike what some of these companies are doing, I'm not sure if this is a good idea. Some downsides off the top of my head:

1. We'd be spending dev resources to allow us to block organizations, while we could spend said resources in implementing a suggestion from ✨ Consider weighting issue credits by issue priority when ranking Marketplace organizations Active . I feel strongly for the suggestion I made there as it would reduce the amount of credits gained from these low-effort issues to zero, effectively removing all incentive to game the system.
2. It enforces the idea that certain companies are lost causes. While I would agree for some of the worst offenders, it may lead to situations where a frustrated maintainer prematurely blocks a company even though they had no intent of gaming the system.
3. It creates an avenue for conflict. We have a system in place where @hestenet reaches out and educates or punishes these companies. If you feel like this is moving too slowly or is too kind, we could investigate whether we can expand this team and perhaps take more decisive action sooner.

Finally, and this has been suggested before, we should either get rid of or limit access to the generic issue queue. Employees of these agencies have already admitted to scouring said issue queue for any module and picking up issues as they are at the top of the list. We should encourage people to mostly (or only) contribute to modules they are actively using.

It creates an avenue for conflict

I would contend the conflict already exists without this system. As noted we have at least one mainatiner sending notices manually. Personally I have considered doing similar (along with posting it with a banner on module pages).

At this point as an ecosystem we need to prepare for these to occur, the questions is not “are maintainers blocking organizations” the question is “how does D.O. handle maintainers blocking organizations”.

D.O. can either standardized the methods of blocking organizations/users, leave blocking as a free-for-all, or ban code owners/maintainers for doing so.

The proposal in this issue is currently that there be a standardized method to reduce friction for both sides.

Even the current system with @hestenet is conflict ridden, we have the org organizations contending they have done nothing wrong and objecting to being portrayed as needing education on best practices while maintainers contend the system is not doing enough.

We'd be spending dev resources to allow us to block organizations,

A valid concern, although I would counter the other side of this is that we would be spending dev resources in order to retain and attract maintainers who might otherwise not work inside the Drupal ecosystem.

frustrated maintainer prematurely blocks a company even though they had no intent of gaming the system.

indeed a risk this could occur, although that would not generally negatively impact the ecosystem as a whole would it?

effectively removing all incentive to game the system.

it may not hurt, however it may just push the problem to A smaller set of modules. It also could lead to more issues created to counteract the loss I do not see these as needing to be mutually exclusive and the proposal here is just another tool in the overall fight.

If you feel like this is moving too slowly or is too kind, we could investigate whether we can expand this team and perhaps take more decisive action sooner.

I’ll note that I have been a part of many of these conversations. While @hestenet has certainly helped over the past year, he himself has admitted that the newer tactics being observed are likely going to need to be allowed by the D.A. I can respect why that is the cases, the D.A. needs to cater to a much more diverse viewpoint that some organizations appreciate these issues while other maintainers do not. I have been proposing in 🌱 Categorize contributions that could be considered 'gaming the credit system' and propose solutions (policy, automation, etc) Active that we take maintainer opinion into consideration as a part of the official policy.

Finally, and this has been suggested before, we should either get rid of or limit access to the generic issue queue.

IIRC GitLab has a similar API and we will not be able to block it without seriously breaking access to GitLab itself.

Even if we could all we have to do is iterate over the individual queues. Slower but not impossible. This also does nothing to stop when org sizarions just go through the list of downloadable modules looking for a single type of error.

Blocking the tools I would contend is less ideal than blocking the behavior which is what this proposal is attempting to assist with. As a real world scenario the recent polyfill attack made heavy use of the global issue queue to help site owners understand the scope of impact.

We should encourage people to mostly (or only) contribute to modules they are actively using.

Absolutely agree, and that is my intent with this. I expect maintainers are wise enough to know those that routinely help in their module compared to those providing a drive-by commits. Frequent offenders being blocked ideally become encouraged to clean up their internal system and work with the ecosystem and individual maintainers.

While I sympathize with the pain that's driving this proposal, -1 as written/formulated.

I agree with basically all of #2, except I don't quite follow this:

we should either get rid of or limit access to the generic issue queue

Do you mean https://www.drupal.org/project/issues → and https://www.drupal.org/project/issues/search → ? How else would anyone be able to search for all issues tagged with a certain tag across all projects? I don't think removing or restricting access to those pages makes sense. If companies are having their employees circle the skies like vultures for anything to hit 'needs review', that's unfortunate, but I think we need a cultural solution, not a technical one. Removing the ability to search issues across projects seems not worth whatever perceived benefits of discouraging this form of "drive by contribution"...

Agree with the counterpoint made in #4, even though we do have "vultures" there. Plenty of them too. I guess we need to keep the generic issue queue around even if it's an attack vector so to speak.

On the main subject: My main point is that I'd rather we spend resources on completely voiding credit gained through spamming issue queues and then see where that lands us. For all we know these companies might stop spamming altogether.

If they still spam the issue queues regardless of the fact that they no longer gain credit for it, then it's a cultural issue and we need to figure that one out. At that point I wouldn't mind spending resources on allowing maintainers to block these companies.

Re: multiproject issue queues: Okay, cool. P.s. those will be changing when issues move to GitLab, possibly goi g away? 😅

Main point: completely agree with this:

I'd rather we spend resources on completely voiding credit gained through spamming issue queues

For everyone voting no on this:

What is your proposal for how we inform vendors that their contributions annd questions are not welcome on a project ?

Alternative ideas of encouraging users not to open bulk issues in general are great and will help this solution be needed less however they are not a true alternative for the request raised in this issue (that we provide a method to block users/organizations at the project level)

At the moment the alternative I see is a large banner (sample screenshot attached) which is less than ideal for D.O. image further driving home “Drupal, come for the code, leave due to the community”.

Yeah, also not a big fan to "block off" entire companies based on a few users. You know there is a saying:

A rotten apple spoils the (whole) barrel

Which in my eyes definitely can apply to those companies. As I cannot imagine every single contributor in the same company has the same intentions.

On the opposite side though, the companies should take the warnings, recommendations and code of conduct/contribution etiquette to hearth, and traint/educate their staff members. And act upon issues early, I can't possibly imagine Drupal is the only case here. In fact, it's in the company's interest that anything what happens online follows the "rules" as it might impact the company brand. (There are fancy terms for this but I can't find the right words at the moment 😅)

also not a big fan to "block off" entire

Not really my preferred option either, however sometimes you do what you feel you need to do for maintainer sanity.

That is the good part of this proposal, it does not force a maintainer to block anyone, it just allows them the tools to do so if they desire and helps give the organizations more reason to intervene early.

I can't possibly imagine Drupal is the only case here. In fact,

I’m not sure I agree. At the risk of getting off topic, the D.O. Credit system is somewhat unique.

I have seen the trouble user that wants to just complain about everything, I’ve seen the user that disagrees with every suggestion (they at least make us think and seriously evaluate our choices), I’ve seen thousands of trivial changes (one misspelled word someone saw while reading a page) and even the angry dev of a fork split trying to trash the project.

In 20+ years I have never seen this systemic behavior we have occur on D.O. of drive by “contributions” from those that have no (apparent) desire to use the project long term or be invested in the outcomes of the decisions.