Thank you Pete - that makes a lot of sense. <div><br></div><div>Might requiring a simple captcha for each edit do the trick..? In addition to, or perhaps instead of, requiring a registered email? Just a thought -<span></span></div>
<div><br></div><div>Best,</div><div>David<br><br>On Sunday, February 9, 2014, Pete Forsyth <<a href="mailto:peteforsyth@gmail.com">peteforsyth@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">David, two things:<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 9, 2014 at 5:54 PM, David Keenan <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','dkeenan44@gmail.com');" target="_blank">dkeenan44@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forgive my naiveté, but - what are the arguments against requiring registration to edit as a permanent requirement, moving forward..? Doesn't seem that onerous - to me, anyway. I know we'd have to vote on it and all, but im curious (and entirely <span></span>open to) to hear from folks who'd be against such a change.<br>

</blockquote><div> </div></div>(1) In my opinion, it is better to leave things open to casual fixes, than to close things down; obstacles of any kind will prevent some improvements (even if they are only small improvements that somebody doesn't feel like bothering with an account for). In my mind this is not an absolute rule, but it's a worthwhile guiding principle.<br>

<br></div><div class="gmail_extra">(2) With MediaWiki, requiring registration doesn't solve the problem, it only pushes it back. The spambots are just as good at creating accounts as they are at making IP/anonymous edits.<br>

<br></div><div class="gmail_extra">This is why i suggest getting a small group of people to focus on the problem and recommend a solution. With MediaWiki there is no magic bullet that we just haven't gotten around to implementing -- it will take a careful consideration of a combination of a number of options, and assessing how effective they are at the current date -- because this stuff evolves rather rapidly. Basically, I'd describe it as a design problem, not a binary "lock down or do not lock down".<br>

<br></div><div class="gmail_extra">What *combination* of various policies, extensions, and settings is right for meeting Sudo Room's needs?<br><br></div><div class="gmail_extra">Pete<br></div></div>
</blockquote></div>