As announced in last week’s dev chat we’ll have an additional meeting to consider the Shiny Updates plugin for merge today, June 13th, 2016 at 19:00 UTC.
Following a summary of the merge discussion from June 8th.
A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community.
Weekly chats are taking place on Slack, and the feature lead is attending the weekly core dev chat.
✅ Meetings took place in #feature-shinyupdates.
A kickoff post and regular update posts are published publicly, tracking the progress and major decisions of the feature plugin.
✅ Kickoff post at https://make.wordpress.org/core/2016/04/18/shiny-updates-chat/ and update posts at https://make.wordpress.org/core/tag/shiny-updates/
The feature works in all of the browsers that WordPress officially supports.
✅ IE8+ and other current browsers were tested
Touch devices can use the entire feature with no hindrance, with visual records for major flows through all new interfaces on all devices posted on Make/Flow. Make sure it functions properly on mobile by asking the Flow team to review it.
Visual records comparing old flow with new flow are provided for any feature that changes or replaces existing interfaces.
The code conforms to the WordPress coding standards.
✅ Assured through the use of a code sniffer and Travis CI: https://travis-ci.org/obenland/shiny-updates
Similarly, the code is well-tested, and has unit tests.
✅ QUnit tests: https://github.com/obenland/shiny-updates/blob/master/tests/tests.js, closed issues: https://github.com/obenland/shiny-updates/issues?q=is%3Aissue+is%3Aclosed
The code is well-documented. (Be sure to ask the Inline Docs team to review it.)
🅾️ @drewapicture wasn’t around but @obenland said that “he’d like to wait with the review until there is a core patch, and he pinged me this morning saying he wanted to review it today”.
The code follows the plugin security best practices, and has undergone a security audit.
🅾️ Only a rough audit was done. @aaroncampbell was asked to look at it.
The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. (Be sure and ask the Design team to review it.)
🅾️ @mapk was the design lead and provided help with design questions. Turns out there was no review for the whole project, only comments on GitHub issues and talks in Slack. A review was requested on May 16th.
The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays.
HTML validates to the proper doctype.
The code has all of the proper hooks in place for localization. (Be sure to ask the Polyglots team to review it.)
✅ That’s true, except for the Update All button.
The feature can be used with just a keyboard.
✅ Confirmed by @aferica.
Any required accessibility support has been added, including (but not limited to) off-screen text, ARIA, and JS-assisted. (Be sure to ask the Accessibility team to review it.)
A merge proposal has been published on the Make/Core blog once the plugin is ready.
@jorbin: The QUnit tests should be merged with the existing tests.
@michael-arestad started with a design review during the chat.
@helen asked: “Given that there was a goal of really polishing the plugin and that it literally has the word “shiny” in the name, how much changing post-merge are people comfortable with?”
@mikeschroder raised a concern on error specificity which is something that he’d consider to be a big support problem.
@jorbin asked: “Who is comfortable merging after the unit test changes unless something the team working on shiny updates team or security team or design team considers major comes up?” @jorbin, @joemcgill, @azaozz, @jeremyfelt, @mapk, @markjaquith, @mikeschroder, @ocean90, @boonebgorges, @karmatosed, @ipstenu, @afercia, @rachelbaker, and @paulwilde reacted with a 👍.
@helen objects: “This seems a little like flexing to favor a merge – that poll is actually saying “this is not ready for merge until XYZ”. I am not saying that that is necessarily a terrible thing, but per my question about what amount of change people (project contributors, committers, etc.) are comfortable with, I am wondering if there is a bit of shifting of mindset from “ideal feature process” to “let’s get it in”.
With 3 teams having a blocker and at least one person who needs more time to review it was decided to set a new deadline for feedback: Monday, June 13th 2016 at 12:00 UTC. An additional meeting will be held on Monday, June 13th 2016 at 19:00 UTC.