Understanding contributor leadership roles in the WordPress open source project

Across the WordPress ecosystem, contributors can take on various leadership roles, such as release leads or lead organizers for Flagship WordCamps. However, it is not well understood how individuals are selected. This discuss will help build stronger undrestanding of how various leadership roles are created and individuals selected, with a focus on how to better share that information.

Facilitator: Aaron Campbell (@aaroncampbell)
Notetaker 1: Emma Sophie Young (@emmaht)
Notetaker 2: Bigul Malayi (@mbigul)

TLDR: We need more documentation

Raw Notes:

LIST OF GOAL EXPRESSED FOR THE DAY (open floor):

  • How are CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers for core projects chosen?
  • Confirmation of how committers from the core team are identified and how they are added to or removed from that role. Also include:
  • How they get into those positions
  • Core releases and roles (historically) how they can shadow to be active in the future ones
  • Get answers about how they are nominated in the future
  • How team reps are chosen
  • How other teams chose team reps, and team leads
  • Get as much information – to take it back to teach students (mentoring high school and college) – make a curriculum around WordPress and opportunities
  • Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. responsibilities – a lot of team reps go more into a team lead role, rather than driving what the team is doing, project managing the team
  • Should there be an additional team role – other than the team rep role (applied to all teams)
  • In a lead role – the person wasn’t aligned or didn’t have the correct expectations of what their role intended
  • What are the objectives of each role
  • Locale meet-up organizer – would like to talk about this in a more traditional sense
  • In addition to getting people to stick around and contribute
  • Figure out how to find out if someone is “worthy”
  • How to trust and give access – gut vs science

CORE COMMITTERS ROLE (and what that means)
Commit many years ago: the way it decided at the moment:

  • Committers slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel
  • Committers use that to discuss the act of committing
  • If someone is asking how to do this using ___ (tool)
  • Contributors are proposed to commit
  • Decided by Matt – he has the final say on who gets to commit to core
  • It is a leadership role at the moment
  • Back when the only way to contribute was to code – it was a natural way to become a “lead”. But now it’s different, and there are more ways to contribute.

The committers need to make the decision if it’s something that is ready to go to core. They are happy with the code, and then it goes into wordpress core.

  • When you commit the code – you take responsibility for it
  • Review other’s code, not just use your own; whatever you sign off, you take responsibility for it. So, if there is a problem, you need to help fix it.
  • In terms of the process – it used to be more in the background, but now it’s more transparent. The existing committers see a committer doing good work, they will propose this person, and then Matt decides (there is influence from other committers)

Is there diversity in how the next leaders are being chosen? Because the current leaders are the ones that are choosing the next leaders – is this a problem?

  • There is no rule that a non-committer can not suggest someone. But it’s just not really happening. It would be interesting to see what it would look like, or how it would go.

In order to be nominated – you need to prove yourself – this can take a lot of time, effort, ability to collaborate, etc. So, there is almost a natural selection for this.

  • The time aspects
  • Seems like the majority of committers are sponsored
  • It can be hard to have the time
  • You don’t get commit because you are sponsored, but you have more time to spend on commit (because you are sponsored – having more time each week)
  • Example: Non-committers were nominated by someone else

A gateway can be a co-lead or specific part of a release (almost like a first step) – people can prove themselves during these stressful weeks and hopefully get a nomination from that.

About the Handbook page – that lists who all of the core commits are. It lacks insights on the role of lead developers vs core commiters and what they are tasked to do.

  • Historically, they are “decision-makers,” a true DRIDRI Directly Responsible Individual - the people who are taking ownership or responsibility for a particular project or feature.
  • A DRI is not necessarily the POWER to do something but has the correct context
  • Do you have that “big picture”?
  • Do you have the trust of the community, not because you have all the things but because they know that you can not know all of the things, but that they trust that you will be honest and say, I don’t know, but I will find the answer for you

A lead – needs to handle feedback well (receive the feedback, commit to disagreeing, and move forward)

  • TLDR: We have context, trust, and authority
  • ^^ this was when there was a release leadRelease Lead The community member ultimately responsible for the Release., and now there are teams
  • We have built other parts of the project up and organized a better – this role could have easily been phased out
  • Lead – was like “water” across projects. – however, the nature of it has changed.
  • The lead role has become irrelevant these days – others may feel a vacuum, and people do not feel like they are
  • If it is a relic, it should know how decision were made, and how it happens within the project, can be helpful, so we are aware of everyone is working and what they need. Not all power to one person, have help

Team reps discussion – team rep role – to facilitate roles – is that really what they do?

  • Idea of what team leads can do?
  • Do not mix up the team
  • A revision on leads
  • Re-grouping of what we NEED
  • The talk of non-code leadership looks like

Team rep vs team lead

  • Someone who is responsible and accountable for the work being done
  • They don’t need to do it (delegate)
  • But they are accountable able (thus responsible)

HOW OTHER TEAMS CHOOSE REPS
Community Team

  • We look at the contribution, consistency, frequency, and how long they have been there, and then we open up nominations.
  • A person needs to be qualified to nominate another person
  • When a new contributor joins the team – where do they fall on the ladder
  • How long will it take to climb the ladder or level up
  • I want to be pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party team rep (ex) 0 what do I need to do to do that
  • Showing people the path on how to start is very important
  • In the past – we dont say we expected you to only do this with this type of code – it’s more self-directed rather than a predefined path
  • Didn’t want to constrain people

REP VS LEAD
Rep for Make teams

  • Leading as well
  • Facilitating
  • Guiding, rather than making decisions
  • Leads for WordPress releases
  • Responsible for making decisions

Polyglots TeamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/.

  • Nominations in the past – 1 time year there is a reminder to nominate
  • Put up a post with a poll (2 or 3 at a time)

Team rep vs team lead – historically – we had 7 team reps who were mentors (which is like a lead/leadership role)

They were conflated – there was an opportunity to get more people in (in the broader leadership role) and get a fresh set of eyes

There is no documentation on how to become a lead or leadership role and what value it can bring – bring clarity – bring in new people

It’s hard to help if you don’t know how to help or where you can

QUESTION: community and major events – how are organizers chosen are there any gaps there?


HOW ARE LEADERSHIP TEAMS CHOSEN FOR FLAGSHIP – WC TYPE ROLES

WCUS – Angela is head of local events – works with it now on who will work on it next year. Then they will help talk to and build the team

  • There is not an open call for leads
  • We attempted to hand pick who showed the varied abilities that we needed
  • It worked pretty good – there were struggles
  • It was hard to be open – making sure you are really covering all the necessary things that you need – and that the people really understand what they are getting into.

The general path:

  • People volunteer
  • Part of organizing team through the open call
  • Then what they see they are in to – move into leadership in the future release
  • Volunteer – organizer – lead organizer (anglea is the one to work with the person to pick the first and build from here)

LOCALE SITES – Another leadership
The first step – was translating WP into another language (German) – ex – there was a merge for core to translation – there was a lot of responsibilities but not guide or rule book, so she had to chat back and forth how to do this. Now how things have evolved over the last decade. DO we have a process on how to do this for locale sites – if you have access or get it, you are almost in a leadership role, how do we deal with that, since you are basically in a leadership role.

In Spain – its been the same locale managers since the beginner (15 years maybe idk). Maybe they think that they control the local community.

  • They have the sense that they have the power inside the locale site.
  • There is a lack of meetings and a lack of talking inside the locale community
  • Example: recently, they tagged someone said they were tagged out of a project, without telling the person. They took away access because they weren’t awre that someone was working on something.
  • We need to work on this on different levels.
  • We have a lot of things in movement.

For The team reps – the last definition is from 2012 – but there were only like 8 teams back then, and now we have 22, so we need to re-design because the commnuity has grown a lot, and the way it works now is not the same way that it worked 10-12 years ago.

  • We need to re-think how we want to – before it gets worse in the future because it will get worse

HOW DO WE ATTRACT THE NEXT GENERATIONS

  • Handing out knowledge, when someone is stepping down from a leadership role

how to transfer knowledge, what are the responsibilities, and what they need to do (core is documented well) other teams don’t have offboarding from a project or a team. We need to implement a blueprint or skeleton form teach team on how to handle this as well.

  • There are a lot of long term contributors, some day we wont be contributing (or leave the project for whatever reason) – so in order to let new contributors grow, but also get new generations into the project. There should be a wp project that the younger generations are engaged and wnat to contribute.
  • Gen Z are not interested in open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. or WP. How do we approach this generation’s shift into projects, leadership, representation roles, etc.
  • How do we get them involved (already been talked about in other sessions)
  • Related parts – even if they are here – how do we make sure that we are passing the information from one person to the next. And that these insights don’t just age our of our projects and aren’t lost.

Core committers have mentors and that person guides you through the process – it can be overwhelming.

  • Mentorship is good for onboarding
  • There is another part to that
  • They dont leave by surprise but they are working their way out
  • How do we retain all the important stuff or as much as possible

You can pass down some knowledge – but what gets done depends on the people involved – so there should be an understanding that if you hand off the reigns to someone else, you need to be ok that they might take it in another direction.

  • Portland example: meet ups – were some combination of passion and business to run the meet up – this was the energy that drove it forwards, then foundation come forward and was like here are the rules you need to follow – and a leader stepped down because they took the fun out of it
  • The outcome is from the energy of people involved

What is the stance on the wordpress foundation

  • there are other projects (local teams) is responsibility on locale teams or are the guidelines on how the locale teams SHOULD run themselves – not sure if there is documentation on all of the process ( historically there has been less documentation then there is today) – in the past there wasnt as much need as there is today – there were less people and everyone just knew all of the information that they need. Documentation is WAY more essential.

Knowledge transfer and documentation

  • We should be documenting – in the same spirit of open – sources the ethos
  • It should not be “im just talking to you”
  • If im saying it, i should be able to write it down
  • If someone wants to fork this projects – they should have all of the knowledge
  • As we build these structures – we are adding more speedbumps
  • How do we keep up with the quality and balance it?

QUESTION: When we talk about leadership roles and titles – who are you thinking about that for? Is the leadership who is the motivation for? Is this yearning for leadership roles and tiles about retention, and attraction? Personal satisfaction – knowing who to talk to.. Each requires something slightly different. This is important to think about when we looking for what to come out of this.

QUESTION: do you think of titles as trailing or leading? Do you think of a title as something that comes when you are already doing a job? Or something that you want to achieve? For yourself?

Passing leadership knowledge to the next person

  • Practice makes person
  • So we should do it more regularly
  • Not waiting until someone is dying off (bad example)
  • Every 1, 2, 5, 10, whatever years, where they hand off the information to the next generation
  • Capping somehow you can be a lead – might one way we can do that
  • LOCAL – this might not be ^^ a good way – tis is run from passion – but project wise

DRIsDRI Directly Responsible Individual - the people who are taking ownership or responsibility for a particular project or feature.:

  • This is a form of communication.
  • You step up into something, you dont really lead it.
  • Its times into the energy of things. If you want to do something in the project, then you become the DRI. BUT you actual work, depends on your energy and your motivation – depends on you.
  • As DRI you need to make a plan for it. No one will nominate you but you. You look at leaders, they have the energy and the passion.
  • Onboarding – we have a proper offboarding process – if you are a supporter and you dont want do it anymore. They remove accesses – etc

LOCAL teams are meant to be a translation of the main site, it should just be a translation – shouldn’t be an open leadership (basically). It should be managed by polyglots team.

LOCALE MEET-UPS – this is the leadership, organizer role, that is held by WP central, core organizers (wp central steps in looks for replacement) – look for new people to take over the new meet ups.

  • Who is running the newsletter? On the local blog bc its not translation – like the locale make blog – put it into the handbook – since its not a translation – it should be responsibility for the locale test teams.
  • Someone who has a leadership role, they should share their knowledge (give access, appoint people etc)
  • The locale manager, should be the highest role for the locale community. But there is a separate side – there needs to be a POC – guide – content generation, locale handbooks, and rulebook for locale communities because its not very clear for each commmnuity.

UNOFFICIAL LEADERSHIP ROLES

  • How to wind down a project – there are no guidelines, no documentation
  • What should outreach look like, unofficial cross team, idk if they are leadership roles – but it feels like it. And the pros and cons
  • There are a number of people who do just take on a role, and someone starts to make decision, without a “role”, there is a point where you step over a line, and you haven’t be given a “role” – there is a bit of risk in assuming a role (people feeling the vacuum)
  • Keep in mind that we started in a locale community (at least a good amount of us started) – meet up, locale word count, you learn themes, etc.

you know there is global team vs local team.

  • We need to think in the locale community – are not only the translation of the wp site – at least right now – need to push a lot of information in other languages outside of english.
  • People want to contirnbute in code but they need help and mentor – but we need to start thinking how the english part, because right now the community is getting old, and we need to go fishing for new people in locale communities,.

ROUND UP

  • We will continue to talk about this in our teams
  • We are making progress – there are struggles and issues in each project
  • Working through it together and going back to our teams and pushing to improve, formalize, and come up with a process for these things anywhere that we see these gaps.

Things to think about moving forward:

  • Is there diversity in how the next leaders are being chosen? Because the current leaders are the ones that are choosing the next leaders – is this a problem?
  • Team rep vs Team lead role. Clear guidelines to what they do and don’t do, who is responsible and accountable for what work?
  • For community and major events – How are organizers chosen are there any gaps there?
  • For locale sites: Do we have a process to evolve the leaders in each locale? or are they the same for the past 15 years? We need to re-think how we want to change it before it gets worse in the future.
  • How to hand over knowledge and transfer knowledge when someone is stepping down. We don’t have an offboarding system.
  • Gen Z are not interested in open source or WP. How do we approach this generation’s shift into projects, leadership, representation roles, etc.
  • How do we attract the next generations into the WP project?
  • What is the stance on the WP foundation? with the local teams? what are their responsibilities? are there guidelines on how the local teams should run themselves? – Is there documentation on all the processes? (also for local handbooks or rulebooks)
  • We need documentation on how to wind down from a project.
  • How can we document knowledge transfer
  • When we talk about leadership roles and titles – who are you thinking about that for? Is the leadership who is the motivation for? Is this yearning for leadership roles and tiles about retention, and attraction? Personal satisfaction – knowing who to talk to.. Each requires something slightly different. This is important to think about when we looking for what to come out of this.
  • Do you think of titles as trailing or leading? Do you think of a title as something that comes when you are already doing a job? Or something that you want to achieve? For yourself?
  • For locale meet-ups – who is running the newsletter?

Part I & II: Communicating…

Part I & II: Communicating on Make Team Blogs: discussions, proposals, announcements

From the session page:

The WordPress community communicates primarily across SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and Make Team blogs, commonly referred to as “P2s”. Make Team blogs in particular see an assortment of updates, discussions, proposals, and announcements. How do these come to be, and how can people provide feedback? How is the feedback considered when decisions are made? This discussion will focus on best practices around conversations on Make Team blogs.

Facilitator: @helen
Notetaker 1: @emmaht
Notetaker 2: @harmonyromo

Discussion Objectives

Discuss the current processes within the Make Team Blogs, what can be improved, how can the community be sure to reach a wider audience before making decisions.

Raw Notes

Best Practices on Make Team Blogs (P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/.) Part I

Current Pain Points:

  • Why do the Make Blog comments not use the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor (Answer: eventually it will happen – but if there are any questions, feel free to drop in any Slack channels to ask)
  • Raise awareness for blindspots that (newer) contributors have
  • Proposals – There isn’t a defined process in place. Often, the way a proposal is presented makes it seem like it’s in motion.
  • There is no discussion about the process to get to the proposal, no step-by-step path, and there is an implied authority when posts make it to the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. P2.
  • The feel is that with a posted proposal, there is an implied absolute direction that a project is taking.
  • Some improvements are needed to be more considerate of other teams. Community members should have the mindset to consider what team should be included in certain decisions and proposals
  • New contributors don’t know about the existence of the team blogs.
  • There is a feeling that you must be proficient in English to partake in discussions. Possible solution: A translation button would be helpful so others can get involved
  • Slack is harder to follow (since information is always flowing and things are always updated), rather than project-based or githubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues
  • If you’re only contributing a few times during the week in small increments, it’s hard to find how discussions across Slack, GitHub, and Make connect to see the full picture. No one is really keeping an eye on things as a whole.
  • (Newer team reps) – when to keep the conversation going vs when to post on the blog. Do I link to the slack? Do I link to the github?
  • Lack of guidelines or general practices
  • Lack of visibility and ability to chime in on what other teams are doing.
  • Cross team decisions – project wide governance.
  • Proposals go up at varying times, no order, and ask for feedback for proposals, but the timeline for said feedback varies (no standardization) In comments, don’t have a standard way of moving forward, just simply look for criticisms.
  • When writing proposals (feature →) to pin the top comment (sometimes used and sometimes not used) – you can pin the comment that says “here is the decision that was made”
  • Ensuring that we are allocating the proper amount of time to comment – especially for the people who are not consistently contributing / more part time
  • Are there standards for who can write comments & how do other open-source projects manage this ?
  • RSS updates page (not linked anywhere) – any github repo that is not attached to any team – RSS are not being reported to any team right now
  • Who is our audience – what belongs on /updates (make/latest this will get you RSS updates) and make/projects
  • Who gets access, how do we ensure that people get access? And do we ensure that this happens?
  • Dealing with a working group vs a team, need an interim website to run surveys, (no make/blog yet), need survey tools to help with decision making. It’s a shame when decisions are made simply on Slack, versus seeking a wider perspective on make.
  • There need to be example templates for how to write meeting notes, proposals, etc. The Sustainability team is looking for these tools. Great to have some sort of skeleton of how to run things- centralized tools. No other place for working groups to post thoughts save for the /projects blog, so it’s hard for people to find.
  • Starting to contribute is soooo confusing – who is on it, who has access, still confused, people tell everyone different things.
  • Feedback is given – but there is no action taken afterwards, or so it seems. This can make the community feel disempowered – “why bother to comment, no one listens” while another team is saying the opposite – we need feedback, AND once there is feedback, it needs to be synthesized in a comment on the proposal post with notes on actions taken.
  • Fundamentally dysfunctional – there are secret meetings -instead of asynchronous meetings

IDEA:Design focus pages: A recap overview focus page could be a good path forward for sharing the full picture of what a team is doing (GitHub links, Posts, Slack discussions)

Good Experiences / Positives Experiences

  • Communication in WP involves having a history of discussions. The Make Team Blogs offer access to discussions from 7 years ago, and allow one to see the issues then; use this as an excellent archive.
  • Some individuals who were cross-team minded are able to spend time to bring groups together, but its also a weak link since so much weight is placed on one individual
  • During the contributor mentorship cohort, many teams worked together to support new contributors and create materials
  • Learn Team’s build-out has been astronomical and in future can continue to be translated for a broader audience
  • Easy to collaborate with another team if it’s clear how that team prefers to be contacted (Slack, GitHub, etc.)
  • Local sites now have the ability to have their own make/blog, worked with meta team to get it done. It is good for local communities to utilize this for onboarding, good feel for new contributors to learn how to bring content from wp.org or make/blog to translate.
  • Persistence is very important for teams and individuals; this is what makes things happen; this is the magic.

Best Practices on Make Team Blogs (P2) PART 2:

Sticky note exercise – everyone writes things we should keep doing, stop doing, and 1 action item.

KEEP

  • Openness
  • Wide audience to participate
  • Monthly recap (human touch of summaries)
  • Concept of cross-team communication/collaboration

STOP

  • Only having team reps post
  • Writing proposals that have already been decided
  • The assumption that “lack of response” is consent (lack of engagement). Announce response time remaining in regular meetings. If not objections shared, move forward after that time, but there is always room for iteration
  • No clarity around what is a proposal versus a confirmed project post
  • There is a lot of noise

ACTIONS TO THINK ABOUT

  • Open to experimentation as a community
  • Content in other languages (MLAI services to do that)
  • Automated translations
  • Easier navigation for non-developers
  • Allow the search to scan across all make/blogs, showing GitHub tickets, too
  • Organization to sum up topics (with call for actions)
  • Better guidelines from cross-team collabs
  • Common pool of assets for all teams
  • Proposals voted on – async and live
  • Show excerpts / or provide summaries or overview of all proposals submitted on projects (or in one place)
  • Sharing feedback (and how to give feedback)
  • Have DRIsDRI Directly Responsible Individual - the people who are taking ownership or responsibility for a particular project or feature.
  • Better UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. / UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.
  • Email summary – from teams a member is subscribed to
  • Clarify guidelines on large project decisions – for old and new contributors
  • Single sign-up for updates

DISCUSSION FOLLOWING ^^ THIS

  • What do people think about voting?
  • Making sure community members are involved in the decision-making process vs ensuring we are moving forward
  • Keep in mind the audience of who is reading the post. Sometimes it’s for the team, other times it’s for the wider community. More refined posts announcing features.
  • Why have people begun feeling unsafe to share their ideas? Or that their ideas are not important? People wonder if it it their role? How do we know when and what to post? What makes someone nervous to post? Am I even allowed to post? Should a conversation start in Slack before making a post? Slack is just faster to get a response, so it’s easier to take that road vs make/blog.
  • Why are we using other tools? Fear of pile-on
  • If a decision fizzled out on github or Slack – maybe it is because it needs to be posted on Make Blog, someone might not have access
  • Involving your teammates is a way to post with less fear and feel like you have support behind your thoughts.
  • Profiles might not align – so it looks like you have no credit because it’s in a different place
  • We can build on the ideas on posts (where decisions are made) – leaving a footprint/legacy for future decision. Ex: training team – WP certification (conversation happened about 3 years ago- didn’t go away, had the convo again, still didn’t go anywhere – but it its documented and we were able to build on. So, it wasn’t a wasted post. Can we encourage people who post – that no post is a dud post? Building more value there
  • On learn – we can support by offering: How to write a well-written proposal
  • Tip: Link to ALL of your posts that are relevant – so people can see what was already discussed (Slack, Twitter, etc.)
  • Offer guidance on “How to kick start a working group & How to give good feedback”
  • Proposals that take off – but then fizzle out – but no communication on WHY it fizzled out (there is no communication or follow-up), so there is no closure
  • Summary ideas: Perhaps AI can assist in this summary posting. Design- this was the week’s topic, this decision was made, etc. Something to consider, given that the majority of the contributors are not funded and volunteering their time.
  • Why use that time to publish summaries rather than the project?
  • Sponsors vs individual – sponsored could assist with the “glue work” – not actually doing the “work” but making sure that someone somewhere is doing the work and keeping the community updated on what is actually happening on certain projects.
  • Caution should be exercised when looking at the AI tools out there that could be leveraged…many are not open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL., so that goes against the ethos of the project. Find a balance.

THOUGHTS ON VOTING

  • PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. – does formal requests for comments
  • Structure helps get things done
  • End of the month voting on projects (proposals are submitted during the month), then have amendments
  • We are missing constructive debate with yes/no voting
  • We need a space (create a space) to have this “debate” with a deadline
  • Not always a “simple majority”
  • There are by-laws (like 2/3s)
  • Can change per project (only contributors etc.)
  • How would you get past that WP is more of a consensus vs a majority

Questions Raised:

Why are we using so many external tools for discussion (GitHub/Slack) versus the make.wordpress blog?

How do we make sure that all necessary parties are involved in making a decision? If we have a discussion only in Slack, this surely will exclude certain people, however, many people aren’t made aware of the make.wordpress blogs for each team.

Conclusions/Summary:

Onboarding needs improvement so newcomers are made aware of the make.wordpress blog and how it is used across teams, as well as how to get involved in the conversation.

There needs to be more balance with efficiency and flow of posts, especially with proposals. There should be standard guidelines related to comment periods, then follow ups to those posts with information on steps taken or not taken and decisions made.

It’s important to make the planning visible (project boards, etc) across teams
The community needs periodic summaries from each team so they can come in and know what’s been happening and what’s coming next

There needs to be clear ownership and responsibility as this is a positive thing to have (have DRIs)

Invisible and under-appreciated: bolstering “behind the scenes” contributions

From the session page:

A number of teams and their work in the WordPress project currently receive little visibility, but also have high stakes or impact on the health of the WordPress community. Especially in recent years, the contributor pipeline for these teams has faced significant struggles. This discussion will explore how to address the broken pipeline, support the contributors involved, and how to give appropriate appreciation to this difficult work. Examples of teams facing this challenge include Plugins, Support, Security, Incident Response.

Facilitator: @clorith

Notetakers: @harmonyromo and @zoonini

Discussion objectives 

Most open-source projects don’t have enough people to do the work that needs doing. Investing time in recognition means we’re building a strong foundation for bringing in more future contributors.

  • Which groups tend to feel under-appreciated in the project?
  • What are some ways to give more recognition to those teams, both to make them feel more appreciated and also to encourage more people to contribute in those areas?

Key points

Publicizing our work and team makeup

  • Certain teams (like Support) are more public-facing than some which have good reason to be operating more “secretly” – like Security and the Incident Response Team (IRT). How can we bring to the forefront those more behind-the-scenes teams and celebrate their work more?
  • Sometimes we aren’t good about posting our work publicly – very few Make posts from certain teams. Need to keep p2 content fresh to highlight the work we’re all doing.
  • Incident Response Team requires a certain level of confidentiality, which can feel at odds with transparency. They try to be transparent about the process and steps, while balancing confidentiality and transparency.
  • People drawn to Incident Response team maybe don’t care as much about recognition? Could be more tenure-based recognition. 
  • Important for community to know who is on certain teams – makes them more approachable. But there’s a flip side where people could be contacted for the wrong reasons if  their name is public, in relation to these teams they work with. 
  • There’s some particular concern about lack of acknowledgement as it relates to the Security & IRT teams. People only know we handled an issue if we publicize it. So it might make it look like we don’t care about harassment or security if we don’t publicize that we handled certain things. Higher level of risk, a lot less reward. How do we find a balance?
  • Security obviously has to be somewhat obscure, though the team does get recognition for individual work on the team, like when a release comes out. Every problem that’s fixed gets disclosed at that time, and generally the person who found the issue is mentioned. PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Review team recently announced the people on the team, with their permission. Tricky team because they sometimes get negative feedback, so everyone gets a choice of whether to be mentioned.
  • Discussed some of the other teams and whether/how their team members’ work is publicly acknowledged. Example: Design team creates elements for WordCamps, meetups – a lot of people don’t realize that logos and other design elements require people to create them. Folks need to know that work goes into it. 

Types of recognition

  • Recognition is multi-level, doesn’t just make someone feel good but also shows others that this work is being done, and gives others the opportunity to see a potential place they might be interested in getting involved.
  • Different people want recognition in different ways. Which audience are we aiming recognition towards – peers? People outside of WP sphere? Self-recognition?
  • Credits page in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ties to release work, so a lot of people involved don’t get recognition. Particular problem with the MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team where work is not tied to a particular release.
  • Being asked to get involved with something specific can also have meaning. You’ve been asked to do something because people think you can bring value to something. 
  • Recap posts are a good time to post recognition. Difference in making work visible and being recognized. Event organizers often feel underappreciated but are approached for help so often.
  • Different motives for being involved – i.e. are you sponsored or not? May be more inherent recognition if you’re sponsored. Reward system built in, i.e. your continued employment. People are known internally (within their company) for that part of the project but might not know folks outside of the company who are doing related work on the non-sponsored side.
  • As a fully sponsored contributor, that desire for recognition is also still important to some.

Identify targets

Whose work do we want to show off/lift up/make more visible within the project? Let’s not forget those who do less visible work – are there tasks on teams that have a lower visibility, where the need for recognition is bigger? Also called the “glue” work.

Two types of target audiences to look at:

  • Team-based, like: Support, Plugins, Meta, Security, IRT 
  • Task-based, like: administration, community, triage, mentorship work

Badges/profiles

  • Lots of discussion around profile badges, with some people being more in favour and some less so. Discussed expanding the types of badges offered – for example, could have more “levels,” or even mention specific years in which someone was involved with a particular thing. Additional text could help make badges more meaningful and provide more nuance and context around someone’s current and historic involvement.
  • There was some research done in the past around multi-level badges but the project has been on pause. If we picked it up, it could more adequately reflect people’s contributions. Levels might be easier to assign for some teams than others, because certain types of work are much less quantifiable. Some classification work can be automated, but some can’t, so would it really be the best use of our time?
  • Some badges are more easily earned than others, so a badge doesn’t reflect a consistent amount of work. For example, a Polyglots badge doesn’t differentiate between amounts of work. In Core you can spend weeks writing a feature, and you get a single “prop” alongside others who make much smaller contributions. Committers have the option to give props to themselves, which can feel weird. Community folks have a similar issue – i.e. meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. organizer vs. lead organizer of a WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. get the same badge, but they often reflect very different amounts of work.
  • Teams work differently in terms of assigning badges, you might do a lot of work on one team but not have a badge for it. On some teams it’s automated (i.e. Photos), on others teams it’s manual (i.e. Support).
  • Suggestion for current badge system to link each badge to the Make blog of the team it references, which could give lesser-known teams more exposure.

Sponsored vs. unsponsored/self-sponsored volunteers

  • How do we ensure we have a pipeline of people for tasks that no one typically wants to sponsor, like admin tasks. How do you get past the thinking that admin work is not worthy of sponsorship?
  • Sponsors expect a return on their investment in the form of recognition.
  • Limited time to volunteer, how much are we limiting the base of contributions in general by making it seem you have to understand so much about the organization before you can jump in and volunteer. A lot of time is spent reading and catching up on what was missed or what has changed since the prior time they contributed. May not know how to spend their 2 available hours and thus don’t do it.
  • Volunteers want to do what they enjoy doing, not necessarily what needs to be done in the project. No matter how much we need help with specific tasks, it’s not likely that we’re going to get people to volunteer to work on it if that’s not of interest to them. Different story for sponsored contributors. 

Onboarding new volunteers

  • With recent success of the mentoring program/cohort, is there a way to parlay success into some sort of rotation/sampling as we bring in a more focused mentoring program for new contributors, so those people can get a chance to experience multiple teams? Introduce them to some of these less seen teams, so they can potentially get involved somewhere they wouldn’t have encountered.
  • New onboarding paths across all teams, all have links to “less than an hour” content for getting started. 
  • What are we doing to help people be able to do “drop in” contributions for smaller pieces of work?

Next steps

  • Formally identify target audiences.
  • Investigate status of upgrades to badge system.
  • Look into creating one dedicated questions/getting-started channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to help overcome the overwhelm people can feel when trying to get started contributing.

#summit, #summit-2023

Community summit discussion notes: Revitalizing contributor teams’ leadership pipeline

Title of session: Revitalizing Contributor Teams’ Leadership Pipeline

Facilitator: @cbringmann

Notetakers: @ninianepress, @peiraisotta

Personal check-in about the topic

How do we feel about the leadership pipeline?

Discussion objectives

  • Identify the challenges to the current leadership
  • Explore motivations for folks becoming leaders
  • Discuss barriers that prevent people from embracing leadership 
  • Brainstorm potential solutions
  • Identify future pipelines

Key points

Identify the challenges to the current leadership

We don’t know what we are doing – things work, but we don’t know why we’re doing specific things.

There’s a different onboarding experience for each team and personal unstructured mentorships, but we don’t know all the things that we have the power to do or all the tools that are available.

Team reps don’t have clear instructions; we have followed some guidelines without knowing the reason why those guidelines are in place.

Burnout and overwhelm are a reality and the confusion doesn’t help.

There’s a particular challenge in understanding what is a “leader” in our ecosystem: 

  • Leadership: whoever is very active in the projects (WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. and MeetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. organizers, folks heavily involved in the releases and projects being sustainable, etc. and not only team reps)

From other sessions we realized the lack of definition of what team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. is, but we know that it’s not necessarily a lead. So, we don’t have a structure to define what a leader is in this community. People who are louder might be perceived as leaders leaving behind other folks. Formally, the only clear definition is a project lead.

Community members expect organizers and team reps to have all the answers, but many times leaders don’t have answers or the power to make the change requested. It causes a frustrating feeling that we do and don’t have the power to create positive change.

There’s a real need for clarity since there’s a lack of documentation for stewardship roles, and people have to:

  • Make mistakes and ask for forgiveness in retrospect
  • Be pushy and take initiative

People expect team reps to move things forward, but there’s no clear way forward often, no documentation, and it’s clear reps can’t do whatever they want. This makes it incredibly difficult to get anything done.

It’s difficult to find people who are willing to share responsibilities in local teams:

  • There’s a lot of focus on global stewardship, but not enough for local communities.

If we don’t have a clear idea about the responsibilities of a leadership role, we can’t onboard new leaders.

New contributors think they can only contribute to small tasks and they don’t realize they can become a team rep.

Leadership onboarding doesn’t exist on all teams and projects.

There’s a lack of connection between local teams and their respective global teams.

Explore what motivates folks into becoming leaders

  • Desire to learn as well as a love of learning by doing, and contributing
  • Desire to support and empower others
  • Maintaining and supporting a local community or project
  • Filling a gap, no motivation
  • Feeling empowered and helping others empower themselves
  • Seeking opportunities to fix things and knowing that we’re making progress (Ex. a high number of closed tickets)
  • Learning how the whole project works – the challenge of getting to learn how everything is connected is the motivation

Discuss barriers that prevent people from embracing leadership roles

  • Contributors aren’t aware about the possibility of growing into leadership roles.
  • The contributor pipelines are clearer on some teams than others.
  • There are knowledge barriers with a lack of documentation on many teams.

Brainstorming potential solutions

  • Better documentation and maybe a few centralized places for the documentation that is needed by different teams:
    • “What is leadership” in General Documentation or the Marketing Team, and maybe linked to team pages on how reps work on their team as well as what the role looks like and what it takes.
    • Further asynchronous discussion will be needed.
  • Request the information that is missing
  • Create an auto-updating chart on WordPress.org or where ever we can find the people responsible of each project and team
  • Leadership training: give contributors the path and tools to develop their leadership skills 
  • Mentorships to help contributors look for opportunities since current leaders can recognize future ones and can help them step into the role little by little
  • Small steps into the role
  • Keeping and maintaining the human component related to leadership without getting lost in process

What are the incentives to being a rep?

  • Every successful contribution helps as a learning opportunity that leaves reps feeling empowered to lead.
  • When a rep is able to lead someone, it further helps develop their skills, which feels great, especially when the project moves forward.
  • Some reps have no motivation to lead, they just became leaders because they were told by others to fill the open, much-needed position.
    • You can lead and inspire without being a rep.
  • In some cases, there’s an aspect of mentorship where if someone notices your hard work and says the role could be a good fit for you, it can snowball; it can be really encouraging and motivating.
  • Knowing your contributions are live for over 40% of the (public) web.
  • You don’t need to be a rep to learn a lot, but it does happen.
  • There are a lot of opportunities on the Test Team and other Teams.
  • You can start to see where there are gaps that need to be bridged.
  • Learning how everything works can be really motivating.
  • Having a role where success objectives are clearly defined such as counting the number of closed tickets is definitely motivating for many.
  • The trust everyone puts in you is empowering.
  • Helping foster a strong sense of community is motivating.
  • Human connection and making life-long friendships.

Identify future pipelines

  • Starting or facilitating meetups and being active in the community can help someone spot you to encourage you into a leadership role.
  • One of the jobs as a rep isn’t just to lead, but to see and encourage others.
  • Mentorships and documentation are key.
  • Create a system to ensure that the current leaders support the next ones by mentoring them and walking them through the leadership path
  • Standardize badge system including leadership badges
  • Standardize training path to leadership (to get the badge folks have to take specific course) and we could use material already available on the Learn platform, or decide what’s needed during contributor days
    • Courses or to-do lists may not be accessible for everyone, unless they’re short and concise
  • Expand and standardize leadership roles to include something like junior and senior reps both globally and per team
  • Offboarding process for when leaders want to step back (information transfers, access removal, etc.)
  • Process to transfer the knowledge 
  • Defining leadership roles is crucial for reps but also for working groups
  • Visuals are needed to understand the structure of everything
    • There’s already a Marketing issue in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ for this idea
  • Too much bureaucracy can be a barrier to entry for new(er) contributors
  • Using accessible tools is critical as Google Docs isn’t accessible

#summit, #summit-2023, #team-reps

Community Summit Discussion Notes: How does the Make Team ecosystem work and how are we connected?

From the schedule session:

There are 22 Make Teams (and counting!) that build WordPress. Each team has it’s mandate and priorities, and are connected by the overarching purpose of moving WordPress forward. For contributors working on one team, it can be easy to lose sight of the broader project and other teams, or see how your team’s work fits in. This discussion will explore how teams are connected and the impact a team may have on others, with an eye towards growing our collective understanding of the Make WordPress ecosystem as a whole. We will also explore how we can keep growing this collective understanding for all new and current contributors.

Facilitator: Hari Shanker (@harishanker)

Notetaker 1: Emma Sophie Young (@emmaht)

Notetaker 2: Erica Varlese (@evarlese)

Notetaker 3: Taco Verdonschot (@tacoverdo)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Is Succession Planning Possible in Open Source?

From the session schedule:

Key work for all leaders is investing in the next generation of leadership. This is especially true (yet especially hard) in free and open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. software (FOSS), where you see hybrid concerns: not-for-profit/for-profit, volunteer/paid, skilled/unskilled. While our leadership group has expanded, it’s still unclear how to confirm a succession plan (either from an emergent or planned perspective).

Facilitator: Joe McGill (@joemcgill)

Notetaker 1: Kim Coleman (@kimannwall

Notetaker 2: Isotta Peira (@peiraisotta)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Exploring how the Accessibility Team can support Making WordPress teams

From the session schedule:

The AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team would like to explore how it can become a shared resource and best support Make Teams and the WordPress project as a whole. The current challenges are that this small team struggles to track where they could be helpful across the WordPress project, and they would like a stronger system that allows them to better address requests as a whole team.

Perspectives needed: Current and interested Accessibility Team members, members from other Make Teams who want to collaborate with Make Accessibility.

Facilitator: Joe Dolson (@joedolson)

Notetaker: david wolfpaw (@wolfpaw)

Notetaker: Taco Verdonschot (@tacoverdo)

Raw Notes:

  • we would like to see how we can be a better support for other Make teams, given our extremely limited resources as a small team.
  • We are in total the equivalent of one full-time person of hours, supporting all other teams.
  • The accessibility team proactively reaches out to other teams, and would like to not do that – one of the biggest consumers of team time is trying to reach out and see what they can do. It’s not about doing more, it’s about being more productive.
  • Some other teams would like to switch this around, and see what they can do to proactively reach out to the accessibility team to see what is doable and how they can help. Recognize at what point they should be asking for input to see where they could go wrong with accessibility without proper support and information.
  • The accessibility team could help to identify what things teams should be aware of, and the crucial timing
  • For other teams: what ways do you interact cross-team that are working already, whether they are formal collaborations or are ad-hoc?
  • Successful is always a work in progress. For example, we have help with accessibility with one point person. It is very helpful, but it would be better to have more than one. Having checkpoints on when we could use extra feedback, providing a feedback cycle. Acknowledging as a team that nothing is set in stone, even if we’ve already started moving forward.
  • One example of the crossover work with the documentation team is that someone keeps an eye on what is going on in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to know what Documentation needs to be updated. Similarly, Learning looks to Marketing and Documentation to see what is coming up and knowing what
  • Each team should have an accessibility lead, who can liaise with the cross-team Accessibility Team. There is a lack of education for teams to know what things they are doing are not accessible. Having a champion of accessibility on each team would make it easier to have cross-team collaboration.
  • Part of the routine, weekly structure of the accessibility team currently is reviewing updates from other teams. It has been hard to get people from other teams to actually do those reports.
  • The Documentation team has someone trawl through pull requests and posts from other teams. It is a fairly intensive project that takes a lot of time to do.
  • Ideally the person for each team has a basic sense of accessibility, even though they are active on another team. What skills do they need, and is that something easily trainable?
  • Some simple things can be easily learned, such as color contrast, font sizing, using extensions that help to manage it, etc would be easy for someone to pick up.
  • Content Creators may have the same questions, and the liaison can give them answers to take some of the burden off of the accessibility team.
  • Working out what a liaison needs will work wildly different based on the team. It could be a process of discovery between those teams. Something within scope of the accessibility is to have a one-on-one with the liaison, have a discussion, document it, and publish it.
  • Real world accessibility at events has other needs, but it is within the team purview. There is a P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. channel and they are working on documenting to setup principles and documentation that can be referred to for every WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more.. Documents will be published from the Community Team.
  • By the Accessibility Team doing outreach to other teams it can be seen as critical, as opposed to being helpful. The sooner that the team can get involved, the more that it can be collaborative.
  • There is worry that the Accessibility Team is seen as a blocker for growth. It is preferable to have others reach out for feedback, as opposed to being reached out to after things have been published.
  • Other teams don’t want to be badgering the Accessibility Team all of the time, so there’s a problem there. It has been tricky to get feedback on some in-progress things. Part of the wordpress.org redesign has been trying to get pages live to get feedback and update, but it has been perceived as being done.
  • There could be some sort of flag that pages need review still. The challenge with having a flag is that it will be perceived as a blocker; everything is done except for that review.
  • Documentation is confusingly not responsible for all documentation. For instance for handbooks. But the documentation team can provide assistance. By helping the Playground Team it has made it more known throughout the project what needs to be done for accessibility.
  • All of the teams could have templates of how to work with cross-teams for things like accessibility.
  • Working with the Training Team, trying to work with the Accessibility Team has been difficult.
  • There are two questions: what are the difficulties with onboarding people, and what are the difficulties with retaining people. We have so many needs that onboarding is hard to do.
  • One of the biggest problems with onboarding is frustration and pushback in trying to get things done for Accessibility.
  • There is a concern as to what legal fears exist for attaching our names to teams for doing things relating to Accessibility. For instance, there are overlay companies who have been doing legal battles, and are highly litigious and have a lot of money. These tools do not really work and people have been sued or threatened with lawsuits. Adrian Roselli is being sued currently as a notable example
  • If there was a way to obtain support from the WordPress Foundation that there would be support concerning frivolous lawsuits. But that would be a difficult ask to have and unlikely to happen.
  • The individual teams could work better at onboarding new people to do accessibility with more redundancy and scaling. This could be done with
  • The looping of people together from various teams sounds like it would be a good place for a Working Group. This would go with the most pressing accessibility concerns to start, and then turning that into a Working Group that would go through getting a liaison for the team, working with Documentation, creating onboarding, having the documentation and onboarding live on Learn WordPress, having things where people can step in, do training, and be qualified.
  • Individuals will not have the confidence to step into a role of being a liaison without having some formalized training that qualifies them.
  • There should be some feedback on how people got interested in being involved in the Accessibility Team from a different team, to determine how to best make people liaisons. The Community Team reached out to see how they could best facilitate to make WordCamp US 2023 more accessible for instance. Community Team has the risk that their accessibility mistakes are often more public, with more people talking about them.
  • The Accessibility Team deserves credit for a tone shift into, “How can we help other teams do better?” as opposed to pointing out what has been done wrong.
  • An issue is when the Accessibility Team provides feedback, and the feedback is not implemented. When issues are highlighted and no one wants to do anything about it. A reason to stop things from moving forward beyond development/merge is that once it is launched, it is hard to get things resolved for accessibility. Maybe for visual or functionality, but not for accessibility.
  • People on teams do too much to move new features apart, making it harder
  • How people can help: having a pause window on pushing new features up, but making it better worded that it will sound like . It is hard to see which things are actually moving forward versus which features are just experimental and won’t ever go anywhere. If everything in progress, even basic experimental
  • There are security audits that happen automatically that will stop things from moving forward. Why are there not automated and manual checks for accessibility that are not blockers for things moving forward? There are some incredibly basic problems that are not addressed before features go out for review or even to publish.
  • Automated testing does have its place. Some of the issues are so basic that the browser automated accessibiilty testing would catch. It would be worthwhile to eliminate a base set of issues by starting to incorporate automated testing, but make it clear that passing that testing does not make it accessible, just saves some time.
  • Guternberg, most of the time, is good with micro issues for accessibility interactions. But is on the macro issues that need help. Getting rid of having to look for micro issues will really help.
  • The hard part is setting up infrastructure for testing, not writing actual tests
  • There is not yet something in Training for general accessibility testing. There is an open issue for something to be vetted.
  • The 5 for the Future discussion talked about having companies take on specific projects, which could be a place for a company with focus on accessibility that would be willing to take on this task.
  • Having a conversation with MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and Documentation team to work out how to be a liaison for those teams would be a good start. Being able to incorporate more automated testing into Core would help. Teaching people at the best point to reach out to Accessibility Team would help.
  • There should be criteria for if something is flat-out a blocker to something launching on the accessibility level. Similar to how there is for things like security issues.
  • Some of the basic things that could be solved are having things like checklists for the Community Team that will make sure that basics of accessibility team are covered for events, as well as the websites around them. Informing people who are attending what accessibility means for your event and venue, not just ensuring that they are there.
  • A proposal to refer to liaisons as “allies” to the Accessibility Team, ensuring that there will be someone embedded in that specific team that will champion their needs. This is especially relevant to content-heavy teams, such as learning, documentation, training, marketing.
  • The need for liaisons could be a specific level of knowledge that is siloed that could be solved by people with the specific, focused knowledge working with the people having issues directly.
  • The liaisons and allies don’t have to be one person on each team, but could be a larger number of people to avoid information siloing. It is all coming down, one way or another, to documentation. The Accessibility Team would definitely benefit from help from the Documentation Team.
  • Upcoming legislation that will be more and more strict on accessibility. Informing people about what is coming up: is that something that would be considered as a role for the team, since there is no legal team? The Accessibility Team says no, they are not qualified to provide legal advice and could not be the resource for this.
  • A rewrite is in progress, but has been in progress for two years, of the Accessibility Team page on make.wordpress.org One of the topics for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. is what the statement that the team will be about, but also having accessibility statements for the website itself.
  • The commitment to accessibility should be spread across more teams. From a practical standpoint, there is nothing that is, “just the Accessibility Team”. There is always a reason to have subject matter experts, to ensure that different teams do not go in different directions on what we should do.
  • Quite a few teams have people that are cross-team active. Given the low resources for the a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team, it’s not feasible to have them in all the other teams.
  • A11y team is actively searching for updates from other teams. This is currently happening with a few teams, but not with all of them. 
  • What would a liaison-person need as skillset? Is that easily trainable?
  • Working out what a liaison needs depends on the team. It would be a process of discovery. A possible feasible offer from the a11y team would be to have 1-on-1 with the potential liaisons. 
  • Does the a11y team also extend to in-person events, or is it limited to the WordPress software?
  • Yes, but it’s taking a severe toll on the time available to work on the software. 
  • What are the challenges to onboarding new people to the a11y team?
  • We’re so busy trying to keep up, we don’t have the time to onboard new people. We need people to be coding, we need people to be testing. 
  • What are the challenges to retaining people to the a11y team?
  • People are getting burned out from the pressure and frustration, due to the slow process and severe pushback. The other reason is Matt Mullenweg, who personally offended many people in the a11y community team. 
  • I don’t feel comfortable contributing to the a11y team because of lawsuits happening against a11y experts. 
  • [short explanation of what’s happening to Adrian Roselli] 
  • Can we form a working group that goes through all the other teams to create a resource on what an a11y liaison should be/do? That way we can create a “personalized” course for each team. 
  • One of the challenges is identifying issues that are actually moving forward vs issues that are just experimental and will never go anywhere, and thus don’t need the a11y team’s attention. 
  • Is it possible to automatically check for some of the basic things?
  • Yes, that would be possible as part of a linting process. But it indeed is very basic, because it would still need a check by a person to verify if -for example- naming is done right.
  • Action items
    • Have a conversation with meta and training to find out what a liaison role should look like
    • Have more automated testing
    • Having champions for a11y in different teams

#summit, #summit-2023

Community Summit Discussion Notes: Aligning WordPress Enterprise with WordPress Community

From the schedule session:

In recent years, WordPress has struggled to grow at the enterprise level. At the same time, companies and individuals invested in enterprise could be an immense value-add to the WordPress open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project. This discussion will explore the current friction points between enterprise interests and community interests, and where alignments can be amplified for mutual benefit.

Facilitator: Siobhan McKeown (@siobhan)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Jon Ang (@kenshino)

Continue reading

#enterprise, #summit, #summit-2023

Community Summit Role: Taking Stack and Keeping Time

Each Community Summit discussion will have:

  1. One Facilitator
  2. Two Notetakers (read about the Notetaker role)
  3. One Stack Keeper/Time Keeper

Please familiarize yourself with the Stack Keeper/Time Keeper role in advance, so you’re ready to volunteer!

Purpose: The purpose of taking stack is to ensure that all participants’ voices can be heard in the discussion. Otherwise, an individual or a small group of people could easily dominate the discussion and shut out other participants.

The role of Stack Keeper: At the beginning of each discussion, the Facilitator will request a volunteer to be the Stack Keeper. It is the Stack Keeper’s responsibility to structure and order the dialogue. “The Stack” is the order of participants who are speaking. If a participant raises their hand to say something, the Stack Keeper puts them on “Stack.” That is, the Stack Keeper puts their name at the bottom of the stack list. When the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and announces who the next two participants on stack are. The Stack Keeper should also make sure that people who have spoken before come after folks who have been added to the Stack for the first time.

Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack Keeper must constantly be paying attention and scanning the room to see who wants to speak. In addition to these duties, both the Facilitator and Stack Keeper may also contribute normally to the discussion.

Keeping time: The Stack Keeper is also responsible for keeping time during the discussion. It’s important that the Stack Keeper/Time Keeper let the Facilitator know when it’s time to wind down the discussion and shift to Next Steps and Action Items (at least 5 minutes before the scheduled end-time). This will help avoid an abrupt end to the discussion, and ensure that the group has clearly identified next steps before the discussion concludes.

Community Summit Non-Attribution Guideline

As we prepare for the Community Summit, we’d like to share the important guideline of non-attribution, to ensure productive and open discussions.

While we welcome and encourage you to share the content and insights from our discussion with others, we kindly request that you practice non-attribution. This means that outside the Summit you can discuss the general ideas and themes that arise, but please refrain from directly quoting or attributing specific comments to individual participants.

Our goal is to create a safe, inclusive and collaborative environment where everyone feels encouraged to brainstorm, share their thoughts, and speak their minds. By not attributing comments to specific individuals, we hope to foster a space where participants don’t have to worry about their words being taken out of context or used against them outside of the Summit discussions.

In the spirit of non-attribution, we request the following:

  • Stay Present: We kindly ask that you refrain from posting on social media during Summit discussions. This helps ensure that everyone is actively engaged and present in the moment.
  • Photos: You’re welcome to take photos, but please ensure they align with our non-attribution guideline. This means avoiding photos that tie specific comments or ideas to particular individuals.
  • Recaps & Summaries: You are welcome to share post-event recaps. However, please ensure that these do not attribute specific comments or viewpoints to individual participants.

Thanks for your understanding and cooperation. We’re excited to dive into these discussions together!