Start of meeting on Slack
This Dev Chat continues the experiment to focus chat time on discussions related to open Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues, rather than repeating links already highlighted in the curated agendas.
Announcements
Following announcement of yesterday’s 6.4.3 release, @jorbin noted that there was one issue of note, but that there were workarounds available at this time. @jorbin further gave props to those who helped facilitate the release.
@hellofromtonya shared that @joemcgill has accepted his nomination to serve as a 2024 Core team rep 🎉. The search continues for a co-rep, where it’s been noted that a contributor from the Core Editor team would be a great compliment, though not required. Nominations remain open until April 1, 00:00 UTC.
Discussion on open proposals in Core
Field Guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. Publish Date
Link to post: Proposal: An update to the Field Guide
Conversation start link
Comments:
- @jorbin was under the impression that neither the dev blog (versus network, site) team nor 6.4 release leads were interested in moving forward with the proposal. @webcommsat shared that 6.4 docs release leads didn’t see 6.4 as the deadline, and discussions were continuing. @joemcgill agreed that the proposal wasn’t release specific, but rather an adjustment to timing of when field guide information is released. @hellofromtonya also added that the dev blog team has opened a discussion to track the second part of the proposal.
- @jeffpaul referred to @chanthaboune‘s comment of where best to separate field guide content based on audiences, suggesting the proposal could be adjusted accordingly. @jeffpaul added that some folks have difficulty processing field guide information to determine what is relevant and actionable, which @hellofromtonya agreed should be explored. @webcommsat agreed with the notion to target field guide content to particular audiences, but also to look at how it relates to other new content produced for the release.
- @jeffpaul suggested the potential to target content according to the five user groups identified in Care and influence: a theory about the WordPress community.
- @ironprogrammer asked if the field guide info would be more easily consumable if it was split into a canonical structure, such as
wordpress.org/6-5/field-guide/, with subpages that match particular areas or audiences.
- @webcommsat noted that segmentation between audiences has grown, and suggested it’s a good time to use teams’ audience-specific insights to improve the field guide format. She added that exploring how best to utilize the limited people and time for the Docs team would be an important factor in implementing improvements. @jeffpaul agreed with concerns around challenges in gathering/publishing content, but noted that the issue should be considered as separate from the proposal.
- @jorbin shared that the original published field guide was the result of an overly long email sent to plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers.
- First-time Docs Co-Lead @estelaris 🎉 asked about adding additional comments to the proposal. @jorbin noted that Make/Core comments close automatically after 180 days (~6 months). @costdev shared that adding the
#keep-comments-open tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) would reenable them, but recommended removing the tag once an updated timeframe for feedback has been reached. @jorbin updated the Core handbook to reflect this info.
- @joemcgill pointed out that the team should review all current channels where field guide-related content is published, to check whether only updating the field guide [in one place] would sufficiently improve the broader sharing of release updates to the community. He suggested engaging with the Docs and Marketing teams to move forward, and @estelaris noted she would begin by sharing with Docs. @webcommsat suggested looping in Training as well. @laurlittle noted that the Marketing team could brainstorm on the proposal for future releases, if not 6.5.
- In response to @joemcgill, @webcommsat noted that there have been past lists of channels and audiences, and suspects more current info should be available. She also suggested it might be helpful to have a single post that links out to the various user groups identified earlier, and to link to that post from the About page.
- @jorbin referred back to @jeffpaul‘s input and asserted that the dev blog and other team areas might be better places to communicate field guide information, as opposed to Make/Core. @hellofromtonya asked if, considering this perspective, the proposal was actionable by the Core team, or if the proposal should be re-worked as a cross-team collaboration. @jorbin suggested that the teams publishing the field guide info would take on the proposal.
- @joemcgill noted that it can be difficult to know the status of a proposal, suggesting some way of flagging these posts. @marybaum suggested a visual system to convey “stalled”, “live”, etc, and @joemcgill raised the idea of a block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. pattern. @desrosj shared that in past proposals (example) he has added status info to the top of the post, assuming the status was clear.
- @hellofromtonya wrapped up the discussion based on the chat, concluding that the proposal be marked closed (“not accepted”), or must be picked up by another team(s).
Actions:
- Part 1: Move Make/Core field guide publication ahead one week, aligning with last scheduled beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process., rather than RC1. Not accepted ❌
- Part 2: Start publishing a simplified field guide to the WordPress Developer Blog. Not accepted ❌
- Other teams to explore revising and adopting this proposal:
- @estelaris to share the proposal with Docs.
- @laurlittle to raise the proposal to Marketing for possible brainstorm.
- @webcommsat to loop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. in Training to gauge their interest in furthering the proposal.
- To highlight in dev blog.
Open Floor
Props @hellofromtonya for peer review.
#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary
