On 01/24/2012 09:13 AM, Ewoud Kohl van Wijngaarden wrote: > Given gerrit already works with openid I was wondering if the wiki > could support the same. It seems there is an extension[1], and it > also seems it's packaged for fedora[2]. Has anyone looked into this > and would it be a desirable addition? > > [1]: http://www.mediawiki.org/wiki/Extension:OpenID [2]: > http://koji.fedoraproject.org/koji/packageinfo?packageID=5922 My major concern with the wiki is keeping us from having spammers ever get accounts on there. We have enough trouble gardening our own work, we'd get buried if we had to manage spam pages. I would reckon that OpenID would give a way for spammers to come in, unless we limited the OpenID servers we worked with, which would sort-of be against the reason for having OpenID in the first place. But I'm very open to other thinking, just unsure how it would be implemented.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 03:40 PM, Ewoud Kohl van Wijngaarden wrote: > I have no experience with mediawiki + openid myself, but maybe > giving it a go and monitor it would be good enough for now. > > Possible downsides: - Spammers use openid to spam > > Possible upsides: - More open to new people - People can use a > single account for both gerrit and the wiki > > Since the wiki edits are also shown on IRC I think spam would be > caught fast enough and in the worst case the change could be > reverted. That's a good point, the wiki edits are watched that way more carefully. What would our reaction be if we started to see spam edits via OpenID accounts? * Can we easily disable those accounts? * Would we revert to not using OpenID? ** Sometimes spammers seem to be doing test-spam on a wiki, so a few scattered edits might be preparation for an onslaught. Also consider all this in terms of who is taking care of the wiki. We don't (yet?) have enough individuals or a team that seem to be taking on any wiki management tasks. So a spamming situation could rally such folks, but it could also kill the energy while in the crib by overwhelming it with spam pages from incrementally more spam accounts. I'm reacting a bit here to e.g. more wiki pages being incorrectly named than not, so a lot of wiki gardening required still. OTOH, I am very much in favor of lowering barriers as much as we can. I'd like to proceed with this discussion and just figure out a way to counterbalance the risks, etc.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 03:40 PM, Ewoud Kohl van Wijngaarden wrote: > I have no experience with mediawiki + openid myself, but maybe > giving it a go and monitor it would be good enough for now. >

On Wed, Jan 25, 2012 at 10:17:43AM +0200, Itamar Heim wrote: > On 01/25/2012 06:03 AM, Karsten 'quaid' Wade wrote: >> On 01/24/2012 03:40 PM, Ewoud Kohl van Wijngaarden wrote: >>> I have no experience with mediawiki + openid myself, but >>> maybe giving it a go and monitor it would be good enough for >>> now. >>> >>> Possible downsides: - Spammers use openid to spam >>> >>> Possible upsides: - More open to new people - People can use >>> a single account for both gerrit and the wiki >>> >>> Since the wiki edits are also shown on IRC I think spam would >>> be caught fast enough and in the worst case the change could >>> be reverted. >> >> That's a good point, the wiki edits are watched that way more >> carefully. >> >> What would our reaction be if we started to see spam edits via >> OpenID accounts? >> >> * Can we easily disable those accounts? * Would we revert to >> not using OpenID? ** Sometimes spammers seem to be doing >> test-spam on a wiki, so a few scattered edits might be >> preparation for an onslaught. >> >> Also consider all this in terms of who is taking care of the >> wiki. We don't (yet?) have enough individuals or a team that >> seem to be taking on any wiki management tasks. >> >> So a spamming situation could rally such folks, but it could >> also kill the energy while in the crib by overwhelming it with >> spam pages from incrementally more spam accounts. >> >> I'm reacting a bit here to e.g. more wiki pages being >> incorrectly named than not, so a lot of wiki gardening required >> still. OTOH, I am very much in favor of lowering barriers as >> much as we can. I'd like to proceed with this discussion and >> just figure out a way to counterbalance the risks, etc. > > can we separate the openid support for authentication (so people > can user same user/password) from authorization (can an openid > account do something)? > > so we would still have the process of an existing user has to > give edit permissions to an openid user? That could be a mitigation in case we do get spammers. I'm wondering how wikipedia handles this since that's an open wiki using the same software. Using an extension for authentication makes us a non-standard target and thus harder.

I think it's important, if not vital, for an open source project to have a low barrier to join. Making it easy to do small fixes on the wiki could help get people more involved.

So in short I think using openid authentication and open authorization will benefit the project at an acceptable risk of spammers. If we do notice spammers we can switch to user authorization with manual approval of users or in the worst case fully disable openid and revert to the current workflow.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPIHWI2ZIOBq0ODEERAiioAJ96Cc0ZKm7ZvnaFfQAnrHhvla0e9wCdG4c4 AIOT2IIfTrJ8qtN47c96hcw= =D3ho -----END PGP SIGNATURE-----

Are you able to volunteer to help with wiki gardening? In specific, keeping things cleaned up if we do get a spammer - reverting changes, deleting accounts, etc. If we can get enough of us to watch things with commitment, then I'm much more comfortable with the idea of rolling out OpenID.

OK, I'm game for doing this then. Can we do a quick process write-up here? That is, what do we think it's going to take in steps so far, then we can find the gaps and fill with our knowledge. In the end, I'd like to have the service up _and_ a page similar to these: http://ovirt.org/wiki/Category:Infrastructure_documentation