Proposal: Introduce Maintenance Mode For Components

This proposal aims to introduce the concept of legacy components and a process of managing them in a way that is intentional and accountable.

Once something is committed and released in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., it comes with an implicit promise of backward compatibility for the foreseeable future. But it’s not clear what to do when a feature becomes outdated, unused, or deprioritized. These features often remain in Core instead of being removed or moved to a 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, where bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports and feature requests can be more appropriately handled, as was done with PressThis.

In the past, components have been reorganized or removed when no longer relevant, but removing a component is not always appropriate and there’s a missing middle ground.

Defining Maintenance Mode

Maintenance mode would be an official status for components that should continue to be supported, but are no longer actively developed. Components might qualify for this status for reasons such as:

  • Low priority
  • No Maintainer
  • Better, more modern options available
  • Being replaced in the near future

These components would:

  • Continue to receive security updates when necessary.
  • Continue to consider and evaluate all bug reports on an individual basis.
  • Stop accepting feature or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. requests, unless they are necessary to maintain backward compatibility or prevent breakage in new WordPress or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher versions.

Maintenance mode could be removed from components in the future if conditions change.

What does maintenance mode look like?

When in maintenance mode, components would continue to have maintainers and regular triaging should continue. They would be marked clearly in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and the Components page.

How would maintenance mode be declared for a component?

The process for placing a component in maintenance mode would be flexible and decided on a case by case basis. The process should be transparent and involve open discussions with the contributor community. The process could work like this:

  • A discussion is opened with (or by) current component maintainers about placing a component into maintenance mode. 
  • A call for proposal and call for feedback on Make Core is published detailing why the component(s) are being considered for maintenance mode.
  • The component is placed in maintenance mode after sign off from leadership.

While a proposal to add the maintenance mode label will usually come from maintainers, it can also be proposed by any Core contributor. Contributors can perform regular audits of all components to try and identify any that are appropriate for maintenance mode.

What are the benefits of placing components in maintenance mode?

  • Clarifies which features are actively maintained, helping contributors and developers focus their efforts where they’re most impactful.
  • Reduces triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. noise by lowering the volume of low-priority feature requests (there are currently over 8200 open tickets in Trac).
  • Prevents contributor frustration by setting clear expectations before time is spent on patches that are unlikely to be accepted.
  • Establishes precedent for responsible deprecation of features without requiring immediate removal.
  • Supports long-term maintenance by allowing legacy components to receive targeted attention without open-ended development pressure.
  • Facilitates better communication with users and extenders about Core’s direction and future support levels.

Current Maintenance Mode Candidates

Here are a few components that are possible candidates for the proposed maintenance mode state.

TinyMCE

TinyMCE no longer powers the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor and only remains in Core to maintain Classic Editor support and backwards compatibility. There’s currently only 5 tickets in the component on Trac, and updating to more recent versions of the library does not have enough benefit to justify contributors’ time and effort. Its low ticketticket Created for both bug reports and feature development on the bug tracker. volume, lack of active development, and functional redundancy make it a strong candidate for maintenance mode.

Customize

The CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. served WordPress well, but has effectively been replaced by the block editor and full site editing. Sites with block themes no longer have access to the Customizer by default. Despite having 184 open tickets, development has slowed significantly with most activity focused on bug triage rather than feature enhancements.

Shortcodes

Shortcodes played a huge role in WordPress’ evolution, but today blocks offer a more modern and flexible alternative. No new features should be added to shortcodes. In fact, the APIAPI An 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.’s brittle nature has historically led to bugs from even minor changes (see #58333). There are currently 54 open tickets in this component (5 feature requests and 11 enhancements).

Pingbacks/Trackbacks

Pingbacks and trackbacks are a big part of blogging, so they should remain for the foreseeable future. It could be replaced by Webmentions in the future should that mature a bit. The last enhancement ticket was merged over 5 years ago now (see #36576), and there has only been one feature ticket in the history of the component (#34420).

XML-RPC

XML-RPC is essential to many external apps and services that interact with WordPress, so it can’t be deprecated. But, the spec has remained largely unchanged for over a decade. There have been no new enhancement or feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. tickets closed as fixed since 2017 (term 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. support, see #40916) and 2012 (retrieving post terms, see #18434).

Conclusion

Labeling components as legacy and placing them in maintenance mode helps set accurate expectations, reduce unnecessary churn, and focus contributor efforts on current project priorities. A documented process also gives maintainers a framework for making intentional, accountable decisions about the level of support each component receives.

If adopted, this approach could help scale WordPress Core’s maintenance model while staying true to the project’s principles.

Props @peterwilsoncc, @priethor, @karmatosed, and @4thhubbard for peer review.

#component-maintainers, #components

Devchat summary: February 26, 2020

@francina facilitated the chat on this agenda.

@valentinbora took care of publishing the meeting summary with special thanks to @amykamala, @audrasjb, @Cenay and @marybaum.

Full Meeting transcript on Slack

This devchat marked week 7 of the 5.4 release cycle.

Announcements

Upcoming Releases

Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)

WordPress Release Cycle

For background, please read:

@johnbillion got to the heart of the matter: should 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. be for fixing bugs that predate the ones introduced during alpha?

@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.

@johnbillion liked the idea that beta is for every bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.

@jeffpaul pointed out that avoiding committing non-regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. bugs during beta means Beta and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.

@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team is happy to release.

@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).

@joemcgill @johnbillion @azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.

per @johnbillion, @matt has, in the past, preferred to keep focus on the current release. 

@joemcgill stressed that the core team needs more clarity on what types of fixes are appropriate to commit to the 5.4 release, pointing out that the discussion in chat echoes this proposal to review historical practices to improve the project and potentially speed up release cycles.

@francina referred the group to the Release Model Working Group Chat Summary: February 19th, 2020 for the latest on that proposal.

@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

@francina proposed a change to the Components Check-in. 

Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:

  1. Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
  2. Adopt a Slackbot that, once a week, asks maintainers for a status update. 

@francina also proposed that those updates — and other communications — live in a new #component-maintainers 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. Core is getting very busy with automated updates like TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and Travis bots, plus RSS.

@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.].

@francina and @valentinbora agreed that going async [communicating asynchronously] could help.

@cenay was in favor of the Slackbot option.

Action items

  • @francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
  • @audrasjb to get all dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. by the end of the week and publish the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before RC1.

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, March 4, 2020, 21:00 UTC.

#5-4, #component-maintainers, #core, #dev-chat, #meetings