Proposal: Learn WordPress Content Maintenance Process

In last week’s Training Team (see Slack thread here) meeting we brought up the question of “what content are we obligated to leave on learn and until what version of WordPress do we need to support”.

This question is a critical one as the team is currently working on relaunching Learn WordPress with a fresh new design and streamlined content experience which includes Learning Pathways, Courses, and Lessons. Part of this project includes content deprecation for Tutorials and Lesson Plans, and a push toward presenting content on the site that is new, fresh, and relevant.

Here’s some takeaways from the discussion on SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at

  • Content that is not relevant to current coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. features of WordPress should be removed (ex. classic editor)
  • We could view the WordPress version usage stats to decide what content is most relevant and should be the focus for our team.
  • We can use WordPress and PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. usage metrics to guide our content maintenance process
    • More than 70% of WordPress installs are using either 6.5 or 6.4.
    • Historically the project maintainers have used 5% as the baseline, ie if more than 5% of WordPresses are using that version of PHP, then support it (this currently aligns with the above point).
  • The team should review content every 6-12 months for relevancy

Proposed path forward

  • Adopt 5% baseline for content, which equates to supporting the last two versions of WordPress
  • Create a content maintenance review process that is run twice a year
  • Triage 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. for content issues which can be closed based on the new baseline

Contribute to this conversation

Here’s some questions to help keep the conversation going:

  • Do you agree with the proposed 5% baseline for content relevance? Why or why not?
  • Should there be exceptions to the 5% rule in certain circumstances? If so, what might those exceptions be?
  • What are your thoughts on the proposed bi-annual (twice a year) content review process?
  • How can we ensure that the content review process remains thorough and effective?
  • What strategies could we adopt to effectively communicate content deprecations to our learners?
  • What other metrics or data sources could be beneficial for informing our content maintenance process?

Please share your thoughts on this topic by June 13th, 2024