# What three WordPress.org courses taught me about working with people > Three Learn.WordPress.org courses on decision-making, writing, and conflict resolution. Most of the guidance applies to any collaborative work, not only WordPress. Published: 2026-04-22T10:00:00.000Z Author: Shameem Reza Category: Notes Canonical: https://shameemreza.com/three-wordpress-org-courses-that-go-beyond-wordpress/ --- I didn't know these courses existed until I started onboarding with the WordPress Plugin Review Team as a volunteer contributor. The onboarding process pointed me to [Learn.WordPress.org](https://learn.wordpress.org/), and I found three short courses that weren't really about WordPress at all. The three were: - How decisions are made in the WordPress project. - Writing in the WordPress voice. - Basic principles of conflict resolution. > TLDR > > While onboarding with the WordPress Plugin Review Team, I went through three Learn.WordPress.org courses on decision-making, writing, and conflict resolution. I'm a Happiness Engineer at [Automattic](https://automattic.com/) and ran into the same principles during my onboarding there years ago, so most of the content wasn't new. But the courses are free, short, and written clearly, and the guidance applies to almost any collaborative work. Treat this as both a review and the parts I'd personally hold onto as a career guide. I've been a Happiness Engineer at Automattic for a few years now, and a lot of these same principles came up during my Automattic onboarding too. The way Automattic operates maps closely to how the broader WordPress project works, so almost none of it was new to me. But seeing it all written down in a structured, documented course did two things. It refreshed what I already knew, and it made me want to share the parts that feel less like WordPress-specific guidance and more like career advice anyone could use. If you're thinking about contributing to WordPress, these courses are a great place to start. If you're not a contributor at all, the principles still apply to almost any collaborative work. What follows is a mix of what's in the courses and what I'd hold onto from them. ## How decisions get made in the WordPress project The first course is titled [How decisions are made in the WordPress project](https://learn.wordpress.org/course/how-decisions-are-made-in-the-wordpress-project/), and it opens with a reality check I wish more teams heard early. Open, collaborative environments can fool you into thinking every decision needs full consensus. It doesn't. Consensus is a goal when everyone shares the same resources, information, and values. In a large project, some decisions still have to be made even when the majority won't love them, because of legal or logistical factors, or just time. That framing alone is worth holding onto outside WordPress. Most collaborative teams I've seen don't fail from too much disagreement. They fail from pretending consensus exists when it doesn't. The course then gets specific about where decisions actually happen: team blogs, project-wide blogs, and dedicated bug trackers like Trac or GitHub. If you want to participate in decisions, that's where you show up. Discussions might start at an in-person event like a WordCamp or Contributor Day, but they have to be documented asynchronously. Otherwise half the project is excluded by default. The part I found most practically useful is the step before a discussion ever becomes a post. You start in your team's Slack chat. You clarify the problem before anyone proposes solutions. Four questions to work through first: What problem are you actually trying to fix? Does solving it fit the team's current goals? How many people does it affect? And will solving it make contribution harder for anyone? That last question is the easiest one to skip when you're excited about a solution. The course making it explicit is worth something. Once the problem is clear, the course recommends light research before writing anything public. Search the team blog for past discussions. Check the handbook. Reach out to former team leads for context you might be missing. Review older chat archives when in doubt. The point is to avoid re-opening something that was already resolved, or proposing something that was tried and didn't work. This maps directly to how good professional communication works anywhere. Rushing to solutions before the problem is understood is one of the most common ways a project stalls, or a team quietly loses trust in each other. ## How to run a discussion that invites real participation Once you've identified a real problem worth solving, the course walks through what a good discussion post looks like. A good post has four things. A summary of the conversation so far, with background and the pros and cons gathered from research. A clear ask for specific feedback. A timeline for when the discussion closes. And a note about who was consulted while writing it. One extra nice-to-have: calling out any solutions that are currently impossible, so the thread doesn't waste time on them. A separation the course makes carefully: closing a discussion is not the same as making the decision. You can stop taking new input on a certain date without that being the day a choice gets made. That small distinction prevents a lot of confusion. What I'd hold onto most: if a discussion thread runs very long and you're worried the conclusion will get buried, publish a new post with just the outcome and link back to the thread. Don't let an important decision disappear into a 200-comment pile. The course also names the three possible outcomes of a discussion up front. Sometimes there's a clear preference and you can move on. Sometimes there isn't, and the team runs a policy or process experiment, usually six months to two years, with an upfront success metric and a public data plan. Sometimes the decision needs approval from project leadership before it can move. Naming those three outcomes before people weigh in saves a surprising amount of drift, and it's a reusable pattern outside WordPress too. If you're leading a discussion at work, tell people what a good outcome looks like before they comment. One small detail I genuinely like: if a change you ship turns out to be wrong, revert it if you can, then go to the other team to discuss what didn't work and how to make it work better. A single line in the course, but it captures a whole approach to collaboration. Being wrong is fine. Handling being wrong is where teams actually get tested. ## Writing clearly for a global audience The second course is [Writing in the WordPress voice](https://learn.wordpress.org/course/writing-in-the-wordpress-voice/), and it opens with a line I'd give to anyone who writes at work. All written communication should be clear and friendly, with a tone that's on the positive side of neutral. "On the positive side of neutral" is a better writing target than most company style guides I've seen. It doesn't demand enthusiasm. It doesn't let you be flat or dismissive either. It's a calibrated middle that works across cultures and moods. The four characteristics of the WordPress voice come from that starting point. Friendly. Clear. Inclusive. Casual while still being respectful. Short sentences. Plain words over technical ones. Contractions are fine. Humor is used sparingly. The reason humor gets an explicit warning is worth sitting with. When you write for a global community, you're writing for people across cultures, time zones, and levels of English fluency. Sarcasm doesn't survive translation. In-jokes exclude people. Stereotypes, even gentle ones, signal that not everyone is welcome. The course also points out something most company style guides miss: be careful when you address groups. "Guys" is singled out as a word to avoid when you're writing for everyone. The best practical advice in this course is the handful of global collaboration specifics: - Avoid acronyms, or explain them the first time you use one. - If you must use "we", be clear about who "we" refers to. - Ask for feedback in numbered questions so people can answer one at a time. - Link to prior Slack discussions and summarize them, because jumping between platforms mid-read breaks focus. And the part that pairs best with the decision-making course: embrace criticism. Thank critics as warmly as supporters. Approach negative reactions with curiosity, not defensiveness. Critical feedback is often more useful than positive feedback, and inviting it can lower the temperature of an unhappy contributor faster than any soothing language. None of this is a WordPress thing. It's how any written communication should work when your audience is wider than the room you're in. ## Handling conflict without making it worse The third course is [Basic principles of conflict resolution](https://learn.wordpress.org/course/basic-principles-of-conflict-resolution/). The line from it I keep coming back to is this one: > Bug-hunting and criticism are always project-labeled, not person-labeled. That one sentence would defuse a lot of the arguments I've seen inside software teams. When someone points at a problem in a project, they're talking about the project, not you. Holding that frame isn't easy, but it's teachable, and it's the difference between a defensive reply and a productive one. The general process for responding to a conflict is simple on paper, harder in practice. Confirm whether anyone is physically at risk. Reach out to everyone involved and explain why you're contacting them. Identify the goal: if it's harassment or a code of conduct issue, it goes to the WordPress Incident Report team. If it's a personal dispute, mediation is usually the goal. Gather information from each person separately. Summarize the facts in a document everyone can review. Follow up before bringing people back together. The separate conversations step is the one most people skip. Gathering information from everyone at once sounds efficient, but it usually means the loudest voice shapes everyone else's account. Separate conversations give each person space to say what actually happened without social pressure. Two more things from this course that I'd hand to anyone managing people. Being prompt matters. Ignoring a complaint doesn't resolve it. It signals to the person who raised it that the community isn't safe, and it makes the next person with a concern less likely to say anything at all. The course is explicit: if you're not sure how to handle something, ask a trusted contributor for help, but respect everyone's privacy. Ask open-ended questions. Avoid forming an opinion too early. Overly specific questions can accidentally hide important parts of what actually happened. For code of conduct violations, the recommended approach is "calling in" rather than "calling out". Don't shame publicly. Address the behavior directly, calmly, and without an audience where possible. The course offers a three-part method that covers most situations: > When you [take this action], it makes [the project feel unwelcoming by XYZ]. Next time, please do this instead. Lighter variations for smaller moments: - A reminder: "This is a family-friendly event. We don't do that here". - A plain statement: "Remarks like that are against our code of conduct". After the conversation, follow up privately. Loop in the other organizers. Don't let it end with a single confrontation and no follow-through. One thing this course gets right that most workplace training doesn't: it acknowledges that async, global conflicts are harder than in-person ones. Video humanizes a conversation and clears up misunderstanding, but timezones, accessibility, and language proficiency can make video worse than text. There's no universal answer. Meet people where they can actually communicate, and if you do run a sensitive video call, take notes and send a written recap afterward so everyone confirms the same understanding. That one habit has saved me more times than I can count. ## Why this matters beyond WordPress The thing that struck me going through all three courses is how little of this is actually WordPress-specific. Clarifying the problem before jumping to solutions. Naming the possible outcomes of a discussion before asking for input. Writing on the positive side of neutral. Treating criticism as project-labeled, not person-labeled. Gathering information separately before drawing conclusions. Addressing bad behavior directly and privately instead of publicly. Taking notes on sensitive conversations so everyone confirms the same understanding. These are the skills that make you better at almost any collaborative work, whether you're contributing to open source, running a team, writing a support reply to a frustrated customer, or mediating two colleagues who aren't speaking. The WordPress project has documented them carefully because it has to. A volunteer community of thousands of contributors across hundreds of countries can't rely on everyone absorbing the culture by proximity. The principles have to be written down, taught, and repeated. That's what makes these courses worth reading even if you never submit a plugin or write a line for a Make blog. Someone took the time to articulate things that most workplaces leave implicit. And because the courses are free, short, and reasonable to finish in an afternoon, the barrier to starting is close to zero. If you're early in your career, or a few years in and looking for a concrete way to get better at working with people across organizations, time zones, and disagreements, I'd start here. It's the kind of guidance I'd hand to someone stepping into their first job with teammates on the other side of the world. The three courses are all under the WordPress contributor track on [Learn.WordPress.org](https://learn.wordpress.org/): - [How decisions are made in the WordPress project](https://learn.wordpress.org/course/how-decisions-are-made-in-the-wordpress-project/). - [Writing in the WordPress voice](https://learn.wordpress.org/course/writing-in-the-wordpress-voice/). - [Basic principles of conflict resolution](https://learn.wordpress.org/course/basic-principles-of-conflict-resolution/).