[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed General Resolution : IRC as a Debian communication channel

>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

 >> by letting future maintainers join (and
 >> lurk), we'll let them learn faster how Debian works. 

 Anthony> Congratulations! Some actual justification for what you want
 Anthony> to happen!  And now, you'll even get some on point rebuttal,
 Anthony> instead of meta-rebuttal.  And you'll note it's on the topic
 Anthony> of an actual *action* rather than some random wording
 Anthony> change, or way of thinking about things.

 Anthony> This isn't particularly true, though: for a start, we
 Anthony> already provide debian-policy, the developers-reference,
 Anthony> several example packages and helper tools, and the
 Anthony> new-maintainer process; they're the "official" guides to
 Anthony> learning how Debian works, and they're available via the
 Anthony> traditional Debian avenues: the package system and email.

	I would also like to point out that IRC is not a medium
 accessible to everyone, and is certainly not a requirement in order
 to be a Debian developer (not that any one has asserted that,
 but). I also posit that presence on the channel does not actually
 lead to any positive insight on the workings of Debian. It may permit
 quick exchange of ideas and opinions with fellow developers (a beer
 in a bar is even more conducive to that). Indeed, were I to base my
 knowldge on the IRC channel, I would come off with a skewed view of
 Debian, and one that is rarely flattering to the project.  The
 working of the project are carried out on specialized mailing lists,
 (debian-www, debian-emacsen, debian-java, debian-perl, debian-policy,
 debian-sgml, et. al), and newcomers should look for a mailing list in
 an area of interest and lurk there, and they shall be far better off
 than someone who spent that time hanging out on IRC.

	New developers are far better off scanning the mailing lists,
 and the documents aj has pointed out. 

	So, I reject the statement that it allows you to see the inner
 working of the project; except in rare occasions.. I agree it lets
 one get to know a few developers better. 

 Anthony> But there're a more important purpose to #d-d than teaching
 Anthony> newbies: and that's providing a quick and easy means for
 Anthony> developers to talk to each other. At the moment we come
 Anthony> close to guaranteeing that everyone on the channel's
 Anthony> committed to Debian, usually evidenced by them being a
 Anthony> sponsored maintainer/in the n-m queue, or being a registered
 Anthony> developer.  For a long while, we kept it that way by
 Anthony> ensuring that the channel's existance wasn't widely known,
 Anthony> that way the only people who'd ever join would be people
 Anthony> recommended by someone else cluey. The benefits of having a
 Anthony> channel inhabited solely by people who're already actively
 Anthony> involved in Debian seems pretty clear: don't have to worry
 Anthony> about "Debian SuX" trolls, don't have to worry about
 Anthony> answering user questions, don't have to worry that someone's
 Anthony> watching your every word about to jump all over it.

	Conduct rules can be enforced on IRC by chanops; and in my
 experience very rarely have I seen out and out trolls on the
 channel. Secondly, being a member of the project is a poor metric of
 usefulness in a channel.  I know a number of very cluefull people who
 take part in the discussion on the mailing lists, excluding similar
 people from the channel would not be in our best interest, merely
 because they have not been blessed by penguin pee, as it is sometimes

	Exclusion rules should not be based on membership in an
 organization or knowledge of secret hand shakes. Conduct rules, which
 is what we seem to be talking, ought to be based on conduct, and not
 merely on affiliation.  I reduced my presence in the channel due to
 some distress by caused by the conduct of the denizens, and these
 denizens are card carrying debian developers. Conduct, and not
 artificial indirect criteria, should be the basis of ensuring a
 environment conducive to productive conversations.

	I think not having to watch over your every word so that no
 one jumps all over it has not been true of the channel for a
 while now,

 >> It's not only about
 >> the channel utility, it's also about the channel "role" (within Debian).

 Anthony> And as far as that's concerned there's another problem with
 Anthony> making irc at all official, which has been alluded to
 Anthony> elsewhere in this thread. IRC is a *very* poor "official"
 Anthony> communications medium. Try summarising an IRC discussion
 Anthony> sometime, or culling out the useful parts of an IRC log in a
 Anthony> way that stands alone and is actually readable,
 Anthony> sometime. It's very difficult to extract the sense from the
 Anthony> noise even in a fairly focussed conversation. That pretty
 Anthony> much wrecks it for archiving purposes.  It's also realtime,
 Anthony> which means that if two people don't happen to be available
 Anthony> at the same time (because ones asleep when the other's
 Anthony> awake, or because one can only do Debian stuff on the
 Anthony> weekends and the other hates touching computers in his free
 Anthony> time, eg) it's also useless. IRC's great as an unofficial
 Anthony> communications medium, but IMO it's too inaccessible to too
 Anthony> many people to warrant being considered "official".

	Pardon me for not trimming this, but I think we need to
 reinforce this message. Very well said.

 if (argc > 1 && strcmp(argv[1], "-advice") == 0) { printf("Don't
 Panic!\n"); exit(42); } Arnold Robbins in the LJ of February '95,
 describing RCS
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: