Development Weekly Chat Facilitation Guide

The OpenverseOpenverse Openverse is a search engine for openly-licensed media, including photos, audio, and video. Openverse is also the name for the collection of related code repositories that make up the project. Development weekly chat is a community focus meeting held in the #openverse channel on the Making WordPress Slack instance.

Meeting Objectives

  • Share any relevant announcements about the project
  • Check in with contributors to Openverse, with the goal of:
    • highlighting work they are proud of
    • unblocking in-progress work that needs help
  • High priority: Schedule the current work of Openverse contributors, providing as much clarity as possible into current objectives and goals.

Top ↑

Top ↑

How to facilitate the meeting

On the hour, when the meeting starts, post to the #openverse channel using the /here command. Here’s an example:

Example welcome message.

/here Hi everyone, it’s time for the Weekly Development Chat! This is weekly meeting to discuss active Openverse development. Today we’re starting a new two-week development cycle. Who’s here, and do you have any recent successes you would like to share?

Note that /here is used in place of @here due to restrictions on the Make WP SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at

At the start of the meeting it’s important to mention if we’re in the first or second week of one of our two-week work cycles. If you’re not sure, the easiest way to check where we are is to backscroll to the previous team meeting’s welcome message, or pingPing The 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.” @zackkrida or another Openverse contributor. If those fail, go ahead and ask during the meeting.

It’s also useful to post links to the GitHub Project Board (and optionally, the GitHub PR Board) so that folks can follow along with the prioritization.

During the meeting we follow along our 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 board, looking at ‘done’, ‘in progress’, and ‘completed’ work. In fourth and final part of the meeting we review any open agenda items. This should be handled as efficiently as possible with an emphasis on unblocking ongoing work and scheduling new work.

Each item here has an approximate timestamp and duration. This guide assumes the meeting starts at 15:00 UTC. The actual time may differ based on the time of year. Follow these time guidelines as best as you can; some of the most critical parts of the process happen towards the end of the meeting! Note that just even though the facilitator moves on and starts the next section, contributors can still participate in earlier conversations and threads as-needed.

The GitHub UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. to archive the ‘done’ column.
  1. [15:00-15:05] Done column. Ask contributors to highlight recently-completed work! Sharing this work keeps everyone informed about recent successes and helps others share their pride in their work. If there’s not much activity, you can either breeze past this information or choose some items you’re excited by to share. Items should be posted as standalone messages, not as part of a thread, so that a thread can be created per-item if any discussion is needed. This issues in the “Done” column should be archived in GitHub after the discussion. See above for what the GitHub UI looks like to archive the cards. You may also archive the “Merged” and “Closed” columns of the GitHub PR Board.
  2. [15:05-15:15]In progress. Ask contributors to share any blockers on their current work or work that is ready for PR review. There’s typically deep technical conversation here, with long threads to discuss the implementation of various features.
    1. Specifically be sure to check on any assigned critical issues.
  3. [15:15 – 15:30]To Do / Backlog. For these last few columns, we try to make sure that our sprint goals will be met by assigning new work to contributors. We do two-week long dev sprints and cut releases at the end of each sprint. Here, ask the community to share issues they would like to work on; or issues they think are important to get assigned.
    1. Review the unassigned non-blocked critical issues and high-priority issues. Encourage meeting participants to volunteer for these issues. Folks can either assign themselves directly in GitHub to issues, or you can ask them to reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. to issues in Slack with an emoji like 👋 :wave: to indicate their interest.
    2. Additionally (in particular for high-priority issues) ask meeting participants to review the list and confirm the priority of issues, especially high-priority issues that are older than two weeks.
  4. [15:30 – 15:45] Address any items in the agenda, recently opened discussions, and ask if anyone has something else to comment or ask that did not have a place in the previous points. If a resolution or decision was reached on an agenda item (e.g. an issue was assigned), please denote the result on the agenda (example from 2022-09-20).

At the end of the meeting, it’s common to send a message containing </meeting>, along with however you’d like to say goodbye.

Top ↑

General Tips

Suggestions and advice for running the meeting smoothly.

  • If new issues, bugs, or problems come up in conversation, encourage contributors to create a new issue. Contributors will often react to the issue request with an emoji, like a checkmark, once they’ve made the issue.
  • It’s really common for contributors to conduct code reviews for each other during the meeting. You might see a lot of PRs changing status rapidly.
  • Feel free to @ contributors directly if you have specific questions about their work, need a PR review from them, or other concerns.

Top ↑

After the meeting

After the meeting, a recap post should be posted to 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. Here are examples. It is easiest to duplicate a past recap post using the “New Draft” button and fill in the new information. The Site Admin URLURL A specific web address of a website or web page on the Internet, such as a website’s URL can be useful for this.

Screenshot of the “Clone” and “New Draft” buttons

Last updated: