During lunch at WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe, there was an informal discussion with some contributors who have an interest in multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site. 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 A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. 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 The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoint for sites and improving the user endpoint to support all multisite functionality. It is also likely that a networks API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://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 Created for both bug reports and feature development on the bug tracker. Gardening
As of this being published, there are 160 bug tickets for the multisite component in Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. 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 (versus network, site) 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 A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.. 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 Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
- Network (versus site, blog) 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
