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 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!
This post summarizes the dev chat meeting from January 31st (agenda, Slack archive).
The next meeting will take place on February 7, 2018 at 21:00 UTC / February 7, 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 recap is a summary of our previous 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.
You can find this meeting’s chat log here.
The agenda for today was to discuss UX mockups and the hosting situation. However, @jaymanpandya was not around for the meeting and we don’t have any mockup update so we were unable to discuss. That portion of the meeting was postponed until next week. @azaozz was present at the meeting and we spent the entire meeting interacting with him with regards to this comment he made.
He expressed some concerns regarding both content (what the servehappy page contains) and location (where the servehappy page lives) of the servehappy page.
For reference and as a reminder, the servehappy information page is the first initiative of the entire project aimed for launch in the first quarter of 2017. You can read more about it (and how it fits into the larger “servehappy” project in the roadmap, the project readme, the related trac ticket and see the current draft. Also keep in mind that “servehappy” is a codename for the project. It won’t necessarily be reflected in any final form for the public facing content.
By the conclusion of the meeting we arrived at the need to focus primarily on location as it is something we haven’t fully worked out yet (it hasn’t received the same level of discussion/planning as the content). We identified some initial factors that should influence where this servehappy information page lives. For the purpose of this summary, I’m going to list the headings and capture some of the related discussion under each heading.
Here’s some factors that can influence the location:
This factor concerns the privacy of any information shared by site owners/sites for the servehappy page generation/content.
Some related background:
Related comments in chat (this is not in chronological order but has been grouped for relevance):
This factor concerns the degree of effort needed to implement, maintain and update the content and anything else related to this server.
This factor concerns how likely user’s will act on something when it conveys something they can trust (i.e. wp-admin, vs external hosted page)
In the course of the meeting we arrived at a discussion on two primary locations where the servehappy information page would be hosted/served. They are summarized below along with the relevant discussion pertaining to each location. The plan is to bring this to a future core dev meeting so that we can get some opinions from others in the wider WP core team/community to help with the decision for where this content will live.
This includes the potential of being a custom domain/separate site, WordPress codex, or as a page on WordPress.org
To prepare for the next meeting, here are some mockups for the PHP Compatibility checker:
This post summarizes the dev chat meeting from September 20th (agenda, Slack archive).
