Multisite Recap for the week of June 26th

Office Hours Recap

The agenda for this office hours meeting included/was continue the previous week’s discussion on component maintenance with a particular focus on onboarding of new contributors.

The meeting’s chat log

Attendees: @afragen @desrosj @drew @earnjam @flixos90 @jjj @maximeculea @pmbaldha @spacedmonkey @stevenkword

Chat Summary:

  • Weekly agenda and recap posts should be published. Preferably responsibility for these should rotate between contributors.
    • To make the process of writing such posts easier and more consistent, boilerplates are available as 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. https://github.com/ gists (for agenda posts and recap posts). These are drafts and open to feedback, but should be used as a foundation for new make posts from now on.
  • Regarding new contributors, the main priority is to ensure those who are interested find their spot. It should be as intuitive as possible where and how to help.
    • Long-term contributors, particularly the person running the meeting should make sure to ask who is around initially and preferably reach out to new people after the meeting per DM to offer help. Even those who are only reading along should be encouraged to let everyone else know they’re around and interested.
    • Having a multisitemultisite 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 setup available in the basic VVV configuration would be very helpful. There is an inofficial temporary solution available, which is not quite the best approach to solving the problem, but yet it should be considered to be added in the official setup until a better solution is available (which might take some time to work on). This topic will be picked up again once VVV maintainer @jeremyfelt is back around.
    • More efforts should be put into gardening tickets with the good-first-bug keyword. Several of those tickets already have a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., but are not obviously highlighted as such, others have turned out to be far too complex, making the search for such tickets time-consuming and possibly frustrating. This particularly affects the agenda of weekly ticketticket Created for both bug reports and feature development on the bug tracker. scrub meetings.
    • Anytime when looking at tickets, it is important to not only take tickets in the “Networks and Sites” component into account, but also those that have the “multisite” focus applied. The latter group gets overlooked by the multisite team too often. This Trac query is a good starting point.
    • An idea from the community summit about a mentorship program was brought up. It may be useful to invest possibilities to dedicate a specific mentor to each new contributor that is interested. This should be discussed in a broader scope though, together with other components.
    • A common issue for new contributors is that sometimes TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets are overlooked or no action taken. Sometimes even when tickets are assigned, it’s a long time for any action or response. Regardless of whether a ticket simply needs more discussion, whether it is considered low priority or too complex to tackle at the moment, the multisite team should ensure to always provide at least a response about why a certain ticket is in its current state. More precise workflow keywords could help describe a ticket’s state as well. Having a weekly ticket scrub is at least a good starting point as it gives a chance to look at those tickets more regularly.
    • A few minor workflow issues with tickets could be improved. An idea was to automatically apply the has-patch keyword once a new patch is uploaded.
  • While the original agenda included discussing the improvements to the sites APIAPI 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., this discussion was postponed to a later meeting.
  • Several contributors were not aware of the weekly ticket scrub. It should be added to the list of meetings on https://make.wordpress.org/core/. A further idea was to set up reminders for both meetings on Slack.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub included/was to look through multisite tickets without a response and provide feedback.

The meeting’s chat log

Attendees: @andy @desrosj @earnjam @flixos90 @jmdodd @kraft @pmbaldha @sergey

Chat Summary:

  • We got the count of tickets without a response from 14 to 6. One ticket was committed, the others are either on a good way or further feedback or updates have been requested. The process will continue next week to hopefully get that list to a count of 0.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary