[Pulp-dev] Spam on plan.io

Dana Walker dawalker at redhat.com
Fri Dec 7 21:26:08 UTC 2018


We should make an effort to mention this to new contributors when on say
#pulp we encourage someone to submit or comment so they don't wonder what's
wrong.

--Dana


Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>


On Fri, Dec 7, 2018 at 4:24 PM Robin Chan <rchan at redhat.com> wrote:

> Removing incentive seems like a good tactic to try. And perhaps we can
> take a look at some metrics to see if it's helping after trying for a bit.
>
> On Fri, Dec 7, 2018 at 7:26 AM Austin Macdonald <amacdona at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Oct 31, 2018, 3:57 PM Austin Macdonald <amacdona at redhat.com
>> wrote:
>>
>>> On Wed, Oct 31, 2018, 2:23 PM Daniel Alley <dalley at redhat.com wrote:
>>>
>>>> Maybe the first comment / issue posted by an account would need to be
>>>> approved, but once approved they could post subsequent comments / issues
>>>> without delay?
>>>>
>>>>
>>> @dalley, sounds right to me. I think this could be implemented using
>>> bmbouters b) option, with 1 difference. If the user can't even file until
>>> approved, I think we shouldn't do it. If the user can file an invisible
>>> issue, I'm ok with this.
>>>
>>> On Wed, Oct 31, 2018 at 1:28 PM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>> b) create a "trusted users" group and have that allow users to either
>>>> post comments, post issues, or both and then disable those permissions for
>>>> "other accounts". This would prevent a new user from filing a bug in a
>>>> self-service way though.
>>>>
>>>
>>> b) Story >>> A new user is created, they file an issue. Issue is not
>>> visible until approved. When issue is approved, user is moved to "trusted
>>> user" group. Further issues are not delayed.
>>>
>>> This would fix the problem at the cost of delaying response to new
>>> contributors at a critical time, right after their first contribution.
>>> Using "trusted users" would allow us to filter out most issues,
>>> significantly reducing the workload to review for spam.
>>>
>>
>> Nothing has changed except my patience. Ugh.
>>
>> IMO we need to remove the incentive, which means hiding the first
>> issue/comment of new users.
>>
>> Unless anyone is strongly against this, I'll file an issue and we can
>> discuss the technical details there.
>>
>>
>>> However, we could also users "trusted users" as an invisible flag that
>>> makes no difference to the user. This would be the exact same amount of
>>> work as b) for us, but new contributor issues are always visible. So after
>>> all this, I'm leaning toward a) + 1/2 b)
>>> On Wed, Oct 31, 2018 at 1:28 PM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>> a) manage the spam better
>>>>
>>>
>>> a) Story >>> A new user is created they file an issue. Issue is visible
>>> immediately. Spam review must review every new issue from every user.
>>>
>>> a) + 1/2 b) Story >>> A new user is created, they file an issue. Issue
>>> is visible immediately. Issue is flagged internally for spam review, if not
>>> spam, user is added to trusted group. Further issues would skip this
>>> process.
>>>
>>> I have one last thought that might make b) more attractive, but its a
>>> shot in the dark. Since the spam is coming from humans, someone is paying
>>> them. If we never show the spam, we remove the incentive, and hopefully
>>> someone will notice and stop it. If y'all think this is how things woud go
>>> down, we could always do b) until the problem stops and switch to a) + 1/2
>>> b).
>>>
>>
>>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181207/9da90ffe/attachment.htm>


More information about the Pulp-dev mailing list