IRC/Group Contacts/Meetings/August 2009/Minutes

What follows is an experimental write up of what occured at the IRC meeting of July 2009. It is initially merely a skeleton of what occured, and what the creator of this page thinks was taken from each topic by the group contacts, other IRC personnel (ops and channel contacts) and the IRC community as a whole - so please add to it.


Chair: Sean Whitton (seanw)

Present: 80+ Wikimedians, including all the IRC Group Contacts.

Topics discussed edit

#wikimedia-ops edit

Discussion edit

  • seanw introduced the topic by asking the channel what they thought of #wikimedia-ops, how useful it is, given that the GCs have been working on getting more channel contacts into it of late
  • harej didn't think that a global ops channel was needed because of the seperate diversity present around Wikimedia's IRC channels; he cited #wikimedia-en-admins-ops as an example of a local ops co-ordination effort that was, in his view, entirely sufficient
  • Martinp23 pointed out that the IRC response to the downtime Wikimedia experienced recently could have been improved with better usage of -ops, to inform ops of what was going on for them to then pass this onto users

There were then various agreements with harej and Martinp23, though mainly with harej!

  • [MarkW] reminded the channel that another key purpose of -ops is to allow banned users to appeal, and Rjd0060 added the function of helping new users out with IRC technicalities
  • saper and Mike_lifeguard together brought out that a key reason for the GCs efforts was to work out which channels had no active operators by getting them involved in -ops
  • seanw added that when he started -ops he wanted to use it as a method of standardising op behaviour to be more respectful for civility, assuming good faith and using banning as a preventative measure not a punishment
  • seanw then asked whether or not the channel thought getting users into -ops was a good use of GC time; it was generally agreed that it was
  • Martinp23 concluded with the point that while we have a standing invite to -ops to all ops, certain communities such as #wikimedia-tech and #mediawiki might choose to ignore it and there was little that could or should be done by the GCs about this
  • ^demon suggested that it was not a refusal but a recognition of -ops having no use on the part of many ops
  • It was then suggested that a bot might automatically find out if ops for smaller channels were available when !ops-channel-name was called in -ops. Mike_lifeguard said he could do this

Conclusions edit

  • GCs will continue to encourage contacts and ops in -ops
  • Those who support the pushing of -ops need to make a better case for it in order to better encourage ops to join, or otherwise
  • The three key reasons for -ops' existance were solidified:
    • Providing general IRC help
    • Providing a place for bans to be appealed
    • Standardising op behaviour by creating a community of said ops

seanw apologised for the vagueness of the first item in the agenda which led to a high volume of barely on-topic messages.

Ease of contacting the group contacts edit

Discussion edit

  • seanw explained that the main advertised method of contacting the group contacts consisted of irc-contacts lists wikimedia org and irc-contacts-owner lists wikimedia org, with the former going to several channel contacts and the GCs, and the latter to the GCs only, with the former encouraged for most use. He asked the channel if this was good enough, and if any alternative suggestions were forthcoming
  • ^demon asked if the GCs knew of people not getting helped who might be helped with a new system, and seanw responded that they hadn't seen any but obviously may have missed some, which was the point of raising this topic
  • At various points in this discussion the issue of the GCs replacing a mailing list with an OTRS queue came up, to which the GCs tended to relpy that since this would only affect them as the input to both systems is just an e-mail address, and they had no problem with the current system, there was no real reason to change
  • The channel generally noted that since the GC team was refreshed there weren't really any problems with contactability anymore
  • lyzzy pointed out that the issue was not contactability, but simply the fact that most users aren't aware that the GCs exist. seanw asked for suggested solutions to this, and lyzzy suggested a general introduction to the GCs and their work on foundation-l
  • The channel seemed to come to the conclusion that since most people don't need the GCs, it made more sense to advertise #wikimedia-ops, who could then forward things on as necessary
  • There were some discussions about renaming -ops to -irc, but there was no consensus so it defaulted to keeping it how it is

Conclusions edit

  • #wikimedia-ops should be advertised broadly as a place for IRC help, as a working channel into which confused users and meta IRC requests can flow to be dealt with
    • A post to foundation-l explaining about -ops and GCs might be beneficial in reducing the number of confused and/or disconnected (from the broader IRC community) users on IRC

mediawiki/ cloaks edit

  • ^demon was reassured by seanw that mediawiki/ cloaks, by default available to all developers with commit access (with appropriate exceptions), were coming as soon as the infrastruction to deliver them, i.e. the approaching rewritten cloak request system, was up and running

Procedures for emergencies edit

Discussion edit

  • kmccoy explained how he was concerned that the mass chaos spawned by site outages disturbed developers attempting to use #wikimedia-tech to co-ordinate their rescue efforts
  • domas reinforced this point, explaining that #wikimedia-tech was a working channel due to the likes of a Nagios daemon spewing status messages there, and kmccoy moved for finding a better way of getting information from the devs out to the ops so they could more effectively manage the crowds
  • domas asked seanw to file a bug report asking that #wikipedia be removed from the default error page that is shown to users when the sites are having problems, on Martinp23's suggestion that the devs get their own status page. Brownout later noted that a similar ticket had been closed as "wontfix"
  • kmccoy supported the listing of #wikipedia as an easy way to give out information, but again noted that said information is often unavailable
  • Aqwis and Until_It_Sleeps suggested a seperate channel called #wikimedia-downtime for these purposes. Prodego countered that #wikipedia was so quiet most of the time there wasn't really any problem with using it
  • AzaToth suggested a bot/tool to allow devs to broadcast information to many channels at once
  • Martinp23 felt that the whole problem could become a non-issue if the channel wasn't advertised, as "we'd just have the usual 50-150 users moaning and it's far far easier then for the ops to communicate" as opposed to many people new to IRC prompted to join by the error page
  • Martinp23 also felt that Twitter would be superior to IRC as a downtime communication mechanism
  • kmccoy asked domas to remind techs that ops will be in -tech listening for messages to pass on and would appreciate status updates
  • Prodego summarised the problems by explaining that if the normal users are not to flood tech, the ops need to be able to get information from -tech to pass onto #wikipedia, and if this is not forthcoming much confusion and ignorance results

Conclusions edit

  • seanw closed this discussion as going in circles and wasting time. It seems clear that we need to work out a set of clear priorities and techniques to use in these downtime situations to help readers and editors of the projects alike

Public logging edit

Discussion edit

  • seanw introduced the topic by explaining that the default prohibition of public logging is held as a GC-level enforcable policy and a discussion a year ago yielded no consensus to change this. He noted that there were many arguments on each side, key ones being the informal nature of IRC for the policy, and the unenforcability of it against it
    • Martinp23 later summarised the previous discussions since he led them, explaining that while the on-wiki discussion leant slightly towards public logging, IRC tended to be slightly in the other direction, but as already explained there was no real consensus
  • Several users argued that this was an issue for individual channels to decide (as -tech and #mediawiki already do), but Rjd0060 said that there should be a standard default for IRC as a whole
  • enhydra said that he thought there should be channel forks, e.g. #wikipedia-logged alongside #wikipedia
  • Mike_lifeguard pointed out that channels have very different content, and gave the example of #wikimedia-stewards, which he said he would not want logged due to the sensitivity of some discussions
  • Avruch noted that views on this topic remain evenly split, so consensus was unlikely
  • kmccoy felt that too much time had already been wasted on the topic, and it should simply fade out of being mentioned at all, as otherwise we encourage people to do it in the style of WP:BEANS
  • seanw clarified why this was being discussed: public logging has always been seen as a GC issue as historically the GCs have been expected to enforce it. He also explained that public logging meant making the logs generally available to anyone with a web browser or comparable tool, which does not include the private logs that some ops have access to that are kept by a bot and stored on the toolserver
  • FastLizard4 moved for logging -ops at the very least for the preservation of ban rationales
    • Prodego replied that he thought such logging would remove such discussion from -ops
  • Mike_lifeguard pointed out that a reliable method of logging would be needed if we started public logging, perhaps on the toolserver, to prevent conflicting sets of logs
  • Martinp23 asked if lightheadedness on IRC should be allowed to "sink into someone's RfA" due to the permanency offered by logging
  • Martinp23 suggested that this whole discussion was not appropriate for this meeting given that such a small slice of the IRC community was present. Rjd0060 concurred with the idea of having such a discussion on-wiki

Conclusions edit

  • seanw closed the discussion as not going anywhere. There was again no consensus, so things defaulted to keeping the rule

Ease of accessibility of checkusers and oversights on IRC edit

Discussion edit

  • harej explained that he recently proposed voicing checkusers and oversights from the English Wikipedia in #wikipedia-en-admins, in order to try and make it easier to for people to know that their requests were seen and being acted upon. seanw noted that discussion on the general accessibility of those with these permissions, especially that of oversight, has been circulating in other venues as well
  • Martinp23 argued that this was a per-channel issue but seanw said he thought the meeting might be able to provide best practices
  • dungodung was afraid that the users who needed quick OS/CU access were unlikely to know what voicing meant in this circumstance, if they understand what it is at all
  • Mike_lifeguard said he had asked the GCs whether or not the checkusers used their private channels in the way the stewards do so successfully, but he didn't get a very good answer
  • harej noted that it had been proposed that a #wikipedia-en-functionaries channel be created
  • kmccoy said that he felt such a policy would discourage CU/OSs from coming on IRC as they might feel it made them always on duty
  • kmccoy and Annemarie argued that a status game would be created by the proposal
  • Martinp23 thought it would be simpler just to maintain the current system of stalkwords, as it works for ops rather than maintaining their +o modes all the time
  • kmccoy (seconded by Annemarie and Danny_B) pointed out that such a symbol was useful in -ops for newcomers, but that it becomes a status symbol elsewhere
  • The channel seemed to conclude that stalkwords were sufficient for the purposes under discussion

Conclusions edit

  • seanw closed the topic as not achieving much

Attendee's conclusions edit

seanw edit

I shall try to keep this uncharacteristically brief by shackling myself in bullet points.

  • Good: we got through quite a lot of topics and no-one seemed to find that what they wanted to discuss wasn't got to, and we found out several 'issues of the day' that need dealing with: we need to advertise -ops more, and we need to work out what to do in emergencies. The GCs will deal with these.
  • Bad: we didn't vet and confirm the meeting agenda beforehand, and I didn't prepare my opening remarks. This led to disagreement between the GCs during the meeting which was not okay at what was supposed to be a GC surgery. The GCs, in consultation with members of the wider community, should set a standard for what is actually supposed to be discussed at these meetings, to keep the agenda manageable and useful. This should also reduce the number of discussions closed as becoming nothing more than circular, repetitive affairs.
  • I found that I learnt a fair amount about chairing larger IRC meetings from this so I hope to be able to carry this forward to November. It is clear that these meetings can turn out very useful material, we just need to tweak what we did this month a little to make them as good at this as they can be. Overall, not bad at all, for what was really a first shot at it. —Sean Whitton / 20:13, 5 August 2009 (UTC)[reply]

Rjd0060 edit

I won't repeat what Sean mentioned above but I'll note that I'm in agreement with all of his comments. The meeting went well and we see a few things that we need to work on. We'll be doing so. The meeting was successful in my opinion and I'm looking forward to the next one. Keep an eye on IRC/Group Contacts/Meetings for details about that.

Of course, in the meantime, I invite anybody to contact us with any questions, comments, or concerns. We'll, at the very least, point you in the right direction. Thanks again to all who attended. - Rjd0060 20:18, 5 August 2009 (UTC)[reply]

Dungodung edit

IMO, the meeting went well. We covered all the topics from the agenda (although, not in the same order, but that's not really relevant) and did that in less than 2 hours. It goes without saying that short and to the point meetings are the most productive. In that regard, I think we did well. However, I felt at times that we were digressing from the current topic, but that's just how people do when you have about 80 attendees and most of them have something to say re the topic. Otherwise, people were quite constructive and Sean did a pretty good job with moderating. --FiliP ██ 20:26, 5 August 2009 (UTC)[reply]

kibble edit

The turnout for the meeting was great, we had a lot of interested people. Considering this was our first meeting and there was a lot more people than was expected, the moderation was a good idea and went well (only suggestion is that we give more of a warning). There was also the issue of staying on topic, but that was to be expected. We could also use more notice in the future, as well as a confirming an agenda around a week or so before with the topics reviewed and ordered based on the meeting.

The meeting also helped us get a lot of great feedback from the people who use IRC, which will be useful in determining what we need to focus on and what things we could do better. We also had very few trolls, considering we did an amsg and invited everyone. :-) Cbrown1023 talk 20:45, 5 August 2009 (UTC)[reply]