As IRC does not work with a bozo list like the forums do, we have a few alternatives available for use in such situations as outlined below. This means we can not mark users for moderation, nor preview what they are trying to say before it is said, it’s all live, and it’s all public.

We want to maintain as much transparency as we can, this is a public medium and we keep public logs of most actions (at the moment the logging devices can not log kick/ban messages), but at the same time protecting the one performing the action from any negative retaliations which may or may not occur after action is taken.

We have three (four) ways of dealing with users who are having a bad day beyond just speaking to them and informing them that their behavior is unacceptable/a bit too much and asking them to calm down or get some fresh air;

• They can be muted
• They can be kicked
• They can be banned

Muting (or “Quieting”) a user (/mode #channel +q Nickname) requires you already have the Operator status, or can be done through network services (/msg ChanServ quite #channel Nickname) but keeps the user in the channel, he is merely silenced and can not speak in public, this is also what hlin does automatically if someone spams.

A kick can be done either by being an Operator (/kick #channel Nickname ) or anonymously through the services of the network (/msg ChanServ kick #channel Nickname ). A kicked user is removed from the room temporarily, but may return at any point.

A ban, like a kick, can be done as an Operator (/mode #channel +b Nickname) or through network services (/msg ChanServ ban #channel Nickname ). Worth noting is that using services will also kick the user, if not you will have to manually kick the user after banning them. A ban will not by default expire unless you physically remove it.

Now that we are familiar with the ways one can deal with a user, a general guideline for when to use the various actions will most definitely be needed. This will be handy both for the users of the channel to know when a moderator should step in so they can be pinged, but also so the moderators know what action should be taken when to ensure a fair ruling.

Feedback will most definitely be required here to iron these out, but I’ve taken the liberty to provide the following suggestions to get the ball rolling;

• Racism is most definitely something we keep an eye out for, users may not be aware that it’s a slur or anything like that (A large chunk of our users have English as a 2nd or even 3rd language),so a friendly pointer by any user should be enough, if they keep using such terms, let a moderator deal with them, if they do not heed a moderators warning a quick ban is swift justice.

• Strong language is handled by hlin, if someone tries to repeatedly use profanity by avoiding hlins filter a moderator can silence them as hlin would.

• Sexist talk or anything non-PG13, this could be straight up dirty talk or excessive innuendos, tell them to stop, if they don’t listen let a moderator tell them so, next step would be a mute, repeat offences escalate the action taken (most people will stop after a kick).

There are many other situations of course, but these are the ones you’ll most likely meet, not only in spoken words, but also as nicknames or messages sent to the channel when leaving it (a part message).

There was also mention of a way to log (beyond IRC logs) offenders to keep tabs on what is going on as everyone might not be on at the same time etc. Thoughts on how this could be achieved in a fair manner are appreciated as we don’t want to make any public shame list at all, we only want to make IRC a welcoming place for anyone to drop by and learn a thing or two during their stay. Possibly a list restricted to moderators on g-docs or similar is an idea?

Another thing that might come up is how to deal with disputes if a user is banned and feels it was unjust. Is there a place we’d prefer them to take their appeal, and if so, where and how?

That means we need to decide on the level of transparency we wish to have, do we wish to have full transparency with users issuing the actions, or anonymize it through network services.

@sams suggested that for transparency when issuing a kick/ban we should state why in the channel after the ban since the logger does not pick up kicks/bans and only shows peoples reactions to them, would this be an acceptable approach and how would we deal with that if services are used to act?

Oh and before I forget, the fourth reasoning mentioned is only if a user should retaliate, this is much like a DDoS on a website, and extremely rare to occur, and even rarer to have any impact as most networks have security to prevent or mitigate such things. Should a disgruntled user retaliate with proxy bots or any other kind of bots that cause spam and disruptions, and it’s to such an extent that a moderator can not deal with it, drop by the kind people in the FreeNode support channel and mention that there’s a botnet and they’ll take care of it. Not that vital as it’s extremely unlikely to ever occur, but good to know just in case.

A closing thought, as it was mentioned that not everyone may be too familiar with the workings of IRC or remember commands and such, I did mention a few of the commands with quick defaults in the post, but is this something that you would prefer a more extensive outlining of made available in some form or other?

All right ladies and gentlemen, the floor is open

Back? OK.

Please do not use language based on someone’s looks or gender. It’s wrong and can’t be tolerated.

I had some difficulty expressing this in IRC but thankfully Siobhan and Mika provided me with support and they explained it well. The reason for my difficulty was simple: this is important, this problem needs to be stamped out early and I wanted to get this right.

When someone joins the #wordpress channel or posts to the support forums it is important to remember that they are either seeking help or attempting to help others. This is a good thing and that participation makes WordPress successful.

It’s not easy for everyone to join or start a public conversation. A forum post or joining an IRC channel is exposing yourself and that’s a risk. For some that can become a painful experience.

When someone replies using language that diminishes, makes people feel uncomfortable or disparages others then that participation is lost.

If the tone of the conversation includes words that focus on people’s looks or gender then that’s it. The person who wanted to join doesn’t feel welcome. That phrase about first impressions is true and an opportunity is gone. People stop participating or they never take the chance and do not even start to contribute.

At that point it’s the WordPress community that loses out.

Unlike the forums IRC is a live medium. There’s no moderation or editing and it’s easy to say something off the cuff. Everyone has bad days and may say things that they regret. And we all have a sense of humor that can be crass sometimes.

But using language based on gender or looks is not tolerable and has to stop. It’s not enough to be aware of this behavior. What will make it stop is when everyone speaks up if they see that.

“That language is not welcome here. Please stop.”

That’s it. That’s all it takes.

That reply alone raises the expectations for the whole community. That’s not a confrontation, that’s an invitation for others to join a community that does welcome everyone.

Let’s all raise those expectations. Speak up. You’ll be encouraging other people to do the same.

The first section is ‘Stuff we, as mods, should be aware of.’ The second is the post itself

Major changes

Auto Upgrader
* How to disable
* In order for Automatic Updates to be enabled, there are a few simple requirements:
* If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled
* If the install is running as a SVN or GIT checkout, automatic updates are disabled
* If the constants DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined, automatic updates are disabled
* If the constant WP_AUTO_UPDATE_CORE is defined as false, automatic updates are disabled
* Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
* Wp-Cron needs to be operational, if for some reason cron fails to work for your install, Automatic Updates will also be unavailable
* What gets updated?
* What changed. ONLY changed files!
* Only for minor releases (3.7 to 3.7.1 but NOT 3.7.1 to 3.8)

Less Major Changes

• Better search results
• Password meter
• Visual editor (TinyMCE) updated for Internet Explorer compatibility

Under the Hood

• New dev tools
• New author queries
• Multisite finally has a way to get an array of all sites on the network
• Better inline documentation
• Better date sorting in the posts page

For the post….

Troubleshooting WordPress 3.7 Master List

Hooray! NEWVERSION is here. But OMGWTFBBQ!? WordPress 3.7 broke everything?

Don’t Panic!

This thread contains the known issues with plugins and themes found in 3.7. Please read this WHOLE topic and come back and check again later, as it will be updated.

Remember to be calm, be patient and be respectful. Volunteers are out here to try and help you, but we need your help too. All of the normal forum rules still apply. Remember, you are just as important as everyone else.

If your post doesn’t show up right away, please be patient. With the higher than normal post volume, more posts get flagged as spam by our auto-spam tool. We’re working hard to keep the queue clear, but making multiple posts slows us down, as we have to go back and check if you already posted. Post once.

• Do use proper capitalization in post titles and body. Punctuate your sentence properly and humanely, it helps us read.
• Do use descriptive subject lines. “All permalinks broken since 3.7″ is much better than “Augh! Help ASAP! This version is terrible!”
• Do describe the problem clearly. Explain what you’re seeing, include error messages and link to screenshots if needed. Linking to your site, if the problem is on the front-end, also helps.
• Do be patient. We know it sucks to be down, but posting multiple times doesn’t get you help any faster.
• Do make your own topic unless you are using the exact same version of WordPress on the same physical server hosted by the same hosts with the same plugins, theme and configurations as the original poster. You may find it weird, but it will be easier for us to help you specifically if you have your own topic.
• Do mark your topic as resolved when it’s fixed so we know not to come looking there anymore.
• Do remember you’re not alone.

Also keep in mind that not liking the direction of WordPress’s Admin Design does not a bug make. If you don’t like a feature, please don’t make a series of posts complaining about it. Look and see if someone already did, and post there, or consider joining the process earlier on (like in Beta or even test via SVN). What you’re seeing today is the result of months of work and testing, and unless something is outright broken, it’s highly unlikely to be changed.

Again, BEFORE you post:

Make sure you’ve read the entire Master List post - and the New Features in 3.7 Codex Article - http://codex.wordpress.org/Version_3.7

Go to your own install’s about page - http://example.com/wp-admin/about.php - to see what’s new.

And then make sure you’ve tried…

• flushing any caching plugins you might be running, as well as server and/or browser caches.
• deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by FTP or PhpMyAdmin (read “How to deactivate all plugins when you can’t log in to wp-admin” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
• switching to the Twenty Twelve or Twenty Thirteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via FTP so the only one is twentythirteen. That will force your site to use it.
• manually upgrading. When all else fails, download a fresh copy of the latest.zip file of 3.7 (top right on this page) to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server. Read the Manual Update directions first.

—

CORE CHANGES

What’s new:

• Background Updates:  WordPress now auto-upates minor releases for security fixes. So when 3.7.1 comes out, you will be automatically updated to that provided you meet certain criteria. – If you’re using SVN/GIT/Any-versioning-software or have to enter your FTP credentials to upgrade, the background updates are disabled.

—-

NOT A BUG

I don’t want background updates you suck!

The core team and many others sat and discussed this for a long time. The auto-updates are there to mitigate security issues, and they’re on by default because the people who need them the most are the same people who would be less likely to notice and turn it on. While you may disagree with this rationale, it’s not a bug. It was a conscious decision. Keep in mind, they’re turned off for people who legitimately SHOULD have them off, like folks who have to enter their FTP credentials when installing plugins etc.

If you don’t like it, you can turn them off. Go into `wp-config.php` and put this above the ‘stop editing here’ line:

`define(WP_AUTO_UPDATE_CORE, false);`

Need more? `WP_AUTO_UPDATE_CORE` can be defined instead to allow more fine grained control. Set it to one of these:

• false = no updates
• true = ALL updates
• minor = Minor releases only

Filters exist to allow you to allow specific kinds of updates as well. Return true to allow each of these, false to disallow them:

• `allow_dev_auto_core_updates` – if you’re on a development version, and this filter gets returned a true value, then it will enable dev/beta updates.
• `allow_minor_auto_core_updates` – Allows minor updates (default true)
• `allow_major_auto_core_updates` – Pretty much what it says on the box (default false).

—-

KNOWN ISSUES

—-

REPORTED OOPSIES

Themes

Plugins

I was looking forward to meeting a few more of you in person at WordCamp Europe, however, unfortunately, due to personal circumstances, I will no longer be attending this weekend.

Getting more involved in the WordPress community has been wonderful, and I hope to continue contributing back to the community far beyond this internship. If you are, or if you know of a, woman interested in becoming more involved in open-source communities, please do consider the GNOME Outreach Program for Women: http://gnome.org/opw/. They are now accepting applicants for their next round, starting December 10th. Feel free to contact me if you want any more information on the application process.

Thank you again.

Last week, I submitted my first two patches to core. These were towards the 3.7 effort to add Inline-Docs to all the hooks in core (make.wordpress.org/core/2013/09/05/add-inline-docs-for-hooks/.) Special thanks go to @kpdesign for encouraging and helping me to submit my first patch, and also to @DrewAPicture and @tierra for their help via the #wordpress-sfd IRC channel. Everyone was really quick to offer their time and help, it really made me happy to be a part of the WP community, so thanks everyone.

I’m hoping to submit some more Inline-Doc patches this week, in addition to helping out as much as possible on the forums.

As always, I’ll be about on the forums this week and I am going to try to do some more theme reviews.

I’m currently getting my head around SVN, PHPDoc standards, and the how to’s of submitting patches. I’m hoping to submit my first patch in the next few days for the Inline-Doc effort (http://make.wordpress.org/core/2013/09/05/add-inline-docs-for-hooks/). If anyone’s got any tips or feedback on any (inevitable) mistakes I make with my first patch, they’d be much appreciated.

When @jdembowski gets back from his Griswald European Vacation, I’ll catch him up and hand over.

Handling Commercial Products

The ‘official’ stance is this: It’s best to go to where the theme/plugin is officially supported when trying to get support.

This means, if someone chooses to help you with a CSS question, that’s on them, unless the product is violating the GPL. Then it’s messy and ugly, and we really should not mess with it. But we, as members of the community in general, no matter our role, need to remember not to assume the worst of people, and be helpful, even when saying no.

If you want some boilerplate reply, the .wetry reply on IRC comes up with this:

We try our best to help everyone with any WordPress problem. However, due to the great variety of existing themes and plugins it is nearly impossible to know everything. Your best chance is to contact the developer for support.

IRC ‘Rockstar’ Clarification

There was a little confusion about the IRC Rockstar thing last week, so I wanted to go over it for (hopefully) clarification. The people who were nominated are not automatically becoming OPs on #wordpress. What they are, are identified people who are willing to help keep make/support updated with #wordpress issues and concerns. OPs has been split out to a separate concern cause everyone gets a little twitchy when we talk about giving people that much power. My personal critera would be someone who is active in IRC, but also other WordPress areas (like comes to some of the other meetups, contributes in trac with comments and/or code, etc).

There’s no real limit to the list of rockstars, though

@peterbooker and @fris – If you’re interested in this, the ‘job’ currently comes with author role on this blog, so you can post issues/concerns, and if possible attend our IRC chats. Reply to this post and let me know. A ‘no’ answer is totally okay too!

The tl;dr is this:

Therefore we propose the following:

• Docs and Support remain separate teams each with their own P2 and rep
• we expect that there will be some crossover
• until it becomes impracticable, we’ll keep our chat at the same time, Thursday 16:00 UTC . This will allow any crossover to take place.

I expect there will remain a LOT of crossover.