Training Team Profile Badges – Final Proposal

The Training Team proposes the following criteria for their profile badges:

  • Team On-boarding (Required): You have joined the #training channel in Slack, been added to the Trello board and the GitHub organization. You have read through the Getting Started information ( and are familiar with the lesson plan template, the team’s workflow, and the teams tools (GitHub, ZenHub, and Trello). You understand the various channels of communication and know when and how they should be used.
  • Training Contributor:
    • Writing – You have developed an approved lesson plan from scratch or completely rewritten one that was out of date. Your efforts have moved a lesson plan from the “Drafts in Progress” stage to the “Instructional Review” stage in Trello.
    • Copyediting/Reviewing – You have contributed five (5) pull requests in GitHub. Or you have successfully moved a lesson plan from the “Copyediting in Progress” stage to the “Style Guide Review” stage OR from the “Style Guide Review” stage to the “Ready for Final Review” stage in Trello.
    • Testing – You have completed a testing feedback form after using a lesson plan in an event and have created GitHub issues for any suggested changes.
    • Auditing – You have audited three (3) lesson plans or surveyed the team’s GitHub repos and created GitHub issues for any needed changes.
    • Connecting – You have made three (3) workshop recommendations by combining existing lesson plans and submitting your ideas through the site (when ready).
    • Other – the team may choose to award the badge for other contributions at the team’s discretion.
  • Training Team: You have admin rights on GitHub, Trello, ZenHub, and/or the site. You assist with final reviews of lesson plans. You regularly contribute to meetings or the maintenance and management of the team. You have been involved within the past twelve months.

Awarding of profile badges: There will be a monthly review of contributions, and badges will be awarded at that time. A list of the new profile badges awarded will then be posted on the site. If you feel that you have earned the badge but were not listed, please leave a comment on that month’s blog post and include your GitHub username and your username.

#badges, #procedures

Training Team Profile Badges

There has been a recent flurry of pull requests from people new to the Training Team. Most of these pull requests are fixing small issues with the lesson plans – and we have many of those! However, these contributors have not introduced themselves to the team in Slack or participated in the team’s meetings. Their efforts are seemingly to procure the Training Team badge on their profile. That raises the issue of what the requirements are to secure those badges.

The Training Team would like to be more transparent and consistent and define the criteria for giving profile badges to people who contribute to our team.

Other Teams

Looking at how a few other non-code-focused teams handle their badges…

The Meta Team

“On your profile, badges are added based on your contributions to the WordPress project. There are two kinds of badges: contributor and team. The contributor badges are generally assigned to anyone who has contributed to a particular team. Meanwhile, the team badges are given to those who are active on their team. Each team can set its own criteria for who should get each badge. When possible, the meta team will automate badge assignment.”


The Polyglots Team

The Polyglots Team requires ten string translations to earn their Contributor badge. The also have an “Editor” badge which is given when a person has Editor status on a [locale] site.

The Support Team

“We have official badges for Support Contributors and Support team members. For the moment being, these badges are awarded manually to active contributors. In the future, we hope to be able to automate that process, and then use the following criteria:

  • Support Contributor: You have contributed over 400 support replies.
  • Support Team: You have been promoted to Moderator.”


The Documentation Team

The documentation team is probably the team that is the closest to the Training Team in their responsibilities. They do not yet have criteria for their badges but are also working on this.

Recommendation for Discussion

One-time contributions are very welcome, but perhaps not the purpose of the badges. As a starting point for discussion, let’s consider the following:

  • Training Contributor:
    • Writing – You have developed an approved lesson plan from scratch or completely rewritten one that was out of date.
    • Copyediting / Reviewing – You have contributed 10 pull requests over a period of more than 30 days.
    • Testing – You have completed 3 testing feedback forms after using a lesson plan in an event.
    • Auditing – Review 3 lesson plans and create GitHub issues for any needed changes.
    • Connecting – Make 3 workshop recommendations by combining existing lesson plans.
  • Training Team: You have admin rights on GitHub and/or the site.

Too easy? Too difficult? Does it deter people or encourage them? Is the “over 30 days” part a good idea? Thoughts? These criteria are up for discussion!

Time to Set Team Goals for 2019

It’s that time of year when we need to evaluate how we did against our goals for this year and make new goals for the upcoming year.

In 2018 our goals were to:

1. Create handbook
2. Move lesson plans to GitHub
3. Restructure
4. Fix broken images
5. Update lesson plans for 4.8-4.9/Gutenberg
6. Make workshop recommendations
7. Accessibility workshop

In fact, 2018 was a year where the team underwent a major restructuring of its tool and processes and we accomplished goals we hadn’t imagined when the year started. So our accomplishments for the year can be summed up as:

1. Create handbook (expected by the end of the year)
2. Move lesson plans to GitHub
3. Restructure
4. Fix broken images (perhaps not all are fixed, but moving to GitHub addressed the problem)
5. Make workshop recommendations
6. Onboarding improvements including a PDF and videos
7. Team management on Trello and in
8. Creation of the page
9. Work towards the relaunch of the site including collaboration with the #design, #marketing, and #meta teams.

Goals that we didn’t quite accomplish include:

1. Update lesson plans for Gutenberg
2. Accessibility workshop

So, for 2019 what should our new goals be? I’d propose a couple to begin with:

1. Launch
2. Create several lesson plans to combine into an accessibility workshop (the ARIA session from WordCamp US has caught my eye…)
3. Use resources from more often as a basis for lesson plans
4. Collaborate with other efforts such as the diversity speaker training and Kids Camp to get their material available from the site
5. Increase the number of regular contributors to the team

These all seem very do-able. What else should the team be working towards? What should we have for stretch goals? All comments and ideas welcome!

We’ll also be discussing this during our meeting this week. Everyone is invited to join in the discussion!!!

Proposed Handbook Outline


  1. About
    1. What we do
    2. Origin story
    3. Vision
    4. Tasks
    5. Team leadership
  2. Get Involved
    1. First steps
    2. Contributor Day
      1. Organize
      2. Participate
    3. Areas to contribute
      1. Present a lesson & Feedback
      2. Write a lesson
      3. Review lesson plans
      4. Other
  3. Communication
    1. Meetings
      1. agenda/notes etc P2
      2. Slack
    2. Trello
    3. Github
    4. Creating meeting notes
  4. General Guides
    1. Style Guide
      1. Tools (screenshots)
      2. Lesson plan
        1. Template
        2. Example
      3. Slides
        1. Template
        2. Example
    2. Presenting
      1. Single plans
      2. Workshop
  5. Roadmap
  6. Learn WordPress site
  7. Resources
  8. FAQ
  9. Old lessons (until Learn launches)

WordCamp US 2016 Contributor Day Planning

WordCamp US is approaching and will be in Philadelphia in early December, with a contributor day on the 4th. Since this will be an opportunity for many contributors of the training team to meet in person we want to make sure we’re gathering a list of all of the items we’d like to address as a team beforehand to make the most efficient use of our time together.

We’ll chat about this subject over the next few weeks in team meetings and will use this post as a place to store our thoughts and asynchronously share our ideas.

Please add your ideas in the comments!

Copyediting Process and Tools for Lesson Plans

The topic of what process should be used for copyediting lesson plans and what tools could be used came up during the October 11 Make WordPress Training Meeting. During the Slack discussion, questions arose about how team members should handle copyediting concerns.

  • Is there a definitive process for new copy editors to follow?
    • What basic guidelines should be followed?
  • How are editing changes handled?
    • Make style edits on the fly?
      • Revisions track changes
    • How to handle major edits?
      • Use strikethrough to flag deletions?
      • Use highlighting to flag additions?
      • Create a new document when rewriting?
      • Need review before committing?
        • By original writer or another editor?
  • What is the difference between copyediting and rewriting?
  • Does the copy editor need to contact the original writer?
  • How should comments be relayed between writers and editors?
  • Can we add a plugin to provide built-in features for extensive editing?

The Make WordPress Training Getting Started page indicates the various roles of contributors on the Training Team:

  • Writing – Create lesson plans.
  • Copyediting – Check lesson plans for grammar, spelling and punctuation and make sure it aligns with our style guide.
  • Testing – Help run tests of beta lessons at Meetups or workshops and let us know how it went.
  • Auditing – Check content for accuracy with the current version of WordPress
  • Connecting – Group lesson plans that together would coordinate for a workshop
  • Reviewing – Screenshots to compare with current appearances

The workflow for Training Lesson Plans is tracked on a Google Apps Sheet: WP Community Training Lesson Plan Progress as in the Getting Started section. The general workflow for lessons is tracked in a Status field:

  1. In Progress
  2. Ready for copyediting
  3. In Copyediting
  4. Ready for testing
  5. Complete

In addition there is tracking of lesson assignments with the following fields:

  • Current Owner
  • Username
  • Previous Owners
  • Progress
    • Started
    • Date to Complete
  • Team Review
    • Copy Editor
    • Status
  • Final Review
    • Testing Stage
    • Testing Results
  • Ongoing Review

There is a Key tab in the Progress Sheet, but that appears to be out of date:

  • correct
  • needs copyeditor recheck
  • abandoned
  • possibly abandoned
  • Ready to Test

Make WordPress Training includes two guides for writing and editing lesson plans:

There is a set of guides and tracking documents already in place; it seems they could be reviewed for updates and documentation to clarify the copyediting process.

Plugin features would be helpful for copyediting tasks and workflow for published lesson plans. However, with editorial tracking already in place with the Progress sheet, the plugin does not need to recreate nor constrain that part of the process.

Some potential solutions:

  • Revisions to backtrack editorial changes
  • Apply strikethrough & color coding to text during editing for review
  • Google G Suite Docs
    • Revisions History
    • Suggestions
    • Comments
      • Tag user
    • Bookmarks
    • Footnotes
    • Research Tool
    • Dictionary
    • Offline mode
  • Editflow plugin:
    • Calendar – A convenient month-by-month look at your content.
    • Custom Statuses – Define the key stages to your workflow.
    • Editorial Comments – Threaded commenting in the admin for private discussion between writers and editors.
    • Editorial Metadata – Keep track of the important details.
    • Notifications – Receive timely updates on the content you’re following.
    • Story Budget – View your upcoming content budget.
    • User Groups – Keep your users organized by department or function.
  • JetPack plugin—After the Deadline:
    • Contextual Spell Checking
    • Advanced Style Checking
    • Intelligent Grammar Checking

Are there other copyediting concerns or potential solutions?

User Experience of Training Team Make Site

Folks in the training team have collectively provided bits of feedback about the current structure of the Make site for the team for a little while. This conversation turned into more of an in-depth evaluation of the site and it’s purpose at WordCamp NYC’s contributor day this past month. In this post, I’m summarizing some of the key pieces of that conversation (myself, @melindahelt and @Becks979 attended) and applying pieces of that conversation to the current structure of the website. Please add your thoughts as to what pieces of the website need to shift in the comments of this post.

General Thoughts

  1. It needs to be more clear that there are completed lesson plans that can be used in real life.
    • I’m starting to think that the “Lesson Plans” navigation item should lead to a landing page that describes the available workshops rather than the long list of workshops in progress.
  2. Examples that show different ways to use the lesson plans would be helpful
    • We could include case studies, for example, that show how the plans have been used at a meetup, at a mini-workshop, at a conference, etc.
  3. We need a handbook.
    • Most Make teams have a handbook that contains the logistical information about how to contribute to the team and how the team self-organizes. This information is scattered across our site currently and needs to be gathered into one location (e.g. style guide,
  4. The lesson plans in progress need an explanation.
    • The handbook on the site is currently used to house the in-progress lesson plans, which is confusing due to it’s inclusion of partially completed plans. An introduction on the first page that explains what this is – and what it isn’t – would be helpful.
  5. Inconsistent use of tagging/categories
    • At different times, folks have categorized/tagged the blog posts on the site differently, leading to a somewhat meaningless structure. @courtneyengle had started to clean this up at one point and perhaps this is something we should revisit.
  6. Areas of Focus
    • The “Areas of Focus” block on the sidebar was intended to be an easy way to find the threads that relate to current conversations the team was having. It hasn’t been used as such much this year, though we were very consistent about using it this way during the second half of 2015. Perhaps this section should be renamed something like “current priorities”? Some of the content linked from it now should really go in a handbook instead and we could use it to bookmark key blog posts instead?
  7. Rethinking the blue box
    • I think revisiting the description of what the team is (e.g. are the lesson plans really “downloadable” as we describe?) could be important. We also should use this area to promote the use of lesson plans that already exist as well as contributing to the team in other ways (the list of which we should also review).

Some Specific Changes

  1. Teacher Resources – this page needs to be rewritten to be in line with the lesson plans that we’ve created and to rely less on outside resources.
  2. An FYI, I changed the time of the meeting on the contact form to the new time.
  3. There are some pages that may not make sense to include any more given the current direction of the team: proposed theme lessons, proposed user lessons, project status.

Please add your reactions to any of these ideas, suggestions of changes we can make to improve the user experience of the website, and any other thoughts about the website in the comments!



Do we want to change our meeting time?

In yesterday’s team meeting we discussed that the current meeting time (17:00 UTC on Tuesdays) may not be the best meeting time for folks anymore and decided that we should poll everyone and evaluate whether or not we should move the time. Once we have a sense of our internal availability, we’ll check these times against the times of the other WordPress team meetings to make sure those aren’t overlapping with our meeting either.

And so, a few questions for everyone:

  1. Is the current meeting time problematic for you?
  2. Are there other times/days of the week that would definitely not work?
  3. Are there other times/days of the week that would be much better for you?

Please comment on this post and we’ll discuss in next week’s team meeting! In your comments, make sure to specify availability either in UTC time or to specify the time zone that you’re referring to.

Troubleshooting Workshop Outline

There was a troubleshooting workshop that was put together years ago by some awesome people in the community. In March, I reached out to @ipstenu, who shared the troubleshooting resources from the workshop held years ago. They are located at and we have permission to use the materials and reformulate them for our lesson plans. Per the group’s initial conversations about this subject, we thought the first step to adapt these lessons for the training team is to inventory what is there and make a list of lessons that could be made out of it and then piece together what needs to happen from there.

The original workshop that was conducted using these resources is described here: The original workshop included the following description for potential students to make sure that folks with the skills to make use of the workshop material were the ones who attended the workshop:

For this course to make sense, students need to have the following experience:

  • Currently the admin of at least one self-hosted WordPress site (i.e., not on, with access to your hosting account and domain registration.
  • Know how to edit settings, manage widgets and menus, update WordPress/themes/plugins, add themes/plugins — in other words, you manage a site vs. just creating content on a site managed by someone else.
  • Able to recognize CSS and HTML, and know at least some of the basic tags/attributes (like href, strong, etc)
  • Have a username (can be new account, doesn’t need to be super active).
  • Have used FTP before.

If you have any experience with SQL (phpMyAdmin is fine), SSH, and/or manually installing WordPress, that’s a plus, but not required.

You do not not need to know PHP or JavaScript for this workshop.

I went through the whole website that @ipstenu created and have created a basic list of what resources are there and what we already have that could fit together in a workshop. A significant amount of the content on the site is actually individual troubleshooting exercises, so I went back to my notes from the inaugural workshop (which coincidentally I attended and thankfully still have the notes from!) to fill in some other pieces in this outline.

All of these exercises need to be done on a local install as they are dangerous to do on the real internet. We already have a lesson plan for local installs (yay!) BUT we could take a look at the breakfix version and see if there is anything from it that would be helpful to pull. In terms of lessons I outlined titles and relevant pages from the website or just bullets from my notes/thoughts.

Troubleshooting Basics

Local Install


Backing up Your WP Site


How to Create a phpinfo() Page for Debugging

  • include material from and

Basic Troubleshooting Process

  • Where is the problem? Is it in a plugin, a theme, or somewhere in core?
  • What is the full error message?
  • If plugin or theme is from the rep/download it and look at the code to see if it matches the code on your site. and
  • Look at the error and the file, see if things match.
  • How to report a problem in the forums

Exercises: Debugging Theme and Plugin Issues

Fixing a Broken Theme with Syntax Error


Fixing a Theme Where CSS Changes Are Not Visible

  • clearing browser cache

Debugging Basic CSS Problems in Themes

  • I didn’t have a lot of notes from this part of the workshop, but I remember it being something where we looked at specific problems in themes and then talked through how to inspect and solve each problem.

Recovering from the White Screen of Death

  • turn off all plugins & bring back one by one
  • switch to default theme
  • use a maintenance mode plugin

Recovering from Changing the URL of the Site

  • change site URL via PHPMyAdmin, clear cache

Recovering from a Plugin that Triggers a Fatal Error on Activation


Fixing Plugin with Headers Already Sent Error on Activation


Debugging a Fatal Error when Plugin is Activated and Theme is Switched


Reviewing and Fixing an Intentionally Vulnerable Plugin

  • review:
  • fix:

Exercises: Debugging Hacks

Debugging an .htaccess Redirect Hack


Debugging a Plugin that Automatically Changes User Passwords


Debugging a Hacked Site that Redirects Non-Logged In Users Elsewhere


This outline is fairly comprehensive for an initial outline of such a workshop, but begs a few questions that were raised by folks on the team in our meeting last week (thanks @melindahelt and @chanthaboune!), namely:

  1. Would these plans necessarily fit with our “format”? If no, is that a problem?
  2. We had the format that we did so that each item could be modular. Can this material be approached in a modular fashion, or do you need to go in order to build on the skill set?
  3. How do we break up these materials into lesson plans? I’m in favor of keeping the individual exercises as their own little plans and having some more general plans that cover the other things.
  4. Would it be possible to leave these materials intact, for the most part, and flag sections that can be used as parts of other training workshops?
  5. Is the idea still to write this in a way that “anyone” can pick it up and teach it (like we did with other LPs) or do you need more of a technical background to be able to make sense of it and more importantly, answer questions?

Next steps on this set of lessons are as follows:

  1. Gather feedback from the group. What do we think of all of this? Are there more considerations we haven’t thought of that should influence how we structure this?
  2. Go through and check the materials to make sure they are still accurate.
  3. Per the questions above, decide what format to present these materials in.
  4. Decide on an outline for the workshop, using the list of plans in this post as a jumping off point.
  5. Write lesson plans for anything that is included in the outline, but that we don’t have written materials for.

Please add your thoughts/comments/feedback/etc. in the comments. All of this will be incredibly valuable as we move forward with making our first troubleshooting workshop!

Common Styling Issues in Lesson Plans

In last week’s team meeting, I brought up a few common styling issues that copy editors have noticed while editing lesson plans. As promised, I’m expanding that list here. For more details on many of the items referenced in this list, please refer to the style guide.

Issues we’ve seen frequently include:

  • Lots of different kinds of quiz formatting. The quiz formatting is outlined in the style guide, so take a look at that when writing out quiz questions.
  • Random horizontal rules. We don’t need these to separate major sections (e.g. “Teacher Notes” from the “Hands-On Walkthrough”), but watch out for them because they are included in some plan drafts that were created a long time ago. Please DO use horizontal rules if they make sense to separate sections of content within the hands-on walkthrough section.
  • Capitalizing WordPress specific terms and phrases like “Posts,” for example. Unless a word is a proper noun in general, we don’t need to capitalize it.
  • Absence of punctuation. Sentences should always end with the appropriate punctuation!
  • Misspelling of WordPress. WordPress has a capital “P” and should never ever be spelled with a lower case “p.”
  • Inclusion of random notes. Once you’re done with your lesson plan, make sure you’ve deleted any notes you wrote to yourself as you were working!
  • Absent quizzes. Be sure to include 1-3 quiz questions for your lesson plan. If you’re not sure what the questions should be, that’s ok. In this case, flag that the quizzes are absent before sending the plan to copyediting.
  • Absent exercises. Be sure to include an exercise that would take approximately 5-10 minutes to accomplish. As with quizzes, if you’re not sure what the exercise should be, flag that an exercise is absent before sending the plan to copyediting.

We’ll be using this list to create a checklist for lesson plan authors to go through before submitting their plans for copyediting and for copy editors to use while editing, so please list any additional items you’ve noticed in the comments!