Dev Chat Summary: February 22nd (4.7.3 week 4)

This post summarizes the dev chat meeting from February 22nd (agendaSlack archive).

4.7.3 Schedule

  • Planning to release 4.7.3 on Monday March 6, 2017.
  • This will be a bugfix and maintenance release, nothing major.
  • Latest view of what’s in/coming in 4.7.3: Trac report
  • This date is coming up pretty soon.  Ideally anything going into 4.7.3 would already be in trunk.  So please make your remaining commits ASAP.
  • Aiming for a code freeze and release candidate either Friday, February 24th or Monday, February 27th
  • Bug scrub planned for February 24, 19:00 UTC in #core

Customizer team update

  • Looking for help on testing the Media widget (#32417: Add new core media widget) as well as proposal for a minor release
    • There will be a Translation need for this widget
    • @westonruter: I’ll do final touches on the patch via the GitHub PR to avoid stepping on each other’s toes and to run the builds. If you have anything to add to the patch, please push to the feature branch. Otherwise, I’ll manually re-sync new patch changes to the PR.
    • Additional tasks to see this land in a release:
      • 1) Search for plugins and communicate with them [@ipstenu to help]
      • 2) Test and try to break the patch in it’s current form [@jnylen0 to help]
      • 3) Confirm Forums response to the question: “why didn’t you ‘just’ use {{my existing widget}}”?
      • 4) If you have a widget that does similar things, try out compat and/or extensions [@helen to help]
      • 5) Make sure that it looks good in all default themes [@jnylen0, @melchoyce to help]
      • 6) Consider whether the widget should be extendable for plugin authors to add new types [@helen to help]
    • Likely means this won’t land in 4.7.3, but will target an upcomming minor release

Editor team update

  • Looking to continue discussion on browser support, no need for an urgent decision, but there’s been some discussion that core devs might want to be aware of and review. The current Plan B is to include an old version of TinyMCE for the browsers that will not support the new one.
  • Related post with more detail: A quick guide to browser selection models
  • A lengthy, pro/con discussion ensued. @desrosj is working to summarize everything from the conversation, will add some browser stats, and post to Make/Core for the discussion to continue
  • If you have statistics that you feel will be valuable to look at, please to send it to @desrosj and he will try to include it in the conversation summary for further discussion

REST API team update

  • The REST API team has no significant updates since last week.

Trac tickets

  • set of tickets with patches from @mte90 that are looking for review. If someone out there has some time to go through any of these for review/feedback that would be appreciated.
  • #16778: wordpress is leaking user/blog information during wp_version_check()

Community Summit

  • Between now and next Friday, the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • See also: Community Summit 2017: Sign-up Request
  • @jbpaul17 posted to Make/Core request to capture input on the three items above, will capture that input and summarize for review in next week’s dev chat, and then send the Core team response to the Community Summit team by next Friday, March 3rd. Please review the post on Make/Core and respond with your input.

#4-7, #4-7-3, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 8th (4.7.3 week 2)

This post summarizes the dev chat meeting from February 8th (agendaSlack archive).

4.7.3 Schedule

  • Still no release date scheduled for 4.7.3, but we began to assess tickets this week and will continue next week
  • Goal is to finish scrubbing tickets in the milestone and plan for release timing
  • 4.7.3 milestone Bug Scrub planned for February 13, 2017 at 10:00 CST in #core
    • Focus on tickets with no owner set to see if any can be picked up and worked towards a commit this month
    • Please attend the scrub if you have tickets you’d like to discuss

Customizer team update

  • Customizer team appreciates any help by looking at tickets and pitching in where you can
  • Going through the customize component ticket backlog, identifying quick wins to add to the next release and then larger issues to tackle for the next major
  • #21666 (Customizer reset/undo/revert) and #38707 (Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out) have initial designs and could use prototype and/or development help

Editor team update

  • The Editor team will post a Make/Design update soon that features a couple of mockups showing block level and inline level controls as well as showing off one or more prototypes in various states of functionality.
  • They’re working to get mockups and prototypes in a place where people can contribute to them, so keep an eye out for their post and please consider contributing and/or giving feedback.

REST API team update

  • @rmccue is working on using the API to improve the editing experience relating to bulk actions in list views
  • With limited team bandwidth, we’re evaluating existing usages of admin-ajax to prioritize places where the API can be implemented to reduce inconsistency
  • During 4.7 Quick Draft stalled out due to questions about content filtering that are happening on the admin-ajax path, and has resurfaced #21170 (JavaScript actions and filters) and #20491 (Introduce some JavaScript i18n functions)
  • @kadamwhite is triaging open API bugs weekly, with a focus on normalizing inconsistencies
  • #38323 (Reconsider $object_subtype handling in register_meta()) is priority from an API design standpoint, because the current behavior completely precludes using register_meta to model your data
  • @jnylen0 has been tracking the multi-site API discussions, and there’s a post from that group up on the make/core blog
  • Our biggest barrier is bandwidth; @rmccue & @kadamwhite are working on 1-2 priorities in their respective areas, but there’s a lot of docs and testing work, as well as POC for future endpoint types (like @westonruter is doing w/ Widgets) that could happen in parallel if there are interested parties
  • Widgets (and therefore Sidebars, later) endpoints are priorities for @westonruter given the Customizer focus
  • Menus endpoints are the other that comes up in conversation the most
  • Once we have the first WP-Admin usage in place, we’ll be looking for more contributors to help spearhead more admin-ajax replacement; that’s higher-priority than new endpoints from a core standpoint, in our opinion
  • The REST API group meets on Mondays at 21:00 UTC in #core-restapi, we hope to see you there!

Trac Ticket(s)

  • @pressupinc advocating for a fix for #34225 (Display correct dimensions for image sizes in media modal)
    • Seems to be caused by #35390 (image_constrain_size_for_editor() should not affect images generated on the front end when `large` size is used)
    • General issue is image sizes not displaying as they should in the Media modal
    • Reported #38906 (wp_get_attachment_image_src() sometimes gives incorrect width and height values)
    • Will check with Media team in #core-media

#4-7, #4-7-3, #dev-chat, #summary

Dev Chat Summary: February 1st (4.7.3 week 1)

This post summarizes the dev chat meeting from February 1st (agendaSlack archive).

4.7.2 Update

4.7.3 Schedule

Customizer team update

  • Still going through the customize component ticket backlog, identifying quick wins to add to the next release and then larger issues to tackle for the next major release
  • We’re in need of patch contributors.
  • Tickets currently in the 4.7.3 milestone: should be read as “next minor release” and tickets are prone to punting.

Editor team update

  • The Editor team is working on a prototype, but otherwise has no other urgent updates.

REST API team update

  • The REST API team is also quiet this week, but will be meeting in-person next week.

Trac Ticket(s)

  • #39701: Do not allow editing users from a different site in REST API
    • related to multisite users handling
    • Discussed adding a ?global parameter to the API to enable managing multisite users, in 4.8 or later
    • REST API currently is essentially a single-site API, this ticket is one of the ways it behaves inconsistently regarding user management
    • @jnylen0 would like to make it behave more consistently like a single-site API for now, until we can thoughtfully and carefully add support for multisite
  • #39256: REST API: Multiple issues with setting dates of posts
    • Really needs more eyes, ideally in the form of failing/passing unit tests and patches
    • @jnylen0: These two issues are backwards-incompatible and the penalty of fixing them now, while not many people are using the API yet, far outweighs the pain of having to support and work around them in the future, essentially forever
  • #39696: REST API: Filter which links get embedded when passing the ?_embed query parameter
    • coming along nicely, but probably not as important for a point release

#4-7, #4-7-3, #dev-chat, #summary

Dev Chat Summary: January 25th (4.7.2 week 2)

This post summarizes the dev chat meeting from January 25th (agendaSlack archive).

4.7.2 Schedule

  • Reminder that no release date has been scheduled for 4.7.2 yet, we will assess tickets milestoned in Trac next week and begin planning for timing then.

Customizer team update

  • Please read two most recent posts: Customization in 2017 and Meeting Notes from January 23
  • Began scrubbing 198 tickets in customize component backlog to evaluate their priorities against the goals for the year, closing the ones that are no longer valid
  • We’re assigning tickets to the next minor release when they are defects or small enhancements that can be tackled in the next month
  • Larger enhancements that are aligned with the year’s goals which are not suitable for the next few weeks will be assigned to 4.8
  • The Future Release milestone is for tickets that should be done but which aren’t a priority for the goals of customizer this year
  • Looking for input on #39692 (Fix missing assignment of menus on theme switch), #39693 (Fix missing assignment of widgets on theme switch), and #35243 (Extending the text widget to also allow visual mode)
  • Big effort around #35760 (Provide API for TinyMCE editor to be dynamically instantiated via JS), so if you’re well-versed in TinyMCE please help
    • In summary, this will provide basic text formatting, links, and media embedding capabilities
  • If you’re looking for patches to contribute, please look at the defects milestoned for 4.7.2 that need patches
  • Continuing big picture design discussions about what the customizer should look like in light of conversations also happening with the editor

Editor team update

  • Please review the What Are Little Blocks Made Of? post and subsequent comments to get some insight into their approach on “blocks” as the focus this year

Trac Ticket(s)

  • #39256: REST API: Multiple issues with setting dates of posts
    • Not really possible to use the REST API to manipulate dates in a reasonable fashion
    • This is something we should fix ASAP before people start relying on the current, broken behavior
    • Please take a look, especially if you have experience with date handling in other parts of WP
  • #39466: Get list of post API request missing status
    • Should be a pretty easy win in 4.7.2
  • #39264: Add WP-API JS Client unit tests to core
    • Could use a review
    • Would love help automating the generation of the mocked data, ideally as a grunt task
  • #39072: Add gmt_offset as a REST API setting
    • Sort of related to date handling, a bit involved, doing it later isn’t so bad because it’s an addition rather than a change
  • #36574: Redesign term pages
    • Patch needs testing from Taxonomy team

#4-7, #4-7-2, #dev-chat, #summary

Dev Chat Summary: January 18th (4.7.2 week 1)

This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

4.7.x Releases

  • Moving to monthly checkins for 4.7.x releases
  • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
  • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
  • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
  • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
  • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
  • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

REST API team update

  • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
  • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
  • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
  • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
  • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
  • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
  • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
  • We’re using a Trello board to track the areas of investigation
  • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
  • @flixos90 did an excellent writeup of our users endpoint discussion
  • We are sorting out how user and site membership management and display should work for the users endpoint.
  • master ticket #39544: REST API: Improve users endpoint in multisite
  • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
  • Multi-site is the first such feature project that’s officially under way.
  • For 4.7.2 we should be looking for related bugs around the existing functionality
  • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
  • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
  • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
  • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

Customizer team update

  • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
  • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
  • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
  • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
  • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

Editor team update

  • Please read and comment on the “Editor Technical Overview” post
  • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
    • Data structure.
    • Parsing mechanism.
    • General UI for block display / controls.

Trac Ticket(s)

  • #39535: Canonical redirects disallow tag named comments
    • @asalce: looking to get owner on the ticket and review of patch
    • will ping @markjaquith or @dd32 as maintainers of Canonical component

#4-7, #4-7-2, #dev-chat, #summary

Dev Chat Summary: January 11th (4.7.1 week 5)

This post summarizes the dev chat meeting from January 11th (agendaSlack archive).

4.7.1 Update

2017 Release Schedule

  • 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
  • Proposal from @samuelsidler:
    • Since we don’t have a set release date for WordPress 4.8, I’d like to propose we look at applicable 4.7.x issues about once a month, and decide if we should ship a release.
    • For 4.7.2, I think we should take a look at issues at the beginning of February, during devchat, and decide if the issues warrant a release, then ship about a week later.
    • That would mean we’d be looking at a release around February 14, but we’d update the schedule after looking at the specific issues.
    • We’d want to evaluate issues the week of February 6 and make a call.
    • I think we said regressions and minor bug fixes are okay in 4.7 at the moment, but we can evaluate other fixes on a case-by-case basis.
  • General agreement on approach, though date for 4.7.2 to be confirmed in February
  • Plan to choose someone soon to lead 4.7.2, maybe at or before next week’s devchat, to keep things moving along. @jnylen0 @aaroncampbell @voldemortensen @swissspidy interest in leading that or future releases. If you have interest, ping @samuelsidler as he’s compiling a list of those interested.
  • @davidakennedy: I’d imagine we’ll package up default theme updates more in minor release. Though, we can also release those whenever to .org. I’d like to think through a schedule for that. Maybe looking at things monthly, and making a decision.

Trac Tickets

  • #39309: Secure WordPress Against Infrastructure Attacks
    • @paragoninitiativeenterprises: propose making it a point of focus for 4.8
    • @aaroncampbell: may not fit as a focus for 4.8, since those should be in the editor, customizer, and API areas. But good to talk about and try to figure out steps forward.
    • @paragoninitiativeenterprises: recommend against punting too far into the future
    • @samuelsidler: let’s think through how to implement it and work on patches for that, then decide which release to put it in
    • @westonruter: Security and performance hardening are ongoing and not limited to focuses
    • @paragoninitiativeenterprises: would like to see this land ASAP, will work on a patch with necessary tests and any necessary back-compat and post to the ticket
  • #38418: Add telemetry (aka usage data collection) as opt-in feature in core)
    • @lukecavanagh: thoughts from the group?
    • @brechtryckaert: personally in favor of usage data collection, but we’ll need to be very upfront about it upon release to avoid criticism; also worried what the impact would be on loading times/slowdown due to communication with the servers that store the data, would all depend on the way it’s implemented.
  • #39157: Feed returns 404 when there are no posts
    • @stevenkword: looking for feedback on approach on adding new conditionals and what to do now. Issue was addressed in 4.7 but caused a regression and code was reverted for 4.7.1.  After 4.7.0 landed, before the reversion, an updated patch was committed that resolved the regression, but it introduced new getters to WP_Query.
    • @stevenkword: would like to find a resolution for this for 4.7.2, but need some opinions how to solve it.
    • Will ping @peterwilsoncc and @dd32 to look at it

#4-7, #4-7-1, #dev-chat, #summary

Dev Chat Summary: January 4th (4.7.1 week 4)

This post summarizes the dev chat meeting from January 4th (agendaSlack archive).

Schedule

2017 Release Schedule

  • no update on the “new release schedule”, so for now it will be process as usual

#4-7, #4-7-1, #dev-chat, #summary

Dev Chat Summary: December 21st (4.7.1 week 2)

This post summarizes the dev chat meeting from December 21st (Slack archive).

4.7 Retrospective

  • Reviewing comments on 4.7 Retrospective post on Make/Core
  • We will go through comments and discuss if there are changes to our process that we should recommend
  • Goal is not to second-guess decisions that were made, the goal is to figure out if the process can be improved in future releases
  • Things to start doing:
    • “We failed at getting the field guide and email to plugin dev out early enough. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases. This time it came out the day before (field guide) and day after the release (email).”
      • Coming up with some documentation and ensuring that it’s not just owned by one person is a good way to improve it
      • We should also ensure it is included in the release checklist
    • “The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the trac feed, and sometimes I know that as a plugin developer a particular ticket is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11y team’s work on removing excessive content from headings on admin screens. Often API changes get documented and UI changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in core, but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.”
      • Request here is to have more Dev Notes and explanations about what is changing
      • It would help to spread the load of writing Dev Notes a bit, sometimes they are time consuming, especially if you’re not much for writing this sort of contextual summary
      • Some components generate a component summary dev note which is a good practice
      • Should we also maybe reach out to the docs team to see if they want/can help?
      • Anyone have ideas for how we get people involved with drafting the note even if they aren’t leading developers on a feature/component?
      • We do list out every change in the “this week in core posts” (shout out to the team that works on those!) already, so there isn’t anything that goes unannounced
      • The solution suggested is more posts, but the problem appears to be that people aren’t seeing changes that they think might affect them
      • Getting to Trac and subscribing to whatever feed is a little hidden. Even Slack notifications is hidden. A more public place would be good.
      • The solution could be to push people to the Week in Core posts, they already list every change categorized by components
      • Someone willing to lead a discussion (likely on make/core) on how to improve this?
      • Action Item: wait and see how lack of timed release cycles plays out
    • “We need to collectively review the “feature plugin merge guidelines” listed here. While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the REST API since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.”
      • Can we reasonably make full test coverage (covering basic use cases at least) a requirement there?
      • This may be null as feature plugins may not play a significant, or any, role in the future
      • More “wait and see how new process/focus shakes out”
      • Action Item: No more feature plugins
    • “On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.”
      • Still a question of who really owns final decision/veto power; @matt as product owner likely
      • Whomever is leading the release has final decision. That’s why they’re a lead. That much should be clear.
      • Action Item: continue to communicate changes clearly and early
      • Release leads and core leads need to be trusted to prioritize based on goals for the release
      • When somebody is unable to solicit feedback, we need to have honest conversations about why this is happening
    • “Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.”
      • Any volunteers to help work on this?
      • Anyone think automated acceptance testing for user flows is a bad idea?
      • It could be difficult to maintain
      • This is done at Automattic: https://github.com/Automattic/wp-e2e-tests
      • Action Item: keep exploring in the ticket
    • “more focus on Trac and tickets, every committer should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious ‘Trac Gardening'”
      • A big ask for every committer following Trac on a daily basis
      • Especially since the vast majority of committers aren’t being donated anywhere near full time (and a large number are 100% volunteer)
      • This is why there’s component maintainers, so that we don’t overburden each person
      • Trac Gardening is something anyone is welcome to do, you don’t need to be a committer
      • Trac Gardening would benefit from some mentorship to be more effective
      • If there could be some mentoring for this – an initial joint meeting to get people started might we get some more interest?
      • We could benefit from improved workflows for managing the resources we do have and to reduce the uncertainty in gardening/contributing in non-code ways
      • Trac Gardening can be a thankless task to a novice who comments on tickets, asks for dev-feedback and then nothing further happens for months. Perhaps the dev-feedback tag needs watching more rather than all tickets.
      • Action Item: generalize 4.7 Bug Scrubs page “to run a bug scrub, announce it here, talk to these people, look at this report in Trac, then ping people on the tickets listed”
  • Things to continue doing:
    • “The combination of a Git startup phase and Slack is excellent. At least for the Twenty Seventeen theme.”
      • GitHub likely helps get new contributors involved, but not sure they stick around
      • GitHub is easier to follow along, post mockups, get feedback, review code
      • GitHub better with searching, labelling, organizing, looking at PRs, realtime updates, making branches and then submitting PRs from branches, plus its app
      • Our current code review process is sub-optimal because there are no workflows to support it (e.g., line-by-line comments on changes)
      • It would be good to separate what is the project management tool vs. version control method
      • GitHub is sub-optimal when iterating on PRs. In Trac, you can make minor changes to a patch and upload it to a ticket. In Github, depending on permissions patch iteration is not straightforward.
    • “Weekly design meetings.”
    • “On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.”
    • “increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.”
  • @jorbin to work on a summary of what was discussed here and post it on Make/Core

General Announcements

  • Uncertain if anyone is planning on running a core dev chat next week (or any weeks going forward), so watch for agendas on Make/Core or other notifications in #core

#4-7, #4-7-1, #dev-chat, #summary

Dev Chat Summary: December 14th (4.7.1 week 1)

This post summarizes the dev chat meeting from December 14th (Slack archive).

4.7 Retrospective

  • Please provide Retrospective feedback on Make/Core
  • We will review the feedback and then present it for discussion during the dev chat on December 21st and agree on action items on how we can improve in the future

General Announcements

  • Discussion on overuse of post meta to make searches in queries
    • Utilization of terms as a potentially better option
    • Data could be stored in meta for precision, terms for searchability
    • Not certain this is something that Core needs to provide
    • Best to prototype and demonstrate use case via plugin first
    • Also dev education to understand problem and available, reasonable solutions
    • @igmoweb to write up idea as blog post or Trac ticket to detail concept, gather input from others via comments, and bring back to a future dev chat
  • Should we start requiring JS for most of WP Admin and thus not providing fallbacks?
    • some things that must always be usable without JS (e.g., changing/updating themes and deactivating/activating/updating plugins)
    • the general attitude of JS support (and some CSS back-compat stuff) is really one of “don’t lock the user out” for the most part
    • It’s nice to also be able to keep no-JS support for some of the most basic tasks, like posting
    • no-js MUST work when it comes to things that could break JS or are 100% vital (plugins/themes/login/logout)
    • no-js SHOULD work for basic tasks (i.e. posting)
    • no-js MAY work everywhere else
    • This needs to be defined more formally and we should define what things like “basic tasks” are
    • Plan to hash out language etc. with a draft and request for comments on Make/Core
  • How do we keep bug fixes and component roadmaps going in conjunction with feature dev?
    • Conversation postponed for a future dev chat

4.7.1 Bug Scrub

  • 4.7.1 open tickets
  • There are 9 tickets that just need merging, everything else is owned by a permanent committer
  • Still no 4.7.1 lead or timeline
  • Could “push” an auto-update to Twenty Seventeen separately from 4.7.1, but that would still need someone to own that process
  • One of the Twenty Seventeen changes relies on a corresponding core change so it would be better for them to go together for 4.7.1

#4-7, #4-7-1, #dev-chat, #summary