The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
This post summarizes the dev chat meeting from May 23rd (agenda, Slack archive).
The next meeting will take place on May 30, 2018 at 20:00 UTC / May 30, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.
Last Thursday, 4.9.6 beta was released. In order to properly address all feedback received from beta testers, more time is needed.
After careful discussion, @desrosj, @allendav, @azaozz, and @sergeybiryukov have decided that to prevent any further set backs, both the 4.9.6 release candidate and 4.9.6 release by two days each.
The new schedule moving forward is as follows:
As previously detailed, 4.9.6 is not a typical minor release because of the inclusion of time sensitive features. In order to give site owners the personal data and information tools needed to be prepared for GDPR (General Data Protection Regulations) before the May 25th, 2018 effective date, these features cannot be removed to ship the minor version on time.
This decision was not made lightly. Deadlines are not arbitrary. However, it is important that the tools are ready and that translation contributors have enough time to localize the large number of new strings in the release.
Please continue to test the 4.9.6 beta package and provide feedback.
This post summarizes the dev chat meeting from May 2nd (agenda, Slack archive).
register_meta, a reminder on the Gutenberg-related issues that need some help, a summary from their meeting last week about those Gutenberg-related priorities, and a reminder on their next meeting tomorrow Thursday, May 3rd at 17:00 UTC focused on the `register_meta()` improvements.The next meeting will take place on May 9, 2018 at 20:00 UTC / May 9, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.
This post summarizes the dev chat meeting from April 18th (agenda, Slack archive).
srcwith a summary and proposed timeline; majority of current info is in #43055
The next meeting will take place on April 25, 2018 at 20:00 UTC / April 25, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.
Trac tickets: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr
GDPR agenda and recaps: https://make.wordpress.org/core/tag/gdpr-compliance/
Trac tickets: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr
GDPR agenda and recaps: https://make.wordpress.org/core/tag/gdpr-compliance/
Ain't no party like a GDPR party
Cos a GDPR party don't stop until someone has a question about personal data.
(Heather Burns)
This post summarizes the dev chat meeting from March 7th (agenda, Slack archive).
The next meeting will take place on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.
This is the agenda for the weekly dev meeting on March 7, 2018 at 21:00 UTC / March 7, 2018 at 21:00 UTC:
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!
On Wednesday, February 14th, the weekly new 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 @abdullahramzan @aduth @chetan200891 @clorith @desrosj @dougvanslembrouck @jorbin @joyously @lakenh @notnownikki @thrijith @welcher @williampatton @xkon
Even though every change to WordPress core must pass through Trac/SVN eventually, SVN is not the only option for creating patches.
See these articles for more intofmation on creating patches with Git:
An easy way to make your IDE/editor aware of the WordPress coding standards regarding whitespace usage is to use the .editorconfig file that trunk contains. This file uses a common standard, and there are plugins available for almost all popular environments that automatically parse the file and adjust the whitespace settings for the project.
Extensions can be found on the website of the project. Some IDEs like PHPStorm already come with built-in tools for the WordPress coding standards.
Older tickets often have attached patches that no longer apply to the current codebase. The older the ticket, the lower the likelihood that the associated patch will apply cleanly. If you find a ticket with a patch that does not apply, add the needs-refresh keyword to indicate this.
Over time, code shifts around and sometimes these patches only need a bit of reorganization to apply. Other times, you may find code that has been refactored and needs an alternative solution for the proposed bug/enhancement. Once this has been done, create a new patch with the clean code and submit it to the ticket.
While refreshing a patch, it’s also a good idea to make sure the patch is what you would consider the best approach and to verify that it follows the style guide.
See Contribute with Code handbook article for more information.
Ticket owner is generally responsible for moving the ticket forward. From the handbook:
When working on a ticket, the Owner field is typically left blank, even if you have contributed a patch. Committers utilize the field to offer traction for a ticket, to identify they are investigating, committing, or otherwise following a ticket, or to tentatively accept the bug or enhancement for core inclusion. It is also common during the feature development phase for developers to accept tasks in the area of responsibility for which they have volunteered, as well as related bug reports. Trusted contributors may assign tickets to others based on an inside knowledge of who should be responsible for reviewing it.
For good-first-bugs, the person who submitted the patch is assigned as an owner so that the ticket shows as “claimed” in the queue.
It’s OK to drop ownership if the ticket is no longer relevant for you, just reassign it to an empty field.
See The Bug Tracker (Trac) handbook article for more information.
Thanks to everyone who attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @flixos90, @sergeybiryukov, @stevenkword, @welcher) with questions on Slack. Or, feel free to reach out to any core developer or component maintainer with questions specific to certain core areas.
This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 15, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.
Attendees:
@mikeschroder @antpb @blobfolio @flixos90 @jdub233 @sergey @desrosj @azaozz
Transcript: Read on Slack
The next part of the meeting was spent on tickets in the next major milestone (5.0).
#33979 – Add filter for 'post_gallery_item'
#38228 – Add filter to default gallery shortcode output
Discussion around how granular gallery filters should be. With #3379 we gain a filter to add styles individually per item in the Gallery. It was discussed that we will need tickets to add more granular filters going forward for captions and other image attributes. From @desrosj : "Currently the shortcode builds the HTML string as it goes. I think if the attributes were built in an associative array, that could just be filtered, and then the element built at the end. That could allow additional attributes to be added, widths to be changed for specific images making it easier to do different grid layouts." This sparked the question above around how Gutenberg will handle backwards compatibility with filtered attributes.
The following tickets need a combination of code review and approval:
Seems good to go as a first step towards more granular Gallery filters if it won’t make it more difficult for Gutenberg to provide backcompat.
The next #core-media meeting is set for Thursday, February 22, 2018 at 1900 UTC. Hope to see you there!
