I know we’ve discussed this at length and were going to use trust levels, but those have the unintended side-effect that we can get low-quality posts, yet still get access. I propose a different route.
What if we require /dev/null, AND trust level 1 on discourse. Why would this work? It’d allow for them filtering out spammers better. Justification still has to occur. I have already denied access to one person whose username matched that of spammers.
Would that require people to have a GitHub ID to contribute to the wiki or JIRA?
Basically, yeah – we can grant it on a case-by-case basis if we know and trust the person. If there is a convincing reason – I have no issues granting access but they need a reason. I hate spammers so much.
I suppose requiring the Friendly User badge before people can add/edit pages on wiki/jira would be okay – i.e., you have to introduce yourself before you can contribute. But I don’t think requiring a GitHub ID is a good idea, since not everyone we want contributing to wiki/jira would have GitHub account. It would also be nice to work toward something between a non-working captcha and a you-have-to-talk-to-robby approach.
Instead of a trust level depending on posts, how about a trust level that is granted to anyone who has a post liked or for whom someone issues “!trust username” in IRC or Telegram?
When it was self-service, what was the average number of OpenMRS ID signups per day? I agree that it appears people are manually signing up for spam accounts, but did you ever try a honey pot field to be sure?
The issue is that I want to make it non-trivial – I do not want to make it easy for them. It’s a necessary evil if we don’t want spam. People can request it but they have to convince me or whoever is reviewing their request WHY they need it. There will be exceptions made but this will also have the unintended consequence of last minute GSoC students being filtered…You can browse issues anonymously but you can’t report them.
Nah. Don’t like this. It has to be something I can easily get via discourse’s API.
We have a honeypot field.
I haven’t been following this too much, but agreed with Burke that I don’t think requiring a Github account is the way to go, as we have implementers entering and commenting on bugs and updating the wiki that may not have a Github account.
I
If they are an implementor – we can grant them access.
I’m gonna go with at trust-level-1 – the idea is to filter out spammers. I want to make it reasonable, yet non-trivial. I’m open to ideas.
I like this approach. Is that easy to do @r0bby? Maybe we could require friendly user + at least one liked post.
I can definitely sympathize with @r0bby on wanting to prevent unwanted spam. I used to work at a company who let spammers publish fake, computer-generated journal articles. It took months of cleanup.
In addition to @Burke’s thoughts regarding efficiency, I would be concerned about lowering the hurdle for those who want to participate. It’s never an awesome feeling to be the brand new guy (or gal!) in a project. Having to bother an admin in order to justify his or her intentions may make them feel unwelcome or leave them with a bad impression.
Akismet?
Let me know if Akismet is something that could help you @r0bby. I used to work at another nonprofit and we were able to get the enterprise license for free.
Akismet has a plugin for Discourse and (I believe) it is integrated into the Q&A platform that runs on top of Confluence. I do not know if it’s also tied in with the Confluence wiki.
We use it to great success on discourse – A few false positives but it works! I looked into it for JIRA/Confluence but it costs $$$ – I’ll see if we can either get it free (we should be able to).
I agree but I don’t know a middle-ground here.
I guess? It works. We can always tweak what we use – I’ll try to write it extensibly.