Talk:Wikimedia Technical Engagement/Team Social Norms

Something I miss in this norms is the "Engage" in "Engage in civil discourse", and "Together" in "We are in this together".

I see a lot of norms dealing with individual behavior, specially acting as free agent. But there's not many that encourage, or convene that we are a team, thus we are not free agents but members of an organization (decentralized or not), so we do not act alone, and each of us acts as representative of the group, prioritizing group level goals and duties over individual ones.

In that similar sense, there's little in the norms that would make me prioritize collaborating with others over working alone, as long as I share any learnings (that could be considered done by working in public).

As a data point, there's only one mention of collaboration, and it's as part of "collaboration rather than competition", that could easily be interpreted to not prioritize working with others as long as you are not competing.

I think we should discuss and agree if we should work as a team or as free agents (in the spirit of https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/define-team/, workgroup vs team), and reflect that clearly in the norms.

Once we know how we organize and communicate between ourselves we can start organizing our systems and processes to match (https://en.wikipedia.org/wiki/Conway%27s_law), trying to maintain a system that does not match the way we organize ourselves only brings friction.

David, I would support the idea that we are a team by the google definition linked. That said, given our broad responsibility set at times (and the intention that these are shared across the department), the "working group" moniker definitely could apply at times. Can you offer an edit or specific prose on what you'd like to see in this space? Would it be an axiom to commit to not siloing knowledge? Something else? It would be helpful for me if you could propose a norm (or edit one) and include a "This can look like" example to go with it.

Some principles/ideas that would point to the direction of "team" as shared in the rework page:

• Nothing is someone else's problem (your problems are someone else's too): Demonstrate care for your teammate's struggles, offer help whenever you can, if something is broken, even outside your comfort zone, fix it. When building something, make sure you share more than enough information for anyone else in the team to jump in and collaborate with them. We collectively share the responsibility of all our services.
• Disagree and commit: When discussing any subject, we offer our personal opinions and points of view, when the subject is decided, we commit to follow the outcome, even if we disagreed with it during the discussion.
• Better together than solo: When starting a project, make sure to plan to include more people as soon as possible, prefer doing things collaborating with others in a slower pace than doing things by yourself faster.
• Shared better than public, public better than private: Whenever possible, actively share your knowledge and situation with others, fallback to just making it public for others to find, and try keep at a minimum private information and communications.

Some practices could look like:

• At least two people per service: each service that the team provides should have at least two people with enough knowledge to keep it evolving. **This does not mean that everyone knows everything**, it does mean that you should not know only one thing.
• Periodical, rotating knowledge sharing sessions, howtos, demos, ... so we have an idea of how things work, what's there and what's not, so we can share insights, learn, discuss.
• Standardize service documentation (similar to the team API effort), alerts, design docs, ... so it's easy for anyone to find the docs on any other supported service (and thus, jump in, help, fix broken things).
• Standardize practices, so it's easier to start working on any other project without having to adapt to all the different processes.
• Shared oncall + alerts + runbooks (as opposed to split oncall, personalized notifications, docs in places that are not common/hard to find)

Some behaviors could look like:

• I start every morning reviewing patches from any project, by anyone.
• I'm creating a new project, and I use the team agreed practices, even though I prefer formatting my code with tool Y.
• I make sure that the team has more than one way to know what I'm currently working on, and actively share that information.
• There's an alert that I don't recognize, and it has no runbook, I jump in to investigate and will write the runbook myself with whatever I find out.
• I seem to be the only one working on this area, let's share that in the next team meeting and find someone else to work with.
• Someone shared that they are working on something by themselves and want someone to jump in, I'll give a hand, as somebody else is helping me now with this other project.
• Feature A on project X is blocking my project, I'll jump in and help delivering it instead of just waiting and expecting others to do it for me.

That should not look like:

• I have to learn everything about everything: you only have to learn as much as you can, but you have for certain have to share that knowledge with someone (might be more than one person for different parts of that knowledge)
• I have to fix all alerts all by myself all the time: you are not alone, and there's a scheduled rotating time to focus on alerts, you will have to focus on it but it's not all of the time, and it's not by yourself.
• I can complain on anything: feedback is always welcome, but constructive feedback is way better, and continuous non-selective involvement is the best way (see the backseat driving rule).
• I should not do anything by myself: there's still times where there will we constrains that will force us to do solo work, that's ok, it should be an exception, and should be remediated as soon as possible.

This was way longer than what I had in mind xd, these are suggestions, not as one block, but each individually.

Make me a bit sad that none of the above made it to the team social norms.

It is alluded to, a bit, with the quote opening the wiki page. Though these values should be reframed away from what we are, and to what we want to be. Open source communities often produce great things. Unfortunately they are often centers of toxic behavior. We are a product of the larger open source world, we cannot escape that, and thus don't really live up to our social norms. Rather we aspire to. I think by making clear that this is what we want to be, rather than what we are, it provides two views that are different from what we have today. One it encourages everyone reading to think about what they do that could be done closer to what we want, rather than "These are our norms. I'm part of the group, therefore I'm what's written here." being the thought, it shifts to "None of us really do this, we come from communities that don't do this, but we can. What do you not do on this list?" Which ties into the second part, the other change is that by stating that we are not this, but want to be it, when we mess up, which we all do, it makes both apology and reflection much easier. The psychology shifts from "Oh! I broke the rules! That everyone else is following! I'm terrible, and not part of the group." Encouraging one to hide what was done, or try to reframe themselves in a positive light, rather than simply think about it. When we start from "None of us are this, but we all want to be." It's a lot easier to step back and actually look at whatever happened, and to try to learn something from it, and apologize for it. One is no longer made the black sheep that didn't follow the rules, rather everyone is the black sheep from the beginning. No one is left feeling separated, and improvement is the norm.

+1 to that, I really like the foundation wide one "we strive for excellence", because of that exact aspirational aspect of it

(that one was me, forgot to log in xd)

The lead of the page I hope conveys some of the historic intent:

Our team social norms help aim to guide our behavior in the workplace and improve our collective civility. These norms are unique to the Technical Engagement team, but should be seen as extensions of other WMF and community initiatives such as the Code of Conduct, the Friendly Space Policy, and the Technology deparment’s Communication Guidelines.

This is not a how-to guide on embodying the idea of a perfect teammate, we all have different backgrounds or stories that might not follow these norms, but we can get there together. There are too many intangibles not included for these guidelines to be the ending to any discussion, but these are specific touchstones that can make up the beginning of one. Humility, generosity, kindness, respect, and integrity are all implicit within the norms.

Having explicit norms help us to increase our awareness that these practices are important and require attention and intention from each of us. It’s also important to hold ourselves accountable and assume both individual and team-level responsibility, let's try and make our when workplace a safe environment for everyone.

I believe that these "rules" are what we hope to do, but it is almost certain that we will occasionally not live up to our own hopes or the hopes of others. "Do Forgive!" applies to ourselves as well as others. We try, we miss, we learn, we grow, we try again.

And I now see that is fresh prose, so thank you to those who added it. I think it matches the spirit of my historic understanding of these norms.

The new verbiage does add a lot to the end of this topic. Though why don't we change the title from "Team Social Norms" to "Team Social Aims" Norms implies a degree of adherence that I do not believe we have, nor should we attempt to enforce or create. I suspect such an attempt is more likely to create rather than diminish adversity.

For me personally, w:Social norm is an actual thing, and what we were attempting to describe. "Social Aims" seems mostly to be an essay by Ralph Waldo Emerson. I cannot speak to the current team management practices of the Technical Engagement sub-teams, but when I was the manager these were very much enforced norms in that we actively talked about them and applied them in our day to day work.

I would agree that for me social norms are an actual thing. And that we don't follow what we prescribe. By claiming a list of social norms, there is an enforcement mechanism of ostracization at play. This is not constructive to getting a community to be more collaborative. As described in the opening message of the topic, enforcement mechanisms cause people to hide things, withdraw, or use some interpenetration of the norms to re-enforce a behavior, usually bad, that they do not feel like changing.

I attempted to capture what was being discussed in this thread in an edit to the opening paragraph. Please feel free to keep editing or discuss if I've not covered everything. One remaining item that I believe is mentioned here, but I'm not sure is addressed is around enforcement or accountability. In the spirit of what I think has been discussed here, I would want to make sure the prose relates that it's about helping each other be better people, and not about punishing those who make a mistake. I think the other policies across the movement, including those linked, better address issues should someone's persistent behavior rise to an unacceptable level.

I made an edit to remove specific timing for when to revisit these norms. I do think this page will continue to be a part of onboarding and thus will be reviewed accordingly. The statement to "Provide respectful and meaningful feedback to the norms and propose changes if we deem necessary." seems sufficient without more detail. Anyone should be able to propose and discuss these norms as needed. Thoughts / Edits / Reverts welcome!

Other things you'd like to discuss or comment about the Team Social Norms page.

We were talking about the "no subtle -isms" item, and Bryan had a good explanation that included some comments about the distinction between how a word/phrase was intended, vs how it was received, and trying to be mindful of the latter.

I think it would be really useful to add that abstract explanation into this page. I don't recall the specific phrasing that was used, and don't want to get into specific examples, so I'm hoping Bryan or someone can help.

It could potentially also/alternatively be mentioned within any of the "Do apologize" or "Do forgive" or "Do reflect" items.

Part of it is "know your audience" (e.g. not making 'mature' jokes around people unless you know them really well). But that's not possible in an public/broadcast settings, where the potential audience is the whole world!

One way that I'm thinking about this, is trying to be aware of the complexity of words with different nuanced meanings in different contexts. I.e. Many words can be understood in different ways, and that if you're talking to someone outside of your closest peer group it's good to remember to try to be aware of the possible misinterpretations.

I dislike the line about "No well-actually's". To understand what that really means, you have to know about a particular internet meme, which is a narrow audience. Would you consider changing it to something that translates across languages and cultures, such as "No pointless pedantry"?

I don't know that meme and still liked that line. I've found myself a few times starting sentences like that without bad intentions but see how it's unhelpful. So I wonder which 'real understanding' I might be missing and if it's crucial. :)

I only know it's a meme because I asked a famous web search engine about it. My first thought was that they didn't want people to say things like, "Well, actually, now that I've thought about it longer, I think you're right".

I also don't consider it to be (meant as) a meme. It works for me FWIW, from my humble POV of a non native speaker. :)

These norms originally created by and for the Wikimedia Cloud Services team have been officially adopted by the Developer Advocacy team. As a result I have moved the content page up to the shared parent Wikimedia Technical Engagement team.

I also <3 how you integrated CoC into this.