As open-source software, the WordPress ecosystem is sustained by a community of contributors. Ranging from voluntary contributors to sponsored people who dedicate a few hours of their weeks to WordPress, these people maintain our beloved content management system and its ecosystem.

There are various ways to contribute. You can visit the Make WordPress page for more details about the available teams and projects.

I’ve been contributing to the Contributor Team in the past few months as part of my Five of the Future pledge. In this article, I’d like to share my experience and explain a bit more about what I do in the team.

What Is WordPress Documentation Team

The WordPress Documentation Team (or, for short – Docs Team) is a group of contributors who maintain the documentation for end users and developers. The tasks range from creating new articles to reviewing and updating existing documentation.

This team is one of the WordPress Make teams that can benefit from both contributors with no technical experience and those who are experts in WordPress development. Even WordPress beginners can contribute simply by giving us insights on how helpful the documentation is and how we can improve them.

There are two types of WordPress documentation:

• End-user documentation (HelpHub) – this is located on the WordPress support page and contains articles to help end users do various WordPress-related tasks.
• Developer documentation (DevHub) – this is located on the Developer Resources page and is mainly aimed at helping developers with their development projects.

The HelpHub is what I mainly contribute to, specifically in the block editor category. 

How I Contribute to the Docs Team

Contributing to the Docs team requires the following accounts:

• WordPress.org profile.
• Make WordPress Slack account, which can be obtained after registering a WordPress.org profile.
• GitHub account, as all Docs team tasks are in a GitHub repository.

Currently, I have two roles in the Docs team – writer and reviewer.

As A Writer

For writing documentation, the workflow starts with picking up the task in the GitHub repository. Since I’m focusing on the HelpHub documentation, I look for issues that have the user documentation label.

There are some other labels that help me decide which issues to work on:

• Priority – some issues are labeled high, medium, and low priority. I usually pick up the higher-priority ones first, if possible.
• WordPress version – indicates for which version the issue is focused.
• New document – indicates that the issue is a request for a new article. Any issue that doesn’t have this label is usually a request to update an existing article.

We also have a different way to see the repository. For example, we can see the repository based on the WordPress version project with a kanban board.

This view is mainly used when we do the issue triage meeting and assign team members for important issues.

After I pick and assign myself to an issue, I’ll start working on it. If it’s an update request, I usually put the necessary text and image on the GitHub issue’s comment section so that another reviewer can double-check them. Or, if it’s a simple update like replacing some screenshots, I’ll do it straight from the WordPress dashboard and update the live article directly.

Things are a bit different if it’s a new document request. In this case, I’ll create a new Google Docs to write the draft. Then, my colleague from our Five for the Future team (who is also a Docs team reviewer) will do the edits and double-check before finally sending the Google Docs draft to the GitHub issue. From that point, the draft can be moved to the WordPress back-end and published.

As A Reviewer

Not long ago, I was appointed as one of the reviewers for the user documentation category. The workflow is not that different from being a writer – it starts with picking up an issue.

In this case, I mainly use the project view, as it’s easier to see which issues need to be reviewed. The prioritization is also similar – I’ll look for higher-priority issues first.

Once I’ve picked an issue, I’ll look into the draft and check the following things:

• Grammar and overall quality of the writing. I’ll make some edits if necessary.
• Style guide compliance.
• Screenshots relevance.

If everything is good, I’ll move the draft to WordPress back-end and publish it. Moving content from GitHub is quite straightforward. However, moving content, especially screenshots, from Google Docs is not just a copy-paste job. Images have to be downloaded first and then uploaded to WordPress manually. This is because copy-pasting the images will effectively make the images hosted from Google, not the WordPress site.

Before publishing the draft, I double-check, including adding alt texts for all images. After I feel satisfied with everything, I’ll click that Publish button.

How to Join the Docs Team

As I explained earlier, you’ll need the required accounts to start contributing and join the #Docs Slack channel. Check out this Documentation Team post to find useful resources and onboarding links. Then, you can start picking up issues from the GitHub repository.

Some issues have the good first issue label, indicating that they are simple tasks suitable for beginners. To pick up the issue, simply leave a comment on the issue, something like “Hey, I’d like to work on this issue,” and the Docs repository member will assign you to that issue.

If you need help, you can always ask questions on the #Docs channel. We also have a regular meeting every Tuesday from 14:00-15:00 UTC.