This post summarizes the dev chat meeting from March 15th (agenda, Slack archive).
- Additional dev chat earlier today on topic of Browser support (Slack archive)
- After some discussion, we arrived at the following strategy.
- A “text” editor available to everyone is the best fallback – the new visual editor will leave old browsers behind.
- Some form of the current version of the editor can be packaged into a plugin. Sites with users requiring a more advanced editor experience for older browsers can install this plugin.
- The WordPress admin screen will display a notice of some sort to users with older browsers explaining the changes and how they can install the plugin for the experience they were used to (possibly utilizing BrowseHappy).
- The editor team will use their research for the new editor to determine which buttons need to remain in the “text” editor with support for older browsers.
- A more general discussion about browser support policies is slated to be had at the Community Summit before WordCamp EU. But this discussion can start before that (@jorbin is working on a Make post to start that conversation).
- Any additional feedback from anyone who could not attend then is welcomed!
Core team reps
- Last week we had nominations for @jorbin and @afercia.
- Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
@afercia not currently scheduled to be at summit, but would like to
- Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core
- Day of REST event was successful, but delayed continuing bug triage, will pick back up on 4.7.4 to make sure we keep solving the critical pieces
@jnylen0 & others resolved issue with tests & daylight savings time
- due to bandwidth the existing REST API contributor group is fully occupied with the API itself
- existing REST API contributor group have neither the bandwidth nor the domain expertise to also be leading the WP Admin implementations that will consume the REST API
@adamsilverstein lead the charge with Quick Draft, and work has begun in several parallel channels, but as of right now there’s nothing that appears to have momentum
- We need help to drive adoption of the REST API within WP Admin, please come chat in #core-restapi any time
- We need more explicit awareness of how the other feature teams want to use the REST API, or volunteers to lead separate implementations to move away from admin-ajax where it introduces inconsistency
- If you’re not able to lead the separate implementations, then please chime in on component tickets as they’re opened to help us triage the pain points
- PHPunit tests (#39265: Missing @covers and @uses in the comments block in phpunt test for wordpress)
@pbearne: I am trying to do is get support to have
@uses required for PHPunint tests
@pbearne: Willing to work through the old tests to add the missing comments
@pbearne: I would like to propose that we require for all new / updated tests and that the code committers commit updates with these added ASAP
- How would we use that information going forward?
@pbearne: add to WordPress.org as way of show code quality and tell how well we are doing
- What would be a realistic number we’d want to achieve?
@pbearne: anything over 80%
- If you use the editor, please look to complete the Editor Experience Survey.