Closed (fixed)
Project:
Drupal.org site moderators
Component:
User account
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Mar 2015 at 22:35 UTC
Updated:
17 Oct 2018 at 08:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
TankTankAdmin commentedI've been having the same issue as well. Hope it get's resolved.
Comment #4
lizzjoy@rdtb418, thanks for adding that comment. You now have the role and should be able to keep on with your comments and posts.
Same applies to you @TankTankAdmin you now have the role.
Comment #6
TankTankAdmin commented@lizzjoy Thank you!
Comment #7
xjmThis account is being used as a bot to inappropriately post automated advertisement-like comments about test results on a particular testing platform to issues. See, for example:
https://www.drupal.org/node/2099137#comment-9769279
(Note that the comment is also false; it claims the test run took 12 minutes, when the actual linked results show that it took 36 minutes. But that's beside the point.)
Many issues have already been commented on by the bot in the past 3 hours:
https://www.drupal.org/user/3186647/track
Comment #8
mlhess commentedI have revoked the role. If it does not stop we can block the account. I will leave this open for now.
Comment #9
nevets commentedSomeone unconfirmed them, I blocked them and deleted the comments (which linked offsite)
Comment #10
David_Rothstein commentedI'm not clear on why this account should be blocked.
What provision in the Terms of Service was it violating?
Personally I saw a couple of the comments it left this morning and thought it was potentially useful. (Among other reasons, we sometimes have unexplained test failures and this would be a good check on that.) I can see not wanting drupal.org to be overrun by hundreds of comments from random bots, but if there's a policy on that I'm not clear on where it is - and certainly this is not the only non-testbot bot that posts to drupal.org sometimes.
At least we could be working with the maintainer to come up with some reasonable guidelines for its use, rather than leaving it blocked.
Comment #11
mlhess commentedI did not block the account, but removed the unconfirmed role. That should stop the auto posting. If the account slows down core dev's then the owner should talk to them about it and work out a solution that helps all.
Given the sprint happening with DrupalCI this week, it would be great if we could have a unified effort on testing.
Comment #12
David_Rothstein commentedYes, revoking the role for now sounds reasonable, given that the account was auto-posting.
But I don't think the account should have been blocked with its comments deleted. Can the account be unblocked so there can be a discussion about how it's being used?
Comment #13
mlhess commentedI have unblocked the account.
Comment #14
nevets commentedThe comments contained link spam. I think blocking the account is the correct thing to do. For new accounts, I only sample what people wrote, it they all contain link spam, I delete all content/comments and block
Comment #15
David_Rothstein commentedPersonally I didn't interpret it as spam. I don't remember what it looked like exactly, but I thought the link pointed to a page that showed specific automated test results for the patch in question (similar to the qa.drupal.org results).
I think it was getting them posted faster than qa.drupal.org too, although probably not by enough to be particularly helpful in that regard.
Anyway, I have no particular stake in this, just thought it was fair to unblock the account to allow @rdtb418 to post manually, including (potentially) posting here to explain the intentions of the automated posts and have the request for the "confirmed" role reconsidered - and maybe come up with a way to do it that is targeted to where it would be most useful and doesn't overwhelm the issue queue.
Thanks!
Comment #16
rdtb418 commentedFor the record, we did explain our reasons briefly in the user profile. Knowing our posting frequency was low, we initially tried to post without the confirmed role as we did not expect this to be troublesome. However, we soon discovered the spam protection system blocked all of our comments (manual or otherwise) regardless of content. As such, we requested the confirmed role since we are not a spammer.
Let’s address the ‘link spam’ charge. Our intent was most certainly not malicious. The links are not spam; they are posted in response to a patch and require a significant machine expense. Spam feeds off the low cost per comment to gain exposure for its message. In contrast, our comments are the opposite. We wait for a triggering event, the expense is very high, and the comment is not self-promoting by intent. The link is merely an implementation detail to avoid being disruptive by posting the entire output of 1600+ test classes in the comment box. We could do this if you prefer. :)
Alternatively, without the link (or a giant results table), you end up with a stale summary that can not be explored further without a disruptive workflow requiring manual discovery of the data on our site. For the same reason, qa.d.o posts its results to the issue.
We would welcome the ability to extend the drupal.org platform to display our result in the file table alongside the result from qa.d.o. But currently, unlike other project tracker hubs (e.g. github), there is no mechanism to inject test results into the issue short of the one already used by qa.d.o (PIFT) which does not allow multiple results to be present. As you can see, all of these alternatives are lacking or undesirable in some fashion. The only alternative worth considering is to enhance PIFT.
Our result page is done in the most respectful manner; in the same fashion as qa.d.o, simply a different domain and theme. It does not contain ads nor self promotion.
Why not a unified effort?
It’s has been admitted by the leader of the “testbot modernization” effort our platform is technologically superior. Even so, he and others resist using it (even hosting an instance on drupal.org infrastructure). This indicates an emotional response and should explain the resistance we have met with over the past 5 years.
Our founders wrote qa.d.o. and the testbot that preceded it. Our attempts to improve on the current testbot infrastructure ran into similar emotion-driven decisions related to: control and lack of technological flexibility. This drove us to seek an environment in which we could improve matters. Because of the aforementioned emotions at play, we have been unable over the last 5 years to contribute our improvements back to drupal.org.
Speed and resource utilization
In its current form, qa.d.o is capable of and being utilized to test against multiple environments:
You might ask, if PIFR has the capability to test multiple environments, why has it not been used to resolve the Drupal 8 blocker for testing against a variety of environments? The most compelling reason seems to be a combination of emotion and the immense resource utilization.
Knowing the resource utilization problem 5 years ago, this was the driving force behind our design. Our platform makes it possible to effectively utilize diverse machine resources for a significant reduction in cost and response time. The DrupalCI effort has not addressed this problem.
In addition to speed, the platform offers many other additional features the community would benefited greatly from (and would have over the last 5 years). We believe it not in the best interests of the community to continue to prevent a vital improvement to drupal.org.
Comment #17
rdtb418 commentedFor reference, an example of the comment is attached. The platform can respond significantly faster than qa.d.o and the differential can be increased with additional machine resources.
In the absence of a violation of the terms of service, as noted by David in #15, we would appreciate the confirmed role to be reinstated promptly and the discussion continued as desired.
Comment #18
MixologicI was the one who confirmed him in the first place after a discussion with him in IRC.
https://pastebin.osuosl.org/19536/
This user happens to be boombatower (https://www.drupal.org/user/214218) , who lied to me in IRC to get this account confirmed. Im pretty sure thats a violation of the terms of service.
evidence here: https://pastebin.osuosl.org/19531/
He has already approached this whole conversation about alternate testbots and his 'review driven' in a problematic way that was currently under code of conduct review.
https://www.drupal.org/node/2425683
He lied to me to get his account confirmed in order to have his reviewdriven bot auto post to the issue queues.
This is not the behavior I would expect from somebody who wishes to have their opinions considered.
We should block this account entirely, as its really just a sockpuppet for boombatower.
Comment #19
rdtb418 commentedThe process for obtaining a confirmed account involves:
All the statements made in IRC were true and you were not lied to.
What if boombatower had come to you directly and asked for this? This response shows once again that there is an unjustified bias against him which prevents certain individuals from responding to the actual topic. Instead boombatower receives emotional, irelevant, or otherwise misleading responses. Your response is again drawing attention away from the topic at hand.
The Terms of Service allows for group accounts representing organizations and does not disallow multiple individual accounts. In either case there is no basis to block this account.
Comment #20
xjmI'm pretty sure that if I created a fake account, contacted infrastructure under false pretenses, deceived them to get it marked as a non-spammer, and then used it with a bot to post noisy comments promoting my own Drupal work or agenda on every core patch that was tested, I could (and should) expect a similar response.
I don't know boombatower personally. The actions speak for themselves.
Comment #21
jthorson commentedAs per https://www.drupal.org/node/2425683#comment-9663095, this is related to an existing discussion already in front of the Community Working Group; with regards to behavior contrary to the code of conduct. Postponing, pending resolution of those discussions.
On a personal note, please stop misrepresenting history and putting words in my mouth. Yes, ReviewDriven was technologically superior to PIFT/PIFR. The comparison ends there.
The reason you have been unable to to contribute your improvements back to drupal.org for the last five years is that you initially proposed a closed-sourced model that was rejected by the community; and you have since done absolutely NOTHING to attempt to work with the community to get it deployed since. This is clear to anyone who knows the history ... the only conspiracy at work here is one of your own creation.
This community is about collaboration ... your actions demonstrate a recurring lack of understanding on that point.
Comment #22
rdtb418 commentedAction has been taken to block this account on the basis of an implied violation of the terms of service; yet no evidence is forthcoming to justify this nor can any be presented. Accordingly the ‘confirmed role’ should be reinstated on this account immediately. Any delay in doing so constitutes an actionable violation of said terms of service.
One reason for this account is as a workaround for the refusal by certain parties to: consider the best interests of the community and embrace a unified effort with regard to the automated testing workflow, including the use of a superior, proven and existing solution.
The claims by @xjm, @mixologic, and @jthorson constitute libel. (If any of you is unclear on the meaning of the term ‘libel’ you would be well advised to look it up.) Further, these remarks are irrelevant to the topic at hand.
Comment #23
joshuamiThe rdtb418 account was in violation of the terms of service, section A paragraph 3.
(https://www.drupal.org/terms)
3. If you are sharing your user account with multiple people (e.g. as your “official” organization account), you are not allowed to do the following using this account:
If you are sharing your user account with multiple people you ARE allowed to:
I am relating the issue that was originally submitted to the Community Working Group and marking this issue as postponed until that process is resolved.
Comment #24
gregglesThanks, joshuami, for reviewing the TOS w.r.t. this issue.
In #10 David_Rothstein asks about a policy on interactions with d.o by automated accounts. That is discussed in #2328093: Establish policies for external bots or tools that post or modify content on drupal.org so adding that as a related issue.
Comment #25
avpadernoI am closing this issue, since the account in object has the confirmed role.