What’s new in Gutenberg? (18th August)

0.9.0 🐧

Other changes:

#core-editor, #editor, #gutenberg

Multisite Agenda for the week of August 21st

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Review progress on roadmap and related discussion.
  • Brainstorm about finding a solid way to check for the existence of the wp_blogs database table for site meta (see #37923).
  • Open floor regarding roadmap, related tickets and suggestions.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite. Note that neither @jeremyfelt nor @flixos90 are available for that meeting, so we are looking for someone to host this one. Please ping one of us on Slack if you’re interested, help is much appreciated. If you want to attend the meeting, please check #core-multisite on Monday to see whether the meeting will take place or has been cancelled. Here is the planned agenda:

  • Review and discuss #41344.
  • Review and discuss #40764.
  • Open floor for any multisite-related bugs and small enhancements.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

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

New Contributors Meeting Recap – August 16th

Yesterday, the new weekly contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @brainfork @clorith @davidmosterd @desrosj @dipeshkakadiya @drewapicture @flixos90 @geoffreyshilling @jnylen0 @johnbillion @joyously @justpeace @mikeschroder @milindmore22 @morganestes @mte90 @mrahmadawais @nabil_kadimi @sergey @stevenkword @zakkath

Discussion Highlights

Documentation on core unit test suite

  • There’s currently no documentation on the core unit testing suite in the handbook.
  • The current and best method for learning is to read some of the existing tests and see how they do it. With specific questions, @boone and @johnbillion are always good people to go to.
  • Several developers indicated their interest in working on an introduction or documentation for it. Any results will be published in a future meeting.

Documentation on contributing with Git

  • Documentation on Git contributions is still lacking. Most typical handbook pages with patch instructions only reference SVN commands and don’t have Git examples. @morganestes will start working on consolidating pages and instructions and would love to have some guidance on contributing tests as part of that.
  • @jnylen0 shared a handbook page specific to contributing with Git.

Documentation on getting started with contributing

  • There’s not a very good “Getting Started” documentation in the handbook. It throws several things at you in different pages. You can learn how things technically work, but not really how to get started from a workflow/mindest point of view.
  • @adamsilverstein shared what is probably the best “Getting Started” page for core contributing.
  • However where you start, to a large extent depends on your preferences. It’s important to find one or two areas of core in which you’re most interested in and concentrate on those first.
  • To get a feeling for what is being worked on and how these processes work, participating or even just lurking in meetings can help a lot. Show up to some dev chats, and other component meetings you’re interested in.
  • If you don’t need to do it remotely and have the possibility to attend a WordCamp, probably the best way to start is attending a contributor day. The in-person communication has huge benefits, especially for the beginning.

Moving tickets forward

  • Persistence is generally key in keeping your patches moving on trac. Knowing who to ping and how often can take you a long way. Start with the component maintainers and work out to the core developers. Ask for feedback at a dev chat, or if you don’t want to jump in yourself ask whomever is running dev chats to toss out the ticket for public discussion.
  • Ping specific people, don’t worry about being annoying or anything. It can happen that someone is short on time and does not respond immediately, and that may feel like a bummer. But every core developer is trying to help, so do not hesitate being persistent. Actually, component maintainters and core devs expect to get pinged and try to make core contributing as welcome as possible.
  • The easiest way to get in touch is commonly in a component meeting if there is one. But if there is none, pinging a maintainer is the way to go.

Changing workflow keywords on tickets

  • Everyone can and should properly apply and modify workflow keywords on a ticket. Here are some examples:
    • If you add a patch, add the has-patch keyword if it isn’t set yet.
    • If you provide tests, add the has-unit-tests keyword if it isn’t set yet.
    • If you feel a patch is rather complex, feel free to add dev-feedback.
  • If you aren’t sure that your patch addresses the issue, or if you don’t feel that you understand the issue well, it’s best to let someone else look and change the keywords appropriately. But also no worries, if you accidentally or mistakenly set a “wrong” keyword.

Next Week’s Meeting

The next meeting will take place in the #core slack channel on Wednesday, August 23, 19:00 UTC. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @stevenkword, @welcher) with questions on Slack. Or, as mentioned above, to any core developer or component maintainer with questions specific to certain core areas.

#new-contributors, #summary

PHP Meeting Recap – August 14th

This recap is a summary of this week’s PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @afragen @desrosj @dimadin @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @pross @schlessera @sergey @spacedmonkey @stevenkword @tfrommen

Chat Summary

The agenda for this week’s meeting to continue our efforts for the planned .org page to educate and convine mainly non-technical users about the benefits and necessity of PHP upgrades. Here are the highlights from the discussion:

  • There is now a new GitHub organization for the core PHP team, and a repository as a central location for the work towards the new page, which now lives under the temporary codename “servehappy”.
  • There’s furthermore an additional repository as a collection of third-party resources on the topic, such as articles or hosting-/tool-specific upgrade tutorials. Some of those will be good references and inspiration for our own version.
  • Everyone is welcome to contribute to both of those.
    • The primary task for the “servehappy” repository will be to open issues for the benefits we’ve come up with over the past few weeks, and discuss them one by one, whether they qualify for the page and how they can be framed in the most convincing way. A project board exists to get a quick overview about where each of those benefits stands in terms of workflow.
    • Any useful resource found about the topic should be added to the resources repository. This can happen in a very intuitive way, as you don’t even have to fork the repository to enhance it. Simply use one of the file editing buttons to make your changes, and create a pull-request from it. Enhancing the resources list is much appreciated too.
  • @nerrad suggested to also have issues for the different sections planned for the page (see last week’s recap for the proposed outline). A project view for these has been created since, which is a work in progress.
  • While we call the first section “What we want from you”, this title should only be used for ourselves to remind us what we’re using the page for and that this should be conveyed in the first section. However, that should be phrased in a way so that the site visitor does not feel put under pressure. It should go more into a direction like “Once you’ve read this page, you will want this too”.
  • The section “What should you need to know before doing an update?” must not unnecessarily make the user worry. Let’s highlight possible issues, but not overestimate them. People should see upgrading as a good thing, and we should point them at how they can determine whether their sites are ready.
  • Users should briefly be educated about the natural requirement of software updates, and that PHP is just the same. Phrases like “Now you need to do this every … months” must not be used, but a more general way that highlights the benefits of staying up to date and that, in order to do so, upgrades are occasionally required. If site owners are not made aware of this, the next upgrade request will be just as painful as this one.
  • An important goal of the page is to improve the distribution of the PHP versions as collected by the installation/update stats of WordPress.org.
  • At the end of the chat, we talked about PHP versions a bit, and which jumps were more critical or problematic than others.@mikeschroder highlighted that the jump from 5.2 to 5.3 was actually one of the hardest, while 5.6 to 7.0 was quite smooth. @schlessera added that 7.1 is a bit more problematic than 7.0 because of some of the changes involved.@mikeschroder will try to see if they still have data at DreamHost about the 5.2->5.3 jump that they could share. He furthermore reminded ask to ask more of these questions in the #hosting-community channel.

The takeaway of this week was that we should finally get in touch with the marketing team. Let’s work on adding a brief one or two sentences for each of the sections that were proposed in last week’s meeting to give them more context, to provide a better foundation for the #marketing team. This can happen via GitHub. More benefits should be added as issues on GitHub as well.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to continue discussing the page outline, benefits and further coordination. If you have suggestions but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

Dev Chat Summary: August 16th (4.9 week 3)

This post summarizes the dev chat meeting from August 16th (agendaSlack archive).

Feedback on 4.9 goals

  • @johnbillion: as part of ongoing Security focus, planning on several user account security related changes, for example bringing some of the Multisite confirmation emails when you change your email address into single site
  • @flixos90: Multisite team is working on REST API endpoints for the multisite objects, like sites and networks, plus improvements to the users endpoint that make it compatible with multisite
  • @westonruter: just published 0.2.0 of the codemirror-wp plugin which adds an a11y option to the user profile screen to opt-out of syntax highlighting in the same way that a user can opt-out of the visual editor
  • @westonruter: feedback and help welcomed via the CodeMirror repo
  • @westonruter: Customizer drafting and scheduling (essentially porting the features from the Customize Snapshots plugin) is currently working through designs with @joshuawold, once that’s set this will move to implementation

Component roadmaps

  • @desrosj: Multisite team using weekly meetings to re-organize the Network & Sites component’s roadmap to align with Core’s current focuses and the component’s short and long term goals
  • @desrosj: We propose using make.wordpress.org/core/roadmap/ as a location for components to house their roadmaps (multisite living at `make.wordpress.org/core/roadmap/multisite`) as roadmap posts on the Make/Core blog slowly get pushed away as new posts are published
  • @desrosj: The roadmap outline (brief descriptions of each item, a timeline, some tickets to focus on immediately) would live on these roadmap pages, and link out to make blog posts with specific details about each item.
  • Agreement to proceed with this with Multisite and assess how its working before pushing other components to do the same

General announcements

  • @koenhuybrechts: looking for update on #17268
  • @mte90: looking for update on #12955
    • @drewapicture: concern with potential performance hit due to the sheer number of times it’s called on a given page load; will leave a comment on the ticket
  • @mte90: looking for an update on #13657
    • No one around related to the Database component, will continue to look for updates via the ticket
  • @mte90: looking for an update on #40542 as well as my other patches

#4-9, #components, #core-customize, #core-multisite, #core-restapi, #dev-chat, #roadmaps, #security, #summary

Multisite Recap for the week of August 14th

Office Hours Recap

The agenda for this office hours meeting was to discuss the format of the multisite roadmap that will be compiled from many of our recent conversations.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @spacedmonkey, @vizkr, @jeremyfelt

Chat Summary:

  • An initial multisite roadmap document has been started. If anyone would like access to edit, please ping @jeremyfelt on Slack.
  • The previous multisite roadmap (2013) was verbose. @jeremyfelt mentioned that it provided the thought process behind a lot of things that were going to become decisions at some point.
  • That the previous roadmap was posted on make/core and then lost in the timeline makes discoverability difficult.
  • There should be a specific URL where the roadmap can be published and evolve over time. Additional (verbose) updates on progress or new initiatives can be posted as posts on make/core and then linked from the roadmap as needed.
  • During the weekly core dev chat, we’ll propose a make.wordpress.org/core/roadmap/ structure under which make.wordpress.org/core/roadmap/multisite/ can exist as well as pages for other components or focuses.
  • It’s also possible we can follow the customizer component’s lead and publish under https://make.wordpress.org/core/components/networks-sites/. Note that this only covers one component rather than the focus.
  • A ticket should be created for everything we plan so that people can help when available.
  • @flixos90 is going to spend some time working on the roadmap document some more to get it closer to the format that we’ve been discussing.

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 was to discuss approaches for better clarifying site statuses, and then have an open floor for further tickets.

The meeting’s chat log

Attendees: @flixos90, @sergey, @ina2n, @afragen, @pmbaldha, @paaljoachim, @desrosj, @spacedmonkey, @jeremyfelt

Chat Summary:

  • #17164 – More elegant handling of site ‘archive’ options for Multisite
  • #39158 – Unify site deactivation process
  • #15801 – Network Admin: Deactivated / Deleted inconsistency
  • These 3 tickets are all related in some way, though deal with different issues around site statuses.
  • The checkboxes at wp-admin/network/site-info.php don’t convey any real information about their meaning or a workflow.
  • Different terms are used in the MS sites list table for network admins (deactivate) and in the site admin (delete).
  • Different error messages are displayed on the front end when a site is archived or deactivated. There should be better documentation for what these mean in the screen help.
  • @flixos90 – “Deactivating should be called deactivating everywhere”, “we should only use the term Delete when it really is delete”
  • It seems that #39158 is a ticket about workflow and unification of deactivate/delete. #15801 is a ticket about terminology.
  • Priorities via @flixos90:
    • change Deleted to Deactivated where it’s not actually Deleted
    • Figure out what all these actions do exactly.
    • Document what these actions do
  • We need to support these workflows in the sites endpoint.
  • #40736 – Ensure that get_blog_count() and get_user_count() return an integer. Specifically—Can the return type be safely changed without issue and/or should we deprecate get_blog_count() in favor of get_site_count(). We aren’t too worried about changing the return type as this function doesn’t appear to be used much outside of core.
  • #41344 – Secure Email Integration. We agreed to look at this ticket next week.
  • #40764 – Multisite theme update not showing new version number. This ticket came up right at the end and can be covered next week.

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, #network-sites, #summary

Dev Chat Agenda for August 16th (4.9 week 3)

This is the agenda for the weekly dev meeting on August 16, 2017 at 20:00 UTC / August 16, 2017 at 20:00 UTC:

  • Feedback on 4.9 goals
  • Component roadmaps
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9, #agenda, #dev-chat

X-post: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

X-Post from +make.wordpress.org/updates: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

Multisite Agenda for the week of August 14th

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Discuss about the format for the multisite roadmap. We have the content ready to be written now. What should it look like, how verbose should it be, where should it be published?
  • Open floor regarding roadmap, related tickets and suggestions.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite.

  • Discuss approaches for better clarifying the different site statuses and solving inconsistencies (see #17164).
  • Open floor for any multisite-related bugs and small enhancements.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

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

X-post: Design team weekly update 14th August

X-post from +make.wordpress.org/updates: Design team weekly update 14th August