Categorize contributions that could be considered 'gaming the credit system' and propose solutions (policy, automation, etc)

hestenet → credited Amber Himes Matz → .

hestenet → credited catch → .

hestenet → credited heddn → .

hestenet → credited kevinquillen → .

hestenet → credited Kristen Pol → .

hestenet → credited markdorison → .

hestenet → credited smustgrave → .

hestenet → credited Spokje → .

In terms of auto updating dependencies for modules or core, perhaps now that we are on GitLab we could leverage Renovate bot for that task. I use Renovate in my own GitLab account for my personal site to keep modules and core updated. I wrote about it at length here:

https://www.velir.com/ideas/2022/10/20/how-to-automate-dependency-update...

It could help maintain composer, yarn, npm, and other package manager types (even docker-compose) by opening MRs automatically, with optional ability to auto-merge, and can be configured in great detail to fit different needs. A real time saver for me.

With phpcs fixes there are at least two places:

1. Issues/MRs against contrib modules - not sure how useful this is but I know people do it manually.

2. Issues/MRs against core MRs - i.e. if core adds a new phpcs or phpstan rule, and this causes an MR to fail on the next test run, stop at the phpcs stage and generate an MR (or comment with a diff, or whatever) with the fixes.

Another potential item could be to automate the removal of License.txt( https://www.drupal.org/node/1587704#licensingchecks → )

That rule is outdated, every project should contain a license, that’s permitted under https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... → . Git repositories are mirrored elsewhere and downloaded without packaging, and those copies should have licenses.

Also, https://www.drupal.org/node/1587704#licensingchecks → is a documentation page for opting into security advisory coverage. (I am going to edit the part about the license file out.) It should not have been used to tell maintainers they need to remove the license file.

We've discussed it at length in Slack, but splitting up the same type of problem into several issues in order to get more credits isn't listed above. For example. multiple coding standard issues or dependency injection issues or typo issues.

I see it's also not listed here:

https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →

though I'm pretty sure I saw it somewhere in the recent updates.

IMO, it makes sense to split a dependency injection issue from the issue that resolves the PHP_CodeSniffer warnings/errors, even if PHP_CodeSniffer reports when a class should use dependency injection instead of using \Drupal methods. Adding dependencies always creates BC issues; fixing that is not as simple as removing spaces where they should not be there.
The same is true for the PHP_CodeSniffer reports about class properties that use $snake_case instead of $camelCase. Public properties cannot be renamed without BC issues; that should be split in a separate issue.

I think that's fine but I'm running into a case where many PHPCS problems have been split out and it's overkill and feels like gaming. I think if there are a large number of problems to fix then pulling some out into large groups for fixing is fine.

I see that 📌 Replace Redirect README.txt with README.md and update Needs review for the Redirect module was closed, due to possible bad behavior by one or more individuals, suspected of gaming the system in other issues.

I don't think rejecting an actual improvement is a fair nor wise decision, especially when the end result looks awesome (in my opinion) and is a clear improvement over the current README in TXT-format.

In my humble opinion, the current Redirect README.txt looks outdated, and the updated README.md reads much easier, and looks more inviting:

• Current, TXT: https://git.drupalcode.org/project/redirect
• Updated, Markdown: https://git.drupalcode.org/issue/redirect-3330770/-/tree/3330770-replace...

It has been discussed at length, and decided that the Markdown works better than txt in #3192842: Make our README more welcoming by converting it into an "entrypoint" into the Drupal ecosystem → , which I very much agree with. By now, txt README's look like relics from the 90's to me, since most projects now use Markdown on Github and Gitlab.

Community members such as @cedewey, @DamienMcKenna, @FeyP, @froboy, @hansfn, @gisle, @volkswagenchick, @Webbeh, and me have worked hard to create what I think is a great looking and inviting README.md template → based on Markdown.

See https://www.drupal.org/node/2181737/discuss → for all the hard work that went into it.

Generally speaking, I think it's a really sad state of affairs that actual improvements are now being rejected, if the intent of the commit is deemed to be gaming the system.

I can only speak for myself, but it's fairly demotivating and a bit of a downer to feel like you're viewed as a "gamer of the system", when all you're simply trying to do, is improve Drupal.

The main reason I put a lot of time into the README.md template → (as I assume the others have) creating MR's, reviewing MR's, and just overall following along very actively in the issue queues circa November 2022 to March 2023, when the README update "storm" took place, was to make sure that what was implemented looked good in the first place, by having a nice looking template, using the Markdown formatting options, and wasn't merely exchanging the extension from .txt to .md.

My primary concern was to improve the image of Drupal, since the README is the face of Drupal to the world. Not to get credits, which was just an added bonus. For example, I have previously also spent a lot of time translating Drupal into Danish. For this you get zero credit, and I only did this to improve Drupal.

I of course agree that bulk posting meaningless, "this line is 82 characters more than the allowed 80 characters" PHPCS's, or opening empty MR's is most likely attempts at gaming the system, and individuals doing this should be warned to stop this, and eventually labeled as spammers if they continue.

But automatically lumping README improvements together with this kind of obvious bad behavior is counter productive, both for the progress of Drupal, but also because it risks alienating Drupal community members.

In my opinion the credit system has failed, if real actual improvements are now Villy-Nilly rejected, merely due to suspicion of bad behavior, by a single actor.

It should be evaluated if we should get rid of the credit system altogether, if it gets in the way of improvements, and too much time is spent countering cheaters. This is unlikely to happen.

Alternatively, instead of trying to find ways to counter gamers of the system in a never ending game of Whac-A-Mole, certain types of MR's could automatically never get any credit, for example involving PHPCS, README updates, or set at an extremely low value, like 0.0000000000001 credit :)

That would be a simple and pragmatic solution, and one I would be totally fine with.

Thank you for the valuable feedback @ressa. I was in “two minds” about closing that but it was something called out in the slack discussions and policy and most of the users did show a pattern of low value contributions. I would like to also here from others on this thread. I certainly don’t want to dissuade valuable contributions so would appreciate more feedback on how to best handle these types of situations.

For me https://git.drupalcode.org/project/redirect/-/merge_requests/43/diffs#no... is a real change, the key thing is the 'and update' in the issue title and the formatting changes. We commit much more trivial changes to core (and credit them) all the time.

Auto-crediting has been switched off for a couple of weeks now, so there's always the option to accept a change but not check the credit box if it's borderline.

I understand, and thanks for a fast response @Kristen Pol.

About Slack, which is another thing I am getting increasingly worried about: I feel that, in general, it would be much better for the cohesiveness of the Drupal community, if important discussions about this and other issues had taken place here on drupal.org, maybe in a dedicated issue, and not what seems for the outsiders at least, like a black box, such as Slack.

It seems to me like more and more frequently, there's a discussion on Slack about an issue, a conclusion is reached, and presented afterwards here on drupal.org. But the context, and who said what, and what were the arguments is often not clear.

@catch: Yes, I think we both agree, that the first two commits add real value, the last not so much, which I also commented in the issue.

I agree that if there are significant changes made to a readme, well beyond changing the file type, a credit should be issued.
Documentation is the most forward facing item when folks come to evaluate our Drupal project.

Thanks @volkswagenchick! It's my impression that there's a general tendency to automatically slag off README updates as credit gaming, which is why I wrote the lengthy comment above -- it has been building inside me for a while. It's even used in the Abuse of the Contribution Credit system → page, which I think is unfortunate:

What is considered abuse of the contribution credit system?

Abuse of the credit system includes any inauthentic contribution activity done for the purpose of farming credit. This is sometimes referred to as gaming the credit system.

Those abusive behaviors include:
[...]

• Bulk posting of low-effort issues, such as:
• Conversion from README.txt to README.md or other minor readme fixes
• phpcs (code style) fixes
• etc.

Believe it's considered gaming as users/companies post 100s of them at once.

Not disagreeing with anything here but would be careful that if we backtrack we may be inviting the flood of the type of tickets that drove tension in the community to a high point.

Maybe some words can be added to the README bullet point on the page https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →

Conversion from README.txt to README.md or other minor readme fixes. Major fixes and adding to the documentation will earn credit.

Just an idea.

Agree with many of the points above. I think we are all working really hard to improve the situation when people are trying to game the system and I appreciate every single person trying to help here. We now have more supporting pages, we've tweaked the tools slightly (ie: no automatic credit on certain actions), etc.

I think we all agree as well that missing some solid/good contributions because of the noise from others is not good and can be discouraging, but again, we are trying our best and we can make mistakes. We are trying to target "automated" or "mass" issue creation in these cases and it was pretty intense for a few weeks.

My only point might be about Slack, I find it really helpful to have conversations with people in real-time (or async via threads) about a possible gaming attempt or a particular issue, where you can ask for advice, ping other people, triage the different cases, etc. More often than not, gaming attempts have been translated to "site_moderator" issues, where the context is added, in order to keep track of things, so it shouldn't feel like a black box.

I think that thanks to the #contribution-recognition-feedback channel, many of us felt supported and were able to learn how to best address these situations and help one another, similar to other channels were people help one another on certain topics.

IMO, the problem with those issues is that there are too many issues created in few time, they contain MRs/patches with the wrong changes, and the people who created them still must understand what is wrong in the changes they did.

It happens with issues to make the code follow the Drupal coding standards, which then change null to NULL in JavaScript code; it happened with issues that proposed to remove the LICENSE.txt file basing on documentation for applications to be able to opt projects into security advisory coverage; it happens with issues that propose changes in Drupal 7 module that do not make sense for a Drupal 7 module, like introducing the core_version_requirement key in a .info file; it happens with the issues where an empty documentation comment is added to avoid PHP_CodeSniffer complains about a missing documentation comment; it happened with issues that proposed to change the value for core_version_requirement, when such change was not necessary.

With too many issues created in few time. I am referring to the issues for the same change opened from the same person. By in few time, I mean that the person who created 10 of those issues did not even wait to get a feedback for those issue before creating new issues of the same type, not even the time to understand if those issues are correct or should be not created because there is nothing that must be changed.

I do not think that anybody who commented in this issue thinks that people who push for changes in the drupal.org documentation are gaming the credit system. This issue has been created for people who seem to aim to get credit by opening many issues.

I do not think that anybody who commented in this issue thinks that people who push for changes in the drupal.org documentation are gaming the credit system.

There are clearly people - some from agencies - that just do edits for the the edit count, not for improving the documentation, but these people aren't "pushing for changes" ;-)

people who push for changes in the drupal.org documentation is referred to people who propose changes on drupal.org documentation and push to make them happen. It is not referred to people who randomly edit documentation without participating to issues opened to prompt for changes, or just to fix a typo in ten different documentation pages.

About crediting the conversion of a README file from plain text format to Markdown formatting or not, or labeling MR creators as credit farmers, the problem is that there is no consensus.

Also, there is a wrong premise in the Issue Summary, as I see it:

[...] there are some categories of contributions that can create friction for project maintainers. These might range from process issues (such as contributions that fail to address existing work such as MRs that are already open), quality issues (such as MRs/patches that don't actually apply, or don't address the root problem), or repetitive, low-effort issues that would be better served by automation tools on Drupal.org (such as converting readme files from readme.txt to readme.md). [my emphasis]

Renaming files from README.txt to README.md could have been automated. But reformatting according to the README Markdown template → requires human intervention, so these really are two very different tasks.

Renaming is a trivial task, but reformatting to Markdown according to the README template is not. Converting the formatting to Markdown and aligning the structure with the README template does take time, and is not low effort.

And yes, of course credit farming can happen, and some users do create MRs with essentially no visible change, or improvements, like adding or removing commas, or changing a few words. But rejecting an update of a README to Markdown format by default, and branding users as credit farmers is not fair.

The problem is that there is no consensus. Here are recent reactions of module maintainers, after the README in their module was updated from plain txt to Markdown format, who expressed gratitude.

Thankfulness after README update to Markdown format

• @joachim: "Committed, with a few tweaks. Thanks!" 📌 Replace readme.txt with readme.md file. Fixed
• @mandclu: "Thanks for everyone's work on this." 📌 README.txt with README.md Fixed
• @pfrenssen: "Thanks!" 📌 README.txt with README.md Fixed
• @RobLoach: "Thanks" 📌 Replace README.txt with README.md Fixed
• @bircher: "Thank you all!" 📌 Replace README.txt with README.md Fixed
• @VladimirAus: "Thank you! Merged! 🧁" 📌 Replace README.txt with README.md Fixed
• @afagioli: "Thanks!" 📌 Replace README.txt with README.md Fixed
• @stBorchert: "Thanks a lot. Committed to 2.1.x :)" 📌 Replace README.txt with README.md Fixed
• @nicrodgers: "Thanks!" 📌 Replace README.txt with README.md Fixed
• @scott_euser: "Thanks!" 📌 Replace README.txt with README.md Fixed
• @artem_sylchuk: "Thanks!" 📌 Replace README.txt with README.md Fixed
• @AstonVictor: "thanks" ✨ Replace ReadME.txt with ReadME.md file Fixed
• @juandels3: "Merged. Thanks!" 📌 Replace README.txt with README.md Fixed
• @pixelwhip: "Thanks for all your work on this. Merged!" 📌 Replace README.txt with README.md Fixed
• @rfmarcelino: "Thank you for your contributions. Merged." 📌 Replace README.txt with README.md Fixed
• @psebborn: "Thanks for this!" 📌 Replace README.txt with README.md Fixed
• @jeroen_vreuls: "Thanks everyone!" 📌 Replace README.txt with README.md Fixed

Credit farming

• @smustgrave: "Will fix this directly. These type of tickets are viewed as credit farming and have been reported dozens of times so I’m just closing out" 📌 Replace README.txt with README.md Fixed
• @jcnventura: "Fixed. No credit given to anyone, since this issue is a frequent target of credit harvesting." 📌 Replace README.txt with README.md Fixed

So while most module maintainers are thankful for the improvement, some might reject a README MR automatically. I think it's most productive and fair to assume good intent, as a default approach. Credit can of course be withheld, that's up to the maintainer. And more typical instances of credit farming, such as adding a comma, changing a word or two, or simply renaming the README file from txt to md without reformatting to Markdown should of course be rejected.

But casting judgment, and branding multiple users as credit farmers, simply based on the type of the MR (update of a README to Markdown format) which can actually be a positive improvement, is not productive, nor fair.

In my opinion this wording in "Abuse of the Contribution Credit system" is ambiguous:

Conversion from README.txt to README.md or other minor readme fixes

... and could instead be updated to this:

Renaming README.txt files to README.md, or other minor README fixes. Reformatting according to the README template → can earn credit.

Reading the issue again, I note that @catch agree:

For me https://git.drupalcode.org/project/redirect/-/merge_requests/43/diffs#no... is a real change, the key thing is the 'and update' in the issue title and the formatting changes. We commit much more trivial changes to core (and credit them) all the time.

Auto-crediting has been switched off for a couple of weeks now, so there's always the option to accept a change but not check the credit box if it's borderline.

https://www.drupal.org/project/drupalorg/issues/3367061#comment-15186449 🌱 Categorize contributions that could be considered 'gaming the credit system' and propose solutions (policy, automation, etc) Active

So I have updated the wording in Abuse of the Contribution Credit system → .

We should not focus on specific type of issues, but on contributions where the introduced changes are wrong.
It is true that lately the trend is to create issues about converting a README file to Markdown, or fixing all the warnings/errors shown by PHP_CodeSniffer, but even a MR that would add a function whose name is not prefixed by the module machine name (for an issue that is then changed to Reviewed & tested by the community by somebody who works on the same organization) is a bad contribution.

Probably, the worst part of those issues is that they are created in bulk, without even waiting for a review on the first ten MRs/patches provided. At least that would help with providing a better MR/patch, or even avoid that similar issues would be further created.
I still remember those issues created to remove the license file from repositories, basing on the fact that the documentation for applications to become able to opt projects into security advisory policy suggested not to have that file. If they waited for feedback, they would have learned they were reading documentation pages whose purpose is not to say what drupal.org repositories must or must not contain, which could also not be updated, basing on the strict number of people who update those documentation pages.

I agree @apaderno, negative contributions are time wasters, and should be flagged and stopped.

But nice improvements are being categorized as credit gaming, just for being a README MR. See #3343722: Clean up documentation → , for example. A great improvement, resulting in a nicely formatted new README.md (original) which reads great. But it was rejected, and on top of that, the creator called out as being a credit gamer.

PS: Increasing the 80 characters per line rule to 120 characters for .txt and .md files in PHPCS (or removing the limit) might prevent some negative contributions? See #3173782: Increase line length limit to 120 → and #3039007: Relax the rule that arrays may not span more than 80 characters → .

negative contributions are time wasters, and should be flagged and stopped.

But nice improvements are being categorized as credit gaming, just for being a README MR… But it was rejected, and on top of that, the creator called out as being a credit gamer.

I made a suggestion on SLACK a while back that we should possibly loosening the list to include “any issue a maintainer deems as credit farming or otherwise views as spam”. Essentially that we move away from
“every little bit of work has a positive value” A maintainer knows their project better than we do and a maintainer knows what issues they care about. Maintainers know who are active in their issue queue and have read historical issues in their queue and who appears to be doing a drive-by MR.

If a maintainer views the request as farming than for their project it does not matter that it would be a helpful change or that the rest of us do not view it as farming, it is their project and they should be the cultivators of their ecosystem.

As a maintainer on D.O.: Often there are small issues I will observe and will not create an issue for because I know due to credit farming I’m going to receive a drive-by commit (even if the issue is assigned to me) that will take me longer to review than just fixing the issue myself. This can lead to improvements being forgotten.

In other ecosystems I would usually tag it into the issue tracker without even a second thought knowing I’m likely to get a quality fix from others, or at the very minimal know that anyone who does attempt to resolve the issue is either personally impacted or otherwise trying to be around for the long term where it is “worth my time” to guide them on the project customs.

I will also add:
Markdown being a “nice improvement” is subjective, yes it allows a pretty rendered page in GitLab and other systems, however it also imposes new maintenance burdens due to being a formatted languages with no universally defined processing standard (to properly evaluate markdown you need to be familiar with several different parsers to know what the compatible result will be).

We are not in a position to judge markdown as being a net positive for every project, that is for the maintainer to decide.

Speaking for myself while I have been converting to markdown it also has usually involved massive changes to the README as part of moving to GitLab pages, as such a straight markdown changeover issue is of minimal to no assistance for me.

I made a suggestion on SLACK a while back that we should possibly loosening the list to include “any issue a maintainer deems as credit farming or otherwise views as spam”.

That is rather subjective and too broad. I would rather not see issues closed with a comment saying I feel this issue has been opened for farming credits. which could always be posted to any issue.

I still think that issues that try to fix all the errors/warnings reported by a CLI tool, where it is not clear which parameters have been used, or where the code is changed just to avoid the error/warning is still reported, without considering if the change is correct, should not be welcome.

Also, spamming is posting the same post over and over, including issues for the same topic opened for different project without waiting for any feedback for the first two created issues. Spam should not be used for everything a person does not like.
(I wish Report as spam would not be understood as Report something that you do not like.)

That is rather subjective and too broad.

That would be exactly the point of the propasl, as noted above a maintainer knows their project better than any of us. Maybe maintainers want these sort of commits and others do not. Defer to each project, let code owners set the rules, and have D.O. support them.

From discussion on Slack we now have reports of maintainers sending Drupal Partners notices to “not contribute” to their projects(or any other projects by their organization) due to a history of the org Organization behavior. I have honestly considered the same myself.o lol

As maintainer frustrations appear to be continuing to escalate I’m increasing the issue priority to Critical.

Also suggested on Slack:
The D.A. Should consider sending the credit policy out to all organizations and require them to accept the policy along with modifying the add an organization page to require accepting the policy before the organization is created. Those that do not should be disabled and unable to be selected for attribution.

There are also maintainers who keep talking of credits gaming without noticing that, for example, the person who corrected the MR, or who effectively provided the MR, did that for a couple of issues created in bulk from a different person.

There is nothing subjective in understanding that there is no need to create a MR to rename a file, or that creating a MR that makes important changes in the code following what an automatic tool reports and doing the minimal necessary to stop a warning to be reported is bad.

Let's not make credit farming a synonym of I do not like this issue, in the same way spam (as noun) does not mean I do not like this post.

Those bulk issues would not be so bad, if the MRs/patches do not contain the same type of errors, like adding a period to the last line of commented code, adding a documentation comment that just described the class with the class name, adding a new parameter to a class constructor in a way that does not keep the backward-compatibility.
They would also be not so bad, if they are not created for any project, including those sandbox projects that are no longer maintained nor used. This actually is not what farming credits would suggest to do, since there are chances a sandbox project will not get commits done. (It could be also understood as issues created in the hope for which the maintainers will commit a change without a detailed review of the proposed changes, which is normally done by somebody who is not maintainer.)

For maintainers who received those bulk issues in a couple of their projects, it is probably irrelevant the issues have been created in bulk. It is more relevant the MR has been created by somebody who apparently does not understand how to change the code, or who in past showed to not correctly understand how code should be changed.

This is all very good discussion, that I assure I am following :)

Let's not /make credit/ farming a synonym of /I do not like this issue/, in
the same way /spam/ (as noun) does not mean /I do not like this post/.

Big +1 to this point.