List of topics proposed by teams

As said in the previous post, the following list of topics which need in-person discussions is not definitive as we’ll loop back in the next couple of months. Here’s the current list of topics proposed by teams:


  • How can we increase Javascript contributions to Core (especially related to utilization of the REST API)? – (REST API)
  • What should be Core’s technology support policy (especially related to deprecating support)?
  • How can we better project manage contributors efforts in Core?
  • How can we improve the on-boarding experience for new contributors?
  • How can we improve the Security process from report through triage through disclosure? – (Security)


  • Onboarding: How do we recruit and attract new designers to WordPress?
  • Retention: How do we retain new designers?
  • Process: How do we communicate a unified design process to contributors?
  • Collaboration: How do we work with other WordPress teams to supply design assistance? – (All)
  • Impact: How can WordPress impact the greater design community?


  • WP API & the mobile apps
  • Possibly the new core block editor experience and how it can work with the upcoming Aztec native iOS & Android editors – (Core)


  • New developments for the the Editor, and how to safeguard it’s accessibility – (Core)
  • Technology version support policies – (Core)
  • How to involve more developers in helping with the accessibility tickets
  • How to proceed with the handbook


  • Increase outreach (Rosetta sites outreach, jump starting and upgrading our locale sites to best fit the community) – (Community)
  • Local contributor days – (Community)
  • Global contributor days (translation days)” – (Community)
  • Improvement of translation and communication tools 2.0 (we’ve already got the first phase of this going with the O2s, GlotPress improvements, etc) – (Meta)
  • Cross locale PTEs implementation discussions – (Meta)
  • Translating documentation (already mentioned above)” – (Meta)
  • New General Translation Editors onboarding/ Mentorship program and new translation contributors onboarding plan
  • Polyglots Leadership team growth plan in underrepresented regions


  • Continue 2015’s discussion about how to make/keep the support community welcoming and open, while at the same time encouraging quality replies
  • Go through the remaining items on the lists of known issues and requested enhancements – (Meta)
  • Create a common style guide (best practices) that can be used across all forum language
  • Improved management of contributors with time to spare


  • How we improve the leadership of the TRT team?
  • How can we encourage and enable more people to lead new projects?
  • What is the vision and goals of the team?
  • What is the future of the theme review team, can we change it to become the Theme Team and be more involved in theme related activities like improving the theme directory or the theme developers handbook? – (Meta, Docs)
  • Future of the theme review theme and making it smoother and faster
  • How we can encourage creative designs and how to stop more of copy themes which can just be child theme


  • Game Plan for recruitment
  • Onboarding Plan
  • State of Doc Team’s own documentation
  • DevHub and Helphub Translation
  • Clear way of contributing to specific parts of documentation
  • Helping other teams with their documentation – (All)


  • Global involvement
  • WordCamps & Money
  • Marketing & Engagement – (Marketing)
  • Paying for speaker travel
  • Regional camps
  • Improving deputy training
  • CoC and harrassment reports
  • Supporting other event types


  • Tools plugin devs need to manage their plugin – (Meta)
  • Tools plugin devs need to manage reviews and support (crossover with forums) – (Meta, Support)
  • How to effectively handle contributor days
  • Dependencies and libraries – can we save WP from DLL Hell? (crossover with core team) – (Core)
  • Safely and responsibly improving communication of closed plugins (crossover with the meta and security team) – (Meta, Security)


  • None


  • Translation of documentation on, including developer hub and (the future) help hub – (Polyglots, Docs, Support)
  • Participate in other team’s discussions to see how the Meta team can help them


  • None

Flow / Test

  • None


  • WP-CLI Package Index / future of WP-CLI packages and new feature development
  • Improving the contributor workflow, and increasing the contributor pipeline
  • Generally, how to bring the WP-CLI experience closer to people


  • None


  • How can the Core Security Team work better with hosts? During the 4.7.2 release, our interactions with hosts were drastically expanded, but I would love to continue to pave a path between core security and hosts – (Security)

#teams, #topics

WordPress Community Summit 2017 announcement

The 2017 WordPress Community Summit (CS) will take place on Tuesday-Wednesday, 13-14 June, before WordCamp Europe in Paris, France and it’s a by-invitation conference.

The main purpose of the summit is to move the project forward before and after the event, with the event being a milestone in a larger set of work.

With this main goal in mind, we’ll touch base with all team reps  to figure out which of the topics proposed can be handled beforehand, and come up with topics that would be:
1) of importance to the project as a whole
2) would benefit from cross-team collaboration
3) will leave us in a better position than when we started

In order to get this goal, we’re asking all teams to figure out which topics really need an in-person planning day, and then start working on as many of these remaining topics as possible online and before the event. This way, we’ll be able to loop back in May to see if there are any obstacles for these goals to be achieved by your team and to identify better which cross-team collaboration is needed, anything we can do to help move things along!

So who is invited?

Based on the topics proposed, the nominations posted by all team reps, and those topic applications received through the sign-up request form, a committee of experienced team leads have reviewed the total list of nominations. This committee voted, taking into consideration involvement with the WordPress project, relevance and representation of different points of view for the topics listed, diversity, company for having a wide number represented, location for representing different origins with active communities.

The selected participants will receive an email or Slack message from their team reps or me during the next week (by March 29th at the most) with more details and with a RSVP link to confirm their attendance. The final list of attendees will be posted in this p2 blog as soon as we receive all RSVP.

List of volunteers to help with the organization of the event

The following contributors will be contacted via WP Slack at the end of next week to join the current organizing team to get the tasks done for the event – thanks for your help!

*Note: It’s been a very hard task winnowing the nomination lists, but the capacity and the nature of this event is to be as small as possible for the level of interaction needed. All teams will post the notes of their discussions at the end of the Community Summit in this blog and on June 15th (next day), all contributors will have a working day during the WordCamp Europe Contributor Day, so don’t hesitate to sign-up to it and to make WordPress better all together.

Call for Community Summit Travel Assistance Sponsorship

As the name suggests the Community Summit only works because of the participation of our amazing community members. But not everyone in our community has the financial support of their employer or the money to pay their own way. Without them we’d be losing out on input from people who are necessary to the conversations we will have at our upcoming event.

With that in mind we are opening a call for 2017 Community Summit sponsors to ensure that we meet our goal of Community inclusion. Most event costs for the 2017 WordPress Community Summit (venue and catering) are being paid by WordCamp Europe 2017 (Thank you WordCamp Europe!!). This allows us to focus our fundraising goals on supporting the Summit’s much needed travel assistance program, allowing us to subsidize travel for volunteer WordPress contributors from around the world who would not otherwise be able to attend.

If you’d like to sponsor the 2017 WordPress Community Summit, check out the Call for Sponsors and sign up. We will be more than happy to get back to you with all details.

Thanks for supporting the WordPress Open Source Project!

Travel Assistance Program

As the name suggests the Community Summit only works because of the participation of our amazing community members. But not everyone in our community has the financial support of their employer or the money to pay their own way. Without them we’d be losing out on input from people who are necessary to the conversations we will have at our upcoming event.

With that in mind we are happy to announce a travel assistance program for the 2017 WordPress Community Summit, which will take place on Tuesday-Wednesday, 13-14 June, before WordCamp Europe in Paris, France. Travel assistance will make it possible for more WordPress contributors to attend this event. This assistance may cover all or part of travel and/or lodging, based on need.

There are no specific requirements to apply for travel assistance — we won’t ask to see your tax returns — but we do have some goals in mind as we introduce the program.

Important note: Before you apply, please determine if you fall within one of the following categories.

  • Contributors selected based on the list recommended by the team reps:
  • Non-active contributors that applied over Sign-Up form and finally selected by the Community Summit organizing team.

Our travel assistance team will be looking for applicants passionate about WordPress who would not be able to attend the event without financial assistance.

Please indicate in the application the level of financial assistance you need, keeping in mind that we strive to accommodate the maximum number of applicants that our budget will allow. In other words, please only apply if you really can’t afford the trip and your company will not pay for you to attend and ask only for the amount you need to fund your attendance.

Application deadline is April 14th, 2017

Things to consider before applying:

  • Please evaluate if you will really be able to attend the event.
    If you decide you can’t attend after receiving a travel assistance award (travel/hotel), you will not be eligible for a WordPress event assistance in the future. We understand that situations may come up last minute, but please be considerate of other applicants and consider family and job obligations before applying.
  • It is your responsibility to research the visa requirements for your country.
    Please research obtaining a visa for your country prior to submitting your application and let us know the anticipated wait time to hear back about a visa. The WordPress Foundation can provide an Invitation Letter if necessary, whether you are applying for a travel assistance or not.
  • You must have a current passport with an expiration date no earlier than 3 months after the conference to apply.
Apply here for the travel assistance program and if you’ve been selected, we’ll be back to you before April 24th.

#assistance, #program, #summit, #travel

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.

Update on March 7, 2017: This survey is now closed.

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 150 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
Cli: @danielbachhuber

#2017, #summit-2017

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.