[Foundation-l] First IRC Group Contacts 'surgery' held this evening, cloak backlog (almost) cleared (yay)

effe iets anders effeietsanders at gmail.com
Mon Jul 28 18:34:41 UTC 2008

Another problem I see, but not sure how important it is, is that this
would make Wikimedia possibly responsible (legally speaking) for the
communication through IRC etc, which might not be wanted. Nowadays we
can just point to freenode, which handles it all, and will be taking
action when required.

Besides that, I don't think that the extra software maintaining will
cost developers the most time, but that the nagging users will. Users
that come for small issues to the developers because sean and/or james
are for a while away, and (disaster!) the cloaks can't be set for a
while. now people turn to Freenode, which is perfectly able to handle
it, doing nothing else practically, either by fixing either by telling
them to have patience. When Wikimedia developers have technical
control over the channels and nicks etc, this would mean mainly an
additional workload on that behalf, would be my expectation.

with kind regards,


2008/7/28 Gregory Maxwell <gmaxwell op gmail.com>:
> On Mon, Jul 28, 2008 at 1:25 AM, Jon <scream op datascreamer.com> wrote:
>> Hash: SHA1
>> Joe Szilagyi wrote:
>>> Is there legitimate reason it would not be more beneficial and easier to
>>> simply set up something like irc.wikimedia.org and host it in-house?
> I made a suggestion that we change networks or run our own during the meeting.
> The bandwidth requirements would be infinitesimal and it could could
> be placed where Wikimedia's traffic is the least costly if bandwidth
> were really an issue.
> There would be a couple of interesting possible benefits:
> * Long term login integration with SUL: Have Wikimedia SUL logins
> function as IRC logins.
> ** Automatic permissions, we could overlay the existing wiki
> permissions onto IRC lowering the amount of special IRC management
> required. Adminship on enwp would permit you ops in #wikipedia-en
> ** Possibilities of extending IP blocks on projects automatically to IRC. ;)
> ** Other integration: Things like chanserv telling you that you have
> new talk page messages.. etc.
> * More consistent handling of private data:  Even if you have a
> freenode cloak anyone can get your IP if you use freenode by doing a
> /whois on you at the moment you connect. This could be resolved by
> obscuring the IP.
> * Improved reliability: In the decade or so that I've used freenode it
> has *always* been the least reliable IRC network that I use. I still
> see netsplits multiple times per week on good weeks, and multiple
> times per day on bad weeks.. It's not so bad as to be debilitating, as
> seanw put it, but it's obnoxious.  Wikimedia's datacenter
> interconnectivity is better than this, and the more limited scope of a
> Wikimedia IRC would make scaling somewhat easier.
> I see three downsides:
> * IRC goes down when the Wikimedia network is down.  At a minimum the
> tech folks will probably need to maintain a presence on another IRC
> network.  I expect that the tech folks are far more likely to have
> other channels of interest on other networks than general Wikimedia
> contributors..  All modern irc clients support multiple networks
> easily.
> * It's another possible distraction for the tech team. More software
> to maintain. ... although not much of one since we already run a
> limited IRC server for the RC feeds.
> * It's another service that Wikimedia would be offering, carrying its
> own possible overheads though I expect that these would be small, easy
> to avoid, and mostly fold into the overheads of the projects.
> _______________________________________________
> foundation-l mailing list
> foundation-l op lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

More information about the foundation-l mailing list