Team roles - new Documentation team handbook page

[zzap]

What is the new page you are requesting?

The page that will hold description and responsibility for each team role in WordPress Documentation team.

How will this new page help you?

It will give clear(er) insight to all documentation contributors about the roles they can take on and ways to contribute to WordPress documentation.

• Update landing handbook page with link to this page when published - https://make.wordpress.org/docs/handbook/#:~:text=team%20roles

[zzap]

Team roles

Per responsibility:

• Team reps (representatives)
• Project reps
• Contributors

Non project roles:

• Facilitating
  • Meetings
  • Issue triages
• Writing meeting notes
• GitHub issues coordinator
  • Reviewer
• Onboarding coordinator
• Contributor Day facilitator

Project based roles:

1. Design
2. End user
   • General
   • Block editor
   • Feedback curator
3. Theme handbook
4. Plugin handbook
5. Common APIs
6. Code reference
   • More Info curator
   • User Notes curator
7. Block editor developer
8. Advanced administration
9. Docs team handbook

[zzap]

Meeting facilitator

Responsibilities:

• Post the agenda on the “Make Documentation” team blog.
• Lead the bi-weekly team meetings in Slack.

How do I do this job?

• Post the agenda in the Slack channel before the meeting (preferably several hours before). Writing agenda.
• Lead the discussion of the agenda in the Slack channel. Facilitating meetings.

Examples of previous agendas: https://make.wordpress.org/docs/tag/agenda/

Recommended onboarding sessions:

• Overview
• Contributor documentation – Documentation team handbook

[zzap]

Note taker/meeting summarizer

Responsibilities:

Take notes during weekly meetings and post them on the “Make Documentation” team blog.

How do I do this job?

• Take notes during (or after) the meeting.
• Post the minutes on “Make Documentation”.

Examples of previous summaries: https://make.wordpress.org/docs/tag/summary/

Recommended onboarding sessions:

• Overview
• Contributor documentation – Documentation team handbook

[zzap]

Project rep (representative)

A Project rep is a person who takes responsibility for the Documentation team’s projects, in parts or in whole.

This means that this person is a go-to person for all new contributors on the project. Also, a rep is monitoring progress of the project, or its parts, and reports on it during team meetings.

One person can be rep for one or more projects but also can be rep for one project and contributor for others. There is no limit to the number of reps per project. The more people take responsibility, the less pressure on one person there is.

Representative is a team member; one performing the role has both Documentation badges, contributor and team.

Anyone who is interested in becoming a rep can ask the appropriate rep for the project to be included or ask directly one of the team reps in Slack.

Responsibilities:

• Monitor and perform work on GitHub issues for their project.
• Guide contributors who want to help with the project.
• Update project documentation based on completed work in GitHub issues.
• Report on project progress at the Documentation team meetings.
• Recruit and onboard new contributors for the project.
• Plan and organise work and improvements of the project.
• Make sure project contributors receive their Contributor badges.

How do I do this job?

• Connect with and onboard contributors who expressed interest in helping to the project.
• Monitor GitHub issues for their project or projects. Label them when applicable.
• Work on those issues or guide contributors working on them.
• Review work of other contributors and guide them how to improve it if necessary.
• Update documentation in their project once the work inissues is completed; or guide other contributors in updating the docs.
• Post the list of completed or in progress GitHub issues at the Documentation team meetings - Project updates agenda item. Also, mention contributors working on those issues.
• Create a list of contributors who should receive Contributor profile badges and post it at the Documentation team meetings - Project updates agenda item.
• Organise work on the project (priorities, good first issues etc) and develop a plan for improving the project if the room is found. Always keeping the interest of documentation user as the top priority.

All Project reps have earned their Team badges by performing these contributions. Badges are manually added so if you have contributed to the Documentation team but don't have one, please contact one of the team reps. Read more about the Documentation team profile badges.

Recommended onboarding sessions:

• Overview
• Contributor documentation – Documentation team handbook

---

Related #639

[zzap]

GitHub issues coordinator

Responsibilities:

• Monitor all new issues created in GitHub repository and label them appropriately. Monitoring can also be done in #docs-firehose Slack channel.
• 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.

This role is complementing Issues triage facilitator and GitHub issues reviewer roles. Roles can collaborate and/or be performed by the same person.

Recommended onboarding sessions:

• Overview
• End user documentation
• Developer documentation – Plugin handbook
• Developer documentation – Themes handbook
• Developer documentation – Common APIs handbook
• Developer documentation – Block editor handbook
• Developer documentation – Code reference handbook
• Contributor documentation – Documentation team handbook

---

Related #640

[zzap]

Onboarding coordinator

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.

Responsibilities:

• 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.

Recommended onboarding sessions:

• Overview
• Contributor documentation – Documentation team handbook

[zzap]

Contributor Day facilitator

Contributor Days are usually organised as a part of WordCamp but can be standalone events as well.

It is NOT expected from Docs team 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 WordCamp and Contributor Day vocabulary.

Responsibilities:

• 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.org accounts attend Contributor Days, for some it's their first contact with open source 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.

Recommended onboarding sessions:

• Overview
• End user documentation
• Developer documentation – Plugin handbook
• Developer documentation – Themes handbook
• Developer documentation – Common APIs handbook
• Developer documentation – Block editor handbook
• Developer documentation – Code reference handbook
• Contributor documentation – Documentation team handbook

[zzap]

Issues triage facilitator

Responsibilities:

• Lead the bi-weekly issues triage in Slack.

How do I do this job?

• Prepare a list of urgent and/or abandoned issues found in Issue Tracker repo
• Lead the discussion about selected and other issues brought up by other members attending the triage in the Slack channel.
• Assign issues to contributors who express interest in working on issues.

This role is complementing GitHub issues coordinator role. Roles can collaborate and/or be performed by the same person.

Recommended onboarding sessions:

• Overview
• End user documentation
• Developer documentation – Plugin handbook
• Developer documentation – Themes handbook
• Developer documentation – Common APIs handbook
• Developer documentation – Block editor handbook
• Developer documentation – Code reference handbook
• Contributor documentation – Documentation team handbook