Project Thread: Contributor Dashboard Pilot Project

A Contributor Dashboard Pilot is underway within the WordPress project, building on previous community work, and responding to long-standing requests from the community for better visibility into contributor journeys – how people join, participate, and grow across Make teams.

Contribution activity, especially non-code work is spread across many tools and systems. This makes it difficult to recognize contributors, understand engagement over time, and identify where support is needed.

Project Status

This project is currently in the active pilot development phase, led by @felipevelzani, @unintended8 and @kel-dc.

A limited multi-team pilot launch is planned for the end of February 2026. This project thread will be updated as work progresses.

What We’re Building

We’re building a Contributor Dashboard that maps contributor activity across teams into a shared Contributor Ladder framework:

Connect → Contribute → Engage → Perform → Lead

The ladder is behavior-based and describes patterns of participation over time. It does not rank contributors or imply that some contributions matter more than others. All contribution types and all contributors matter.

The goal is to help teams understand participation patterns, identify where support may be needed, and improve contributor experiences over time.

Why We’re Doing This

The project addresses several challenges across the project:

  • Contribution activity is scattered or not tracked
  • Non-code contributions often lack visibility
  • Teams have limited insight into how contributors progress over time
  • Cross-team onboarding, retention, and engagement patterns are difficult to assess

How We’ll Build the Pilot Dashboard

For the pilot, we’re taking a multi-team approach using a custom 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 that maps existing contribution activity from 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/ systems to ladder stages. This activity-based approach allows us to validate the model, identify data gaps, and gather cross-team insights without introducing new infrastructure or requirements for contributors.

Additional technical details and implementation notes are documented in the project’s public reference materials.  

Scope and Data

This pilot starts intentionally small and focuses on a limited set of existing contribution signals to test the dashboard and ladder approach. It does not aim to capture 100% of all contributions across Make teams.

The pilot does not replace or change Five for the Future, contributor recognition programs, or existing team processes, and it introduces no new requirements for contributors or Make teams.

Contributor privacy is a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. consideration. The dashboard uses existing WordPress.org accounts and activity data, does not display personal or sensitive information, and does not create new contributor profiles.

Hosting

  • The pilot dashboard will be hosted on Pressable to support development, testing, and iteration during the pilot phase, with the intention of moving to WordPress.org infrastructure in a future phase.
  • The custom plugin is designed to work within existing WordPress.org 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. systems and data constraints, without introducing new external dependencies.

Timeline & Milestones

• January–February 2026: Implementation, testing, and review  

• End of February 2026: Pilot launch


How to Get Involved

We’re looking for contributors to help bring this pilot to life and welcome collaboration from across Make teams. For this pilot, we’re especially looking for contributors who can help with the following: 

  • Building and improving the dashboard and plugin
  • Reviewing and validating contribution signals and ladder mappings
  • Testing the dashboard experience and reviewing insights
  • Helping iterate on documentation and communication as the pilot evolves

If you’re interested in getting involved:

We welcome ideas and participation from all Make teams and contributors during the pilot and as the project evolves. Community input will help inform iteration and improvements, while the pilot proceeds unless material concerns are raised around privacy, security, or alignment with WordPress project values.

Props @4thhubbard for post review.

Proposal: 2026 Major Release Schedule

As 2025 comes to a close, it’s time to reflect and start thinking about what the major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. schedule for the 2026 calendar year will be. This year, the community came together and published two fantastic new major versions of WordPress to the world: 6.8 “Cecil” in April and 6.9 “Gene” in December.

While 2025 saw just two releases, the goal is to return to 3 major releases in 2026 (roughly one every 4 months).

This cadence has proven to effectively balance the many different factors at play within the global contributor community. The 4 month release cycle also:

  • Is long enough to build out quality new features for each release.
  • Is short enough to encourage shipping iteratively rather than pursuing perfect software (release early, release often).
  • Allows for 1-3 minor releases in between when following a 6-8 week timeline.

2026 Schedule (Proposed)

Using the ideal 4 month spacing between each release and making efforts to avoid major holidays, the final release dates for the next three releases fall within close proximity to a few prominent in-person WordPress events for 2026.

Following the successful live release of 6.9 during State of the Word earlier in December, the schedule below was created to continue trying out this model.

WordPress 7.0 – Thursday, April 9th

To start off the year, 7.0 is targeted for release during Contributor Day of WordCamp Asia. This creates some unique and exciting teaching opportunities! Newer contributors can observe the release process live to learn about how to contribute, or even participate in the release process, pitching in to help ship a version to WordPress to the world on their first day contributing.

Important dates

  • 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. 1: Thursday, February 19, 2026
  • RC1: Thursday, March 19, 2026

WordPress 7.1 – Wednesday, August 19th

This date for the public release of 7.1 coincides with the final day of WordCamp US. WCUS begins on a Sunday and ends on a Wednesday, which makes the final day more suitable for a release.

Important dates

  • Beta 1: Wednesday, July 1, 2026
  • RC1: Wednesday, July 29, 2026

WordPress 7.2 – December 8th, 9th, or 10th

To round out 2026, the community can celebrate the year’s accomplishments by releasing 7.2 on or around the annual State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/. address.

Important dates

  • Beta 1: October 20-22, 2026
  • RC1: November 17-19, 2026

A Few Notes

  • A call for volunteers interested in serving on the 7.0 Release Squad will be published the week of January 4th. If you are interested, please keep an eye on Make WordPress Core or subscribe for updates via email in the site’s sidebarSidebar A 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..
  • While the releases are lining up with in-person events, there is no requirement to travel in order to be on a release squad. All communication and coordination will continue to happen in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
  • A healthy balance between in-person and distributed contributors on release day is actually preferred. This helps ensure that any unexpected technical issues such as poor/unavailable WiFi do not result in a delayed release.
  • The spacing between the three flagship WordCamps in 2026 presents a strong opportunity to be intentional with release timing. With the proposed April 9th date for 7.0, moving straight into the 7.1 cycle would significantly compress the alpha period for feature work. The eight-week window between 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. Asia & WordCamp Europe is an excellent fit for a minor releaseMinor Release A 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., which could help to deliver meaningful improvements with confidence and adequate breathing room.
  • During the 6.9 dry run and final release, contributors identified several opportunities to improve the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook, especially the pages aimed at documenting the release practices and processes. The live release of 6.9 notably shined a light on areas that require clarification to ensure both in-person and distributed contributor groups can synchronously collaborate more transparently and effectively. These will be collected and shared in a separate Make Core post in January.
  • The WordPress 7.2 date is the least flexible of the three with earlier dates encroaching on the major global financial holidays of Black Friday/Cyber Monday/Giving Tuesday, and later dates getting too close to major religious holidays and end of year time off.
  • Friday, Saturday, Sunday, and Monday have historically been considered unsuitable for a release to avoid spoiling weekends of those who use, build with, maintain, or support anyone with a WordPress site.

Discussion & Feedback

As always, the dates above are being proposed to allow contributors to begin planning for the rough timing of each of the 3 releases in 2026. There is some flexibility to make adjustments if necessary based on community feedback or factors that were not considered.

Do you have questions or thoughts about the release schedule as proposed? Ideas for ways to improve the Core Handbook or the release process itself? Or maybe a specific feature that you’re most looking forward to in 2026? Share them below and join the conversation.

Props @annezazu, @jorbin AND @4thhubbard for helping to narrow down possible dates and/or reviewing this post.

Announcing the Core Program Team

This program model was first introduced with the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. AI Team. Building on that experience, I’d like to expand it into an experiment with the launch of the Core Program Team. Tammie Lister has agreed to help as the first team representative.

The goal of this team is to strengthen coordination across Core, improve efficiency, and make contribution easier. It will focus on documenting practices, surfacing roadmaps, and supporting new teams with clear processes.

The Core Program Team will not set product direction. Each Core team remains autonomous. The Program Team’s role is to listen, connect, and reduce friction so contributors can collaborate more smoothly.

You can get involved by joining the #core-program 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 and following updates on the Core Program Team Blog, including a the welcome post that outlines next steps.

I am excited to see how this experiment helps Core teams work together and makes contribution more accessible to everyone.

Props to @karmatosed, @dd32, @desrosj who helped move this forward.

A Little (Late) Spring Cleaning

Following up on the codified criteria for a repository to live under the WordPress organization on GitHub, a comprehensive audit of all repositories under both the WordPress and bbPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org. 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/ organizations has been conducted.

To support this effort, every repository was catalogued in a spreadsheet, along with metadata to assess which met the established criteria. This includes factors such as ongoing maintenance, alignment with an active 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/ team or initiative, and whether the repository serves a continuing purpose.

Archived Repositories

In total, 20 repositories in the WordPress GitHub organization were identified as no longer meeting the criteria for active maintenance under the organization. These include:

  • Feature plugins for projects that have already been merged into WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and are no longer providing any additional functionality.
  • Some repositories were created for short-term experimentation or one-off demonstrations. While useful at the time, they no longer serve an active purpose and were archived to reduce clutter.
  • Legacy communication efforts that are no longer relevant.

The following repositories have been archived between June 5, 2025 and June 24, 2025:

Additionally, one repository was archived under the bbPress GitHub organization: wpbbp.

Archived repositories remain publicly accessible for reference purposes. Specific reasons why each repository was closed can be found in the Archive Notes column of the spreadsheet

Closed Plugins

Archiving repositories was only one part of this effort. Since the GitHub repositories often overlap with plugins hosted on the WordPress.org Plugin Directory, all plugins maintained or supported by the wordpressdotorg user were also reviewed. Plugins tied to deprecated features, outdated support needs, or now-merged projects were closed to reduce confusion and focus contributor attention on current tools.

The following 11 plugins were closed on June 24 2025:

To preserve historical context, a new page in the Core Team Handbook has been published as a reference of all retired plugins that were officially supported by the Core team at one point. Plugins closed prior to this effort can be added retroactively as they’re identified.

Archived 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/. Channels

Beyond code and plugins, Slack was also reviewed. Slack channels associated with completed initiatives, legacy features, or inactive Core components were archived. This helps reduce noise and ensures that active discussion spaces align with the project’s current areas of focus.

feature-* and core-* component channels were considered inactive if there had been no meaningful collaboration for at least one year.

The following 30 Slack channels were archived in the WordPress.org Slack instance on June 24, 2025:

Archived Slack channels remain publicly accessible and can easily be unarchived if new maintainers come forward or if the channel is the most appropriate space for new discussions.

Looking Ahead

As the project continues to evolve, periodic audits like this help keep our resources aligned with current priorities. If you believe something was archived prematurely or have suggestions for future cleanups, please detail in the comments.

When archiving certain code bases, plugins, and channels, it’s important to pause and thank the many contributors who brought them to life. Their work forms the foundation for continued progress. Every commit, idea, and conversation has helped advance WordPress’s mission to democratize publishing. And for that, we say “thank you!”

Props @4thhubbard for post review.

X-post: The Incident Response Team is looking for new members

X-comment from +make.wordpress.org/community: Comment on The Incident Response Team is looking for new members

Five for the Future WCEU25 Chat

🎯 Meeting Purpose & Context

This pivotal meeting convened many WordPress stakeholders, including grassroots contributors, corporate sponsors, team leads, project managers, advocates, and community organizers. The dialogue focused on dissecting and reshaping the WordPress contribution landscape in 2025 and beyond.

The primary objective was to address the challenges and opportunities holistically:

  • Defining what constitutes contribution beyond traditional code-centric views.
  • Ensuring contributor sustainability by mitigating burnout and securing equitable funding/support.
  • Enhancing recognition systems that acknowledge the full spectrum of work supporting WordPress.
  • Establishing transparent and effective funding governance and sponsorship models.
  • Standardizing team structures, onboarding, and offboarding workflows for clarity and respect.
  • Leveraging AI and technology to consolidate fragmented knowledge and facilitate onboarding.

The Five for the Future” (5ftF) initiative—originally a rallying cry for companies to contribute 5% of their resources back to WordPress—was intensely scrutinized. Participants widely agreed the initiative’s ambiguous nature has diminished its effectiveness and propose a comprehensive reinvention aligned with the modern open-source ecosystem and diverse contribution types.


🔑 Major Topics & Deep Insights

1. The State and Future of “Five for the Future”

Context & Historical Analysis

  • 5ftF was conceived as a simple, inspiring call-to-action. However, its coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. metric (5%) was never concretely defined—whether it applied to revenue, personnel time, or budget allocations remains unclear.
  • This vagueness led to mixed interpretations, with some companies adopting it as a guideline, others feeling pressured or unfairly judged, and some dismissing it altogether.
  • Over time, 5ftF became a source of contention, sometimes weaponized to criticize contributions or lack thereof, which alienated community members.

Implications for Today

  • The lack of clarity makes measuring compliance and impact difficult, frustrating sponsors and contributors alike.
  • The initiative’s framing as an obligation risks fostering resentment instead of fostering intrinsic motivation to contribute.
  • Diverse organizations contribute in myriad ways that don’t easily map to a singular percentage metric.

Community Sentiment & Recommendations

  • Strong desire to rebrand or replace 5ftF with a framework that is:
    • Explicit about what counts as contribution (code, docs, events, advocacy, sponsorship, infrastructure support).
    • Flexible and adaptable to different organizational sizes, cultures, and capacities.
    • Presented positively, encouraging pride rather than guilt or competition.
  • Proposals for concise, easily digestible messaging (e.g., TL;DR summaries) to increase community engagement and understanding.
  • Emphasis on clear terminology distinctions, such as differentiating “projects” (workstreams, campaigns) from “teams” (organizational units) to improve clarity.

Logical Considerations

  • The original 5ftF suffers from ambiguity, resulting in a vagueness fallacy that allows for multiple contradictory interpretations and hinders effective implementation.
  • There is a risk of moral licensing bias, where companies might justify minimal or token contributions by pointing to vague pledges.
  • There is an opportunity to apply clear measurement theory to reframe the initiative for maximum effectiveness.

2. Defining Contribution: Inclusive Recognition

Contextual Breakdown

  • WordPress’s contribution recognition has historically focused on code commits and bug fixes, marginalizing critical roles like:
    • Event organizing and community building.
    • Mentoring and onboarding support.
    • Moderation and conflict resolution.
    • Localization and translation work.
    • Documentation and educational content creation.
    • Advocacy and sponsorship liaison roles.

Risks & Consequences

  • Contributors performing “soft” or non-technical work often remain invisible in metrics and appreciation systems, leading to feelings of undervaluation and eventual attrition.
  • Community diversity and vitality suffer if key roles go unrecognized, risking burnout in these critical but less-visible areas.

Community Sentiment & Recommendations

  • Strong advocacy for broadening contribution definitions and institutionalizing formal recognition for all contribution types.
  • Development of standardized, time-sensitive badges that:
    • Reflect contribution types (e.g., mentor, organizer, translator).
    • Are era-aware, capturing when contributions were made to provide historical context.
  • Emphasize project-based recognition, acknowledging contributions that cut across traditional team boundaries (e.g., marketing campaigns, community challenges).
  • Proposals to formally recognize corporate contributors who provide financial or infrastructure support beyond volunteer hours.

Methodological & Logical Notes

  • Recognition systems should avoid the availability heuristic, which favors visible code contributions and neglects less tangible efforts.
  • Incorporate multi-dimensional recognition frameworks to capture the complexity and breadth of contributions.
  • Explore measurement instruments and surveys to quantify “invisible work” and incorporate it into metrics fairly.

3. Burnout Crisis & Sustainability

Underlying Factors

  • Contributor burnout is pervasive due to:
    • High volunteer demands with insufficient systemic support.
    • Lack of equitable financial remuneration or stipends for ongoing work.
    • Pressure to maintain legacy systems and innovate new features leads to overwhelming workloads.

Consequences

  • Loss of institutional knowledge and experienced contributors.
  • Increasing technical debt and slowed innovation cycles.
  • Threat to WordPress’s long-term ecosystem health.

Community Sentiment & Strategic Actions

  • Consensus on the urgent need to establish funding mechanisms that:
    • Support contributors financially without the expectation of full-time commitment.
    • Include stipends, grants, bursaries, or scholarships to enable sustainable engagement.
  • Strong calls to relaunch and properly resource the Sustainability Team, with mandates across:
    • Social sustainability (community well-being and diversity).
    • Economic sustainability (fair contributor compensation).
    • Environmental sustainability (minimizing the ecological impact of project activities).
  • Integrating sustainability principles into all relevant teams and projects ensures a holistic impact.
  • Reopening the Sustainability 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 as a hub for collaboration and information sharing.

Cognitive & Structural Analysis

  • Burnout stems from a resource allocation failure, where human capital is overextended without support.
  • Sustainability efforts require systems thinking, addressing interconnected social, economic, and environmental factors.
  • Avoid single-factor attribution bias by recognizing multiple contributing causes and solutions.

4. Metrics, Accountability, & Transparency

Current State

  • Many contribution promises remain unverified pledges, undermining accountability and measurement.
  • Sponsors and leadership struggle to assess impact and justify investments.

Negative Impacts

  • Reduced sponsor confidence and risk of resource misallocation.
  • Inadequate data restricts informed decision-making and priority setting.

Community Sentiment & Preferred Solutions

  • Strong advocacy for a shift to data-informed contribution tracking, including:
    • Leveraging the Contributor Dashboard and Bitergia analytics for verified data.
    • Transparent publication of contribution types, amounts, and outcomes.
    • Linking sponsors directly with contributions they fund for accountability.
    • Generating KPIs meaningful to sponsors and leadership.
  • Centralized communication hubs like https://make.wordpress.org/updates are critical for aligning contributors and sponsors.
  • Standardized reporting and sponsorship communication to clarify expectations, investments, and impact.

Logical and Methodological Considerations

  • Reliance on promissory pledges is a credibility gap, weakening trustworthiness.
  • Data-driven approaches embody evidence-based decision-making, which is critical for sustainable governance.
  • Metrics must balance quantitative rigor with recognition of qualitative impacts.

5. Contributor Funding & Governance

Present Challenges

  • Absence of formal, transparent governance structures for contributor funding and sponsorship leads to:
    • Informal, inconsistent decision-making.
    • Slow progress and risk of bias or mismanagement.
    • Contributor confusion regarding eligibility and processes.

Risks

  • Erosion of community trust and possible inequities.
  • Inefficient utilization of sponsorship funds.

Community Consensus & Proposed Framework

  • Empower contributors and teams to “just start doing it”, reducing excessive gatekeeping.
  • Develop transparent matching processes, aligning sponsors with contributors based on project priorities and skills.
  • Recognize corporate financial and infrastructure contributions alongside individual efforts equitably.
  • Create comparable incentives for event sponsors and other sponsors, ensuring fairness.
  • Establish clear, measurable deliverables tied to sponsorships to maintain accountability and justify investment.

Governance & Ethical Analysis

  • Governance gaps represent a principal-agent problem, where misaligned incentives may reduce funding efficacy.
  • Transparent processes are necessary to prevent conflicts of interest and favoritism.
  • Empowerment aligns with decentralized governance principles, fostering agility and innovation.

6. Team Structures, Onboarding, & Offboarding

Current Limitations

  • No standardized or documented procedures for team formation, closure, onboarding, or offboarding.
  • Contributors often feel lost, pinged unnecessarily, or disconnected from team goals.

Implications

  • Reduced morale and retention.
  • Inefficient resource use and duplicated efforts.

Community Recommendations

  • Standardize team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. roles, empowering them with decision-making authority and responsibility for inter-team coordination.
  • Establish clear, documented onboarding and offboarding workflows, including:
    • Providing formal closure for departing contributors.
    • Respectful disengagement processes.
  • Clarify and communicate distinctions among teams, projects, and working groups to improve organizational adaptability.
  • Define transparent criteria and community involvement in team lifecycle decisions (creation, closure, restructuring).
  • Consider revamping https://make.wordpress.org/updates/team-reps/ 
  • Suggest sponsors list opportunities on the jobs board.
  • Prioritize “Get Started” pages and streamline contributor pathways to lower barriers for newcomers.

Organizational & Psychological Insights

  • Lack of structure breeds role ambiguity, undermining team efficacy and contributor identity.
  • Formal onboarding/offboarding fosters psychological safety and closure, improving community health.
  • Clear boundaries between teams and projects reduce scope creep and enhance accountability.

7. AI & Knowledge Sharing

Contextual Challenges

  • WordPress knowledge is siloed across Slack, meeting notes, GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues, and documentation, hindering 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).
  • New contributors face steep onboarding curves due to fragmented and voluminous information.

Potential AI-Enabled Solutions

  • AI tools to summarize and synthesize dispersed knowledge into accessible, structured formats.
  • Generation of digestible TL;DRs contextualizing priorities and history for newcomers and busy contributors.
  • Facilitating cross-team collaboration by reducing duplicated efforts and knowledge gaps.
  • Maintaining a people-first ethos ensures that AI supports human relationships and respect rather than replaces human interaction.

Ethical and Practical Considerations

  • AI use should respect data privacy and community norms.
  • Avoid AI-driven dehumanization by complementing, not substituting, human engagement.
  • Emphasize transparency in AI-generated content and maintain channels for community feedback.

💬 Selected Highlights & Quotes — Context, Implications & Community Sentiment

  • “Five for the Future was never clearly defined and became a weapon or obligation.”
    The original initiative’s lack of clarity led to division and resentment, discouraging genuine contributions. The community now seeks a new framework that is inclusive and clearly communicated.
  • “We’re throwing money at an endless problem without accurate metrics.”
    Without verified contribution data, funding is inefficient, trust erodes, and strategic impact diminishes. Community demands robust, transparent metrics.
  • “We need an attitude shift from endless discussion to ‘just start doing’.”
    WordPress’s culture of prolonged debate has stalled progress. There is enthusiasm for empowered, decentralized action and iterative delivery.
  • “Onboarding and offboarding are essential for contributor closure and team health.”
    Formal contributor lifecycle management ensures respect, reduces burnout, and maintains engagement.
  • “Invisible and soft contributions must be recognized for a truly inclusive community.”
    Non-code work—event organizing, mentoring, and moderation—is vital for sustainability and must be formally acknowledged.
  • “Sustainability affects every WordPress team and cannot be ignored or discounted.”
    The disbanding of the Sustainability Team highlighted governance gaps; urgent reactivation and funding is necessary.
  • “We already have programs like mentorship and dashboards; let’s build on them, not recreate.”
    Respecting and extending existing legacy programs promotes efficiency and continuous momentum.
  • “Corporations want measurable outputs and KPIs to justify their sponsorship.”
    Transparent, actionable metrics are critical to sustaining corporate sponsorship.

⚠️ Challenges & Barriers — Contextualized

ChallengeImpactNotes
Data & Metrics DeficiencyInhibits fair recognition, accountability, and fundingNeed for verified, transparent contribution data
Governance GapsInconsistent funding, unclear team lifecycles, and decision delaysRisks bias, erodes trust, reduces agility
Contributor BurnoutLoss of contributors, slower innovationRequires systemic support and equitable funding
Communication SilosFragmented channels, poor knowledge sharingLimits collaboration and onboarding
Role AmbiguityLeadership confusion, inefficienciesStandardized roles and processes are needed
Cultural Discomfort Around FundingHinders open discussions on money and supportNormalize funding conversations and transparent governance

✅ Action Items & Roadmap — Context & Community Focus

  1. Publish comprehensive, transparent meeting notes for community-wide accessibility and feedback.
  2. Form dedicated working groups to:
    • Define and standardize contribution frameworks, including all roles and types.
    • Develop formal onboarding and offboarding procedures with contributor closure.
    • Formalize transparent governance for team lifecycle management and funding.
  3. Reinstate, resource, and empower the Sustainability Team, reopening communication channels. See Overlapping Initiatives
  4. Build or improve a centralized dashboard and jobs board mapping contributor skills, team needs, sponsorship opportunities, and project priorities.
  5. Promote and expand data-informed contribution tracking via the Contributor Dashboard, Bitergia, and similar tools.
  6. Foster a culture of empowered, decentralized initiatives, enabling contributors and teams to act swiftly within shared governance.
  7. Collaborate with the Core AI team to design tools for knowledge synthesis, onboarding TL;DRs, and reducing information fragmentation.
  8. Implement inclusive recognition systems valuing code and non-code contributions equally with badges, public acknowledgment, and corporate recognition.
  9. Maintain open, ongoing dialogue with WordPress leadership to ensure alignment, resource support, and respect for grassroots contributions.
  10. Clarify and document team rep roles, responsibilities, and communication workflows to enhance coordination and empowerment.
  11. Update and prioritize Get Started pages, contributor pathways, and onboarding resources for improved newcomer experience.
  12. Develop and execute a communication and change management strategy supporting the adoption of governance, funding, and recognition reforms.

📌 Additional Community Priorities & Critical Questions Highlighted

  • Why must contributors ask permission to act? Empower autonomy.
  • What are the actual, data-verified contribution numbers? Move beyond guesswork.
  • Should we shift from promissory pledges to data-confirmed contributions? Strong yes.
  • How can we measure and recognize hidden work like event organization and mentorship? Develop metrics and recognition tools.
  • How do we prevent wasting contributors’ finite time? Streamline processes, improve communication.
  • Team badges reflecting eras and specific projects, not only teams: Implement dynamic, time-stamped recognition.
  • How to recognize company contributions beyond volunteer hours? Develop corporate recognition programs.
  • How can initiatives (e.g., shipping WebP) be communicated clearly and not blocked at the last minute? Improve project communication and accountability.
  • Standardize badge processes and sponsor incentives; ensure equitable benefits for sponsors.
  • Allow contributors to declare sponsor support per activity, increasing transparency.
  • Recognize sponsored contributors’ blog posts and reporting efforts.
  • Centralize team priorities and synthesize cross-team projects for clarity and alignment (e.g., https://make.wordpress.org/updates).
  • Map contributor sponsorship needs to sponsor interests and required KPIs transparently.
  • Empower team reps to maintain up-to-date skills and sponsorship needs lists.
  • Clarify distinctions and governance around sub-teams (e.g., Core sub-teams like Performance, AI, 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/).
  • Standardize proposals, sub-team processes, and unblocking procedures.
  • Prioritize an actionable roadmap aligned with core and ecosystem-wide priorities.
  • Highlight and formally recognize invisible, soft contributions.
  • Reframe or rename 5ftF to reflect inclusivity and modern realities.
  • Support horizontal collaboration across traditionally vertical team structures.
  • Use AI to maintain and curate WordPress knowledge repositories, respecting data privacy and community ethos.

📚 Final Reflection

WordPress is at a pivotal moment in its development. By adopting transparent governance, recognizing contributions inclusively, implementing sustainable funding models, clarifying team processes, and thoughtfully integrating AI, the community can create a resilient, vibrant, and equitable ecosystem for contributors. By building on past efforts and adapting to changing circumstances, WordPress can ensure that every contributor—regardless of role or background—feels valued, empowered, and connected to the project’s future.

#5ftf, #contributor-working-group, #discussion, #five-for-the-future

Criteria for Creating or Migrating Repositories under the WordPress GitHub Organization

With WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. now following an annual release cadence, community-maintained canonical plugins have become even more crucial to the project. Because canonical plugins serve as official first-choice recommendations, they should live under the WordPress organization on 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/. However, there are currently no guidelines around what is allowed or prohibited under the project’s GitHub organization. Establishing some clear criteria will help community members understand the requirements and expectations for this.

Core Principles

WordPress should balance experimentation with quality standards and project philosophy. GitHub repositories under WordPress should benefit the community, prevent single points of failure, and ensure open-source 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).

Before outlining specific criteria, here are the underlying principles that guide these criteria:

  1. Community Ownership: Code that serves the WordPress project should be collectively owned and maintained rather than dependent on individuals.
  2. Responsible Stewardship: Maintainers must commit to responsible management of their repositories.
  3. Quality Assurance: All code under the WordPress umbrella should reflect the project’s commitment to excellence.
  4. Transparency: Clear documentation and communication about repository status and purpose.
  5. Inclusivity: Lowering barriers to contribution while maintaining standards.

Criteria for Inclusion

For a repository to be included in the WordPress GitHub organization, it must meet the following criteria:

Project Documentation and Goals

  • The repository must have a clear problem statement and some roughly outlined goals. This can be in the README.md file or linked to in a Making WordPress blog post.
  • Maintainers should aim to regularly post updates about the project at a cadence that makes sense for the overall level of activity.
  • The repository should have an agreed upon tag on the sponsoring team’s Make blog to easily find all related posts.

Team Sponsorship and Maintenance

  • The repository requires at least one active maintainer under an established Make Contributor team, with multiple maintainers encouraged for continuity. This should be noted in the repository’s READEME.md file at a minimum, and within the CODEOWNERS file if useful.
  • The sponsoring team takes collective ownership and responsibility for the repository’s oversight.

Maintenance Commitments

The contributor/team maintaining the repository agrees to reasonably maintain the project. This includes but is not limited to these expectations and requirements:

  • Issue Management: Triaging submitted feature requests and bug reports in a timely manner.
  • Communication: Responding to community questions and providing reasonable support channels.
  • Transparency: Clearly communicating the project’s status, roadmap, and any changes in maintenance capacity.
  • Best Practices: Adhering to project-level best practices and expectations.
  • Policy Compliance: Using project-level policies, such as being compatible with the GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples., and the Community Code of Conduct.
  • Documentation: Maintaining clear, accessible documentation for users and potential contributors.

Quality Standards

Repositories must follow WordPress coding standards where appropriate, establish suitable testing processes, and maintain the same quality standards as other WordPress code bases.

Governance

  • Appeals or exceptions to these criteria can be discussed in the appropriate Make team blogs.
  • Periodic reviews of repositories may be conducted to ensure ongoing compliance with criteria.
  • Project leadership has the final say for what can be included.

Repository Lifecycle Management

Archiving Policy

  • If maintenance ceases and the repository does not represent a canonical 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, the repository will be archived after 6 months if reasonable efforts to find new maintainers are unsuccessful.
  • Archived repositories can be unarchived if factors change and/or a maintainer steps up.
  • Exceptions can be made to this policy. The repository’s current usage, importance to the ecosystem, maintenance burden, etc. should all be considered before archiving a repository.

Security Considerations

  • Unless a repository is explicitly mentioned in the project’s HackerOne policy, it will not be eligible for the project’s bug bounty program.
  • Should any security vulnerabilities be discovered, critical security issues must be addressed promptly in coordination with the Security Team, even in experimental repositories.

Special Considerations

  • Experimental repositories should be clearly labeled as such and may have modified expectations for support and stability.
  • Tools primarily used by WordPress contributors (e.g., phpunit-test-reporter) may also have different support requirements than user-facing components. Some repositories may require little to no maintenance and should remain open to signal that it’s still relevant.
  • Specific expectations and requirements for Canonical plugins should be explored separately.

Conclusion

These criteria balance innovation with WordPress’s high standards. They create a framework for healthy GitHub repository management that supports project growth while ensuring quality and sustainability. Community feedback is welcomed and encouraged so these guidelines can be improved to appropriately serve contributor needs.

Props @4thhubbard, @jeffpaul, @priethor, @johnbillion, and @annezazu for pre-publish review.

Restoring Trust while Preserving Safety

In April, @matt wrote about reflection; how, after twenty years, WordPress is still growing, not just in code and contributors, but in responsibility. The Jubilee post invited us to pause and ask what kind of project we want to be for the next twenty.

One piece of that reflection was a review of accounts that had previously been banned from participating in our community spaces, including 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/ and 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/.. This review wasn’t done in isolation. It took collaboration across community teams and a shared commitment to fairness.

Any community as large and global as WordPress will at times feel the tension between openness and accountability. Processes don’t always hold up. Intentions don’t always translate into outcomes. And sometimes, we just get it wrong.

This review wasn’t about undoing everything. It was about restoring trust. Trust in the systems we use to moderate, and trust in the people behind them. Each account was considered in context and with care.

Most were reinstated. And a small number remain blocked, in cases where there were credible threats, harassment, or other actions that compromised the safety of others. In those moments, we choose safety. That’s not always the easiest choice, but it’s the right one.

What’s next

With this review now complete, I’d like to shift focus toward improving how we handle these situations going forward. That includes being more transparent when actions are taken, creating clear and consistent paths for appeal, and documenting decisions in ways that are easier to understand and easier to trust.

It might also be time to take a closer look at how responsibilities move through the project. In areas like moderation and community safety, is it time to establish clearer rotations? Rotating roles can help us avoid centralizing too much authority in any one place, and it guards against the single points of failure that 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. and communities should always aim to minimize. It’s a principle we trust in architecture. It applies equally to people and processes.

Bans and blocks aren’t a sign of failure. They’re part of maintaining a healthy space. But growth means we keep looking at how we apply them with care, with humility, and with a willingness to evolve.

If we continue to center empathy, transparency, and the shared goal of making WordPress better for everyone, we won’t just be stronger. We’ll be ready for whatever comes next.

Props to @jdembowski for help with this post

Review of Blocked Community Members

In an ongoing effort to foster a healthy and inclusive community, we are conducting a thorough review of blocked community members, prioritizing individuals who were blocked between August 2024 and the present date without communication or notification. This initiative spans both the 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/ and 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/. platforms and aims to identify accounts that can be unblocked and reinstated, allowing those members to re-engage with the community.

Unblocking Criteria and Process

The decision to unblock an account will be based on a thorough evaluation of the actions that led to the initial 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.. While some blocks were justified and will be upheld, we acknowledge that mistakes may have occurred, and some members may have been unfairly blocked. Our aim is to correct any past errors and provide a clear path for those members to re-engage with the community. We believe that by working together and fostering open communication, we can move forward and build a stronger, more inclusive community for everyone.

Factors Considered During Review

  • Severity of the Infraction: The nature and severity of the situation that led to the block will be a primary consideration.
  • Time Elapsed: The length of time since the block and any subsequent behavior of the individual will be taken into account.
  • Agreement to Adhere to Community Guidelines: The individual has expressed a commitment to follow the community code of conduct and forum rules.
  • Community Impact: The potential impact of unblocking on the overall community health and well-being will be considered.

Timeline and Communication

We understand that this process may take some time due to the number of accounts under review and the need for a thorough evaluation of each case. Please note that we are prioritizing those who were banned without notice or communication, and spammers will not be notified.

We are committed to providing regular updates on the progress of this initiative and will communicate any significant developments to the community in a timely manner.

Commitment to a Healthy and Inclusive Community

This unblocking initiative reflects our commitment to fostering a welcoming, inclusive, and respectful community where all members feel valued and supported. While maintaining the health and integrity of our community is paramount, we also believe in providing opportunities for individuals to learn, grow, and contribute positively. This initiative is a step towards achieving that balance, and we are hopeful that it will contribute to a stronger and more vibrant community for all.

We appreciate your patience and understanding as we work through this process.

A New Cadence for WordPress Core

There have been a few questions around our decision regarding the WordPress Release cadence, which I’m glad to address. After years of releasing WordPress three times a year, and a recent discussion with Core committers, we’re making a change — for now.

Starting in 2025, WordPress will move to a single major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. per year, with WordPress 6.8 “Cecil” marking the final major release for the calendar year. From there, the next major release will land in 2026, and we’ll continue on that annual cycle for the time being.

This decision reflects current realities — particularly the energy and resources being diverted due to ongoing legal matters. If those lawsuits are dropped or resolved, we’ll revisit this cadence and strongly consider returning to a three-releases-per-year schedule. That remains the ideal for a fast-moving, community-driven project like WordPress.

In the meantime, the annual cycle gives us the space to focus on essential work that often gets sidelined:

  • Reducing technical debt and long-standing bugs
  • Improving performance across coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
  • Supporting noncommercial community plugins
  • Investing in design, testing, and the broader contributor experience

We’ll continue to issue minor releases as needed for maintenance and security, and we’re introducing quarterly core committer town halls to strengthen collaboration and alignment across teams.

Looking ahead, this cadence puts WordPress 7.0 on track for 2027 — and with the additional time, we’re aiming for more than just a version number. 7.0 will be a milestone: a thoughtful, intentional release that reflects how far the platform has come and the kind of future we’re building toward.