Dev Chat Summary, January 28th

https://wordpress.slack.com/archives/core/p1422478864000437

https://make.wordpress.org/core/2015/01/28/dev-chat-agenda-january-28th/

 

Decisions

  • Jumpstart posts will be posted every Monday.
  • Weekly 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. scrubs will occur on Fridays at 16:00 UTC in #core.
  • Each feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. will have a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. mentor.

Assignments

  • @drew will post a Jumpstart to make/core on Monday.
  • @mark will be the core mentor for CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. Theme Switcher.
  • @azaozz will be the core mentor for Press This.
  • @boone will relay term splitting doc plans to the docs team this week.
  • @pento will post a Shiny Updates update post to make/core by the weekend.
  • @ryan will post to make/core about contributing to mobile flow improvements.

Links Mentioned

https://core.trac.wordpress.org/ticket/29820
https://github.com/dd32/Github-to-WordPress-Plugins-Sync
https://core.trac.wordpress.org/ticket/5809
https://core.trac.wordpress.org/ticket/30335
https://core.trac.wordpress.org/ticket/5809#comment:151
https://make.wordpress.org/core/2015/01/26/customizer-theme-switcher-update/
https://github.com/MichaelArestad/Press-This
https://make.wordpress.org/core/2015/01/22/press-this-update/
https://github.com/MichaelArestad/Press-This/issues/36
https://core.trac.wordpress.org/ticket/28579
https://core.trac.wordpress.org/ticket/30988
https://core.trac.wordpress.org/ticket/29906
https://core.trac.wordpress.org/ticket/29989
https://core.trac.wordpress.org/ticket/31162
https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/
https://core.trac.wordpress.org/ticket/30937

Jumpstart Posts

drew [15:03]
1. Kickoff Part II* (edited)

drew [15:04]
The first thing on the agenda is meant to be a continuation of kickoff last week. I wanted to take minute to talk about how I see structuring the release from week to week.

drew [15:04]
*– Monday jumpstart posts*

drew [15:05]
I think in some past releases, we’ve missed an opportunity to really try to set goals at the beginning of weeks instead of waiting until the dev chat on Wednesdays.

drew [15:06]
So starting next week I’ll be posting a jumpstart post on make/core on Mondays outlining the 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) hitlist (more on that later), relevant chat times and locations during the week, and any other priorities or volunteer opportunities there might be for the week to follow. (edited)

Bug Scrubs

drew [15:07]
*– Bug Scrubs*

drew [15:07]
We’ll be starting weekly bug scrubs this week, and those will happen on Fridays at 16:00 UTC in here.

@eric has expressed interest in helping out with those. If anybody else outside the regular cast of characters wants to come and participate, please do. Bug scrubs are a great introduction to how our ticketticket Created for both bug reports and feature development on the bug tracker. process works.

drew [15:09]
As we progress through the release, the frequency of those bug scrubs will likely increase to 3 times a week during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and dailies during RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..

Ticket Management

drew [15:10]
*– Ticket management*

drew [15:10]
Just reiterating that if you milestone a ticket you own it. So keep that in mind. We’ll also be leveraging priorities for this release, I’ll probably post on make/core later this week with how that’s going to work.

drew [15:11]
last one before we jump in to the regular meeting …

Mentoring

drew [15:11]
*– Mentoring*

drew [15:12]
Traditionally we’ve waited until the merge window opens to try to find core mentors for feature plugins. I’d like to start that process now. So in that vein, @mark has kindly consented to helping @celloexpressions ready the theme switcher and @azaozz will be helping @michaelarestad with Press This. (edited)

drew [15:14]
Outside of feature plugins, I think it would be an interesting experiment to invite longer-ish term contributors to seek out new-ish contributors who seem to be struggling with the process, and offer some helpful advice. We only grow by help ourselves :simple_smile:

Feature Plugin Publishing

mark [15:14]
One thing we could do better than previous attempts is to have them in the plugins repo immediately and have them updated regularly (but kept stable-ish).

sabreuse [15:15]
Assuming I can still remember the process myself 🙂 I’m happy to help with helping new folks

sam [15:15]
Both are in the plugins repo now and on the beta tab as well.

drew [15:16]
It may be worth talking to @pento about the best way we might package up some of the shiny updates stuff so it could be testable outside of trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..

michaelarestad [15:16]
We’re looking into a way to send daily updates to the 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 repo. Any ideas welcome.

drew [15:16]
I know he had that plugin on his 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/ account, but I’m not sure what the status is with that, whether it’s simply a proof of concept.

pento [15:17]
The plugin was just a proof of concept.

pento [15:17]
The main work is going into the 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. on #29820.

WordPress TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. [15:17]
#29820: Smooth installation and updating of plugins and themes
https://core.trac.wordpress.org/ticket/29820

pento [15:17]
There’s a certain irony in the plugin updates work not being a plugin, I know.

drew [15:17]
@michaelarestad: I’m pretty sure @dd32 shipped some code last week to make syncing feature plugins to the .org repo easier. He might have more info on that. (edited)

rachelbaker [15:18]
https://github.com/dd32/Github-to-WordPress-Plugins-Sync

GitHub
dd32/Github-to-WordPress-Plugins-Sync
Github-to-WordPress-Plugins-Sync – Scripts for syncing from Github to WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Plugins SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.

dd32 [15:18]
@michaelarestad (and any other feature plugin devs) pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me after the chat and I’ll start looking into the auto-syncing :simple_smile: The script is ready, just needs some proper real testing

dd32 [15:18]
(FYI; I’ve got a different w.org hosted endpoint built for feature plugins)

michaelarestad [15:18]
:sunglasses: Cool. Let’s figure that out afterward.

Term Splitting

drew [15:19]
Alright, let’s move on.

drew [15:19]
*2. Term splitting update*

drew [15:20]
I believe @boone wanted to talk about this.

boone [15:20]
Just for a moment.

boone [15:21]
For those who need a refresher: Shared terms (terms from different taxonomies sharing the same row in wp_terms) were slated to be removed in 4.1, but we pulled it at the last minute because of worries about how plugins store term_ids. See #5809, #30335

WordPress Trac [15:21]
#5809: Updating a term in one taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. affects the term in every taxonomy
https://core.trac.wordpress.org/ticket/5809

#30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id
https://core.trac.wordpress.org/ticket/30335

boone [15:21]
The consensus is that we would write up some clear documentation for plugin authors on how to update their plugins, and shoot for 4.2.

boone [15:22]
https://core.trac.wordpress.org/ticket/5809#comment:151 This latest patch and comment has a brief description of the current state of things, including a link to some draft documentation. If you’re familiar with the issue, please have a look and provide any feedback.

We want to announce this as soon as possible in the dev cycle, but the details have to be pretty well set first, as we don’t want to ask plugin authors to be making updates to their plugins if we’re going to change the internals in teh meantime

drew [15:23]
@boone: What would you need to move this forward for inclusion in 4.2?

boone [15:24]
I’d like a lead – @mark or @nacin probably – to sign off on the draft documentation (and the recommendations that it contains)

Once that’s set, we’ll want to put up some persistent documentation – probably a codex page – accompanied by an announcement on make/core

boone [15:25]
(the commit would happen between those two steps)

drew [15:26]
@sam: Any recommendations on the best place for that documentation?

sam [15:26]
Plugin developer handbook, of course. :simple_smile:

boone [15:26]
Ah yes :simple_smile:

sam [15:26]
But if there’s current codex pages that need updating, we can do that.

nacin [15:26]
@boone you got it.

boone [15:27]
Great. And in the meantime, any dev who has done funky things with taxonomy should feel free to provide feedback on the documentation draft, with your own projects in mind.

That’s it from me. Thanks, drew.

drew [15:28]
@boone: Great. Do you think you could find a minute to pop over to #docs to relay documentation plans to the docs team? Sounds like plugin developer handbook is the way to go.

boone [15:28]
Yes, I’ll do that in the next few days.

drew [15:29]
Excellent.

mark [15:29]
Did we decide if there was any way we could proäctively reach out to plugin authors who might be affected by the tax stuff?

boone [15:30]
mboynes and I did an analysis and found 11ish plugins of the top 100 that will be affected, and I’m glad to reach out to them.

boone [15:30]
I don’t think there’s a way of automating it.

boone [15:30]
unless we send a blanket notice to all authors

mark [15:31]
It would be ones who store ttids, yeah?

boone [15:31]
No, term_id. So we could search plugins for those containing ‘term_id’.

wonderboymusic [15:31]
both really

boone [15:32]
Those using ttid will not be affected, as ttids are persistent.

mark [15:32]
Considering how long tail plugins are, searching term_id plus a little manual peeking at those results might give us pretty broad coverage on the plugins that will cause the most heartache. (edited)

boone [15:33]
The patterns are hard to identify, even in a relatively small sample of the top 100 plugins. But, at the very least, we should call out the most popular ones.

mark [15:34]
Gotcha. Sounds like you have a head start anyway! Okay, I’m good.

Customizer Theme Switcher

drew [15:35]

3. Feature Plugins*

*– Customizer Theme Switcher*

drew [15:35]
It sounds like @celloexpressions isn’t around today to talk, but he did run a chat in here yesterday.

And of course, as mentioned before, @mark will be helping shepherd that effort. Seems like there’s a good deal of testing going on at this stage.

drew [15:37]
If you’re looking for the update post on the Customizer Theme Switcher, that’s on make/core, here: https://make.wordpress.org/core/2015/01/26/customizer-theme-switcher-update/

Make WordPress Core
Customizer Theme Switcher Update
The Customizer Theme Switcher feature-plugin brings theme switching into the Customizer. This project aims to clarify the relationship between themes and theme options by introducing a themes “pane…

I’d like to see a plan in place by next week’s meeting in terms of figuring out which areas are being missed of testing and next steps. (edited)

drew [16:03]

Before we move on to WordPress Core Weekly, I wanted to return to the theme switcher discussion for a minute.

Apparently there’s little to no test coverage for a good portion of the customizer code.

drew [16:03]
And there’s some confusion about whether what is going in now needs coverage – which for the record, I don’t think is confusing at all.

drew [16:04]
I think if it’s new it should be testable regardless of whether tests for existing code are in place.

ocean90 [16:06]
@drew: I agree, Customizer is also more QUnit, where we already have some tests.

westonruter [16:06]
We need PHPUnit tests too

westonruter [16:07]
there is a lot of logic related to filtering settings for preview

westonruter [16:07]
which need tests

westonruter [16:07]
I have written but need update

drew [16:08]
@ocean90: @westonruter @mark I guess the main question I have is how do you think including that testing might influence the current development schedule.

mark [16:09]
@westonruter sounds like he has the best idea.

drew [16:09]
Are there areas where more intensive testing would be beneficial over other areas?

drew [16:09]
Yeah, got it.

westonruter [16:10]
we’ve had a ticket open for awhile to add full 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. coverage for the Customizer

westonruter [16:10]
and have been knocking it out bit by bit

westonruter [16:10]
added a bunch of JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. tests in 4.1

westonruter [16:10]
still lack PHPUnit tests

westonruter [16:10]
but I have a patch

westonruter [16:10]
I want to write extensive tests

westonruter [16:10]
but I need to get confirmation on Transactions

westonruter [16:10]
since that will determine a lot of how the tests are written

ocean90 [16:11]
#28579 is the ticket

https://core.trac.wordpress.org/ticket/28579

WordPress Trac [16:11]
#28579: Add unit tests (phpunit, qunit) for Customizer

westonruter [16:11]
The PHPUnit tests I have written are in a patch on #30988

WordPress Trac [16:11]
#30988: Setting’s default value doesn’t apply on preview window
https://core.trac.wordpress.org/ticket/30988

drew [16:12]
@westonruter: OK. Reframing my question … it’s obvious that the test coverage for the Customizer is lacking currently. Are there specific areas of testing related to implementing the theme switcher that would be blocked by not having existing tests in place already?

eric [16:13]
docs would be cool too :simple_smile:

eric [16:13]
i’m glad to help in that regard

westonruter [16:14]
I need to look at the Theme Switcher more to get a sense of the tests required

westonruter [16:14]
It’s on my todo list

drew [16:14]
OK, great. Thanks.

westonruter [16:14]
but from what @celloexpressions has said, it doesn’t introduce fundamental changes, but is more of a UIUI User interface enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.

westonruter [16:14]
so I don’t think unit tests are critical to move forward

westonruter [16:15]
Transactions, on the other hand, are critical to have unit tests because it is a fundamental change

Press This

drew [15:39]

– Press This*

@michaelarestad: How’s it going?

michaelarestad [15:40]
It’s moving along pretty quickly. There’s been much more activity on the repo since last week and a few more contributors. We’ve started making some decisions on which features to include for 4.2. Some of the fancier things (browser extensions) are being pushed to a future update/release. @azaozz is working on adding TinyMCE (and apparently has a demo working somewhere). We’re exploring installation UXUX User experience for the bookmarklet.

Like I mentioned earlier, daily updates to the plugin repo will be handy because we could use more users testing it out and providing feedback/suggestions. https://github.com/MichaelArestad/Press-This (edited)

michaelarestad [15:42]
We have two major features to be added. TinyMCE and the image modal.

drew [15:42]
And I see you posted an update last week on make/core: https://make.wordpress.org/core/2015/01/22/press-this-update/

Make WordPress Core
Press This update Once again it’s been awhile…
Press This update Once again, it’s been awhile, but let’s get everyone unfamiliar with this project as it’s about to go full steam ahead again. What is it? Press This is a redesign with a focus on …
Jan 21st at 20:26

michaelarestad [15:42]
Work on both is being done.

michaelarestad [15:42]
Yep.

Our meeting time is Thursday at 17:00 UTC in #feature-pressthis

drew [15:44]
@michaelarestad: Do you see any blockers in terms of having the time and resources to also test these two new, fairly large additions?

michaelarestad [15:45]
There could be a potential blockerblocker A bug which is so severe that it blocks a release. on the media modal integration. I’m fairly confident we can have TinyMCE integrated with few issues.

michaelarestad [15:45]
@stephdau: Thoughts?

drew [15:45]
It’s obvious these parts are pretty vital to post-writing workflow. I just want to make sure you’ll be able to ebb and flow as we lead up to the opening of the merge window.

kjprince [15:45]
joined #core

stephdau [15:46]
@michael: Ozz has some uncommitted code that brings TinyMCE in PT, I saw it in Texas last week. We wouldn’t call it a blocker, from what we discussed in person.

stephdau [15:47]
He’s been sick for a couple of days though, but we shall now more shortly.

stephdau [15:48]
What I saw was encouraging, but we need to dump the current image selection UX, as being investigated in https://github.com/MichaelArestad/Press-This/issues/36

GitHub
Need to rethink and finalize the image/embed selection process. · Issue #36 · MichaelArestad/Press-This · GitHub
Press-This – Posting images, links, and cat gifs will never be the same.

michaelarestad [15:48]
Yep.

stephdau [15:48]
Doesn’t fit in with the TinyMCE/WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. paradigm

michaelarestad [15:49]
Also, we want to take advantage of the work being done in #feature-imageflow when that gets merged in.

drew [15:49]
@michaelarestad: Have you consulted with the a11yAccessibility 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) team yet on concerns they might have, or are you waiting on having more of an MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia first (minimum viable productMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia)? If the latter, when do you see getting to that point?

michaelarestad [15:50]
I’d like to get TinyMCE in first so we don’t end up having to test the editor twice. (edited)

drew [15:51]
OK. And your feature chat is tomorrow, correct?

michaelarestad [15:51]
Yep.

stephdau [15:51]
Should be a fun one (unsarcastically so)

michaelarestad [15:51]
Yep.

drew [15:52]
I think you’ll want to work with @azaozz to figure out what’s left on your checklist and make some decisions about what needs to happen to hit the February 11th deadline.

michaelarestad [15:52]
Yep.

drew [15:53]
Alright, great work so far. Keep it up :simple_smile:

Shiny Updates

drew [15:53]
– Shiny Updates*

@pento: How’s it going?

pento [15:53]
It’s going. :simple_smile:

Updates are working on `plugins.php`, installs are working on `plugin-install.php`. (edited)

drew [15:54]
It’s worth mentioning to everyone else that “Shiny Updates” isn’t strictly a feature plugin but _is_ an action item for 4.2. It’s mostly localized to a couple of trac tickets.

pento [15:54]
I have a rough TODO list:

pento [15:54]

  • Add FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients. support
  • Update themes from `themes.php`
  • Install themes from `theme-install.php`
  • Do updates from `update-core.php`
  • One click updates from `update-core.php`

pento [15:55]
And some things to make more betterer:

  • Handle errors
  • Figure out a nice way to show progress
  • Make sure we don’t activate plugins that cause PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher errors
  • Move the JS strings to central location
  • General code tidying and refining

lgladdy [15:55]
Was there any progress/opinions on post-install action @pento?

pento [15:56]
No change there. It’ll either be a plugin headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., as you suggested, or a special post-install hook.

pento [15:57]
But I really like the idea, especially for more advanced plugins.

drew [15:57]
@pento: Are you needing any kind of additional feedback from ui folks? Have you consulted with the a11y team or mobile to get feedback on the experience(s)?

pento [15:58]
For UI, I need some thoughts on how to show that things are progressing, even though the UI isn’t changing. For example, Jetpack takes ~30 seconds to install, which is a long time to be staring at a spinner.

pento [15:59]
I haven’t consulted with either a11y or mobile yet.

georgestephanis [16:00]
We’ll take far less once we don’t need to ship translations!

georgestephanis [16:00]
flees.

pento [16:00]
@georgestephanis: Sorry to pick on Jetpack, it’s just a convenient example. 😉

georgestephanis [16:00]
@pento: :heart:

georgestephanis [16:00]
I accept being the elephant in the room.

mark [16:00]
The elephant that spans all rooms in the east wing.

strebel [16:01]
ha

drew [16:01]
@pento: OK. I think you said you’d be holding a short chat right after dev chat today (correct?), and I’d like to see an update post on make/core before the weekend if possible.

pento [16:01]
Sure.

drew [16:01]
Maybe you could gather some moss there in terms of feedback.

pento [16:02]
I’ll be around for a bit, I’m happy to chat about what still needs to be done.

drew [16:02]
Great. Thanks for the update.

pento [16:02]
:thumbsup:

WordPress Core Weekly

Make WordPress Core [16:04]
WordPress Core Weekly
Hi Everyone! It’s time for another run-down of what’s going on in WordPress core. This edition covers January 17th, 2015 [31234] through January 25th, 2015 [31281]. If you’re interested in helping out with these updates, comment below, or ping me 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/. as @mike! Without further ado: Adminadmin (and super admin) Menus: Improve accessibility of nav menu locations […]

Make WordPress Core
WordPress Core Weekly

https://make.wordpress.org/core/2015/01/28/wordpress-core-weekly-5/

Hi Everyone! It’s time for another run-down of what’s going on in WordPress core. This edition covers January 17th, 2015 [31234] through January 25th, 2015 [31281]. If you’re interested in helping …
Today at 14:38

drew [16:05]
Serendipity!

drew [16:15]
*4. WordPress Core Weekly*

drew [16:15]
As you can see ^^, @mike very kindly posted last week’s roundup on make/core a little while ago.

drew [16:16]
Mike’s going to need some help going forward. Any volunteers?

morganestes [16:17]
raises hand timidly

drew [16:17]
Excellent!

drew [16:17]
I think we can judge from @nacin‘s silence that he’s an obvious choice here as well.

drew [16:18]
@morganestes I’d say get in touch with @mike and he can give you the skinny on what that entails.

johnbillion [16:19]
I’ll volunteer for weekly roundups too

drew [16:20]

@johnbillion: Awesome. The more volunteers, I’m guessing the less work there is to do.

sam [16:20]
There’s a channel for this, of course. Those interested should join #core-weekly-update. :simple_smile:

boren [16:20]
I can provide material. Collate our perspectives.

johnbillion [16:20]
Holy topical channels Batman

sam [16:21]
I am certain @mike can use you all there. :simple_smile:

boren [16:21]
OUT threads and Jumpstart could be mined for material.

Accessibility

drew [16:22]

*5. Accessibility*

drew [16:23]
As mentioned earlier, we’re trying a more proactive approach to tackling open accessibility tickets in 4.2.

drew [16:23]
On Monday, @joedolson and I went through the entire list of a11y tickets marked for priority in 4.2 and came up with potential owners for all of them.

drew [16:24]
The plan is to identify 3-5 tickets a week that would make up a “hitlist” for the Monday jumpstart posts. We’d promise to dedicate resources to working on those tickets that week and the a11y folks would be proactive about recommending those tickets every week.

drew [16:25]
@afercia has kindly volunteered be present and attentive at the weekly dev chats (hi!) and we’ll see how this goes.

afercia [16:25]
hello everyone :simple_smile:

drew [16:26]
Obviously the goal is to try to find some wins and close out some of the accessibility tickets that have been hanging out there on trac for a while.

johnbillion [16:26]
Awesome

drew [16:27]
I believe @jorbin will also be involved in this effort as well.

Mobile

drew [16:27]
*6. Mobile*

drew [16:27]
@boren: Did you want to weigh in on what kind of feedback you’re looking for on #29906 and #29989?

WordPress Trac [16:27]
#29906: Submenus can’t be dismissed on mobile.

https://core.trac.wordpress.org/ticket/29906

#29989: Hide Media Buttons on small screens

https://core.trac.wordpress.org/ticket/29989

drew [16:29]
Apparently he’s stepped out.

drew [16:29]
It appears that these two tickets are of particular interest to the make-flow effort for 4.2.

drew [16:30]
29989 seems like it might be related to auto-focus of a text field when the modal opens. @azaozz or @helen might have some insight on that.

helen [16:31]
not following.

drew [16:31]
Tapping an image in the editor launches the edit image modal. And on mobile it launches the keyboard when you open that modal.

drew [16:31]
Wrong ticket. Whoops! haha

helen [16:32]
well you are focusing inside the editor, so it shows a keyboard. i’d have to look at the modal stuff, i know we had to deal with that somewhere once already, but i doubt the two things are really related.

drew [16:32]
I think I was thinking of #31162, my badness.

WordPress Trac [16:32]
#31162: Prevent device keyboard from displaying after selecting an image in TinyMCE
https://core.trac.wordpress.org/ticket/31162

iseulde [16:33]
I’ll take a look at that last one next week, together with other editor on mobile stuff.

drew [16:34]
@iseulde: Great.

iseulde [16:34]
I wonder if it would make sense to add a “mobile” focus to Trac. Think @boren would like that.

boren [16:35]
Sorry, I was kibbling a bug I saw while live note taking the meeting. :simple_smile: (edited)

drew [16:35]
@iseulde: I’ve brought it up before, but haven’t gotten any traction. You’re welcome to try to convince @nacin :simple_smile:

iseulde [16:35]
Sure, I think it makes sense @nacin. (edited)

helen [16:36]
i’m not sure what “mobile” means – touch? screen size?

boren [16:36]
@drew I’m looking for the committed patch kind of feedback. :simple_smile:

helen [16:36]
we focus a lot on devices instead of capabilities, would really like to shift our thinking to capabilities instead.

nacin [16:37]
I think “mobile” has never been proposed beyond vague platitudes as to what it means.

nacin [16:37]
Otherwise, sure, whatever.

drew [16:38]
OK. @boren I think a post on make/core or make/flow explaining how people can contribute would be a good next step.

hereswhatidid [16:38]
left #core

drew [16:39]
Sorry folks, I realize we’re running a little long today.

boren [16:39]
@drew Okay.

drew [16:40]

Other Stuff

*7. Other Stuff *

drew [16:40]

I think @westonruter was soliciting feedback on his Customizer Transactions proposal on make/core, here: https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/

Make WordPress Core
Proposal: Customizer Transactions
You may be familiar with transactions in a database context. The idea is simple: once you start a transaction, any change made to the database in the current session will not be applied to other da…
Jan 26th at 05:04

drew [16:41]
There’s also a ticket: #30937

WordPress Trac [16:41]
#30937: Add Customizer transactions

https://core.trac.wordpress.org/ticket/30937

drew [16:42]
Lastly, @pbearne would like to request the ability to fast-track commits on test coverage for existing code.

westonruter [16:43]
(I’m back)

drew [16:43]
@wonderboymusic: Any suggestions on the best workflow for fast-tracking those kinds of commits?

helen [16:44]
they already seem to go in faster, not sure what the ask really is

drew [16:44]
Seems like sometimes they get committed alongside tickets asking for new functionality tests, seems like @boone‘s suggestion for simply splitting those tests to separate patches would do the trick.

#4-2, #meeting