During lunch at WordCamp Europe, there was an informal discussion with some contributors who have an interest in multisite. This post is meant to summarize those discussions and create a plan for organizing and improving the multisite component moving forward.

Present for discussions: @flixos90 @stephdau @spacemonkey @desrosj

Weekly Component Dev Chats

Because all contributors cannot be present every week, there have been a few instances where deep discussions have reoccurred in consecutive weeks due to a different set of people being present. This has slowed progress, and also limited feedback to only those who can attend.

The meeting discussions sometimes veer off course to items that are not necessarily a part of the current component goals. Weekly bug scrubs have also on occasion turned into detailed discussions (more on this later).

For these reasons the following items were proposed:

• Post a meeting agenda weekly at least one full day prior to scheduled dev chats.
• Post a meeting summary after the meeting.

The meeting agendas will help keep the conversations on target and ensure they are productive. They will also help contributors decide which meetings they want and need to attend. If someone has anything that they would like to contribute but is unable to attend, they can post a comment on the agenda post.

The meeting summaries will help inform all who were unable to attend by communicating what was discussed. It will also help prevent discussions from reoccurring in consecutive weeks when a different set of contributors are present. Anyone can also comment on the meeting summary with any additional feedback. If there is a lot of feedback on the summary, the topic can be slated for more discussion during the following week’s dev chat.

These two things have proven effective for both the Core and JavaScript chats, and should also help the multisite component.

Multisite Roadmap

In an ongoing effort that will continue through the next couple weeks, a component roadmap is being discussed. Roadmaps are great for identifying the current problems that should be solved in a general order and establishing a direction. The roadmap should also describe why each problem needs solving with examples, and what steps potentially could be taken to reach a solution.

By listing out the goals and needs of the component in the rough order they should be tackled, dev chats can be more targetted and the component can progress more effectively.

Currently, the primary goals of the multisite component are implementing a REST API endpoint for sites and improving the user endpoint to support all multisite functionality. It is also likely that a networks API endpoint will be introduced, although that is a lower priority than the other two. Sites and networks are the only WordPress core component without a REST API endpoint.

Information Sharing

Since WordPress.com has had a Sites endpoint for quite a while now, @stephdau shared some links after the meeting with the other attendees. He emphasized that nothing there is secret and there is a desire to share information and collaborate. He also stated that much of the code is actually packaged in Jetpack.

Ticket Gardening

As of this being published, there are 160 bug tickets for the multisite component in Trac. It would be great to decrease this. As mentioned above, weekly bug scrubs occasionally turn into continuation discussions of the previous dev chat. Having specific ticket lists to work through on a given day may help more effectively manage tickets belonging to the component, gardening them into the appropriate milestones.

@johnbillion also mentioned in a separate discussion that he has an offline list of multisite bugs that he has noticed. He will be going through Trac at some point to ensure each issue has a Trac ticket (although most already do).

Follow Up

As a follow-up to this meeting, @flixos90 created a Google Doc to help collect thoughts and serve as an organizational document for the multisite component.

Weekly Office Hours

The meeting’s chat log

Attendees: @jeremyfelt @flixos90 @johnjamesjacoby @desrosj @sergey @spacedmonkey @saracannon @stephdau @earnjam

This week’s office hours were used to recap the discussions above and gather further input. @flixos90 shared the Google Doc linked above, and then discussions were had to determine if the policies roughly outlined are viable for common procedures in multisite. Eventually, after the necessary tweaks are made to the document, it will be posted on this blog and on the Networks and Sites component page. This will ensure more permanent visibility and also allow other components to possibly follow some of the ideas for their workflows as well.

Key points summarized from the document by those who were at WCEU:

• Not repeating ourselves week to week is important. Meeting recaps will inform people who cannot attend office hours. Agendas will keep meetings focused.
• Responsibility for creating agenda and recap posts (especially the recaps as they’re more work) should rotate between multiple contributors. This is a great way to help onboard new contributors and foster interest in the component.
• There should be more targeted ticket lists to focus on during bug scrubs. Try to tackle the ones that relate to our roadmap goals and properly prioritize.

At times, the component does get a little slow. Even during these times, an agenda should still be posted. It was also decided that there should be one agenda post (stating the agenda for both the week’s upcoming bug scrub and office hours), and one summary per week. Having consistent agendas will help us stay on target. Establishing a roadmap as needed will also help. “The multisite group is currently focusing on these 3 things from X date to X date” could be a useful way to clearly state the current goals. This would fit well on the component page.

It was decided to change “bug scrub” to “ticket scrub” as it is not limited to discussing bugs. Also discussed was having people who can focus only on bug fixes without needing to worry about when new features will land around them. This would be very helpful to the component. Current contributors each have different strengths and utilizing these strengths effectively should be a priority.

Increased documentation around why decisions are made needs to happen. This will help future contributors understand why specific actions are taken, and why certain features are implemented how they are.

Better utilizing Trac’s “good first bug” was discussed. These tickets are very helpful for picking up new contributors and giving them a positive experience contributing to the component. Ensuring that good first bugs are in fact easy to fix is important. Good first bug tickets should not remain open for multiple releases though. Otherwise, there is a risk for a negative experience when the contribution is not immediately accepted. There was, however, some disagreement on this. Leaving easy fix tickets could be counter-productive.

There was also some post-meeting discussion about making multisite contributions to core easier. Currently, VVV does not allow a multisite install to be created using trunk. This would make writing and testing patches much easier.

Next week, @flixos90 will run office hours. @spacedmonkey will run office hours the week after that. The rough plan for office hours the next three weeks is:

• Continued discussion on component organization and, afterward, on the sites API
• Site meta
• Network meta

Next week’s ticket scrub will focus on tickets without a response followed by tickets awaiting review.

To conclude the meeting, @spacedmonkey was officially approved as a component maintainer. Congratulations!

If you’re interested, please come to our meetings or leave a comment on this post with your thoughts. Multisite office hours are held every Tuesday at 16:00 UTC, while our ticket scrub is held every Monday at 17:00 UTC, both in #core-multisite. The next ticket scrub will be Monday 17:00 UTC and the next office hours will be Tuesday 16:00 UTC.

#multisite, #networks-sites