Community Summit Discussion Notes: Diversity, Equity, Inclusion, and Belonging (DEIB) for all Make Teams

From the session schedule:

This discussion will focus on how the WordPress project can welcome and sustain a diverse pool of contributors to all Make Teams. What are teams currently doing, and what practices can be brought to the whole project? What new practices, resources, support should be introduced?

Perspectives needed: Current and aspiring Make Teams members interested in DEIB.

Facilitator: Birgit Olzem (@coachbirgit)

Notetaker: david wolfpaw (@wolfpaw)

Notetaker: Bigul Malayi (@mbigul)

Notetaker: Taco Verdonschot (@tacoverdo)

Raw Notes:

Topics:

  • What is DEIB? Diversity, Equity, Inclusion, and Belonging.
  • Current state of DEIB in the WordPress project
  • Potential Improvement
  • Collaboration and Support
  • Scope of a DEIB Team?
  • The project today: how the WordPress project can welcome and include a diverse team of makers across all teams.
  • Equity is to ensure that we have the opportunity to give underrepresented groups the same opportunities that already represented groups have.
  • How do we honor the very best of this community? How do we bring people in and feel as welcome and included in our spaces as possible? What can we do to address things that prevent that from happening?
  • We would like members of this community to reflect how diversity in the world exists in the many local communities within our global community.
  • We want to have a diverse mindset
  • Belonging is a new word as part of the acronym. It makes me think of the premise of this discussion: sustain. It is great to have belonging because while we can make this community open, how do we ensure that their needs are continued to be met while as part of this community. I believe that Belonging is representative of that goal. Not only surface things but being able to sustain your presence there.
  • A group of four of us outside noted that we were all from four separate continents. The WordPress community can be an example of making the world more open and peaceful, and bringing the dream of 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. to things like politics. I fell in love with the WP community years ago because of that.
  • When we talk about DEIB we have to talk about what the barriers of access for different people. Some of us do not have as much ability to easily access spaces for different reasons. The access for everybody is not the same, and e have to look at that and consider how we individually provide 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). We also acknowledge that it is not free to do this, for instance adding ramps. We have to invest resources, not just human, but financial, to ensure that events are accessible to everyone, through things like sponsorships and financial support and reaching out to underrepresented groups.
  • Diversity is special to us. India is a land of languages. Different languages, culture, food. The WordPress community is an ecosystem that has allowed many people to come and contribute. There is a communication issue but discussing this will help the community to learn and improve.
  • Seconding that Belonging is important. It is one thing to have DEI, but Belonging brings it full circle.
  • This community is very open. Some people do not know if they will have a place in the WP community and it is great to show that everyone can belong here. I can do what I do here without being judged by my background or what I look like.
  • I want to acknowledge that we have come a long way in this community. Sometimes it is easy to say, “we’ve done it, we’ve created a space”, but as a community what we haven’t quite done yet is have some of the invisible inclusions. We need to be honest about where we are and aren’t inclusive yet. We don’t want people to have to share their invisible inclusion, but be able to show up and already have space for them. Whatever person you see in front of you, you should not judge their ability or situation.
  • I grew up in India and lived my adult life in the US. I worked in the corporate world before WP, and sometimes I was the only female among white, male developers. It was hard to get that sense of belonging there. I am generally a quiet person, and for folks who are quieter and introverts you don’t feel as left out in the WordPress community. People welcome you and it is very different between this community and the corporate world.
  • We have a variety of diversity, inclduing people from many countries coming here, and finding it enjoyable. It gives me hope because I have been in other technology communities as the lone woman and designer in a room of developers who are men. WordPress has many things to be improved, as any other community. But this community gives me the feeling that things can be changed. I asked a question and it became a team. WordPress has the ability to evolve and improve, and there is an opportunity to make changes that can be little or make great, big things.
  • I love to hear the positive stories about where we are, but for me the diversity and inclusion part is about who is not in this room, and who is not at 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.. Someone posted yesterday that they do not feel welcome or safe at WordCamps. We should not ignore this and despite how far we’ve come and how diverse the group is, we cannot stop realizing that there is so much more work to do before everyone feels welcome.
  • What is our status in diversity, not only on events, but within Make team collaborations. Where are the differences between the global and local Make teams, and do you see any interference or points.
  • Local communities are disconnected from Make itself. It is a challenge to introduce a local community to what we do as the WordPress project. A lot of people at local Meetups are seeking help, and a majority of the time it is walking them through a problem, not introducing them to what the WordPress volunteer project does. It creates a sgnificant challenge in introducing more people to the WordPress project.
  • If we are talking about Diversity and Inclusion, we have to talk about it in the 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. community. How do leaders include you, how safe do you feel, and how do they ensure that you return because you feel welcome and safe enough. If you return over time you will learn about the Community and Make teams.
  • How do we handle bad actors in and outside of the community?
  • One of the significant barriers of having people involved is the language barrier. A lot of the Make pages are only in English, and a lot of people cannot read English. Polyglots cannot increase participation in the project because of the language barrier. Many people who don’t speak English do not feel comfortable reaching out about getting involved. How do we get the non-English community feel more welcome to get involved.
  • Translation tools have been very helpful for me to get involved as a non-English speaker
  • WordPress is very open to join, but it is hard to stay for some people. The belonging is not there for everybody. WordPress a toxic positivity problem. We try to make narratives to change minds to get people who are prejudiced to be involved. There are people who cannot be here because their abusers are here. I do not feel safe at conferences where I have spoken out about racism, sexism, and homophobia. It got bad enough that if some people have not stood up for me I would not still be here. How do we do that for everybody? I am one person who stayed, but there are people leaving and losing diversity because people are scared. When people do things and make mistakes we should do something, and we cannot let bad actors blossom in the community. They are not even the best of the community. We have to be strong and speak up but it should not be on us to do so. People don’t want to be calling out their friends, but you should be the one doing so, as you have a better chance of changing them than a stranger. We are a global community. When it is positive it should be global, and when it is negative we should be global.
  • Where does the Code of Conduct apply, and where doesn’t it? Where can we apply things and where can we not? As a community, people can come out and do things, but where as WordPress can we come out and regulate and mandate, and where do we have influence? We have a lot of issues because of this.
  • I am new to WordPress and I am more of an observer. It is a hard place to get more diverse. Unfortunately the people who run the events can take over the conversation sometimes. As an educator I want to make sure that you are included and will try to call you to come into the conversation to ensure that you are heard. It is ok if you come and are lurking but we have people who tend to take over conversations and ensuring that we introduce ourselves to people to get them involved.
  • I have tried getting involved in some teams but onboarding is hard, and it took time to build my confidence to speak up a bit more. Everything is a learning moment. We should be learning every day to be better and support people around us.
  • Instead of organizing a Meetup sometimes we will do things like have a coffee chat or at a sponsor office. Sometimes instead of having a session we will just have talks so that people can be part of a group and we try to bring in newcomers. Most of the people coming to Meetups are coming for their own personal goals. We will try to accommodate them so that they return for the next Meetup and next event. We tell people that if you are attending a Meetup you are a part of the community. We tell people that you do not have to think that you have to be a programmer to be a contributor to an open source project. We tell people to come, write documentation, translate a few strings, post a video. We want people to feel safe to be part of the community. We also have events like parties, and organize in a WhatsApp group. This is going good. We want to have different contributor days, for specific groups and types of contributions, like coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. one day, and documentation another.
  • How do we deal with something that happens when someone is being intolerant? Should we ask them not to come
  • I have held events where we have threatened to be sued. We have to take someone’s free speech into consideration, and there is a fine line that you have to draw. You don’t want to position yourself where you lose everything when someone pushes the right buttons. You can speak up and say that you don’t feel comfortable, but to tell someone “leave” is a very slippery slope. It is hard to keep ourselves in a way that we do not have to deal with legal issues.
  • We have had issues with someone at our events who had made physical threats to members of our team, in part because of our marginalized status. We already had issues with this person and WordCamp CentralWordCamp Central Website for all WordCamp activities globally. https://central.wordcamp.org includes a list of upcoming and past camp with links to each. was aware of them. But it took too many meetings, one-on-ones and finally having threats made in a written format that could be shared before something was done.
  • There is a lot of talk about regulation of social media right now for how it influences children. It is hard to see when it is something that you were not born into to see how that works. The current political climate is how we have had a presidency that for four years folks emboldened to say whatever they wanted to say. Before what was unacceptable to say, or only said behind an avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name., is no longer unacceptable to say. It now becomes legally ok to say things. There are other parts of the world where there are other similar political issues.
  • Some people engage and organize online, and some people do so via their local communities.
  • The world has a variety of different laws, but we have to tailor based on what some parts of the world define for ourselves, such as GDPR in the EU, and their position making us shift accordingly. Depending on where you are in the world you may not have those checks and balances. There are a lot of things that I see about where you are breaking the law. We don’t just have to deal with various cultures, but also with various legalities around the world.
  • There was a member in our community who wanted sign language interpreters and it had to be with a specific company. This person was very vocally threatening with me about it. I had to have conversations with Central about how to handle it, because they can handle the legality but myself as an individual I cannot handle that.
  • When we look at someone we cannot tell if they are all seeing the same things to consider as we are.
  • The biggest thing that I wanted to bring into the conversation was the idea of community responsibility. Not just what the Community team does about bad actors, but what we as community members do. There’s a level of respect, curiosity, and response that I think is a default in WordPress community interactions. One of the strengths that we have as part of a diverse community is that we can continually learn from people who have different backgrounds and experiences. If we are not growing and adjusting we are not learning. The community has grown tremendously in accepting others, but we are going to see those bad actors. What can we do as a community but also individually in doing something about those bad actors.
  • If you want to make people feel like they belonging, what do we as a community do about bad actors? We cannot just let it go. Personally I would not feel that I belong and feel relaxed in an environment where I do not feel like a human being. We need to do things to protect the community in our Code of Conduct.
  • We could come up with a digital policy for the Code of Conduct for how people interact digitally around the community.
  • Your freedom does not allow you to interfere with other people’s freedoms.
  • Punishment could be applied for specific infractions, and what people can do, for instance being banned from events for a specific timeframe.
  • We had an incident a few years ago where someone had to be banned for a year and is not going to be an organizer when brought back.
  • Respect others. It is not ok to attack other people online.
  • We do have a community-wide Code of Conduct that does address both in-person community spaces, and online community spaces as well. It is a specific scope. Conversations on social media can become hostile and they are outside of what we consider the core of where we participate. It is challenging to consider where we can have influence from a community support perspective.
  • We have been building out this Code of Conduct as well as an Incident Response team. There is a lot that goes into reaching out to people and supporting community members as best we can. If there are edits that we want to make, we can improve it.
  • Toxic Positivity It is already big that we are talking about it, but some people have to realize that a conversation about diversity an a willingness to improve is important and not making it look like it is a fairy tale.
  • I see someone with an opinion that I absolutely do not appreciate, and is hurtful and wrong, and I see them being scolded at and attacked online by people trying to defend inclusion. It was very much counterproductive, while responses from someone saying that they want to help and educate was taken positively and agreed upon. If there is a chance to educate someone and there is a chance to do something about that and specific people don’t always have to be defending, there are ways to keep people involved and try first to have conversations with someone to show why their position is wrong and hurtful.
  • There was an incident of racism in the community and I had to talk to people that I considered friends and I thought that we’d had an understanding. But they flipped and called the reporters liars, and the incident response team stepped in and helped, but not a lot of people know about them. We found out that the person had multiple violations already. Luckily we had evidence of what these people did.
  • People can be educated and people make mistakes. But you have to be willing in good faith and honesty to take that help. The Incident Response team will step in and help, but why did it have to get to that? How can we stop it from getting to that point where people are on their fourth or fifth chances.
  • We don’t always know the right action if it is not your exclusion. Lots of instances that we are seeing time and time again where people who are marginalized have to stand up for themselves and be the ones to educate, and that is wrong. The people who are being attacked should not have to do the work, and those of us who are privileged should be stepping up, going on a quest for education, learning what support is needed, and offering it.
  • Exclusions impact greatly in a range of spaces outside of just Meetups and WordPress. Tokenism does not help in those spaces. This has happened because of a scarcity in the community spaces and I do not want that to happen.
  • Doing incident reports is one of the hardest jobs. If you love the community and have to see the not so great aspects of the community, it is hard to see. We nee
  • The amount of support that we can directly provide is limited legally, but as people we still care and want to help. Where we can help is collaborating with incident responders for knowledge share to offer support.
  • What can we do in our work to make active contributors feel seen, heard, and belonging?
  • One thing that has been done for regional conferences of a different open source project is having people specifically available both online and in person at smaller events to help with incident response. There are more people present who are not just organizers to respond to attendees in that space. We tried getting people with varied experiences. We have a response playbook that is public for events that we use when an incident occurs at the events. After the event we summarize and anonymize all of the incidents that occurred and what was done about them and publish it for transparency.
  • What would it take to proactively make events and other contributions safe for people? There are different barriers for different people and we can only know about what challenges we are facing ourselves. As much as some of us may want to contribute to events, we cannot take on certain roles. We could ask community members to fill a form to proactively address issues that they may have, to ensure that we are proactively being welcoming to those people.
  • Letting people know how they can feel going to an event, such as a tech event as an older woman who is not a developer.
  • Amplifying incident response teams. A lot of people don’t know who to go to when there are problems, with mediating, helping with people who made mistakes and want to learn, etc
  • Is there a way that we can start learning laws from different parts of the world to solve some of our challenges with a response team and education. The Incident Response team has some access to the legal team for Automattic pro-bono
  • An idea is to create advocacy and ally workshops to educate the rest of the community as to what that entails.
  • We have a Code of Conduct, but if we create a DEIB statement that says something along the lines of if you are part of a marginalized group, whether visible or invisible, you are welcome. If you
  • Three suggestions: making the language more inviting on bringing forth accessibility needs for events. Currently the form for WordCamp tickets asks you to list accessibility needs, but does not invite people who may not feel emboldened to share that those needs will be heard and a good faith effort will be made to address them. Second, trying to be transparent where possible what the limitations of a Code of Conduct would be, for things like legal reasons. Third suggestion, ensuring that a transparency report is published after events to address issues that came up, to avoid toxic positivity and ensuring that there is a bit less second and third hand reporting.
  • There is an organization called CHAOSS (chaoss.community) to help with open source groups, including a knowledge base with metrics around public health and safety. They have a badging system that linux events are required to go through to organize.
  • We asked people with experience organizing events to put some of that experience and ideas on things that went right and wrong in a document for others to review. Having that documentation will help others to get ideas and practical knowledge on how to improve events. My idea is to create a group around having this institutional knowledge available as a resource.
  • The pandemic gave accessibility to Meetups in an interesting ways. There are no Meetups near me, and it is hardly the most remote place. We need to create an online experience as much as possible. If you have a Meetup and can stream it and share it, please do that.
  • We have an aging contributor pool and we need to think about how to expand it to include younger contributors.
  • We need to address other things beyond just community events, such as having onboarding available in multiple accessible formats, and they are not yet. If something is available in only one format, we need to make sure that they are available in other formats to ensure that we have different contributors eventually.
  • We could publish a menu guide at WordCamps to ensure that people can attend an event and ensure that everyone has some form of food that is protein for them. We cannot expect all organizers to know what fits for a vegan or gluten free diet as an example. We could include a template for adding menus on WordCamp sites.
  • I think that we can start with something simple and concrete for how individuals can contribute.
  • One thing that we talked about is what happens when people cause bad situations but we haven’t talked about what happens when team leads are the ones that are causing problems. When someone in leadership makes disparaging comments I have to decide to ignore it or tell people to try to talk about people in different power dynamics.
  • There should be a separate process for project leadership to address power dynamics. It’s a whole different way to be held accountable. It shouldn’t just be holding them accountable, but requiring that they go through extra education, to ensure that they know a bit more.
  • We can look to other organizations that have had to deal with things done by higher ups, and see what they have published and how they have solved problems. For instance, in the Drupal project.
  • The WordPress project intentionally keeps ticket prices as low as possible to make events accessble, and we don’t cut things like captioning when the budgets don’t work. We need to share the intention about how we spend our funds to ensure that sponsors see that and
  • Future community summits could have captioning to help when people cannot as easily hear speakers. We need people to speak slowly and project and not cross-talk. Can these be part of the guidelines of events, and add specificity.
  • As a teacher, a suggestion is that we can incorporate language like, “ouch” to say when people say something harmful and stopping to address it. Or “elmo” to indicate “everybody, let’s move on” when someone is going on for too long.
  • One thing that I’ve heard over and over is that, “they should already know” for things that things that we assume that people should know, but not everyone knows. I would rather that more is put in the handbook even if we think that people should know them, so that we aren’t put in the position of having to ask uncomfortable questions.
  • Sometimes it is hard to be the person to step up and say something even as an organizer. If you are an organizer, try to recognize when people are having issues or seeing an issue and stepping up on their behalf.
  • There is a dedicated 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, #deib-working-group on the Making WordPress Slack
  • How do we honor the very best of our community? What can we do to address the things that prevent that from happening. 
  • Belonging is a new word to this acronym. It’s great to have belonging here. Because once we invited people in, how do we sustain their presence. How do we make them want to be here?
  • The WP community can be an example for the world, as we are ahead of the curve in bringing people together.
  • The WP community has never made me feel uncomfortable or unwelcome, which is a first given many communities I’ve been part of. However, DEIB is a never-ending project, because there’s always more to improve. 
  • When talking about DEIB we also have to think about barriers. Access for everyone isn’t the same. And we need to acknowledge that people can be in the majority in one aspect, but in a minority in another way. 
  • India is a land of variety. Different cultures, different languages, different foods. The WP community is a kind of ecosystem. It’s adopted many people. Everyone can come in and contribute. 
  • This community is a very open community. There’s a place for everyone in our community. I feel I can do what I do, and be who I am in this community.
  • What we haven’t quite done yet in this community is pay attention to invisible disabilities or needs. 
  • We need everybody here. 
  • We should think beyond these flagship events. Where do we see the state of our online community? What’s the state of our local communities?
  • Local communities are disconnected from Make itself. As a meetup organizer, I see that many attendees are beginners in WP. They’re not even aware there’s a global WP community. Not everyone organizing events is aware they’re then part of a team.
  • If we’re touching about D&I, we have to talk about meetups and how we’re supporting meetup organizers integrate people into those local communities. 
  • Part of DEIB means making the WP community slightly less welcome to those who are not open to DEIB. So how we deal with bad actors?
  • I want to echo the disconnect between local communities and the Make project. One of the challenges there is the language. Not everyone can speak English. This language barrier brings up the next barrier. 
  • WordPress is very open to join, but it’s hard to stay for some. The belonging is not there. If something happens, we try to out-positive it. But we seem to think that with a Disney-movie ending, it will all be fine. But in reality, it’s up to the same people over and over again to fight this fight.
  • When there’s a bad actor, yes we need to educate them, but maybe we also need. People are afraid to call out their friends, but that is what’s needed to make things better.
  • Where does the COC apply, and where does it not? Where can regulate, and where can we only influence?
  • Everything is a learning moment. We should be working every day to improve ourselves. 
  • Most people who come to our meetups are mainly looking for help. Most of them are in a learning curve. So oftentimes we organize meetups that a basically a chit-chat, instead of doing a session. We also continue to tell people they don’t have to be a programmer. 
  • When someone is crossing a border about inclusivity, is telling them not to come to an event non-inclusive?
  • [General response] No. 
  • As an organizer, there was a prior attendee who made me and other feel physically unsafe. That made organizing very difficult. It was challenging at the time to get the support we felt we needed. It was disheartening that it came to the point where it needed to escalate to a physical threat via email before action was taken.
  • We have generations that didn’t spend the majority of their life on social media. It’s important to recognize that there is a generation that is completely influenced by social media.
  • We are in a situation where things that in the past were only said from behind an anonymous avatar online are now said in-person, due to changes in the cultural and political climate.
  • We’re a world-wide community, but we’re not dealing with the same laws everywhere. So beyond different cultures, we’re also facing different legal structures.
  • If you want to make the community more diverse, we have to respond to bad actors. We can’t let it go. We need to protect the people we want to keep in the community.
  • We do have a community code of conduct, that addresses both online and offline parts of our community. Sometimes it’s outside of the scope of what we (WP) can regulate. WP does have an Incident Response Team that’s handling COC violations within WordPress. make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//community/handbook/code-of-conduct/
  • Create more awareness for the IRT. 
  • Create list of things that make people feel unsafe/unwelcome. 
  • Create an inclusivity statement that we publish in our community to help people understand expected behavior. 
  • Create a (non-exhaustive) overview of the spaces where we can interact.
  • Have a transparency report from the event’s IRT in the post-event wrap up.
  • Learn from https://chaoss.community/.
  • Create resources to do better. For example an example vegan menu to help local organizers get that right.
  • Share the list of names of people who are on the IRT, to make clear to the community that it’s not just Automatticians. People from around the world are included and they’ve had “formal” training.

In the first half of the session we have mainly discussed the following. 

  • What is DEIB
  • Current state of DEIB
  • Potential improvement 
  • Collaboration & Support
  • Scope of a DEIB Team  

Key Points came out in the discussions are

  • WordPress’s growth continues. We are a very big team now. 
  • WordPress is a never ending project 
  • The WordPress ecosystem accommodates thousands of people from different backgrounds(like nationalities, languages, religion, cultures, politics, beliefs etc..) 
  • The Make WordPress project is also vast and has multiple tracks. 
  • We are a very diversified community. 
  • Because of diversity our each local team will be different & has many barriers 
  • Diversity will be different for each local team 
  • Our community represents multiple interests
  • WordPress is very open to join, we have to maintain that 
  • Therefore we need a team to take care of both
  • The biggest challenge is we have to make sure the community accessible to all 
  • The next generation is coming to the stage now. So we have to make sure a smooth generation change  
  • We have to welcome & open new people & ideas always 
  • The biggest challenge is accommodating new people & transforming them as contributors 
  • So the Sustainability of contributors matters 
  • Transparency in all actions are must for it 
  •  We have to consider the feelings of new & existing people
  • The community should be open to all and there should be any judgement based on their background 
  • We have work on the documentations to keep the resource live & easy accessible 
  • Because of language barriers we can consider of translating documentations 
  • Each one should be considered equally(not matter of gender & race) 
  • The local community should be connected with global community 
  • Meetup Organiser should make sure everyone’s voice is heard 
  • Document the meetups if possible 
  • Everything is a learning moment. So support the people & their ideas around with kindness and tolerance 
  • We are living in a era of extremism so we have to consider the people with equality 
  • It will be great if we can consider digital code of conduct. It will be more helpful for the people
  • We can also regulate the code of conduct often 
  • We are from different continents & countries. So may have to consider the localization of the code of conduct with extra attributes/terms   
  • We should start to train the people about the code of conduct 
  • Clear & easy guidelines for the newcomers specially 
  • Global & local team to monitor and take actions if any incident happens 

Actionable Items to improve DEIB 

  • All should feel as more welcomed
  • Events should be more aligned to DEIB
  • Looking for make our work(contribution) more sustainable 
  • Raise more awareness & committee/team for code of conduct
  • We have to take care of disabled people, their requirements will be different. Encourage participation & contribution from them
  • Keeping an ongoing list for people from all backgrounds(Organiser, Volunteers & participants). It will welcome & encourage more people
  • Local communities face different legal issues. A legal handbook to refer for the working group
  • Create advocacy and allyship. Classes for organisers 
  • Educate, meetup members & conduct workshops. 
  • Transparency & inclusivity statement
  • Have a form people can fill our(even anonymously) 
  • Ageing(balance between ageing contributor & new one)
  • Incorporate wording that lets people to know that it is okay to ask for accommodation on form 
  • Transparency around what can & cannot be done 
  • Transparency reports around issues to clarify and avoid rumours 
  • Publish official responses
  • Checkout documents the other organisations have already created and adjust accordingly. Example for those documents are Drupal & https://chaoss.community/ 
  • Create online experience as much as possible 
  • Make information/meetups available through more than one format 
  • A menu guide for WordCamps 
  • We can be friendlier & more open as a community. Proactive with other community members also 
  • A separate process for the higher leadership
  • Training for the leadership
  • An open forum to speak, report regardless of the level of leadership 
  • Setup as an organiser
  • A WordPress Language 
  • Add as much info as needed more to the handbook 
  • WordPress events are budget events. We have to keep the sponsor aware about this 
  • Budget Transparency 
  • Text capture in next community summit 

#summit, #summit-2023

Community Summit Discussion Notes: Improving maintenance of older default themes

Title of Session: Improving maintenance of older default themes

Facilitator: @desrosj

Notetaker 1: @mikachan

Notetaker 2: @zoonini

From the session schedule:

Recently, there was a proposal to retire some old default themes. In response concerns were raised around how to do so. This discussion aims to explore how to maintain older default themes in more sustainable, streamlined methods.

Key Points

  • Concerns raised around breaking the promise of supporting all default themes forever, just like we do for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
  • Can we write an underlying framework to help support all themes?
    • They’re all so different so may be difficult to build a framework to support all of them. It could be a lot of work.
  • Older themes are an educational resource for theme developers. By maintaining older themes we are educating developers on how to update their own themes.
  • The burden falls on the Core team to maintain themes. Original theme authors often get re-assigned or leave the project.
    • How can we help spread the workload?
    • Can we onboard more people to maintain themes?
    • We have already tried having a default theme maintenance team. This has previously been a burden; 20xx themes are a burden to maintain. 
  • Why is there only a default theme lead for the last version of the year?
    • Why not each release so updates can be bundled in each release? 
    • Used to have a Theme Wrangler for each release but this dropped off.
  • More docs needed for default themes.
  • Using the default theme to showcase new features makes it difficult for backwards compatibility.
  • Does it have the same impact if we make all default themes 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. themes?
  • Is there a world where we could make all default themes as light as possible?
  • Default themes can be updated outside of the release cycle. Could we introduce a regular cycle of updating default themes? Theme cycle vs release cycle
  • What about designing a method of testing older themes for each release?

Action Items/Next Steps:

  • Explore moving default themes to 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/ (with sync to SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/.)
    • Pick the most critical issues from tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. to move over
  • Consider having a Theme Wrangler for every release
  • Explore creating style variations and patterns based on past default themes, as a way to blockify the older themes
  • Explore setting up visual regression testing for default themes
  • How do we improve the feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. from people building themes in GB?
  • Improve default theme docs

Raw Notes

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Refining Five for the Future For a Robust WordPress Community

From the session schedule:

The Five for the Future (“5ftF”) program can help ensure the long term health of WordPress’ contributor pipeline. To make 5ftF as effective as possible, strong participation from 5ftF companies and project-wide understanding of Make Team needs and priorities is required. As such, this discussion will focus on two related topics:

  1. How we can more readily identify priority needs and opportunities and match them to 5ftF contributors.
  2. How to incentivize and facilitate further participation to the 5ftF program.

Facilitator: Jeff Paul (@jeffpaul)

Notetaker: Kim Coleman (@kimannwall)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: Building trust in WordPress CMS and plugin security

Community Summit Discussion Notes

Title of Session: Building trust in WordPress CMS and 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 security

Facilitator: Peter Wilson

Notetaker 1: Ryan McCue

Notetaker 2: Weston Ruter

Notetaker 3: Jason Coleman

Key Points

  • Communication of security practices:
    • Organization
      • The security page on WordPress.org needs to be refreshed with a clearer message – this will benefit WordPress from an external perspective, and can be a jumping off point internally too
      • This can point out to the various handbooks (security, plugin, theme, hosting)
      • The whitepaper is also heavily out-of-date and needs refreshing
    • WordPress as a project should be “owning” the security conversation, rather than leaving to third-parties
    • Documentation can be improved, but is “passive” – active communication (i.e. marketing) must also take place. Other teams (docs and marketing) are able and willing to help if the raw communication is available, and can share some of this communication burden.
  • Responsibility and ecosystem:
    • WordPress decided to provide plugin functionality, so must take responsibility for the security of it – we cannot say that this is the ecosystem’s problem alone to solve
    • The ecosystem is broader than just the .org repository, so security cannot be “controlled” through the repository alone
      • Tools such as scanners could potentially be built into WordPress itself, mirroring operating system virus scanners eg
      • A “safe mode” could be added to disable all plugins (eg), but this is often one of the first things to be bypassed – external tools (such as those operated by hosts) are likely to be a safer way to achieve this
    • Tools are available to the ecosystem (autoupdates via the plugin team, eg) but awareness of these is low. These are available for authors of non-trivial usage plugins (e.g. something like 20k+ installs would be a workable threshold)
    • Documentation exists around how to write secure code, but there isn’t sufficient or sufficiently-known documentation on procedure of how to deal with vulnerabilities, how to issue security releases, and how to communicate
      • Make it clear to ecosystem authors that vulnerabilities will happen, and destigmatize the process
      • A “what to do if your plugin has a vulnerability” guide could bring this information together
    • Documentation needs to be clearly findable and approachable for the ecosystem, and can tie in to the refreshed page

Action Items/Next Steps:

  • Refresh the .org security page
  • Refresh the security whitepaper
  • Write documentation on procedure for dealing with vulnerabilities

Raw Notes

Continue reading

#security, #summit, #summit-2023, #wpscan

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: Ad hoc session on iterating on the Field Guide

This was a follow-up session over lunch building on the backwards compatibility session.

Date: August 23, 2023

Attendees: @ellatrix @mcsf @ndiego @clorith @bernhard-reiter @timothyblynjacobs @jorbin @priethor @annezazu @richtabor @gziolo. Everyone consented to being listed here since it was an ad hoc session.

Notes

History of Field Guide

Around 3.2 – 3.3, there was a field guide around backwards compatibility from Nacin. Around RC1, having an email to 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 developers came up and the email that was created was too much for an email, resulting in a post published on Make. This evolved to become the Field Guide process after being well received by the community. It has since grown in length every single version. When looking at a visual comparison, it is now 6 times as long in length just to look through, making it harder to scan.

Questions to frame the conversation

The following questions were used to guide and frame the conversation:

  • How can the content of the Field Guide by reformatted to improve developer messaging?
  • Is the Make blog the right channel for this resource for folks to engage with?

Developer blog discussion

Developer blog is relatively new and right now anyone in the community can contribute to it. It’s a small group of folks currently along with a monthly “what’s new” roll up that could be expanded and built upon. The original idea of the developer blog was to cut through the noise and provide valuable resources to extenders. This then reserves the Make Blog for folks who make WordPress. There’s more of a process with the dev blog currently that might make it trickier to stick to.

Information spread out

When googling for features or updates, there’s a confusing experience where what comes up could be something from 4-5 years ago rather than linking to documentation. This is due to posts being shared on Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that then start getting linked to and shared, causing the weighting of that post to go up and the first hit on Google is a dev note rather than documentation. We might need to return to dev notes after docs are updated to link to documentation as a way to redirect folks to the latest.

Specific to dev notes, there’s also an issue of dev note being a form of documentation and acting in place of documentation rather than “here’s what’s breaking”. Right now, dev notes are both acting as docs and breaking changes basically. 

If you go a step further to look at 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 handbook docs, it includes a mishmash of content. Work is underway right now to ensure learning/tutorials get into Learn WP and documentation remains in docs. Docs in general though are scattered in official blog posts, unofficial blog posts, dev notes, dev handbook, user facing docs, etc. It’s not necessarily bad that it’s in so many places but are things going to the right places or are things getting missed? This comes down to even basic formatting changes like labeling things as “breaking changes” or having a dedicated section for breaking/high impact changes. Right now, it’s broken down by component rather than priority for the Field Guide.

Content reformatting

When thinking about the format and approach of the Field Guide the following questions were thrown around when thinking about the persona of a person using the Field Guide: Are there big 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. changes to inform customers about or update plugin around? Are there things that might break and what do I need to do about it? What are the big things in the release? Where can I get more information? This led to an idea of two Field Guides with different approaches:

  • A hyper focused version with more curated info. 
  • A longer, more robust version. 

Right now, separating out a curated source requires a level of expertise to determine what’s most relevant that isn’t widespread in the project.

Pain points in getting early feedback from extenders

We talked about the general process before a release and getting folks to test, give feedback, etc as part of the broader process of sharing dev notes. Before a release, there are alpha/betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. forums where you can get some feedback but it doesn’t often go anywhere. Developers are more likely to use TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. and 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/ so we can point them more in that direction to get feedback. In general, getting devs to beta test or RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. test is very hard. 

Iframing the editor example

To ground the conversation in a specific example, we talked in depth about work around iframing. For some plugins, they didn’t reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. because they felt there would be a fix in the future for iframing rather than taking action and reporting something on. We can’t make changes if we don’t know about the feedback though!

The WordPress Developer Blog would be a good way to surface issues like iframing and go in depth about ways to overcome different pathways for adopting. If this effort is backed up with documentation, it could help cover the big, breaking topics nicely.

We went on a bit of tangent around how we could use Site Health with lack of iframing to help encourage folks adopting. In general, for larger changes like iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., we need to think of communication plans as part of the effort. For iframe, every situation is quite different so it’s tricky to get right. Developer Relations should be able to help here. DevRel is tricky within 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. since it’s typically going to have to be sponsored by a company, which then brings in bias and questions around motive for amplifying certain changes. At the same time, we need folks who are doing the outreach and engaging.

Motivation to adapt to changes

Part of what has to be considered is what the sell is to update things, especially if there aren’t clear benefits. This can be metered against having things in Site Health that informs users that plugins might not be doing their work to keep up to date. Having warnings could help encourage better practices and have folks address problems. The more we can make it visible, the more it will reinforce updating.

Deprecation strategies

The topic of deprecations came up: When we deprecate something, when does it get removed? We should look at timeframes for figuring out how best to handle and communicate. This can be tough for implementors and has been in the past when things are changing so fast. This came up when the 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/ plugin first came out and work was done to encourage folks to build with it while things were also changing so quickly. This led to some mistrust and frustration. We still have things from 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. from 0.7.1 that we deprecated but didn’t remove so this is a larger problem. Some inelegant solutions were thrown around before focusing back on the main topic of communicating and the Field Guide.

Documentation and Dev notes

Dev notes in general are rough to find and some of this could be improved with WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ website redesign. Dev notes should feed documentation that gets regularly updated and maintained. We talked about application passwords work where the info is only in a dev note rather than in docs and how that’s a problem. 

A more limited set of folks can write documentation places but it’s fairly open to write on the Make Network. For developers, it becomes easier to just do dev notes rather than helping with docs. The documentation team should be able to handle these doc updates from dev notes though. The docs team has a repo where you can create a ticket and they can handle changes, except for the block editor handbook which is handled on GitHub. In theory, a step could be just to create a GitHub issue of the dev note changes and have those docs updated.

Timeline of dev notes

We talked about how dev notes require submissions by a certain timeline but, in truth, things get done throughout the release sometimes as late as RC4. At the same time, dev notes are useful for comments/feedback and iterating on the messaging. If the updates were moved straight to docs, you would miss that engagement and opportunity to do better.

Next steps: 

  • Propose that the responsibility of docs lead could be to help ensure dev notes get into dev docs. 
  • Update dev notes after when docs are updated to help with SEO problems. 
  • Go through dev note tracking issue (example) in GitHub for priority/sense of breaking changes and explore the idea of having a dedicated “breaking changes” section in the Field Guide.
  • Explore the idea of two Field Guides: A hyper focused version with more curated info & a longer, more robust version. 
  • Do a theme author email similar to plugin author to communicate breaking changes. 
  • Re-think dev notes and see what can be evolved in the handbook since the first introduction. 
  • Create a pattern for dev notes to create more consistency and ease of writing. 
  • Ship dedicated developer blog post for breaking changes that get deeper into the changes. 

#summit, #summit-2023

Community Summit Discussion Notes: Unifying development tooling for contribution

From the schedule session:

Today, the local development tooling for contribution to WordPress is fragmented. Contributors use tools such as VVV/Vagrant, Docker, and Playground, but each have limitations and may not be endorsed for contributions. Additionally, some tools require specific set ups, making it challenging for contributors to get started. This discussion will explore how we can unify tooling to provide clarity around recommended tooling and process for contributors.

Facilitator: Aaron Jorbin (@jorbin)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Emma Sophie Young (@emmaht)

Continue reading

#summit, #summit-2023

Community Summit Discussion Notes: What is the criteria for delaying the upgrade of foundational tech, and what triggers reconsideration?

From the schedule session:

From time to time, it’s necessary to delay adoption of newer versions of our underlying technology, either because our software isn’t yet fully compatible or we otherwise cannot recommend the use of the new technology. This is an appropriate measure to take when we are thinking through the promises we make to our users, but what should be the acceptance criteria for reconsidering a delay?

Facilitator: Marius L. J. (@clorith)

Notetaker: Weston Ruter (@westonruter)

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