Community Summit 2017: Sign-up Request

The Community Summit unconference is the event of conversations, so the time will be dedicated to group discussions prioritizing topics or tasks which are sensitive enough to specifically require in-person discussion and of importance to the open source project and plan for the coming year.

We know that lots of people contribute to the success of WordPress in ways that don’t fit into our current set of contributor teams, so we’ve also reserved some spots with those contributors in mind.

Summit attendees will be selected based on what topics are identified by contributor teams as sensitive or contentious enough to require an in-person discussion to resolve them. Or if you wish to submit a discussion topic for the 2017 summit, please fill out the form below. Note that you can nominate yourself or any other person who you think is required to reach agreement on the issue.

We’ll create a committee with all team reps to select the topics and participants submitted through this form and we’ll contact the selected attendees before March 15th.

Note: Promotional activities of any kind will not be welcome.The entire event is dedicated to the WordPress open-source project and its future.

If you’d like to submit a topic to be discussed at the summit, fill out the form here.

Community Summit 2017

The 2017 WordPress Community Summit (CS) will take place on Tuesday-Wednesday, 13-14 June, before WordCamp Europe in Paris, France (the venue will be in the XV district of Paris).

The CS is now in the planning stages, and this site will grow in the coming weeks to include information for attendees as well as event sponsorships, agenda, etc.

Based on the feedback and discussion p2 post ( about a new approach for the 2017 CS, these are the next steps for every contributor team.

Next Steps:

Team reps, please post the following in a comment to this post.
The deadline is March 3rd, 2017.

  1. A list of topics/issues which are relevant for the progress of the team and the WordPress open source project as a whole, prioritizing topics or tasks which are sensitive enough to specifically require in-person discussion.
  2. A list of representatives to attend the Community Summit (not limit-determined, but please keep in mind that our venue capacity limit is of 190 attendees), with selections based on several factors, including: representation of a wide, diverse range of opinions (based on the agreed-upon topics selected by each team), diversity, inclusion, and activity of the contributors.
  3. One or two contributors who are willing to help with the organization of the event: posts, communication, travel assistance, finding sponsors, etc. The intention of this approach is to propose a more open and team-focused Community Summit with transparent participation from all active contributors and reps of each team. This way we can hopefully anticipate barriers and cross-team difficulties that might come up, and avoid them.


  1. The contributors who are willing to work on the summit (referenced in #3, above) will join the WCEU team working on the Community Summit. If there are not enough contributors available to help organize, the WCEU team has volunteers available to help.
  2. We’ll work on finding sponsors to cover travel expenses for those contributors who face financial barriers. We’ll open a call for CS sponsors in the next days.
  3. For those teams with sub-teams, for example, Core: REST API, security, etc. the representation of these sub-teams will depend on the list of discussion topics provided by the team.
  4. In the next days, we’ll open an application form for people who aren’t invited as contributors, but who represent other interests within the wider WordPress Community.

Pinging all team reps:
Accessibility: @rianrietveld, @joedolson, and @afercia
Community: @francina and @hlashbrooke
Core: @jeffpaul, @helen
Design: @melchoyce, @karmatosed, @joen, @michaelarestad
Documentation: @kenshino
Test: @designsimply
Hosting: @mikeschroder
Marketing: @rosso99
Meta ( Site): @samuelsidler
Mobile: @astralbodies, @rachelmcr
Plugins: @ipstenu
Polyglots: @petya, @ocean90, @nao, @chantalc, @deconf, @casiepa
Support: @macmanx
Themes: @jcastaneda, @grapplerulrich
Training: @bethsoderberg
TV: @jerrysarcastic, @roseapplemedia

Welcome to the Community Summit Workspace!

The Community Summit is a working day for face-to-face discussions of thorny or incendiary topics (the kind that frequently result in flame wars). Sometimes it is followed by 1-2 Team Days where each project team has time to complete targeted projects together. The Summit is a small event that isn’t owned by any one project team, so this space is where you can find information about planning, participate in discussions, and generally stay informed as the event takes shape.

After each event, we’ll also post anonymized notes here so that discussions are open and available to anyone participating in the project in the future. They aren’t necessarily held every year, though, so there will be times when this p2 is quieter than usual.

Subscribe to stay informed, and happy planning!

#summit #announcements

Notes from Eliminating Pain when Changing Themes discussion

One of those frustrating issues. 1) Target the problems and 2) propose solutions.

Nothing works when installing a new theme. Doesn’t look like the picture. Takes time (a couple of hours even) to get it set up. How can the theme switch be minimized so that the new theme contains the old site content without any additional work?

Chris: Problem is assumptions. The assumptions we make only fit to a certain category of themes. Inconsistincies crop up and bad things happen then. There’s not an ability for an admin to change something and not modify the front end for visitors. A theme “trial run”. Customizer does this a bit, but not to a great extent. This wouldn’t work for Chris’s complex theme.

Chris: If there was a way to start up a trial run, and then push it live when it’s ready.

Clay: Widgets are the biggest issue. Switching themes puts all the widgets in the unused widgets section and scatters them.

IDEA: Storing groups of widgets to allow for dropping them in after changing themes.

Michael: Allowing a theme to define a primary widget area. Most themes will have that in the sidebar, but in some cases could be a footer or otherwise. Skip the step for at least one widget area.

Clay: Might not need much of a new UI, really.

Now discussing menus and how they behave. Builder, for instance, can have many layouts and change things. Since changes in recent versions, child theme changes when using the same sidebar IDs scatters widget setups.

“Every widget be shufflin’”

Moving away from widgets. What about when a featured image call is made and there isn’t a featured image set? What should we do?

IDEA: A fallback, designed specifically for those cases. Apparently Genesis does something similar by declaring a fallback image in the theme folder. To avoid including multiple sizes, Michael suggests using media sideload to move the image over into the WordPress media section so resizing can happen natively.

Chris: iThemes did an editor-only thumbnail image that tells them there is no image there, but they can add one if they want. And that they are the only ones to see the image.

Michael: A user suggested a UI for quickly adding featured images to posts. Could be plugin territory.

Problems so far boil down to widgets and featured images.

Syed: Moving from a framework theme to a dot org theme will confuse people. From many things/screens to something simpler.

Chris: We have pressure from customers to do that kind of stuff.

Syed: WooDojo, for instance, solves the problem of duplicating lots of code in a bunch of themes. Or at least, allowing users to swap themes and keep core functionality.

Ryan: TGM Plugin Activiation class, dropping notices within statuses.

Michael: I hate when themes put the home page template in the page template. For one thing, which theme screenshot do you display if you have a front page and a blog page? Two screenshots? Multiple image UI? Or on that page, since the dashboard knows the setting that is chosen, just display the one that’s selected. So, include two screenshots, one for each type. Naming convention maybe?

Chris: We’ve trained people that themes are easier than plugins. It’s understood that plugins are a bit more work. But for themes the expectations are different.

Michael: JUX is a publishing platform on the front end that loads content on the get-go every time. He doesn’t like it, but it’s kind of neat he says.

Chris: Perhaps multiple screenshots showing different possible setups is one way to approach the problem.

Is there any way that we can track statistics for how widgets are used?

Action Items

  • Start a ticket for the issue when widgets are scattered after a child theme is modified, when using the same sidebar IDs.
  • Start a trac ticket for grouping widgets to make swapping them between themes after switching themes.
  • Start a discussion around a plugin for quickly adding featured images to a bunch of posts.


How WordPress Businesses Can Give Back

Simon Wheatley – If Simon runs into a problem in core then he tries to create a trac ticket and follow that through

Jonathan Davis – Shopp. Contributes bug fixes, hasn’t managed to get a ticket in.
Mike Pretty – Wants to work out how to work with core to create a team to work on bigger tasks.
Jake Goldman – 10up Ad hoc trac widgets, donate 50% of Helen’s time to core.
Tom Auger – Runs an agency, attends events. Wants to work to GPL his plugins
Tom Willmot –
Ronnie Burt – Edublogs no formal process, developers create bugs, focused on Multisite
John Hawkins – no formal process, runs on trunk, more of a ticked submitter instead of a patcher
Alex King – Lots of ad-hoc trac tickets, they run into a lot of edge case issues that might not be found otherwise. Have found that larger tickets can stall
Ptah Dunbar – Runs an agency, hires contractors – Has “Open Source Fridays” to contribute back to core but finds he ends up doing a lot of admin work.
Ron Rennick – Copyblogger Media – Does a lot of multisite testing, does a lot of testing of large new features coming in the next version (like media stuff). Self funded his way through the work to merge mu and single, it took a lot longer than expected which was tough.
Justin, iThemes – No formal core contribution policy, would like to have one.

People find that they spend to much time on admin around trac tickets and not enough on developers.

Jake shared how they started the process of Helen contributing to core, it’s driven by her passion, started as a small percentage of her time, increased over time.

Helen is not the only person that has “non-client” time, others choose to spend it on plugins etc.

It has to be driven by the person, you can’t expect all employees to contribute or to want to contribute. There is a large amount of trust. You can’t micromanage the amount of time you are allowing that person to core, it’s a privilege to be allowed to contribute to core.

Alex felt that the issues around trac tickets not being well received, abandoned etc. can put people off. It’s a worry that one of your staff spends a month of company time on a patch that then isn’t accepted. What about if core team had a better roadmap that they shared with companies, companies could then pick large items off the roadmap.

Nacin joined the discussion, was asked about assigning large tasks to agencies to work on. The point he made was that agencies would often write that feature anyway because it’s something that they need for a client site, so build that feature as a plugin and if it gets traction then it can find its way into core.

Why can’t core team reach out to development shops and ask them for help with specific items. Nacins point was that he wasn’t sure that agencies would want to do that. Also large feature development shouldn’t be happening behind closed doors. Also agencies could offer to help develop specific features.

iThemes shared their experience with the image uploader, they had a meeting where they brainstormed how they would fix the image uploader but they found that Koop was already working on it. They felt it would have been better if that had been shared earlier. Nacin felt that it was shared as early as it could be. Nacin talked about the menu’s code, although it wasn’t architected correctly it didn’t matter that non of the code was eventually used, it acted as a starting point which then lead to menus making that release.

Alex wanted to talk about how larger changes could be “pre-approved” so that we avoid large patches that are then left to rot.

Nacin felt that large features are a special case that don’t / can’t follow the standard processes, they really require the personal touch, chatting over a beer or pick up the phone.

People wanted to know how to get involved at the roadmap level.

The underlying issue seemed to be about the fact that core contribution is a 24/7 lifestyle which doesn’t always match with the time that an agencies developers have.

Another issue that was raised was the pushback against new features, when a core dev says “thats not going to make it in” does that mean never? Nacin recommended releasing the feature as a plugin. Nacin went on to explain the process that goes on when planning new releases. The perfect time to pitch new features is between releases, before the scoping sessions for the next release, core developers will go back and look at features that didn’t make the last release.

Jake asked about planning a cycle ahead so that agencies could assign a developer or a set of developers could work on. Nacin suggested a lot of things that could be worked on for 3.6. Can we have a roadmap of future tasks. Nacin said that trac has got too large which prevents a lot of changes that would help these issues.

Another important thing to remember is that you can give back in other ways that just code, there are a lot of administrative tasks that need doing, agencies could help create that roadmap.

One great option that should work for agencies is to run trunk and test patches against your client sites. Unit testing is another area that agencies could make a big difference, it is good for developers to learn how to write unit tests. If someone only has 3 hours per week to contribute they can still help with admin on trac or write a unit test for a specific patch. Remember that having developers working on core benefits the agency because it is on the job training.

Jake asked Helen whether the other people in the company that have contributed to 3.5 would have contributed if Helen hadn’t have been there. Helen felt that there wouldn’t have been as much contribution. Jake wondered if the fact that Helen is on the team meant that more of 10ups contributions got into core (contributions from other developers), she felt not as a lot of her stuff ends up sitting round not getting in as well.

Could we have an ombudsmen from the core team that could reach out to agencies with sanctioned features that need working on.

Nacins final point was that the number of new tickets per day was increasing at an unmanageable rate, he said we can help by testing patches and triaging tickets. He would like to see teams per component that can be in charge of triaging. Those component owners are then often given commit access for that release.

Nacin wants to build a list of future features that people could start working on, a list of easy fixes / low hanging fruit and component owners.

WP Tuts can help by posting about upcoming releases and beta’s which raises awareness and increase the number of people testing that beta.

Nacin wanted to re-enforce that we can all contact him at any time to ask about how we can help.

Our action item is to create a mailing list for companies to discuss how they can help make each other aware of things they are working on, patches that need testing.

The Future of the Customizer

Theme Foundry currently using theme options used with back compat. Eventually, they’ll go exclusively customizer.

Changing the look and feel of the customizer.

Implementing controls can be challenging. Clicking through in the preview can be a challenge (which is generally refreshing bugs in custom code, not core code).

Customizer as a website creation wizard.

How do you get someone to fire up their website and make just enough changes so that they’re married to it?

Make this website yours.

The customizer as an onboarding tool for core.

  • Can we add the customizer to the install process?
  • Would doing so help user retention?
  • The customizer is about quick wins, and quick wins are especially important for new users.

The customizer interacting with the theme repository.

Let’s make it possible to browse and install themes in the customizer.

What else can we customize?

  • Post previews
  • Widgets
  • Menus

The customizer is more powerful when you control the presentation layer.

  • Post layout
  • In-preview UI

How far will WordPress core go in terms of adopting the customizer?

Other Ideas

  • User test adding a customize link to the Appearance menu.
  • Provide “starting points” for developers.
  • Offer examples and default templates for customizer controls.
  • Consider potential higher level abstractions for themers.

How can the customizer be used to improve and influence the settings API?

Action Items

For core:

Roadmap for allowing the customizer to support multiple instances, which allows it to be used in any use case, instead of just theme switching.

For theme review team:

  • Recommend customizer usage in the theme review guidelines.
  • Work on best practices for theme developers.
  • Documentation and create examples.

Improving the JavaScript Proficiency of WordPress Developers

In attendance: koopersmith, Chris Hobertsen(?), getsource, George Stephanis, duck_, Kailey, lessbloat, Andy Peatling, Dougal, azaozz, Kurt Payne, Matt, Amy Hendrix, Tenpura, Koke, mdawaffe.

JavaScript in WordPress – Woo!

Koop has found that most WP/PHP devs are not comfortable with JS. What are the causes?

  • History as a language.
  • Grabbing what works.
  • Browser incompatibility.
  • Programmers with strong belief in good/clean code now have a bad opinion of JS.

All WP devs should feel comfortable with JS: reading certainly, writing too. This includes familiarity with JS libraries we use: jQuery, Backbone.

Other sources of confusion:

  • Prototypal inheritance
  • event based
  • functional programming.

How to teach: make developers use it. WP is including more and more JS APIs that devs will need to get comfortable with.

It would be helpful if everything in WP is consistent. There are many different ways of writing JS in WP.

Koop said that there is a one true way and we’re working on standardizing that and getting all the old stuff cleaner. He suggested a style guide for the contributor handbook.

Shredder noted that the JS in cored didn’t fit the original PHP style.

Matt asked who has contributed a JS patch to WP? ~90% of the table. He said that it’s important that the JS stuff is as inclusive as our PHP code.

How about Backbone: ~15% of the table.

Underscore: ~20%.

Backbone is the future of MVWTF in WP.

Matt said that we adopted jQuery as it makes JS easier for us PHP devs. Backbone hasn’t made anything easier for us WP devs since WP isn’t MVC based anywhere else.

Koop said that WordPress sort of is MVC based, we just don’t notice. Posts are not tied to themes. Our JS should be similar.

Ruby/Python: 35%

Underscore adds more functional methods to JS. Filter, first, iteration, mapping, flatten, event throttle, event debounce + simple templating. Good utility library: well documented. ~800 lines.

Backbone is built on top of Underscore. There are conventions that keep your APIs consistent. ~800 lines. Event handling. Models: Key Value + Listeners (change:key_name). Simple means of interacting with REST API (not used much by WP since we have no REST API).

Collections: Ordered list of Models. filter, first, etc. Events for adding/removing/changed models. “Tell me any time any model changes it’s X”.

View: Convention: Root element (specific element, tag/classname so that it will build for you), render method that does nothing by default. You are responsible for writing to fill up your root element with stuff. Root element’s parents, DOM irrelevant. Just build it, listen to events, whatever: don’t care where it is: ensures your logic is compartmentalized and specific to your task at hand.

Lessbloat: What’s a simple example?

Duck: The API documentation isn’t good enough. We need this explanation of Koop’s for everyone.

Peatling: I know a good tutorial:

Matt: When we build an interface with Backbone, how do we make it accessible and degrade down to HTML?

Koop: Same principles: make sure tab indices make sense, etc. Many platforms require you to “pollute” your HTML with custom attributes etc. Beauty of backbone is that it’s minimal and doesn’t invade your HTML. You control the render(), you pick your tempting engine, etc. A designer can do CSS without having to know backbone. Not that much magic going on.

In terms of degrading to no-JS experience, you can cross compile templates in both JS and PHP. WordPress doesn’t do that much, largely because where we currently use it is JS only anyway: TinyMCE, Customizer, etc.

We shouldn’t be using Backbone for everything, but it’s a good tool.

But for media, for example, if we didn’t use backbone, we’d have ended up writing backbone anyway. Backbone’s knocked out the edge cases, has documentation, has community. Using it has sped up WordPress development. We just need to get people used to it and get more people contributing.

Lessbloat: Take media as an example. Is there one small piece of it I can look at to teach myself what’s going on?

Duck/Koop: Models are the best fleshed out. Attachment Model is a good one to check out.

Old Bad way: AJAX returns HTML for attachment. Have to parse that, regex, string compare for errors, never stored anywhere convenient client-side, …

New Good way: AJAX/Deferred returns JSON. Putting that in a Backbone model makes it easy to keep track of everything. Change the model in one place, easy to update all the dependent views.

There exists a WP PHP code style. Is there a styleguide for JS? (Koop: Yes – working on getting it in the handbook).

What about JavaScript Unit Tests?

Koop: I would love it. I suggest QUnit: good for browser unit testing, easy to implement/use.

Our build process is very simple. Just minifies. It’d be cool if we had something more sophisticated: grunt (Ben Alman). Integrates with test suites. Koop talked to Ben at the jQuery summit about blockers for using grunt in WP. Will be resolved in the next release. Also wants to show how plugin/themes can use grunt too.

Old school devs: don’t want to touch JS.

Koop: Agreed. We want to expose people to these new tools and show them WordPress is doing exciting things.

Matt: We have this exciting thing, but only 3 people are doing anything with it – that’s the problem.

LESS/SASS precompiling? Maybe. There is a barrier to entry. We already have a perception that JS is either ugly or hard 🙂

Koop: The problem may not be JS, but that where we’re using JS right now is this big new thing: Media. How many people would be comfortable building that from the ground up? Maybe iterations, when it’s already built, will encourage more involvement from more community members.

We’ve tried to write really good inline docs, good commit messages, etc. so that people can pick things up more easily.

Koop wants to take a pass through all WP JS and document them inline.

Koop showed us Docco for JS. Matt said that we should have that for PHP too. Easy to see what code isn’t documented: too much whitespace!

Kurt suggested a make/js blog?

Koop has thought about it.

Matt: Why not just post to core? Don’t separate.

They agreed to use a JavaScript tag?

Shredder: What about mentorship? That was super helpful for me when I started in WP. Can we pair less/more experiences JS folks up?

Koop would love to mentor interested people to bring them up to speed.

Matt: Yes. Expand our workforce: it’d be nice to get more than one JavaScript heavy feature per release.

Kurt: We don’t have a real QA system. Is that the bottleneck with JS features?

We’ve never had QA for anything – probably not the issue.

Koop: we do need more tests. Headless browser, etc. Use the tools that already exist rather that building our own system. Higher learning curve, but faster in the medium/long term.

Action Item

Post to “javascript” tag in make/core.

Other Ideas:

  • Links to resources
  • JS Styleguide in handbook and Codex
  • Best practices on passing data back and forth between PHP and JS.

WordPress Global Communities


Andrea Middleton, Takayuki, Remkus, Katia, Eric Mann, Viper, Ze, Xavier, Scribu, JJJ, mitcho (notetaker), Jorge Bernal, Scott, Tenpura

Discussion Notes

The first suggestion for visibility of WordPress as a global solution was to create something like, which doesn’t exist right now. Its objectives would be to present how WordPress exists around the world, where the latest localized versions are available and who is involved in which language.

The user profile issue was raised and explained where we’re at by JJJ: it’s originally a project of Automattic, uses BuddyPress and the profile page information is pulled in by feeds. He also mentioned that it’s slow and prone to crashes.

The idea is that all activity, including posts in international forums, translation work and event organizing should go into the profiles.

Zé noted that we are on hold as far as new international forums are concerned until we can figure out how to integrate bbPress (plugin) into the Rosetta sites.

The problem isn’t just one of profiles, however.

There is often the need for a visitor, beginner or not, to be able to look at one of these regions/countries where multiple languages exist, and see what the status is and what the community is like. Right now, if you want to know who’s the Russian person in charge, you have no idea.

Also, translators sometimes feel left out of some decision-making in core, despite being often (if not always) the first contact in local communities. According to Xavier, one of the issues is that many documents (such as WordCamp guidelines, handbooks and so on) are in English.

Translations need to be recognized as equally valuable contributions to core. Some formal liaison maybe necessary; in fact some language communities already have unofficial leaders and liaisons with core or even Andrea. One question was raised if one problem might be that there needs to be an “owner” of a language/local community? Some places have that, others don’t.

Following that, the suggestion was made to have group profiles by region. Zé mentioned that it might not be feasible, as the relationship between languages and countries is not one-to-one, nor is it one-to-many, but rather many-to-many. It would be better to have profiles searchable by region and language.

This all could be helped by having a place for communities to live inside of, as opposed to or other solutions. JJJ mentioned that BuddyPress could be used for this.

Rosetta sites: Even though (in English) is now sexier, and the roadmap seems to say that it’ll be even more so, Rosetta sites are three years behind. Cátia made it clear that it is very important to give more freedom to Rosetta administrators; it can be frustrating to not be able to do what you want.

As the discussion veered towards languages, Zé reminded that communities can be different things and most of the time are actually a mix of countries speaking the same language, different languages spoken in the same country and so on. This is not clear to visitors right now. As an example, the ISO code for Georgian inside Georgia (the country), is not the same as the code for Georgian spoken outside the country. This could mean two language communities and one country community ir any combination of those.

Historically, however there seem to be not many formal connections between various communities in different varieties of the same language, e.g. Portuguese from Portugal and Portuguese from Brazil.

Finally, many of the community sites are not on the infrastructure. They may even look like they are, but their domain is mapped. However, to be able release a language pack (and core upgrades), they need to be on (Rosetta).

Forums (or maybe even a P2?) for language/translations, per locale, would be a good place to have discussions for that community. Also, those contributions could feed into a user’s profile. Xavier warned that many communities have totally different sites, and this content archive is important.

Cátia asked the question about the Foundation and transparency and representing WordPress inside a community; what should a community leader do if people don’t follow guidelines? Are there “semi-official” capacities in different places? There seem to be none. Andrea said that right now, in core, we have a team rep system, which is transparent, but none of these people then represent the foundation. A community leader/rep’s importance is determined by the time he puts in, and the better he becomes at his tasks, i.e. “if you’re here (at the summit), it’s because you are perceived as a leader”.What about a team rep system around communities or languages?

Zé suggested there should be a global/international P2/make/forum site, written in English, but global. A place where polyglots can voice their opinions on the global reach of WordPress and how to make it more visible. The Polyglots P2 is not the place to do that as it is where Nacin and Zé deal with technical issues and fix various stuff.

The kinds of questions discussed there should be, for instance:

  • How do we make reps in a region legitimate?
  • Viper: What happens if a community ends up creating a fork? A different looking site?
  • How do we reach out to those communities and make them more legitimate?
  • How do we make reps in a region legitimate?
  • Should we implement voting per language community like for the other team reps? (Cátia and Remkus noted that voting might be different for other cultures)

The general consensus:

  • Having profiles and a make/global site is a good start
  • The other stuff is more about the particular community itself
  • Communities need to be made visible and open
  • Transparency is important
  • “This is how I got to be Nacin” would be very helpful for local communities/international contributors


  • There were lots of discussions of where international conversations occur, about transparency, and on how to get involved.
  • Profile integration and a make/global, or similar, were seen as a good start
  • There should be more discussions about community structure and legitimacy

Action Items

  • Create
  • In the long-term: beef up profiles to show who is active in language communities and region communities

(if people want to talk about technical stuff, they should talk to @JJJ)


In Attendance:

  • Aaron Jorbin
  • Emil Uzelac
  • Kevinjohn
  • Amy Hendrix
  • Michael Fields
  • Dave Martin
  • Jake Goldman
  • Isaac Keyet
  • George Stephanis (note taker)

Discussion Notes

Kevinjohn brought up the initial concern that, in the EU, some groups can’t use WordPress, as it hasn’t met some accessibility requirements for a few releases now — but we’re close.  Have to meet AAA standards for EU.

How’s the back-end for accessibility? Jorbin brought up that he, Nacin, and Koop sat down with a blind user and did accessibility testing of post screen — everything was properly set up except for the post box itself.

(aside: question of if we should / how we could make it easier for front-end users to be accessible is nipped in the bud for later discussion)

Amy Hendrix brought up the question of new accessibility tests for themes — which is a work in Progress

What is the accessibility group?

Aaron Jorbin pointed out that we should get accessibility experts more involved in WordPress. By bringing the accessibility community into the WordPress community, we all benefit.

One of the challenges is that it is hard for much of the core team to test accessibility patches do to them not having copies of accessible technology software. A good deal of the software is commercial (or only runs on one operating system) and few people have copies to test patches against.

(aside: someone pointed out that it would be nice to automate patch applying by generating trunk installs on the fly and applying patches to them, to enable less-technically-minded people to contribute to testing.  Perhaps on or similar?)

We need to migrate from being reactionary to proactive!  While there are a couple patches for 3.5, we may need a set of guidelines for a11y standards, the same way that we have php and css guidelines.

It would be very useful to add a high-contrast theme for the admin UI.

We also need to emphasize the reasons to focus on accessibility — better SEO results and marketing, for one. The W3C has an article on the web accessibility business case.

(aside: could we possibly include an API for toggling high contrast mode on or off?)

It would be nice if TwentyThirteen was designed accessible as a number one priority, but how do we get there? We need someone to take responsibility.

Isaac Keyet mentions that mobile apps are mostly compliant, but it’s more dependent on the platform that you’re on.

Drupal contacted the governments and asked what they needed to do to become fully compliant. We need to get data / feedback that lists what we have already, and what we need to be properly up to spec.

Standards — which ones should we focus on? There are multiple options.

Checklists to compare patches against would be really helpful! Accessibility is much more than that, but it’s a tool that could help devs not as familiar with Accessibility. Not a solution.

Should we add a `not-accessible` or `needs-accessibility` tag in trac? These could make it easier and puts accessibility on the same level as UI or UX. It’s not a feature, it’s a core asset.

We need more accessibility talks at WordCamps … bring accessibility into the popular mindset.


  • Add a section to the Handbook.
  • Add in some requirements for patches that they be tested against accessibility guidelines.
  • Need someone to take ownership for things going forward.
  • Page on .org talking about what certifications we meet.
  • Challenge TwentyThirteen to be designed with accessibility as it’s number one Priority.

Action Item:

We want to add which will be a one stop shop for successes we’re having and ways people can get involved. This is partially inspired by The Drupal Accessibility Page.

#a11y, #accessibility, #eu, #standards

Education and Training Discussion

Note: These discussion notes are from the team reps summit the weekend before WPCS.

Have made a lot of headway with Core Handbook, internal training documentation. Codex mixes dev and user materials – needs work.

Where do we put these materials? Anybody can write to the Codex; issues like voice consistency, information accuracy. Support Handbook in progress: Someday it will be Learn WordPress (learn.wordpress).

Next steps: get it right. Get videos. Get screenshots. Get more bodies. Move from overviews to specific items/features.

Core Handbook idea: interview people who committed/contributed their first patch and review what they did or didn’t know or needed to know based on information in the handbook. To discuss more: onboarding core contributors.

Better documentation

What’s changed in a cycle. Development/code comments → commit message → new developer API announcement/tutorial → to-user announcements → support documentation → tutorials. Better changelog tracking – plain (user-facing) English!

Official API documentation site. Special doc style for actions/filters (needs loooots of bodies to write code docs). Developer portal.

Huge part of education is the transition from being a user to getting into development.

Better incorporate high quality content from Virtual “WordCamp Ignite” – flash talks.

Beyond Documentation

New user workshops. New developer workshops. Workshops! We’re not bad with 101 (new and non-technical users) and 401 (established developers), but not so much with 201 (power users) or 301 (beginning developers). Workshops would help, perhaps “pre-packed” materials that can be shipped out for use.

Courseware plugin (Stas) as training support on .org is a long-waiting idea. What would curriculum/syllabus be? Who would teach it and where? Libraries, meetups, etc. Example teachers/classes: Austin meetup, Lorelle, Boone. Would need a person to collect/collate/review exemplar syllabi, etc.

Quizzes – how well do you know WordPress? Don’t want to go down the path of certifications, but self-testing, maybe as auxiliary helpful material for vetting Happiness Bar volunteers and WordCamp speakers.


More standardized “Happiness Bar” (in-person at-event help). What are issues – naming (confusion about what it is), nobody goes, misinformation being given as help. Volunteers should be scheduled on skill/specialty + time – a volunteer per area per time. How do you point a user, who might know where their problem lies, to the best fit for help?

Ask speakers to volunteer at the Happiness Bar (opt-out, of course). “I’m interested” on your .org profile – WordCamp speaking, helping at a Happiness Bar, etc. Exit survey for Happiness Bar users.

Hack Days should include more than core or code contribution – also documentation and support, especially for tasks that really need bodies. How about a Happiness Day / WordPress Study Hall?

Action items

  • Learn WordPress: Call for curricula and volunteers to review curricula.
  • Move materials over from handbooks (“final resting place” –Mika). Need to find Learn.WP structure idea that already exists somewhere, or do it again.
  • Exit survey for Happiness Bar users.
  • A better default name for the Happiness Bar.