Additional meeting to consider the Shiny Updates plugin for merge

As announced in last week’s dev chat we’ll have an additional meeting to consider the Shiny Updates pluginPlugin 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 for merge today, June 13th, 2016 at 19:00 UTC.

Following a summary of the merge discussion from June 8th.

Merge Criteria

A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community.

✅ https://wordpress.org/plugins/shiny-updates/

Weekly chats are taking place on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., and the feature lead is attending the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..

✅ 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.

✅ https://make.wordpress.org/flow/tag/shiny-updates/

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 standardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP 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 Docsinline docs (phpdoc, docblock, xref) 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., 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 GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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.

✅ https://make.wordpress.org/flow/tag/shiny-updates/

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. validates to the proper doctype.

The code has all of the proper hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. in place for localization. (Be sure to ask the Polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. to review it.)

WordPress continues to function, and the feature is still usable, with JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. turned off.

✅ That’s true, except for the Update All button.

The feature can be used with just a keyboard.

✅ Confirmed by @aferica.

Any required accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) support has been added, including (but not limited to) off-screen text, ARIA, and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.-assisted. (Be sure to ask the Accessibility team to review it.)

A merge proposal has been published on the Make/Core blogblog (versus network, site) once the plugin is ready.

✅ https://make.wordpress.org/core/2016/06/02/proposal-more-shiny-updates/

 

More Feedback

  • @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 testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. 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 blockerblocker A bug which is so severe that it blocks a release. 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.

#4-6, #shiny-updates