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: http://bit.ly/zT9WyG

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 global.wordpress.org, 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 wordpress.org 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 WordPress.org, as opposed to meetup.com or other solutions. JJJ mentioned that BuddyPress could be used for this.

Rosetta sites: Even though WordPress.org (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 WordPress.org 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 xx.wordpress.org (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 make.wordpress.org/global
  • 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? https://make.wordpress.org/accessibility/

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 wpusertesting.com 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 WordPress.org/accessibility 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: https://make.wordpress.org/support/handbook/. 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 WordPress.tv. 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.

Growth and Marketing

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

WordPress is successful because it’s seen as friendlier than competitors. Homepage is old, but still better than Joomla, PHPNuke, etc in how we talk about ourselves. It’s more challenging than ever, though, because saying wp can do anything is not super compelling — people don’t relate to it. Specific uses — I want a site for my bakery, for my book club — are better. How do we reach constituencies, how do we keep our percentages up, how do we market to developers and overcome the perception there that wp is lame, and evangelize to people who would work in app platforms. What would help?

WordPress.org needs a facelift. Not just design, but content like /about. Old features (post revisions) are listed instead of cool stuff that is newer. Marketing the features is a good step.

Let’s have each area of wp (via contributor groups) give a synopsis to promote their section. Rep will say what is awesome about their app/section/teams, and we’ll compile them all to make a new about/features page.

The Showcase is kind of tired. It should answer the question of what wp can do. Entries should become case studies. Who worked on this site, what plugins and themes are used, is there anything special about it, interviews with stakeholders on the experience of making this site with WordPress, etc.

Let’s put videos of people using wp on home page. Show them customizing a theme, writing a post. Make the video a hero, and cycle through different videos so they are short and consumable. But before we decide how to do it, we need to decide what we are about.

What makes developers gravitate to other platforms?  We need to answer that question up front and use content to convince them to use wp.

When wordpress.com put more features on the home page, fewer people signed up. Many use it because someone told them to. Anything that slows down their getting set up is a risk.

A lot of people/devs initially hear from someone else what to use. Having a page that compares the systems would be cool. We’d need to keep up with other projects to keep info current. Let’s have an email address for if info on that page is out of date.

Our tone is playful and irreverent; we don’t pretend the rest of the world exists (a la apple/slate). We even thank Movable Type and Drupal on the about page for inspiration.

Which issues do we need to convice devs on, vs which things do end-users care about? We need separate convincing paces, not overwhelming info on one. Two home pages/landing pages, a developer portal.

Jekyll has been taking off. jQuery uses wp for everything, but if they hadn’t always used us, they would likely be on github pages on jekyll. Making wp sexy enough for devs to use is important. Caching — not great on wp, but good on jekyll. Devs need scaling info.

We focus on ease of use and SEO for users. Focus on security, deployment/staging, APIs, etc for devs. We should promote examples of cool devs/projects using wp (like jquery, nasa, math blogs).

What about how to market to non-traditional blog users? Corporate, etc.

Hello world is the first post. Make the default view clearer that it’s not just a blog. They may not know where to go next to make stuff in their site. New user panel is going toward that (that’s a breakout discussion). Important to make sure the support materials don’t lose the threads started in the marketing. Make priorities clear. Jetpack is an attempt at unified marketing, user experience, and support.

We should also make sure people are in the right place. “I just want to get started” — Direct them to the right host.

When they’re on .org, we convince them to look into something, but then they have to pick a host. What if we could do the install while right on .org, create hosting account, site title, etc. The nice part about passing off early is that user associates early with the third party, but we can ameliorate that with language and branding within the ux flow. We could improve the conceptualization of .com/.org/host/etc. We could email them — communications could change to tell them the host vs .org usernames etc. Whatever we do, should be careful not to confuse .com/.org more than it already is.

We’ve talked before about using .org as a dashboard. We could theoretically check the login against their site.

Let’s get back to marketing and come back to NUX as breakout. Use best practices based on .com that hosts should follow.

Events. Booth at bridal conference, comic-con, auto shows, outreach at non-tech events. More wp illuminati speaking at dev conferences (not WCs). Need to get Events on .org site instead of on separate domains.

In addition to WCs and meetups, educational events, local wp training.

A friendly face can overcome a lot of difficulties and make up for anything confusing at in-person events.

How do we tap into local groups to evangelize?

Something to remember (as we talk about guidelines for official meetups and WCs) is  that people with less desirable practices/intents are still getting people on WordPress. Look at Thesis.

Re WCs, some people still think ,”Isn’t it kind of cheap?” so it’s not taken as seriously.

How can we make WCs more unified? What’re the important common threads to ensure?

We should start doing video testimonials/commercials. WP “rockstars,” celebs who love WP, average people.

Where do we go after the home page? Where are people going on the site? Top pages on .org  are: home, themes, download, plugins, support, codex for installing wp.

Should there be marketing for mobile apps? Yes. Let’s get them on the Download page at least.

Action item: Each team comes up with one great thing about wp that is a marketing blurb. One sentence per team, to be used in new features page.

What the Meetup?

Attendees: Aaron Jorbin – Notes, Sara Cannon – Leader, Erica Varlese, Lisa Sabin Wilson, Ryan Duff, Ryan Imal, Brandon Dove, Dre Armeda, Michael Torbert, Jane Wells, Andrea Middleton, Remkus

Brief Chat about the different Meetup Groups Present:

Sara Cannon – WordPress Birmingham Meetup, WordCamp Birmingham
Although the WordCamp is large, the meetup group is tiny. 12 regular ~30 – over 300 for WordCamp (destination conference in the south: people travel) Wants to learn how to expand and have good programming

Brandon Dove – WordCamp Orange County, OC WP Meetup
Active contributor – virtual and in person meetup – 2 meetups a month (1 dev, 1 user) – active members 150 – regularly 40-50 people. Their events are live streamed, have different people and interests, and is free, not run through the Foundation / Meetup.com. They use a private Facebook group (must be accepted and verified) and have found that people are more active in conversation on Facebook is better then in person. Anyone that asks gets answers quickly. In Brazil – private Facebook is more active for support than forums.

Ryan Duff – Harrisburg PA Meetup
The area has a lot of back and forth & can’t get any traction. There is one meetup group in the area that does well becouse it moves it around. The area that the airport serves is 6-8 cities each with their own identity. People won’t get in the car and go far if there is weather – he sometimes has problems getting anyone to come. He knows there are WordPress users in the area: but might only get 5 maybes: people can’t commit. He uses meetup.com – but believes geography is the biggest challenge & persistance is the problem.

Aaron Jorbin – One of the organizers of the DC meetup.
DC has about 1,100 members who meet once a month with between 70 and 100 people at all meetups. Occasionally they partner with the PHP group. They made the decision to be a user group, so keeps it pretty user-centric. If it’s something that’s more dev-centric they partner with the PHP group rather than fill their meetups with it. There is not yet a WordCamp, but they do host an annual open source barbecue.

Ryan Imel – Fort Wayne Meetup
Fort Wayne is similar to Birmingham – 10 to 15 people that regularly come – He’s been working on getting more organizers and that has been great for the group.

Lisa Sabin Wilson – Milwaukee Meetup, former 2x WC Chicago organizer
They host about 25 to 30 people. Milwaukee used to be a very Drupal city, but now it is getting more diverse – tehy have 4-5 organizers and around ~100 people at the WordCamp. WordPress is getting bigger and bigger each year.

Erica Varlese – NYC – not an organizer but interested in helping more.
NYC has diverse topics and is large and can be overwhelming. When they had the large WordCamp in 2009 – it was big and helped really grow the community.

Michael Torbert, Raleigh Meetup & WC Organizer
They use Meetup.com. They have 600 in the online meetup group roster: but 1/2 never have been.  Between 30 to 40 people will attend each meetup. When Jane was there it was very popular and they had to turn people away because the venue was too small. They usually have 2 meetups a month. One is classroom “teaching” oriented and the other is at the semper fi lounge and is networking oriented.

Dre Armeda – WordCamp San Diego
He is starting a group in Riverside since he moved inland – So Cal is popular and there are many meetup groups going on there.

Andrea Middleton – Portland
She doesn’t lead the meetup, but helps with organizing WordCamp – not very active in meetup (time/day of meetups).

Jane Wells – Tybee Island, these are her people
Before coming to Tybee: She was in NYC  and before that in SF – She organized WordCamp Savannah. There was no Savannah meetup group. She talked to group about hosting it, and then after a year just said screw it and started one Meetup.com and got 15, then 30, then 45. At the same time she started a  meetup group on Tybee, with about the same number of people at each. The first one had 12 people show up (tybee), 8 or 9 (Savannah). The first meetup was about what the meetup should be: they decided to have multiple types of meetups: 1 night, no presentations, just coworking. They wanted to grow the people doing stuff and not just be people showing up to learn. They also have one at lunch time and demo what they are doing or watch a wordpress.tv video and then talk about it. The WordCamp really inspired people in Savannah, that is how most people learned about WordPress.


  • Meetup.com helps with publicity and drawing a larger untapped audience in some areas
  • Sandwich boards outside helped bring people in.
  • Putting up signs just helped bring people in.
  • Outside the US/Canada primarily doesn’t use meetup.com, they use FaceBook.
  • Centralizing the events will help know what else is going on.

We have a resource for WordCamps, we don’t have resources for meetups. Want to bring more stuff over to WordPress.org and make it more visible. Surface Meetups on WordPress.org so if we know your zip code, we can show on the page when the next meetup in your area is.

One challenge of being a very successful meetup is the need to divide things up. If there are 800 people, you are basically cattle moving between rooms. 300 is the highest comfortable size for a WC. Multiple WordCamps in a year.

Challenge: What are we going to talk about at the meetup? What kind of programming do we need to have? One answer is to Skype in a group to talk about the things that you don’t know. Have a pre-recorded presentation and a google hangout.

In one meetup, when it started there were 3 presenters — they were the experts. All of the attendees are presenting regularly: but some are not as experienced as others, so sometimes there are issues with consistency of quality. Challenge: Getting locals over the fear of public speaking, upping the quality of presentations.

There should be a good ratio of local and non-local speakers. If someone is not an expert, but they have the time to give the presentation, w can get them in touch with people who have given similar presentations for help.

Challenge: Some leaders are not well versed in teaching new, new, new people how to use WordPress. Are there resources or ways to teach that? We need to share curriculum. Or have a “WordSchool” focused on teaching new people. Or just suggestions for WordPress news to share each month: A sales flyer.

Challenge: Not everyone pays attention to trac, so we need to educate our groups on core development. Meetups gives people an avenue to talking about new core features.

Two great Meetup Ideas from DC: 1) “My favorite plugin” lightening talk. 2) Upgrade-a-thon!

ACTION ITEM: make.wordpress.org/events – get organizers to start writing best Meetup practices.

#education, #meetup, #wordpress-meetup-groups