Thursday, September 15, 2016

Re: IRC SIG needs external oversight

>>>>> "SJS" == Stephen John Smoogen <> writes:

SJS> While there will be cases of that, there is also a very real
SJS> problem with the amount of time, the amount of good bandwidth that
SJS> IRC seems to require over website and email moderation.

I know this is nitpicky, and I apologize, but:

I find that an odd statement given that IRC dates from the time before
time and many web sites can be quite heavy. It should actually be very
bandwidth-friendly. My client, in a large number of channels and with
automatic whois and nick watching and all of that kind of thing running,
sees occasional bursts of traffic in the tens of kilo_bits_ per second.
Visiting a single ask.fp.o page generates more traffic than IRC does in
ten minutes; it takes 50 https requests and nearly 2MB of data. Maybe
there's a mobile or plain version I'm missing.

IRC does require a bouncer, though, if your network is so bad that you
lose connectivity constantly; otherwise the experience isn't so great
and the network sees you come and go. The latter does tend to annoy
some people, but I've always thought that those people should just hide
join/part events and go on with life. And what I really don't
understand is why the one poor person with the bad network who wanted to
be involved but kicked out of some channels wasn't just offered a
bouncer somewhere. I mean, there's a completely technical solution to
that issue which doesn't involve any arguments or feeling-hurting or
whatnot. (I'm assuming that didn't happen; if it did and that person
refused then that's a different story.)

IRC does require an enormous amount of _personal_ bandwidth though. And
it's not just time, but also the capacity for absorbing stress. Since
the conversations are real time, you don't generally have luxury of
posting a well reasoned response at your leisure. I think that lack of
reflection time, coupled with the GIFT (please don't make me expand
that) makes IRC such an unpleasant place so much of the time.

That said, #fedora-devel and many of the domain-specific channels like
#fedora-kde or #fedora-kernel are pretty much always pleasant. There
are many of us who are there and trying to help out when possible, but
we just don't have the bandwidth for #fedora. I guess that doesn't
really help anything, but if we (or, more properly, the domain-specific
channel we're in) were pinged to see if we could drop into
#fedora to ask a question, I'm sure some of us would at least try.

- J<
council-discuss mailing list
Fedora Code of Conduct:

The Fedora Project's mission is to lead the advancement of free and
open source software and content as a collaborative community.

No comments:

Post a Comment