The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
From – https://make.wordpress.org/core/weekly-developer-chats/
The weekly WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developer chats take place on Wednesdays at 20:00 UTC in the #core channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. These chats generally last one hour.
The purpose of the meeting is to discuss core WordPress development. This is a working product team meeting, not an open town hall or Q&A session. The focus is on technical issues and release scheduling, and the players are the people who are working on patches for the active core development cycle. Anyone is welcome to attend to keep up with what’s going on in core, but the agenda is generally limited to discussion by active contributors.
At the moment, one dev chat is held every Wednesday. This often makes it difficult for folks in different time zones to attend dev chat.
Multiple teams hold more than one weekly chat. For example Community has two chats, one at 8:00 UTC and one at 16:00 UTC. While this doesn’t cover every time zone, it does expand the opportunity to join a team chat for contributors close to U.S. and EU time zones.
After 4.9.8, it was suggested a discussion be held around adding an alternative dev chat.
During the 4.9.8 release cycle, @pbiron and @joshuawold tried running two independant bugbugA 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, one about 10 hours before the usual one, and one at the usual time. The jury is still out as to whether this was a success or not.
During dev chat on Wednesday, 29 August, and after a discussion with those interested in running a second dev chat, it was proposed to hold an alternative dev chat 12 hours before the current chat.
Some concerns were voiced during dev chat:
@karmatosed mentioned this time is during school hours in EU time zones.
@clorith and @afercia raised concerns that two meetings could result in a disconnect between the community and present communication obstacles for decision making.
@jeffpaul floated the idea of holding three chats, eight hours apart. This approach is more inclusive of global time zones, but requires additional dedicated volunteers to manage the chats and communicate with the other dev chat volunteers.
@jorbin feels that decisions should rarely be made during dev chat highlighting the fact that the dev chats be just that, chats about current development cycles, not a time when decisions should be made.
@nerrad (and others) echoed the sentiment that “there’s value in clearly identifying in agendas when a item needs a decision and what chat that decision will be made in ahead of time”
The general consensus was that all of this should be shared in a Make post, so that the greater community could comment on it and we could vote publicly on the subject.
Problem: Not all who want to contribute and participate during a devchat are able to because of the timing of the devchat (currently 20:00 UTC).
Questions to guide our designing a solution to the stated problem:
Is one Dev Chat enough or should alternative dev chats be considered to accommodate more time zones?
If there is agreement that alternatives should be considered, what times/intervals are the most suitable for maximum coverage of folks from all corners of the world?
Is there some process that can be implemented to improve the decision making process and therefore either take that requirement out of any proposed dev chat or, alternatively, make it easier to reach decisions in any given dev chat?
This post’s comments will remain open for two weeks to allow for comments and/or suggestions.