Agree on policy on repeated posts

Thank you for reporting this to the site moderators.

I agree that this is problematic behaviour:

• Copying screenshots already uploaded by others provides zero new information.
• Adding screenshots of a patch applying/not applying is not helpful and provides zero information (the system performs these checks automatically). It is also item #11 on the "don't list on our Issue Etiquette page.

I can only speculate the motivation behind this behaviour, but I've noticed that if somebody uploads "something" to an issue queue, you're automatically added to the list of people that is credited for the issue, and it is up to project maintainer to remove the person in order to avoid handing out an undeserved issue credit.

If you look at comment #6 in core issue, he gets a core issue credit for uploading two "patch applied" screenshots.

Is this a problem the site moderators can and should do anything with?

The guidelines for Moderating users says that a user should be blocked for "Repetitive posting of trash content". I would say that the postings documented in the issue fall into that category.

While he has been informed multiple time by others that this is not appropriate (as documented in the issue summary), he hasn't (AFAIK) been put on notice by the site moderators.

I propose to do the the following:

1. Send him a PM alerting him about this issue, and asking for a public comment.
2. If he replies within 14 days, recognizing that this behaviour is not appropriate, and that he will stop doing it, close this issue without any further action.
3. If he does not answer, or do not recognize that this is inappropriate. Block the account.

I'll leave this open for discussion for 48 hours. If nobody objects, I'll proceed with the steps outlined above.

I am going to create a separate issue in the Drupal.org customization issue queue to ask for the automatic addition of uploaders to the list of people to be credited, as I suspect it encourages some individuals to upload trash content.

I've also informed CWG about this issue, in case they want to weight in.

Thanks @gisle for addressing this concern. I think what you have proposed seems fair and allows the user some time to reflect and reply thoughtfully.

No objections from me.

There seems to more than one user doing this. We need to have plan for how to deal with this. Changed title and Category to reflect this.

Also added a "Proposed solution" based upon comment #2.

#2871769: Discuss ways to encourage more valuable contributions through issue crediting has some good discussion on this. In particular, we should assume good intentions and guide people toward productive contribution, rather than being entirely punitive. Of course, once they’ve received clear guidance, and continue to post non-helpful contributions, then more-punitive warnings and action can be taken appropriately.

Thanks for the link to #2871769: Discuss ways to encourage more valuable contributions through issue crediting. I've read it carefully. It is mainly about how to deal with minor patch re-rolls and other low-hanging fruit, and I understand that such attachments may be submitted with honourable intentions and not to game the system. I think that in particular, xjm made some excellent points.

In this issue we are specifically discussing attachments that are re-posts of images already uploaded by others, and screen shots of patches applying. I think there is less room for assuming good intentions in this particular case, but a possible explanation may of course be that the user simply does not know that such attachments are not helpful.

However, I certainly agree that we should provide guidance, and not be entirely punitive.

I've added a draft of a generic PM I to send to community members doing this to the issue summary. Any help with the text, in order to provide better guidance, grammar and spelling, will be appreciated.

Grammar in issue summary.

Removed gendered language from the summary. thanks.

Thanks, volkswagenchick!

Thanks for the context. Reposting screenshots is indeed beyond not-helpful, so a more-direct message is appropriate here.

Just sent this. Postponing until there is a reply from the user, or 14 days has gone by.

Dear [redacted],
Hi, I am Gisle Hannemyr and I am a site moderator at Drupal.org.

The site moderators have been notified about some of your posts in issues on Drupal.org, please see issue summary for the report:
https://www.drupal.org/project/site_moderators/issues/3226762.

To be precise, it is a report about posts with images already uploaded by others and posts with screenshots that show that a patch apply/don't apply.

I'm sending you this PM to inform you that such posts are unwanted in issue queues on Drupal.org, as they are in no way helpful, and you should stop posting them.

Please comment on the report in the issue containing the report. Please also make it it clear that you understand that such posts are not helpful, and that you will stop doing this from now on.

Please also read the community post on Issue Etiquette
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...,
to learn more about what to do and what not to do when posting in issues at Drupal.org.

I hope for your full cooperation in resolving this matter.
I am sorry to tell you that if you, for some reason, do not want to cooperate, your account at Drupal.org will be blocked.

@Gisle ----
Thanks for this concern. Keeping this in mind will update the proper screenshot in every tickets that have been updated.

Keeping this in mind will update the proper screenshot in every tickets that have been updated.

Please just stop posting screenshots. Even if they are originals instead of copies – if they show the same result as the previous ones, they will provide zero new information to the project's maintainers. In other words: They will still be trash.

If you really want to help out with resolving issues, you should help out resolving the problems that persist, instead for going after extremely low hanging fruit such as posting screenshots.

This is still happening. The last time was three days ago.

On the proposed resolution:

1. Send the user a PM alerting them [...]

This is a bit vague. Does it mean an e-mail message, a direct message on Slack, or something else?
I'm a bit concerned that it may not reflect their preferred communication methods, or may escape their attention.

2. If the user replies within 14 days [...]
3. If the user does not answer [...] Block the account.

Does this mean block the account merely because they haven't replied within 14 days? And after just one message?

That seems unduly harsh to me. A message may get routed into a spam folder, or just buried in a very busy inbox.

14 days certainly seems too short. Many college recess/holidays (e.g. Easter) exceed 14 days, so a contributor who uses their college computer facilities might face a blocked account before they've had a chance to read the message. Similarly, many vacations from work exceed 14 days: a "two week" break from work really spans 17 days, if you leave work on a Friday and come back on a Monday.

andrewmacpherson,
thank you for replying.

I can see that the wording about means of contact was vague. I've changed the issue summary to specify that the user's "contact" tab should be the primary channel for the PM, that a notice should be posted on Drupal slack, and additional means of contact should be used if available.

I also agree with you that blocking the account after just a single unanswered PM is too harsh, and has modified the proposal to take a much softer approach, where the primary sanction is to unpublish the trash post (with a notice about it being done). It the revised proposal, the account is not blocked until the user has been unpublished 10 times, and received 10 PMs asking them to stop. I hope this revised proposal is more acceptable.

However, as noted by apaderno in number #15, some of our community members persists, despite being told repeatedly that this is unwanted behaviour.

As long as this is happening, we need to implement some punitive measures when community members attempt to game our reputation system. I don't think they're only doing this for bragging rights. The reputation algorithm is heavily weighted with the number of installs, so being credited on a core fix comes with a huge bonus that inflates the position of the person's agency in the Drupal marketplace.

Another incident today: https://www.drupal.org/project/file_mime_validator/issues/3287567

Can confirm that unpublishing trash posts (in this case exact duplicates of a Rector patch) excludes the person from the list of people that receive automatic issue credit for posting patches.

With Rector patches being posted to the project's issue queue, we now have trash posts that "review" the Rector patch and changes status to "RTBC", sometimes accompanied by a screenshot showing that the patch applies cleanly.

Quite frequently, somebody also adds patch of their own to the Rector issue, where the only thing their patch does is to change the "core_version_requirement" key in the info.yml into:

core_version_requirement: ^9 || ^10

In most cases, at least in the projects I maintain, this is done without even checking for deprecations, and where Rector has left the comment:

Drupal 10 Compatibility

According to the Upgrade Status module, even with this patch, this module is not yet compatible with Drupal 10.

Currently Drupal Rector, version 0.13.0, cannot fix all Drupal 10 compatibility problems.

This patch does not update the info.yml file for Drupal 10 compatibility.

I find this annoying for the following reasons:

1. The Rector workflow depends on the issue having the status "Active", "Needs Review" or "Needs Work". By changing status to "RTBC", the user disrupts the workflow and requires me to manually set it to "Active".
2. The "pach" that add "^10 to the core_version_requirement key is worse than useless. If the Upgrade Status module thinks it is not yet ready, claiming that it is, is just misleading.

I maintain a lot of modules, and after Rector starting doing the rounds, I get several of these unwelcome interferences in the workflow every day now. Is there anything we can do to stop these users from doing this?

Suggest to address this in the d10readiness channel where this behavior is promoted by mentors

Agree on #1 about setting RTBC being undesired at this moment. Unless the bot adapts to the normal expected workflow concerning patches. In that case it would make sense to do so, assuming it was properly tested. You don't need to test the claim of the bot, you need to test functionality provided by the module patched.

Disagree on #2 about the change for ^10 not being useful when Upgrade status claims it is not. It remains your prerogative as a maintainer to make things available for D10. That doesn't mean it is bug free. Nor that you need to resolve all deprecations. That is YOUR decision. The software just claims that when patches are applied it is considered compatible. Again, that is YOUR decision to agree or disagree with. Serious maintainers do plan for the next major release and decide how to support that. That is not always the way the bot suggests to do it.

Item #2 doesn't say it useless for the module's maintainer to set ^10 if they think doing so is the right thing to do.

Item #2 says that somebody parachuting into a rector issue to post a patch suggesting to add "^10" to the "core_version_requirement"key is worse than useless when it is blatantly obvious that the person:

1. haven't bothered to check the code base for depreciations; and
2. haven't bothered to check the issue queue for open issues to deal with deprecations.

It has calmed down now, but I maintain a lot of modules, and I had to inspect a lot of useless patches of this type in the days just after Rector was deployed.

Maybe those issues can be assigned to a maintainer or owner. Hopefully, that will stop inexperienced contributors from participating.
Don't expect that to stop contributions that really matter.

Saw one contribution that overruled the maintainer, clearly not something to do. Guess, that `consider positive intent` and `learning experience`, `allow for mistakes` apply there.

With https://www.drupal.org/project/infrastructure/issues/3309815 fixed, setting RTBC is no longer considered sabotaging the bot.

However, reviewers still fail to understand that related functionality needs testing. Agreeing with the findings of the bot is nice, but need to be backed up by mentioning the scenario's tested. There is no need to produce screen dumps of the same tools the bot uses. Do consider running them valuable as there are many aspects being a moving target.

No-brainer patches only declaring D10 compatibility don't need testing functionality as there are no refactors done to the module. Same thing goes for refactors limited to the scope of tests. The functionality to be tested here is local testing when there is no automated testing done for the module.

Can someone clarify what is still be done here? Is there documentation that needs to be updated?

Is this now covered by Abuse of the Contribution Credit system?

@quietone You are right: What described here is already covered by that documentation page.

I am closing this issue.