When maintaining an open source project, there is a need to have at least one person listed as the “Maintainer”. The rationale for having a Maintainer role for an open source project is because it:
The Maintainer role can also be seen as an alternative to a typical “Technical Lead” role on client delivery projects in that it expects someone to help mentor and guide others towards a shared outcome for a project while also helping shape a project’s roadmap and provide technical review of implementation details. Maintainers are listed in a project’s CREDITS.md file in the Maintainers section (e.g., Distributor) as well as in a WordPress plugin’s readme.txt file in the Contributors section (e.g., Winamp Block). Inactive Contributors listed in the readme.txt file will only be removed at their request as we otherwise keep them listed as continued thanks for their historical maintainer efforts.
Similarly, central to a successful open process are setting expectations and respecting the time of other participants, especially when they are volunteers or “Contributors”. The following are expectations in how to communicate with and recognize the efforts from contributors on open source projects.
In the 2017 Open Source Survey conducted by GitHub, the number one issue that people feel is most important for open source projects is “responsive maintainers.” As such, we should aim for quick response and triage on all newly opened issues and pull requests. Not so much that we quickly resolve those issues or merge those pull requests, but that we respond quickly and set realistic expectations for what contributors can expect from us.
We have set up default Issue and Pull Request Templates in the 10up .github repository, so feel free to let those do the work, or create custom ones for your repository (example: ClassifAI).
Issue triage will primarily be handled by our Open Source Practice leadership as well as specifically identified Maintainers for each project, but to help ensure we reply to all issues and pull requests within five business days, others within 10up are always welcome to assist with triage. We ask that as you review issues and pull requests you consider the following:
The following GitHub Actions are also recommended on most, if not all, projects:
We recommend limiting the number of accounts that have access to your plugin on WordPress.org SVN, as this reduces potential attack vectors and minimizes the risk of bad actors nefariously affecting your code. The downside to this is that the nice “Plugin Author” label and highlight that appears alongside messages from plugin contributors as well as the ability to mark threads as resolved or sticky within the forums is limited to that small number of accounts. Not to worry, you can use Plugin Support Reps to add others on your team who will then appear with a nice “Plugin Support” label and highlight alongside their messages in the forums. Support reps can also mark threads as resolved or sticky, but will not have commit access to the plugin codebase on SVN. You can assign support reps on the Advanced View on your plugin pages (e.g., https://wordpress.org/plugins/restricted-site-access/advanced/).
When a support topic has been resolved, ensure that you change the Status from not resolved to resolved. If a support response has been left on an open topic, but there is no response or update from the original reporter then the best approach is to leave a final comment after 30 days noting any additional information or feedback and that the topic is being closed “due to inactivity” and note that subsequent updates can be tracked in a new issue as additional information becomes available.
In the scenario where your organization uses GitHub for code and Slack for communications, then integrating the two seems reasonable. In this case, we recommend setting up a dedicated channel to track activity within your GitHub Organization using the /github subscribe owner/repository Slack command. Even further, utilize the /github subscribe owner/repository issues, pulls, releases, deployments, reviews, comments, discussions command to ensure you’re alerted to comments or discussions that come into your project repositories. Once GitHub feeds are set up, we also recommend utilizing a specific Slack emoji reaction to note that someone from your team will take responsibility for that specific activity (example).
In the scenario where your organization uses GitHub for code and publishes code to the WordPress.org repository, then integrating the two seems reasonable. In this case, then we recommend setting up a dedicated channel to track activity across your suite of plugins and themes using the RSS Feeds functionality. More specifically, you’ll want to pull up your Support page (plugin example, theme example) and Review page (plugin example, theme example) and then add /feed/ to the end of the URL that you utilize for the RSS Feed subscription (Support example, Review example). Once RSS feeds are set up, we also recommend utilizing a specific Slack emoji reaction to note that someone from your team will take responsibility for that specific post (example).
In general we follow the Version Control guidelines from the 10up Engineering Best Practices including the approaches for structure and workflows.
Our defined minimum supported versions for WordPress and PHP are set as follows:
The WordPress minimum should be updated with each subsequent major version release, but may be increased for specific projects where fixing a bug or adding a new feature is specifically more simpler by not supporting as many WordPress versions.
We expect to review the PHP minimum heading into 2025 and bump that to 8.2 (with 8.1 already in the “security only fixes” support level and increase in WordPress core support up to 8.3). PHP supported versions and end-of-life timelines can be viewed on the PHP Supported Versions page.