Next steps for GitHub updates

Summary: This post gives a brief overview of what updates have been introduced to the team’s GitHubGitHub GitHub 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. project management system so far, and outlines the next updates being planned. If you’d like to get involved with the next round of process updates, please comment below 😃

Updates so far

The Training Team migrated its project management tool from Trello to GitHub in early 2022. Since then, different updates have been implemented to the team’s project boards. These have included:

  • Making use of GitHub-specific tools
  • Creating entirely new projects for new processes (such as content localization)
  • Ensuring current processes enable the growing number of contributors in the team to effectively contribute to the team goals
  • Triaging the backlog of issues accumulated from TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the team uses for example: days

The team handbook now also has documentation regarding the team’s GitHub repository structure, and step-by-step guides for different team processes that use GitHub. These can be found on How we use GitHub and its child pages.

Current issue – checklists

Training Team processes have relied on checklists for a long time. However, due to the way access is set up in the WordPress GitHub organization, GitHub checklists can generally only be ticked by those who added the checklist to the issue. This has made it difficult for multiple contributors to effectively collaborate on a single issue. The checklists added to issue templates have been somewhat ineffective, as the person who submits an issue is in many cases not the person who will actually work on the issue.

To get around this issue, an idea was brought forth to move GitHub checklists into the handbook, and direct contributors to copy-paste the checklists into GitHub issues when they work on an issue. This update has been implemented into the following administrative processes, and has received positive feedback so far.

Next steps

It’s time to make similar changes regarding checklists to content development processes next. Here are specific tasks that need to be completed:

  • Move checklists currently in content development issue templates into the handbook as markdown text which contributors can copy-paste as needed
  • Update issue templates and project interfaces to link to the respective handbook entries
  • Audit handbook entries around content development processes and update to reflect the new GitHub setup

Additionally, the team’s GitHub repository currently has 114 labels, of which 20 are not being used on any open issue. I suggest we audit the current list of labels and make sure they match the current processes and tracking needs in the team.

I will be able to start implementing these updates from July 31st, and am looking for one or two other volunteers to collaborate with. If you would like to get involved, please comment below, and I’ll discuss next steps with you!

Final thoughts

Switching project management tools is not an easy feat! I appreciate the efforts of Training Team members before me who got this work started.

The team also has a desire to implement automations into the GitHub repository to automate some of the manual processes. If you have experience with GitHub automations, and would like to help implement those into the team’s repository, please comment below.

#handbook, #process

Community Course Creation: A Proposal

Course creation is tough. It’s long; it’s laborious; but it’s glorious when finished.

I’d love to see more courses go live on WordPress – so, how can the community get involved in the creation of a collaborative course? 

I’ve written out some proposed steps we might take to create courses from start to finish. These are by no means permanent and are simply a suggestion of a process that may work.

The Overview (Visually)

A flowchart of the community course idea. It starts with a contributor having an idea; this contributor writes a proposal and submits it to the faculty program for review. This review can take anywhere from 48 hours to 1 week. If the faculty approves the course idea, they create a course github issue and assign a faculty buddy to help the contributor with learning objectives, audience, and micro-objectives (mini-lesson s that add up to a finished course project or "chunked" units). There will be a buddy planning conversation to generate these ideas. During their conversation, they will create a course project objective, focusing on what skills learners need to complete the course project. From there, they break the course into lesson plans; the content creator writes lesson plans and can collaborate with other training team contributors to create and complete lesson plans. As lesson plans are created, the creator's buddy can answer questions. Once all lesson plans have been completed, the training team will review all lesson plans using the normal process. After that, the buddy helps the creator create a course frame in; they reach out to the marketing team with a proposed "finished" course timeline. At the same time, the creator migrates lesson plan content to A final review is conducted by both the training team and the marketing team. Final changes are made, and the course is published. Finally, the marketing team promotes the content.


So you have a course idea. What should (could) you do first? (We have a documented process for this here, but this proposal aims to augment it to better serve the community).

  1. Write a Topic Proposal: I propose we create an intake form (a very simple one to start) on GitHubGitHub GitHub 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. for this that asks users what course they might like to write, briefly describe it, and submit resources that already exist on Learn that would help shape this course (lesson plans, workshops, etc.)
    1. Looking for Inspiration: What makes a good topic? 
      1. Check the team’s Github for existing high-priority lesson plans that might make a better course than lesson plan.
      2. Consider new WordPress releases: are there related lesson plans waiting to be written that would make a good course?
      3. At some point, we will have a completed Needs Analysis that will help us determine the most high-impact courses; this will be good to reference when it is created.
  2. Get Approval: The training team should likely review course topic proposals and set up a meeting with the course proposer, which could be done by a process we set up within the faculty program or reviewed as a team at the weekly meeting. 
    1. Note: Courses are extremely time intensive, so I would also suggest creating a buddy/faculty member check-in program around this in order to help contributors with their ideas.
    2. Github Issue: Once this proposal has been approved, we will create a Github issue
    3. A Question: What should the timeline be for review? Is 48 hours enough (this would require faculty managing this), or a week (the greater team could help with this during the weekly meeting)?
  3. Brainstorm Canvas: This would be an outline we provide as the training team, specifically to generate ideas about the audience for the course, overarching course objectives, and the micro-course objectives (that will be used to make up the lesson plans for the course). An example of what a Brainstorm Canvas could look like can be found here (rough draft). I would also be open to walking through this with folks if they were interested ahead of time! 
    1. This brainstorm canvas can be done individually or during a Zoom call with a buddy / other interested contributors.
    2. There are no right or wrong answers on the brainstorm to start; once the brainstorm has been completed, a faculty member (likely an instructional designer, but basically anyone who is approved) should be pinged to review course objectives and work with the contributor to polish learning objectives.
    3. What is the timeline on reviewing a brainstorm? Would a week be enough time?
  4. Map It! Each micro-objective from the brainstorm will become the learning objective for a lesson plan within a course (example)
    1. The course will be made up of lesson plans. 
      • Some lesson plans may already exist about that topic and may simply need to be modified for an online audience; 
    2. Other lesson plans will need to be created; these can be written either by the course creator, or with others assisting.
  1. Create the Course Frame: Once a user creates a map of the anticipated lesson plans within a course, they can get started creating the course structure within The 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.
    1. Write the introduction: This introduction should help learners assess their own readiness (readiness question), explain what a learner should be able to do at the end of the course, help learners set up what they need to be successful in the course, and establish several other things that are present in most lesson plan – need to be revised for courses, potential course outline to help users experience success here?
  2. Write each Lesson Plan on 
    1. These lesson plans should be included in the monthly sprint and recorded in Github.
    2. As you complete a rough draft of each of the lesson plans, make sure to keep the Github board updated and let the #training team know during the weekly meeting or as you complete it.
    3. Link each Github Lesson Plan to the course Github as they are created.
    4. One concern I have: There is a lot of “extra” (but important) information in each lesson plan that may distract students from the content they’re expecting to receive. We’ve talked about…
      1. Having a toggle button to show teachers what they need to know in order to teach content when pressed
      2. We may also consider ways to streamline the lesson plan creation process and/or the way content is displayed. 
      3. We also might want to consider if these lesson plans should be identical to the ones that exist already, or if we need a secondary format specifically geared towards online learning. For example, an existing lesson plan may say, “Put students into groups and have them discuss X topic” which wouldn’t work for an online, asynchronous format. 
  1. Rough Drafts to Finalized Versions: Completed lesson plans will go through the typical review process:
    1. It will be reviewed for content, copy edited (likely with this copy editing checklist), and for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). ( (making sure every image has a detailed alt text and descriptive title, that links are descriptive, and every video has a caption, to name a few examples)
    2. If a course is in progress, it may be useful to organize “mini sprints” to get feedback and insight from faculty members on all lesson plans in a timely manner.
  2. When all lesson plans / modules are complete, a final review will be conducted.
    1. We can make a brief checklist here to help faculty members and training team contributors review content quickly, but basically this is a final set of eyes on the finished product.
    2. At this point, we can publish the course!
    3. We may want to consider working with #marketing ahead of time to announce the course and get eyes on it, but in my view, not at the expense of slowing it getting it out into the world.
  3. PUBLISHED! The course goes live, and everyone celebrates.

What do you think of these proposed steps? What should be changed, added, or removed? 

Please leave your thoughts in the comments section here, and in a few weeks’ time, we will finalize how we would like to move forward. I will create a list of action items to be put into Github for what documents, supports, ettc. need to be created.

#contributors, #courses, #getting-involved, #process