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,
Lodewijk
2008/7/28 Gregory Maxwell <gmaxwell(a)gmail.com>om>:
On Mon, Jul 28, 2008 at 1:25 AM, Jon
<scream(a)datascreamer.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l