When the Make WordPress network was created back in 2012, every team that existed at the time got its own blog to use for transparent communication, collaboration, and coordination. An Updates blog was also created to be a place each team could use to report on their activity to other teams, and beyond.
The number of contributors and teams has grown in the nearly-ten years since, along with the user base of WordPress itself. As organizations expand, more coordination and communication work becomes necessary to keep everyone connected and working together. We’ve always used the Updates blog for this, because it was our only contributor-focused, cross-team space.
As more contributors get involved in cross-team efforts, I have heard complaints that it’s distracting or confusing when the Updates blog is used for announcements (like this one) and discussions (like these).
The last thing that I want is to create confusion or distract from the way teams keep each other informed, so I think the best solution is to create a new blog for all-project communications and cross-team collaboration. This blog should make it easier to host and find discussions that affect all teams, and make WordPress project “back-office” work more transparent.
This blog is not associated with any one team but rather with all the teams, and may be used for topics ranging from short-term initiatives to long-term maintenance work. User permissions will be closed-selection, with the list of people who can author posts listed on the sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. Since the work accomplished on this blog exists across all teams, contributions won’t receive an additional profile badge. Once the work on make.wordpress.orgWordPress.orgThe 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//project feels more settled, we can all take a look to see if a specific badge is needed.
P.S. – From an open sourceOpen SourceOpen 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. perspective, this idea might sound pretty “business-y.” A simpler explanation might be that this is similar to the work done by our MetaMetaMeta 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: creating and maintaining the tools, infrastructure, safety, and processes that make contribution possible and more successful.
To keep everyone aware of big projects and efforts across WordPress volunteer teams, I’ve reached out each team’s listed representatives. I asked each of them to share their top priority (and when they hope for it to be completed), as well as their biggest Wins and Worries. Have questions? I’ve included a link to each team’s site in the headings.
Priority: Getting the minimum accessibilityAccessibilityAccessibility (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) requirements for GutenbergGutenbergThe 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/ done prior to merge. ETA is before 5.0
Struggle: Would like better accessibility knowledge/awareness in the project (here are a few training options for those who want to learn more)
Big Win: A lot of support from the community to make WordPress as accessible as it can be. All the designers, testers, a lot of developers and team leads are making an effort.
Priority: New major version v2.0.0 which restructures the packaging system to improve the developer experience (especially contributor on-boarding). ETA is beginning of July.
Struggle: Assembling a larger team of regular contributors/committers (which informed the team’s priority).
Big Win: Version 1.5.0 released at the end of January was full of useful new features and bug fixes.
Struggle: Getting into WordCampWordCampWordCamps 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. season and there aren’t a lot of mentors to support event organizers
Priority: Gutenberg polishing and GDPR preparations
Struggle: Timelines are in flux, but the new editor is getting into refinement phases. GDPR is being coordinated among a number of teams, so that’s taking significant time, but the next steps are clear.
Big Win: Got a number of new contributors to help lead releases. A few debrief posts about learnings and possible improvements are coming.
Priority: Team building, empowering designers to contribute, and continued focus on supporting CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
Struggle: Making the path to contribution clearer (no designated tasks for designers to perform and contributing through TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets is very technical/can be overwhelming).
Big Win: A bit of new involvement on the Design team and some partnering with people on other teams as well.
Contacted: @kenshino Priority: Releasing HelpHub (background: https://make.wordpress.org/docs/2018/02/26/state-of-helphub-february-2018/) by May 30. Struggle: A lot of work is short term or project-based, so it’s hard to keep volunteer engaged over long periods of time
Struggle: This is a newer team without a lot of dedicated time to put to it.
Big Win: Grew list of hosts running distributed automated tests to 9. This now also keeps track of the WordPress.orgWordPress.orgThe 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/ TravisCI setup, and automatically emails hosts if tests fail on their setup but are passing on WordPress.org’s Core TravisCI. Read more here: https://make.wordpress.org/hosting/test-results/
Priority: Preparing for an increase in Gutenberg support (due to the potential callout, and 5.0 itself)
Big Win: Have been providing new workshops recently, focusing on various parts of support, as seen from various pluginPluginA 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 and theme related perspectives and roles.
Priority: Finish audit and updates to lesson plans. ETA is May 2018
Struggle: Onboarding to new systems, but there are some trainings planned in the near future.
Big Win: Moved lessons to GitHubGitHubGitHub is a website that offers online implementation of git repositories that can 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/
During 2020’s State of the Word, Matt reminded us of our overall roadmap for GutenbergGutenbergThe 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/. Much of that roadmap is on a multi-year timeline, and it can be hard to know what’s next with such a distant North Star. This post contains some near-stars for the year, but there are some things you should know before you read them.
These are intentionally broad
There is more to WordPress’ success than the code we write, or the open sourceOpen SourceOpen 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. freedoms we share. While the goals below are focused on shippable projects, I understand that there are supporting contributions (translations, testing/triage, accessibilityAccessibilityAccessibility (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), support, etc) that are part of these project goals.
These are intentionally incomplete
There are always small projects that arise over the course of our year. And there are big projects that we move forward in pieces over the course of multiple years. This project is too big for me to see everything all the time, and I rely on the information from team reps and the vision from project leadership to help navigate any surprises.
Just because a project isn’t written here, doesn’t mean it is forgotten or has no value to our overall success.
The Big Picture
Full site editing: Bring into the Gutenberg pluginPluginA 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, and subsequently WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., the ability to edit all elements of a site using Gutenberg blocks. This will include all in-progress features designed to help existing users transition to Gutenberg as well. Scope/Timeline: MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia in the plugin by April 2021, v1 in Core by WordPress 5.8.
LearnWP: Enable WordPress skills-leveling by providing workshops, pre-recorded trainings, and self-serve learning opportunities on learn.wordpress.orgWordPress.orgThe 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/. Scope/Timeline: regularly publish new workshops and lesson plans, maintain a high pass rate on workshop quizzes to establish learner success and comprehension.
Contributor tools: Decrease the manual overhead of maintenance work for teams through better tooling. Scope/Timeline: Varied, and pending additional testing.
How can you help?
As I mentioned above, I know that our code isn’t the only measure of our success. If you already know what sort of contribution you’d like to make, you can check out this list of teams (with links to their community sites) and team reps. If you’re not yet sure, here are the areas that each team falls into:
Development, Technology, Code: Core/Editor, Mobile, CLICLICommand Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress./Tide, Security
Design, Product, UXUXUX 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./UIUIUI 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.: Design, Accessibility, Test, Triage
Community, Extending WP, Education: Community, Themes, Plugins, Polyglots, Training
Contributor Experience: MetaMetaMeta 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., Docs, Hosting, Privacy
Communications: Marketing, Support, WPTV
A Note on Specialized Groups
There are a couple of coordinated efforts that provide essential support to the progress of multiple teams.
Triage: The triage effort happens across multiple teams and has two purposes. One purpose is to make sure tickets are sorted and have all the elements needed for someone to work on them. The second purpose is to determine priority. Not everyone has the information to set priority, but anyone can help sort and replicate reported bugs!
Test: The testing effort also happens across multiple teams and has two purposes. One purpose is to try out features before they get to our users. The second purpose is to bring high quality feedback into our process early. A lot of that coordination happens on make.wordpress.org/test, but there are also frequently calls to participate on make.wordpress.org/core.
I’d like to start an experimental channel for all WordPress team reps to collaborate in. It would be set up very similarly to #core-committers and #5-8-release-leads where it’s open, but posting is requested to be limited to team reps.
Some Background
Many contributors (whether they were team reps or not) have suggested this over the years and I have been strongly against it every time. I worry that it will create a new silo, that it will cause team reps to stop reaching out to one another directly, or that it will somehow create a feeling of “exclusivity”.
But given the way our project has grown and the way the world has changed how we do things (learning/working/living moving increasingly online), I feel it’s time to give the channel a try. Like the last couple of coordination channels I’ve created, I have some thoughts on what the expectations should be:
All team reps will be included in the channel by default.
The primary goal is ease of collaboration, not private decision-making conversations.
The channel can be used by team reps for cross team collaboration or hand off.
The channel can be used by me (though I am not a team repTeam RepA 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.!) to share important information and also to check in with everyone more easily.
Do you have feedback?
I’d love to hear your thoughts. Let me know what you think in the comments below! Discussion is open through May 28, 2021. 🙂
Many people find that the structure of the WordPress community is ambiguous. While there are Team Handbooks that address contributors, the way different groups influence and support each other can be unclear. The duty of care is the responsibility of one group to avoid decisions that harm another group in an organization.
I learned about this interesting progression of care and influence recently from Josepha Haden, and wanted to share what I thought was a brilliant way to communicate this. She explained it to me and a group of other contributors, by showing us this flow.
Like all great sticky notes, there is no clarity without explanation. I would like to shed some light on my understanding of how the WordPress community works, and see if these ideas resonate for other people, the way they did for me.
The five sticky notes above are the 5 groups of people within the WordPress ecosystem.
Visitors
Users
Extenders
Contributors
Leaders
Duty of Care
Examining the graphic below, the duty of care from the left extends to all groups to that particular group’s right. For example, an extender exhibits a duty of care toward both the users and the visitors while a user’s duty of care is primarily toward just their visitors.
Levels of Influence
Each group directly influences those adjacent to it via feedback loops and meeting their needs. Groups to the left influence groups to the right, while feedback from the right directs what is needed from groups to the left.
For example, a WordPress user is affected by both visitors and extenders. Imagine a content creator that shares their passion for photography through a WordPress website. This photographer may have visitors that need to purchase photos. In response, the user now has a need to make it possible for visitors to purchase photos on a site.
The extenders build the pluginPluginA 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 that supports the need.
The user installs it on their site.
The visitors can now purchase photos.
The groups
Visitors
Visitors are the people that arrive at a WordPress site to gain information or engage in an activity. These people may not be aware of the groups, or even that they’re using WordPress, but they do care about their task at hand. Their needs can directly influence the user’s website.
Users
Users are people who use WordPress as their CMS. These range from website builders, to website designers, to small businesses, or content creators. They are affected by their visitors, and care about what happens when people visit their site. Users are also affected by the extenders, who build things that add new functionality to WordPress.
Extenders
Extenders include those who extend WordPress through the creation of themes, plugins, blocks, and more. They are also people who teach WordPress to others through WordPress podcasts, newsletters, and tutorials. The WordPress ecosystem is enriched by a large number of extenders.
The extenders are affected by both the users and the contributors. Users determine the value of their plugins and themes. Contributors directly impact their work by creating/maintaining the CMS and providing ways to distribute quality extensions, like the plugin or theme repositories. Extenders also care not only for the users, but also about the users’ visitors. Extenders know their product’s success relies on both the WordPress user and the website visitor. Extenders also benefit from the success of the WordPress platform.
Contributors
Contributors are the people who contribute to the open sourceOpen SourceOpen 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 (OSS) and the infrastructure that supports the project. These include WordPress.org contributor teams and other volunteers who give their time to the project itself and not necessarily just the extended ecosystem.
Contributors are affected by both the extenders and project leadership. The extenders’ needs are often considered by the contributors, for example with regards to backward compatibility and enabling 3rd party integrations. Project leadership influences the contributors by communicating vision and future goals for the project.
The contributors make decisions that demonstrate their care for each group to their right: the extenders, the users, and the visitors. If they did not care about the visitor, they would build software that would not help users meet their goals. If they did not care about the user, they would build software that lacked an ecosystem, because no one would use it. If they did not care about extenders, they would not build an extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software. product.
Leaders
Leadership is a very small group. It includes currently Matt Mullenweg (Project Lead) and Josepha Haden (Executive Director). These two help drive the vision and strategy for WordPress.
They both are directly affected by contributors, because the contributors are the people building and maintaining WordPress, and the community surrounding it. Project leadership relies heavily on the ability and skills of the contributors to ensure the project’s goals are met.
Project leadership carries a duty of care that encompasses every level of WordPress. They work hard to avoid decisions that explicitly harm the other groups. No doubt there will be people who will be affected negatively by a decision, but the decisions at this level are made to support and benefit the majority.
Moving through the groups
Because these group relationships can be ambiguous, it is often unclear how people move between them. In fact, moving between the groups often happens unintentionally, and as the result of expressing more care toward people within one’s own group.
One example is the move from extender to contributor. An extender primarily cares for their own extension product (ie. a plugin), which benefits their users and visitors. At some point, an extender might run into an issue, or innovate on a solution, that can help all extenders. By sharing this solution with contributors and helping to implement it, the extender contributes to the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. software, resulting in a better experience for all other extenders. Their level of care expands through their desire to contribute in a way that benefits others.
Users often become extenders when they can not find the extension that suits their needs. The user, when a solution is not provided by existing extenders, might decide to create their own extension (ie. a plugin) to meet their need. When the user shares their product, they have just become an extender, and their level of care expands to include all other users who might find their product a necessary solution for their own sites.
Overall, WordPress group dynamics generally depend upon the duty of care and levels of influence. The more one cares about other groups, and those in one’s own group, the more likely that person will influence the community in a positive way.
What do you think about this theory of how different parts of the WordPress ecosystem connect and relate to each other? Does this description sound mostly right to you, or do you have an experience or perspective that conflicts with this set of ideas? I’d love to know your thoughts!
To keep all aware of big projects and efforts across WordPress volunteer teams, each team’s listed representative has shared an update from the start of the year. Listed below are their top priorities, as well as their biggest Wins and Challenges. Have questions? I’ve included a link to each team’s site in the headings.
Previous Priority: The main focuses of the AccessibilityAccessibilityAccessibility (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 for WordPress 5.6 were:
Moving the WordPress Accessibility Coding Standards from WCAGWCAGWCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.0 to WCAG 2.1 and improving the documentation to include more resources and describe patterns and antipatterns;
Making the new default theme (Twenty Twenty-One) ready for WCAG AAA;
Creating a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. to add a tool to generate an Accessibility Statement, as was done with Privacy Policy;
Checking the accessibility of the new widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. screen in GutenbergGutenbergThe 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/.
Priority: The team’s focus is to keep a closer eye on Gutenberg in general and on Full Site Editing in particular and to continue work on documentation and accessible patterns.
Challenge: The team continues to be challenged with onboarding new contributors so that more people can be involved and get to actively contribute more quickly. In addition, keeping up to date with Gutenberg development, the blockBlockBlock 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 evolves too quickly for the team to cope with it: dedicating a release to fix its accessibility issues instead of adding new features would probably be beneficial to make it really usable for everyone.
Big Wins: The creation of working groups inside the team helped in keeping better track of accessibility issues across the project. The mood of the team is high: the environment has been more welcoming, some new contributors joined the team, and collaboration inside and across teams has improved.
Previous Priority:Our goal is to provide automated PHPPHPPHP (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. http://php.net/manual/en/intro-whatis.php. Compatibility reports for every theme and pluginPluginA 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 in the WordPress.orgWordPress.orgThe 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/ repository and the infrastructure needed to create other types of reports once we have a stable version 1.0 of the Tide APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
Priority: The team is currently working on getting a release out for the WordPress/Requests library; all necessary changes were completed, and only a few updates to the test suite are missing. This release is the last remaining blocker for WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/ 2.5.0, which should be deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. shortly after WordPress/Requests v1.8 is pushed.
Big Win: After a lot of back & forth with the testing pipeline regarding Travis and PHP 8, the CLICLICommand Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. team is now at the point where the entire test suite has been redone and ported over to GitHubGitHubGitHub is a website that offers online implementation of git repositories that can 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/ Actions (including the automated deployment), and all the bundled packages pass all of their tests successfully for PHP 8.
Priority: Checking in with our Community Deputies and Mentors to see how we can support them and their contributions to the team. Last year the deputy and mentor workload dropped drastically because of event cancellations. That’s why some deputies and mentors might not be up-to-date with all new practices. The Community team is investing in training and activating deputies and mentors to bolster our support of the global community, with an eye towards the end of this year when a larger amount of in-person events are hopefully possible again.
Challenges:
We still need to find greater ways to support WordPress contributors, users, and events online.
Determining when and how it is safe to return to in-person WordCamps.
Getting the team, contributors, and program ready for a greater return of in-person events after a long break.
Set up WordPress 5.8 according to FSE go/no-go decision.
Ship WordPress 5.7.1, which contains several fixes for 5.7. Set up the next 5.7.x iterations.
Find new coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. committers and new component maintainers.
Challenge: The team struggles with working with a small number of core committer and component maintainers.
Big Win:
Shipped WordPress 5.7!
Week in Core blog posts shows that more and more new contributors are joining.
Previous Priority: The team is focused on moving old TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets and PRs forward.
Priority: To initiate an APAC-Friendly Working Hour.
Challenge: The team is catching up with FSE and other relevant components of the releases.
Big Win: The Design team’s engagement with new contributors added to the Team for Note-taking and other focuses.
Previous Priority: To develop an overall documentation information architecture; improve discoverability & usability on all documentation; Refine the “getting started” processes (video and text) for onboarding of contributors; apply the external linking policy in Plugin Developer Handbook; Google Season of Docs projects.
Priority: Applying a new style guide and external linking policy to existing documentation and improving UXUXUX 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. for end-user documentation based on new designs. The team is still refining the “getting started” processes (video and text) to onboarding contributors. Finally, we will begin documentation on Full Site Editing as soon as possible.
Challenge: Some challenges the team is encountering include: tools and workflows are sometimes not working as expected and sometimes are overwhelming, which requires too much effort for small improvements; collaboration with other teams and keeping up with new features and releases; the pace of making decisions and responsiveness of team members when their action (opinions/comments) on p2 posts is requested.
Big Win: The team had a fair amount of wins: Google Season of Docs successfully finished project; Plugin handbook is being reviewed for external linking policy; communication with Full Site Editing team is slowly happening, and new designs for end-user documentation are nearly finished.
Previous Priority: Priorities included PHP 8 Compatibility for distributed hosting tests, helping inactive test reporters start reporting again, and improving the process.
Priority: The team’s focus is on helping inactive test reporters start reporting again, the first steps towards GitHub Actions. The team is also creating a new format called “WP Hosting Live;” it will be a global meetupMeetupAll 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. group focused on hosting professionals.
Big Win: Three big wins for the Hosting team: PHP8 Support for test runner, New Format “WP Hosting Live,” and new Team Reps.
Previous Priority: Continue to support the Learn WordPress resource; assisting Polyglots with materials to encourage and sustain contributions; establish a series of contributor introductory training sessions and ongoing work on contributor event marcomms materials; and training for team members.
Priority: The current priority is to continue to support Learn WordPress, Full Site Editing, and WPDiversity initiatives, provide communications support to Community’s newsletters, and plan with Polyglots ways to raise interest and awareness around key mini translation events around a central focus. Ongoing contributor event marcomms and joint working with WCEU and others. Maintaining support for new contributors and inclusion in the team.
Challenge: Sustainable contribution at a time of pandemic and its effect, identifying gaps and solutions relating to the role and benefit of marcomms within the project using available tools.
Big Win: Developing marcomms strategy and long-term planning for People of WordPress, ongoing internal awareness-raising on FSE and support to release teams, trialing inclusion measures for greater participation and to reduce access barriers, and enabling greater asynchronous contribution.
Previous Priority: Focus on handling incoming tickets faster, and maintain the overall level of open tickets.
Priority: To focus on handling incoming tickets faster while continuing our recently implemented component-specific focuses and maintaining the overall level of open tickets.
Challenge: There are many open tickets, often old, comprising mainly esoteric requests and feature requests for large and medium projects.
Big Win: The team updated the handbooks plugin to support importing content from a remote source (e.g., GitHub) and improved support for multi-handbook sites, which facilitated the implementation of the Documentation Style Guide and reorganization of the Block Editor Handbook.
Previous Priority: Port core blocks to reach 100% coverage on non-FSE blocks.
Priority: Mobile is focused on editor onboarding, porting core blocks, block picker improvements, dual-licensing Gutenberg to increase adoption and contributions, basic Global Styles Support, and adding the ability to add block patterns.
Challenge: Fixing regressions, some projects turned out more technically challenging than originally thought.
Previous Priority: The team’s current priority is to help identify struggles for contributors and work on resources or tooling to streamline the workload for under-resourced teams.
Priority: We’ve published Polyglots TeamPolyglots TeamPolyglots 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/. Plans for 2021 with three focus areas (improving translator/editor communication, promoting team growth, and clarifying the translation approval process).
Challenge:
The organizational structure of translation/adaptation for HelpHub, Learn, Marketing needs to be better clarified.
We have a high number of pending requests for new locales that need to be vetted and acted upon.
Previous Priority: The security team is preparing for a pending security release. There is ongoing work related to migrating older branches of WordPress to Github actions for automated testing, as Travis is no longer available. The team also has a proposal out to drop support for older versions of WordPress.
Priority: Right now, the team is shifting the release process to have a central person that manages all of the minor releases for each major version of WordPress; see more here. After completing the work to get automated testing working on each version of WordPress, all the way back to 3.7, we can now confidently release those versions with full test coverage.
Challenge: Working with security reporters on deadlines for known issues.
Big Win:@peterwilsoncc wrangling the 5.7 minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. process!
Previous Priority: To land actionable plans for forums landing page (done).
Priority:
To prepare for the site editing experience and expected increase in questions post-update relating to this specifically.
Improve the available controls for various user groups on the forums.
Challenge: Site editing preparations are not always easy before the feature is finalized. Maintaining the momentum of enhancements landing for support-related tickets outside of metaMetaMeta 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. focus sprints.
Big Win: Meta teams focused development time helped landed a lot of support-related tickets during Q1
Previous Priority:Our goal is to provide automated PHP Compatibility reports for every theme and plugin in the WordPress.org repository and the infrastructure needed to create other types of reports once we have a stable version 1.0 of the Tide API.
Priority: The team’s current goal is to finish documentation and testing of Tide refactoring to Node and integration with PHP Compatibility Checker plugin.
Challenge: There are a limited number of contributors with Golang experience to help with refactoring out of Golang to Node, but post-refactoring, the hope is more will be able to contribute with the codebase in Node.
Big Win: Partnership with WP Engine to help integrate refactored Tide endpoints to PHP Compatibility Checker plugin.
Previous Priority: The team introduced a sprint approach for 2021. Priorities for the first sprint included revising all team procedures/handbooks as a solid foundation, documenting how brands are represented on Learn, and evaluating options for slide presentations.
Priority:
Brand guidelines and options for slide presentations as well as those identified in our April sprint.
A high-level curriculum roadmap encompassing programming languages and build tools for those wishing to pursue WordPress-related development. This will help plan ongoing training materials on Learn.
Challenge: Personal issues and the pandemic have impacted the resources available this quarter to get the brand guidelines and tool for slides presentation drafted for discussion amongst the wider community. The team has done work on this and hopes to conclude this coming quarter as we have a lot of lesson plans that could be published once this has been agreed upon.
Updated the Training handbook and will continue to work on our procedure for getting lesson plans onto Learn WordPress.
Learn WordPress handbook has also been published, led by the Community team with input from the Training team. Both handbooks will continue to progress as we improve the way that we work.
Contacted: Jonathan Desrosiers (@desrosj) & Sergey Biryukov (@sergey)
Previous Priority: Limit the total number of tickets in Trac, and ensure that every ticket is accurate and actionable.
Priority: Continue to bring the total number of tickets in Trac down to a more reasonable number and/or ensure that every ticket is accurate and actionable (especially really old and really new tickets).
Challenge: The main team members have had their resources consumed by a combination of various active roles in recent releases, overarching project tasks (migrating automated testing to GitHub Actions, etc.), and new contributor mentoring. An additional challenge has been striking the right balance between documentation (to better allow other contributors with much less time to contribute to the overall goal) and action (performing triage efforts ourselves).
Priority: Collection of the WordCampWordCampWordCamps 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. videos from organizers for publication and to correct the speaker’s name and tags of submitted/ published videos.
Previous Priority: Collection of the WordCamp videos from organizers for publication and to correct the speaker’s name and tags of submitted/ published videos.
Challenge: The lack of volunteers who can work with us is a present challenge.
Big Win: The team submitting subtitles for videos.
With thanks to team reps for their quarterly updates.
Full site editing is where the promise of GutenbergGutenbergThe 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/ gets proven—the technical aspects meet the philosophical aspects as a user-focused tool meant to empower the user to create, and express, and sustain themselves online. Community readiness should be higher for full site editing than for the blockBlockBlock 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, but there are known (and unknown) gaps in knowledge we still need to bridge.
The following is an outline of the communication work needed in the pre-merge period for Phase 2 of the Gutenberg project. This will put us in a position to merge Full Site Editing later this year while raising awareness and increasing the skills of our community as we go.
Some Context for Where We Are
Phases of The Full Site Editing Project
2019 – Throughout 2019, Gutenberg project leads explored the necessary interactions and potential technical implementations of full site editing.
2020 – Early in 2020, technical leaders (Matias et al.) worked publically on full site editing based on the learnings from 2019.
2020 – Throughout 2020, CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developers built and refined full site editing tools and interactions.
Apr/May 2021 (ASAP) – Finalize teams for WordPress 5.8
Jul 2021 – WordPress 5.8 release and follow up iterations
Communication of This Project
As in the pre-merge time period for the block editor, there are four genres of content to provide:
Updates and progress content to WordPress contributors—all contributor teams including theme and pluginPluginA 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 authors—so that there is confidence in the process.
Where – SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., Make network, WordPress.orgWordPress.orgThe 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//news/, social media, events
Training and explanation content to WordPress users—end users, agencies, theme authors, plugin developers—so that there is confidence in exploring full site editing.
Where – WordPress.org/news/, WP publications (newsletters, blogs, podcasts, etc), events
Aspirational and inspirational content to WordPress users’ and their clients—site maintainers, account executives, business owners—so that there is confidence in choosing full site editing.
Where – WordPress.org, WordPress.org/news/, events
Awareness raising and broadcast content to the WordPress users outside the contributor community—new users, users who aren’t aware of the community, etc—so that there is confidence in the choice of WordPress as a CMS.
Where – WordPress.org, WordPress.org/news/, events
The Communication Work Ahead
Who Communicates and What Do They Share?
We’ve got a lot of excellent voices ready to help us share important information, as well as many who can help promote and disseminate it. I want to make sure that we can identify which type of content is most important for each group to create or share. (Note that some people can/will float from group to group, depending on the context.)
Leadership
Who – Project lead, Executive Director, technical and product leads.
Message – Clarify the project’s North Star; the “why” behind the vision. Remind what we stand to gain, and the short-term wins.
Product
Who – Design, development, and others who are at the front of defining what blocks are and how they improve WordPress.
Message – Share what is changing. Remind what’s at the end of this journey, wayfinding footholds, and clarify where we are in the journey to Full Site Editing.
DevRel
Who – Community voices that developers look to for updates, training, and general Gutenberg insights.
Message – Training and awareness among our various developer communities, and testing/feedback between “co-developers”/users and product folks. Remind where we are in the journey to Full Site Editing.
Marketing
Who – Further the existing messaging with the tools and experience marketing folks can offer.
Message – Raising awareness about Full Site Editing.
Known Challenges
Here are a few things that might make this communication more difficult. If you can think of other communication challenges (or solutions to the ones below), please share them in the comments!
We don’t have established communication channels with theme and plugin authors.
Communication on the Make network, Slack, and WordPress.org/news/ is only in English, and there are no established methods of translating non-English language feedback for Core designers and developers.
Since the last update, the Make WordPress Global Design Team met on Tuesdays at 16:00 UTC for the Weekly Trige and on Wednesdays at 18:00 UTC. This post contains the update for Design Team between the dates 17 March and 16 April 2021.
Edit, 23 Mar 2021 – Josepha answered main topics of concern here: https://make.wordpress.org/updates/2021/03/19/experiment-coordinating-sponsored-contributor-teams/#comment-5208
It’s hard to believe that WordPress has grown to support 40% of the web since its release on April 1, 2003. It’s even harder to imagine that a lot of this growth was due to word-of-mouth marketing, the quality of our contributions, and the strong community behind the project.
2020 was filled with hardships for many of us in the WordPress community, and we saw a predictable downturn in the level of volunteer contributions. Despite all of that the project continues to move forward, tackling big projects like full site editing, what to do about IE11, and reworking our long-standing contributor tools. This is where pledged time from Five for the Future comes into play.
Since its introduction in 2014, Five for the Future has encouraged organizations that benefit from the WordPress open sourceOpen SourceOpen 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 to give back to the project by sponsoring full-time contributors to move the project forward. When we experience lulls, like we are now, we know that there are company-sponsored contributors to continue mission-critical work.
The Experiment
Most everyone is aware of our contributors who are sponsored full-time to work on the WordPress project. In the near future, you will see a few more sponsored contributors around to make sure we are keeping up with the necessary tasks, from marketing professionals to backend developers. To assist in coordinating, I have created an experimental SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel for contributors who are sponsored for 32 hours or more. It is a closed channel, and since I have historically been publicly opposed to this, I have set some expectations for everyone who will be joining.
Contributors who are sponsored full-time to contribute to WordPress (as opposed to their company’s product) will be added to the channel, no matter which company sponsors them or what country they work from.
I will revisit the implementation post-WP5.8 to make sure it’s useful, focused, avoiding black box decisions, and committing to transparency.
Once we are all post-COVID, I will also revisit the implementation to see that it’s our most effective way to build psychological safety.
I will clarify group norms that include what should always be discussed in public so that we continue upholding the project’s communication norms..
The primary value of this group is not to have discussions and decisions behind closed doors. It is primarily an opportunity for those who are contributing full-time to WordPress to gain valuable knowledge of how we lead with a global mindset and how WordPress applies open source methodologies in a broader context than software development.
If your organization is interested in learning more about Five for the Future and how to participate, check out the white paper below and feel free to reach out to me with questions!
