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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. needs to provide
    • Best to prototype and demonstrate use case via 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 Plugin Directory or can be cost-based plugin from a third-party first
    • Also dev education to understand problem and available, reasonable solutions
    • @igmoweb to write up idea as blogblog (versus network, site) post or TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. to detail concept, gather input from others via comments, and bring back to a future dev chat
  • Should we start requiring JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. for most of WP Adminadmin (and super 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 CSSCSS Cascading Style Sheets. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.
  • 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-1, #core, #dev-chat, #summary