Welcome to the official home of the WordPress documentation team.
This team is responsible for coordinating all documentation initiatives around WordPress, including the Codex (moving to HelpHub and DevHub), handbooks, parts of developer.wordpress.orgWordPress.orgThe 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/, admin help, inline docs, and other general wordsmithing across the WordPress project.
Want to get involved?
There are many ways in which you can help the Docs team. Every small contribution counts and helps! You can report an issue or typo you found in the docs, or even help us write new documentation for parts that are still missing. These are some helpful links to find out more about what we do and how to collaborate:
Block Editor Handbook: An overview of documentation contributions of BlockBlockBlock 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 / GutenbergGutenbergThe 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/
Documentation Issue Tracker on GitHub: Submit any DevHub/HelpHub/”Doc Team Handbook” Docs-related issue on GitHubGitHubGitHub 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/.
Join our discussions of documentation issues here on the blog and on Slack.
GitHubGitHubGitHub 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/
Assign contributors who express the interest to work on the issue.
Welcome assigned contributors with information about the docs project the issue belongs to: who is the project rep, onboarding docs/video for the project if exists, and where to go to ask for help (meeting time and place).
Check project boards and make sure issues are in appropriate columns (Todo, In progress, Review, etc)
How do I do this job?
Subscribe to issues for the repository and review every newly created one. Apply appropriate labels (should be familiar with all docs projects and their labels).
Assign interested contributor to the issue. Contributor needs to post a comment on the issue, expressing their interest to work on the issue (otherwise we can’t assign them – GitHub settings).
Post a comment with following info (these could be premade templates):
Thank contributor for volunteering to work on the issue.
Username of the project rep or any other person responsible for reviewing the work and helping if needed.
Link to onboarding section in team’s handbook (for project if exists).
Information about the next Docs team meeting (time, date and place) where contributor can ask for help and/or report on progress.
Move issue to appropriate project column (In progress, Review etc) where applicable.
Monitor all issues marked for review. This is mostly for end user documentation and status can be seen in dedicated project boards. (e.g. 6.0 board, 6.1 board)
Monitor project board and make sure issues are in appropriate columns (Todo, In progress, Review, etc)
Review contributed content and/or media.
Follow the workflow for next steps (move issue to another column, assign other person, update article etc)
How do I do this job?
Check project boards and move issues to appropriate project column (In progress, Review etc) where applicable.
Review new content and/or compare it to existing article. Follow todo list and check each completed item.
Request changes/updates if applicable. Otherwise note in comment that everything is completed.
Some issues require two reviews. Depending on this following steps can be:
Move issue to next review column and pingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” other reviewers.
Move issue to Ready to publish column and ask contributor if they want to update the article themselves.
Move issue to Ready to publish column and update/create the article.
Onboarding process can last anywhere between 7 days and 4 weeks, depending on contributor’s prior knowledge, skills, and experience. During this period potential new contributor should learn about documentation projects, team members and other contributors, and all the ways in which they can contribute to the Documentation team. It is not mandatory to attend Documentation team meetings (time zones can be difficult) but it is advisable, for all members of course.
During onboarding period new contributor can start contributing by facilitating the meeting or writing meeting notes. These are great ways to meet the team and get familiarised with all the projects and current priorities. If desired, new contributor can start contributing with other tasks as well.
Welcoming new people in #docs Slack channel.
Introducing all Documentation projects to new contributors and helping them find tasks that match their interest and skills.
Enabling new contributors to independently contribute to any documentation project after the onboarding period – in a way to know where to look for information and who to talk to in order to learn more.
How do I do this job?
Familiarise yourself with all documentation projects and their representatives – basically what we have in onboarding videos.
Greet all new members in #docs Slack channel and offer help with onborading.
Communicate regularly with contributors who expressed wish to contribute – at least once a week checking up on them and replying to all their questions meanwhile.
Mention members going through onboarding process at the Documentation team meetings – Project updates agenda item.
After onboarding period is completed, officially welcome new contributors at the Documentation team meetings – Project updates agenda item.
It is NOT expected from Docs team Contributor DayContributor DayContributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. Facilitator to organise the event. Docs team Contributor Day Facilitator is a person who represents the Documentation team at such event, organised by other people. In following description I will be using “table lead” term as it is more commonly used in WordCampWordCampWordCamps 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. and Contributor Day vocabulary.
Presenting documentation tasks for the day, either to all attendees or just to the group of people who registered for the Documentation team (this depends on how organisers of the event want to start the day).
Basic onboarding for first timers – it is not unusual that people without wordpress.orgWordPress.orgThe 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/ accounts attend Contributor Days, for some it’s their first contact with open sourceOpen SourceOpen 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. community. Basic onboarding covers creating wordpress.org, WordPress Slack and GitHub accounts.
Collect all wordpress.org usernames so that Documentation contributor badges can be added to their profiles.
Helping out contributors at the table and answering their questions, or directing them to a person who can answer the questions.
Gathering info about completed work during the day and presenting it at the end of the day (if organisers have this planned).
Reporting on progress made and new contributors at the following Documentation team meeting.
How do I do this job?
If you are attending a WordCamp check with organisers if there will be Contributor Day (this is usually announced somewhere on the website) and if they already have someone to lead the Documentation team table – it is not unusual to have more than one lead so you can offer to help out if they do.
Once you know you’ll be leading the Documentation team table at Contributor Day, check with the Documentation team what could be good tasks for the day. This is best done at the Documentation team meetings – Open floor agenda item, but can be done anytime in #docs Slack channel if needed. You can also ping one of the team reps to help you out with this.
Contributor Day organisers will communicate with you about the schedule for the day and if you should prepare something – usually that’s just list of tasks from previous item.
At the beginning of the day organisers will introduce all teams and their table leads. They might present the tasks for each team or they will invite table leads to do that for their team.
Do not hesitate to bring the cookies to bribe contributors. This is, of course, a joke. However… it’s been tested and proven to attract undecided contributors and to have a certain impact in making the day more enjoyable and fun.
Help new contributors register all the necessary accounts (wordpress.org, WordPress Slack, and GitHub) and explain them the tasks they might work on. Explain the tasks to more experienced contributors.
Invite all contributors to join #docs Slack channel and communicate there anything regarding tasks they are working on.
Collect all the wordpress.org usernames so that we can give them contributor badges later.
Help contributors with any questions they might have. If you don’t know the answer, ask in Slack channel and someone will answer it.
At the end of the day present the progress being done during the day (organisers will invite all table leads to do so in closing remarks). This doesn’t need to be detailed, just some interesting statistics: number of new and total contributors, number of issues it’s been worked on, number of closed issues, how this progress is helpful for WordPress documentation in general etc
Present this same statistics at the following Documentation team meeting – Project updates agenda item.
Contributor Day goal
In general, Contributor Days are used for tasks that are, at the moment, higher priority for the team but also doable during the day so that all contributors can have a sense of accomplishment.
Some contributors just want to try out contributing to documentation, some want to keep contributing in the future and some contribute only during Contributor Days. Whichever the case, Contributor Day should be a pleasant experience where everyone feels welcome, enjoy the tasks and learning experience and, hopefully, decide to keep contributing in the future as well. It is table lead’s job to create such atmosphere.