Dev Chat Summary: June 21st (4.8.1 week 1)

This post summarizes the dev chat meeting from June 21st (agendaSlack archive).

4.9 ideas and brainstorm

  • No immediate 4.9 timeframe, but the planned timing for 4.9 will come shortly after we confirm the major focuses of 4.9 and will be closer to 3 months than 9 months in duration
  • @jorbin: Scheduled customizer changesets going live could be a big win
  • @westonruter: adding statuses for changesets: being able to draft a changeset to come back to later, and then to be able to schedule it to go live.
  • @youknowriad: We have some REST API needs in Gutenberg:
    • Retrieving The permalink using the API (making more things available from wp-json/wp/v2/settings)
    • An API endpoint to save/get random settings (we’d use it to save some layout options)
  • @androb: Expanding link boundary behavior in TinyMCE to other inline elements
  • @androb: TinyMCE has a new mobile-optimized UX that will also result in a responsive toolbar, this should land in the 4.9 time frame
  • @androd: tweak the TinyMCE UI to be closer to Gutenberg (e.g. toolbar color, default font) to get users used to the Gutenberg UI before releasing that in WordPress 5.0
  • @saracannon: look at customizer revisions in a way that we might want to look at Gutenberg revisions in the future from a visual standpoint and start making progress there (@melchoyce: see mockup for customizer revisions on #21666)
  • @melchoyce: code editing improvements across core — CSS editing, the plugin/theme code editor, etc. Making it better to use and harder to mess up and break your site (see #31779)
    • @clorith: As soon as we do this, we need to handle the issue of lacking forked plugins, lacking child theming etc
    • @westonruter: add a warning to encourage people to be aware of the dangers of editing code without version control (see #41078)
  • @melchoyce: evisions for everything – Customizer revisions, page/post revisions, code editor revisions…
  • @hugobaeta: reduce the amount of declared colors (namely shades of gray) in the admin, more info on codepen and a little backstory on this flash talk at WCUS last year
  • @melchoyce: some in-progress tickets for improving theme switching: #39692, #39693
  • @melchoyce: also Customizer menu improvement – #40104
  • @melchoyce: automated testing in place for theme switching (@netweb to work on this)
  • @melchoyce: making “page on front” less confusing (again)
    • @westonruter: harmonizing with menus and page hierarchies. Merging those concepts together
  • @melchoyce: finish the gallery widget (@m1tk00 to work on this)

4.8.1 agenda

  • @westonruter: resolve text widget removing code issue (see #40951) alongside implementing HTML code widget (see #40907), three options proposed, one recommended
  • a11y bug-scrub will happen next Monday, will focus on 4.8.1 milestoned tickets
  • approaching 4.8.1 tickets as more traditional regression types of issues
  • Tentative timeline for 4.8.1 last week of July

#4-8, #4-8-1, #4-9, #core, #dev-chat, #summary

Dev Chat Summary: June 7th (4.8 week 6)

This post summarizes the dev chat meeting from June 7th (agendaSlack archive).

4.8 timing recap and Pre-Final Release & Dry Run checklist items

  • Beta 1 went out on Friday, May 12th; Beta 2 went out on Monday, May 22nd
  • RC1 went out on Thursday, May 25th; RC2 went out on Thursday, June 1st
  • 4.8 is scheduled for June 1, 2017 at 9am EDT
  • Events widget looks ready
  • Credits API to be updated by @ocean90 tomorrow morning
  • About page update for responsive, CDN-hosted images coming from @melchoyce
  • Announcement post draft is ready to go; @jorbin & @ocean90 to help provide contributor & language count as input
  • Announcement email being drafted by @matt
  • Codex page to be updated by @jbpaul17
  • Agreed to remove “partial back to IE8” from Browser support page in Design handbook
  • tinymce/plugins/wpembed to be added to $_old_files by @ocean90
  • No new default theme, so $_new_bundled_files is fine
  • Updates to default themes and submission to repo to be done by @davidakennedy, committed by @ocean90
  • Hosts email to be drafted by @jbpaul17, email to be reviewed & sent by @jorbin
  • Systems to be covered by @vnsavage
  • grunt prerelease check for tests & standards to be run by @jorbin

4.8 Bug Scrub

  • Reviewing four tickets in Defects Awaiting Review, reported against trunk section from Report 40
  • #40929: relates to improved translator docs, punting to next minor release (4.8.1)
  • #40932: moved to Future Release
  • #40927: not a regression, moved to Future Release
  • #40906: marked as a dupe of #40685, not a blocker for 4.8

Other News

  • Customize: looking for a new contributor to work on the HTML/Code widget, a good-first-bug, please chat in #core-customize if you’re interested
  • Editor: working to get the plugin in the plugin repo so that more people can review it and provide feedback. Goal is this week.
  • Devchat coordination: will be covered in upcoming devchat

#4-8, #core, #core-editor, #dev-chat, #summary

JavaScript Chat Summary for May 16th

Below is a summary of the conversation from today’s JavaScript Chat (agenda, Slack archive):

Build Tools for Code Standards

  • There’s a desire to replace the current JSHint configuration with an ESLint solution (#31823)
  • @netweb shared a number of ESLint-related projects targeting parity with existing JSHint and JSCS configuration
  • JSHint was mainly designed to identify potentially erroneous code. ESLint builds upon this with support for style and custom rule enforcement
  • What steps do we then take to extend the ruleset to meet the remainder of the JavaScript Coding Standards? Parity with .jshintrc has the benefit of serving as a drop-in replacement, but legacy code and existing patches may be impacted by broader rule enforcement.
  • Options for incremental adoption of rules: first configure rules as warnings, or attempt to lint only lines modified in proposed change (as in PHPCS, or Calypso’s git-based eslines)
  • Alternatively, forgo incremental adoption and instead make a single pass to fix offending code, using ESLint’s fixer or prettier (discussion ticket to be created), at the cost of potential disruption to existing patches by conflicts introduced. This appears to be the favored path.
  • How do we reconcile a desire to retroactively fix coding offenses with our guidelines explicitly forbidding this sort of refactoring? The guideline was revised with an ending note about internal consistency. @jorbin later remarked that exceptions have been made in the past for allowing JSHint-based refactoring.

General Remarks on JavaScript Standards

  • @aduth raised a concern of the difficulty in following spacing exceptions on function arguments, arguing that the mental overhead in understanding how context varies application of the rule could explain why it’s followed inconsistently.

Tickets

  • @adamsilverstein requested feedback on a ticket proposing to make two utility functions specific to Press This more widely available (#40635)

Open Discussion

  • A meeting topic was proposed: Module patterns to extend or replace Browserify and make internal utilities more broadly available. Special attention will need to be made for interoperability with existing patterns for declaring script dependencies.
  • A meeting topic was proposed: Making a decision on a framework to use in place of Backbone, based on consensus from last week that a replacement is needed.

#javascript, #summary

Dev Chat Summary: March 15th (4.7.4 week 2)

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

4.7.4 Planning

Browser support

  • 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

Customize team

REST API team

  • 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

General announcements

  • 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 @cover and @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.

#4-7, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #dev-chat, #summary

Dev Chat Summary: March 8th (4.7.4 week 1)

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

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

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

Dev Chat Summary: March 1st (4.7.3 week 5)

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

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th 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
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

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

Planning for Community Summit 2017

In preparation for the 2017 WordPress Community Summit (“CS”) on June 13th-14th before WordCamp Europe in Paris, France we’ve been asked to provide the following (in summary):

  1. A list of topics for the CS
  2. A list of representatives to attend the CS
  3. One or two contributors who are willing to help with the organization of the CS

This post serves as a request for input for the above three areas. Note that these three requests are detailed further with some clarifying notes on Make/Summit.

I will capture and summarize comments on this post ahead of next week’s Core dev chat, will present them for review in next week’s Core dev chat, and then send our responses back to the Community Summit team by next Friday, March 3rd.

#community-summit

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

Week in Core, December 14th 2016 – January 3rd, 2017

Welcome back the latest issue issues (sorry) of Week in Core, covering changes [39599-39665]. Here are the highlights:

  • 67 commits
  • 56 contributors
  • 203 tickets created
  • 24 tickets reopened
  • 145 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Bootstrap/Load

  • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
    Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39605] #39132

Build/Test Tools

  • Tests: Restore the database connection earlier when switching test groups. [39626-39627] #39327

Bundled Theme

  • Twenty Seventeen: Fix incorrect $content_width value in theme. [39635], [39650] #39272
  • Twenty Seventeen: Hardens the logic for calling featured image in header.php [39624] #39302
  • Twenty Seventeen: Ensure functions in customize-controls.js don’t count on Customizer sections always being present [39623] #39335
  • Twenty Seventeen: Improves code readability and code standards in files [39618] #39152

Comments

  • Ignore the ‘comment_order’ setting when determining comment pagination. [39663-39664] #31101, #39280
  • Fix placement of the wp_update_comment_data filter to safeguard filtered data from triggering a database error. [39640-39641] #39380

Customize

  • Fix visible edit shortcuts for wp_nav_menu() instances using the menu arg (such as in the Custom Menu widget) instead of the theme_location arg. [39622], [39653] #27403, #39101
  • Bump wp_custom_css_cb from running at wp_head priority 11 to 101 to ensure Custom CSS overrides other CSS. [39616], [39651] #35395, #38672, #39270
  • Prevent edit shortcut from losing event handler after selective refresh. [39606] #27403, #39100

Editor

External Libraries

Feeds

  • Replace the RSS2 lastBuildDate date field with the r date specifier. [39614] #39141
  • Do not translate the lastBuildDate field in RSS feeds. [39613] #39141

Filesystem API

  • Filesystem: Add return statement to WP_Filesystem_ftpsockets->rmdir [39644] #39405

General

  • Update copyright year to 2017 in license.txt. [39659], [39661] #39433
  • Docs: Misc corrections and additions to inline documentation. [39639] #39130
  • Use interpolation instead of concatenation for all dynamic hook names. [39600] #39148

Mail

  • Ensure that any phpmailerException exceptions generated by setFrom() are caught to avoid PHP Fatal errors. [39655] #25239, #39360

Media

  • Move a variable definition outside of conditionals to ensure it’s always available.
    This [39654] #39250
  • Allow PDF fallbacks filter to process custom sizes. [39617] #39231, #38594
  • This [39612] #39250
  • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39607] #39195

Posts, Post Types

  • Taxonomy: Eliminate redundant and inaccurate dupe check when creating categories from post.php. [39637] #16567
  • Ensure is_page_template() can only return true when viewing a singular post query. [39599], [39608] #39211

Query

  • Don’t double-escape terms payload in WP_Tax_Query::transform_query(). [39662] #39315
  • Improve documentation for orderby=relevance in WP_Query. [39636] #39336

REST API

  • Add missing assertions to the view and embed context response data for the Users Controller. [39660] #39399
  • Add the supports property to the Post Type response object. [39647] #39033
  • Remove errant annotation from test_get_items_pagination_headers() method. [39643] #39398
  • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39642] #38593, #39042
  • Docs: Add and correct @since docs for a variety of functions and methods. [39638] #39343, #39357, #39344, #39130
  • Allow sending an empty or no-op comment update. [39628] #38700
  • Improve the rest_*_collection_params filter docs and fix the terms filter. [39621] #39300
  • Fix PHP warnings when get_theme_support( 'post-formats' ) is not an array. [39620] #39293
  • Do not include the password argument when getting media items [39610] #38977
  • Do not error on empty JSON body [39609] #39150
  • WP-API: JavaScript client – fix setup of models used by wp.api.collections objects. [39603-39604] #39070
  • Add support for filename search in media endpoint. [39598] #39092

Shortcodes

  • Clarify the docs for pre_do_shortcode_tag and do_shortcode_tag. [39665] #39294

Taxonomy

  • Redirect to current taxonomy when adding a term without AJAX. [39649], [39652] #39328
  • REST API: Merge similiar error message strings in the Terms Controller. [39648] #39176
  • Ensure that mods to query vars in pre_term_query callbacks have an effect. [39625] #39354
  • Restore the ability to use string-based $args in wp_get_object_terms(). [39611] #39215

Upgrade/Install

  • Updates: Show the Authentication key settings after selecting the SSH transport in both the modal, and also on the plugin/theme updates screen. [39657-39658] #39057
  • Updates: Remove a stray " from a tag. [39656] #39057

Thanks to @adamsilverstein, @afercia, @bcworkz, @boonebgorges, @chandrapatel, @ChopinBach, @chris_de, @davidakennedy, @dd32, @dhanendran, @dl, @dlh, @dots, @dreamon11, @dshanske, @garyc40, @gitlost, @iseulde, @jblz, @jesseenterprises, @jfarthing84, @jnylen0, @joemcgill, @johnbillion, @jorbin, @JPry, @keesiemeije, @keesiemeijer, @kkoppenhaver, @kovshenin, @laurelfulford, @MattyRob, @MikeHansenMe, @natereist, @Nikschavan, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sfpt, @shazahm1hotmailcom, @sirbrillig, @sstoqnov, @stevenkword, @szaqal21, @thepelkus, @timmydcrawford, @tymvie, @tyxla, @voldemortensen, and @westonruter for their contributions!

#4-8, #week-in-core

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