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!



Screencasts: A New Old Visual Asset

Way back in 2014, when the make up of this team was a little different, it was suggested that we have screencasts to accompany each of the lesson plans. This was recently suggested again and it raised a lot of questions for us. Here are the big few that I saw/have been asking myself:

What is the Purpose of the Screencasts?

It would give us the chance to have a first pass at a lesson for accuracy and flow internally before it gets to testing. It will also be a good way for teachers to get an idea of the intended pacing of the lesson as they prep.

What Would This Screencast Look Like?

It would be a very rough run-through of any one lesson. From start to finish, a screencast would be the script and user-driven demo (that’s you, clicking through the actions described in the lesson) with no need for intro or exit language. So it would be your screen that we can see and your voice that we can hear.

Would It Replace the Need for Screenshots?

No, it wouldn’t. We could use the screencasts to get screenshots (possibly), but the screenshots will still be needed.

And my biggest question:

How Does This Fit in to Our Priority List?

There are a few ways this works in my mind:

  • Given that the words are Must Have content, we could prioritize that over anything else and call screencasts a Nice to Have (as in, we can add it later).
  • If we think we can use stills from the screencasts as screenshots, thus consolidating a little of our effort, we could call them a Should Have (as in, we can get through copyediting without them, but must have them before they are tested).
  • If we think they are essential to the lessons, or we have scads of people waiting for something to do, then we can put together a little mini-task force just for making the screencasts.

I’m happy and willing to help us work through any of these options. Let’s discuss what we think is the best fit for our plans moving forward.

Group Pings: BethChrissieChristina, CourtneyJosephaJulieKathyKimMeaghan, MelindaMicheleMikeScottTonia

Please also ping anyone I missed in the comments!

The Lessons We Most Need

After quite a bit of number crunching (item 4) and testing plan outreach, I think it’s time for us to rethink how we plan which lessons to write. We started out Q1 with 45 lessons and too few hands to get them done before the end of March, so I’d like to suggest a new plan for us.

The Givens

First, re: Volume of lessons. Even if we were to average about 20 minutes per lesson, 45 lessons going at a speedy pace would take 15 hours to teach. This seems too long for a Getting Started workshop and maybe a little too much information for new users regardless.

Second, re: Testing the lessons. I got some generally held feelings from Meetup organizers that each lesson isn’t necessarily long enough to allow it be tested individually. Some suggested it would be possible to use it as an intro to a larger topic, but then there was the question of how to get viable feedback from people who already know the content (a reasonable question).

The Solutions

I’d like to focus on groups of lessons at a time. I propose starting with:

  1. Feature Overview and Site Management units (14 lessons, 1/3 of the original total)…
  2. …with the intention of adding on installation (2 of 3 are complete)…
  3. …and intro to themes (1 of 3 are complete).
  4. Intro to plugins is already complete and needs one more round of testing to be ready for a workshop.

This way, we can lump things into units for testing and offer to groups as they become available. Two birds with one stone.

Your Thoughts!

I would love to hear any thoughts or concerns you have about this plan, or just a vote in favor or not if you have no thoughts in particular!

PostScript – The Lessons

These lessons are the six we are focusing on at the moment. Let us know in the comments if you’re working on one or need to ask for it to be reassigned!

4 Tiers for Workshops

As planned by @JenMylo during Community Summit

Tier 1: Getting to know WP

  • setup/install, use all features, intro to concepts of themes/plugins/core/open source
  • popular free plugins (the ones you put on every site you set up for someone)
  • where to learn more (, local communities, docs, etc)
  • jetpack (outsource to jetpack team for content creation since third-party plugin)
  • setting up a store (outsource to woo, other ecomm plugins)

Note: Goal: they can set up a site for a small business with the most commonly requested features and customize it using the dashboard. they become able to contribute in support forums (beginner questions) and doing subtitles

Tier 2: Leveling Up (assumes knowledge of HTML and CSS)

  • Troubleshooting basics (swipe old curriculum that @ipstenu is hosting still)
  • Intermediate troubleshooting (create more learning examples like what’s in the basics but harder)
  • Plugins & Themes: where to find them and what to do with them (how to tell a good one, dealing with conflicts, etc)
  • Modifying Code – child themes, customizing with css in jetpack (for simpler things that don’t need a whole new child theme, also bc it’s what is used on WC sites so they can contribute there), looking at plugin code

Note: Goal: they can do fancier sites, give better advice, do more in support forums, etc

Tier 3: Theming (assumes knowledge of html and css)

  • build a theme from _s (borrow heavily from the themeshaper tutorial)
  • php basics for theming
  • design and ux for theming
  • intro to the theme repo (include talk of licensing, code requirements for repo, etc)
  • submitting a theme to the theme repo, how theme reviews work

Note: Goal: they can build custom themes, can answer theming questions in forums, possibly start trying their hand at theme reviews

Tier 4: Specialized/Advanced skills

  • Build a plugin (and into repo)
  • Running multisite
  • BuddyPress, member plugins
  • Advanced troubleshooting
  • Contributing to core
  • JavaScript wackiness
  • More advanced PHP
  • all the things not covered in lower tiers

Note: Goal: they can become a wp professional, can contribute to any of our contrib teams