Theme Topics @ Contributor Day

Future of the Theme Review process & making it smoother and faster

In this session we continued the Theme Review specific discussions from the 13th of June.

The main focus was an improved review process with a new backend.
We discussed the possible changes and differences between the current and a new system:

  • The current Themes Trac would be replaced by WordPress.
  • Reviewers will no longer be assigned to themes. This means that anyone can do a followup review. The reviewer would not need to wait for the reply and would be free to review another theme meanwhile.
  • There will no longer be a 7 day deadline for an author to reply. The theme will wait until an update is submitted.
  • The reviewer would not need to close a theme as “not approved” because of minor coding errors, only if the themes are copies, spam etc.
  • The term queue will no longer be used. Reviewers will be able to decide if they want to review the oldest theme or any other theme.
  • Communication between authors and reviewers would be through e-mail.
  • Theme authors should have access to SVN to update their theme once it is live.
  • Parsing of the readme file: multiple authors, multiple screenshots etc.
  • There should also be standard texts for common errors, that could be added to a review.

We discussed how we can make the reviews available for anyone to read, and also where the accessibility review would fit in the new workflow.

Parts of the system is already in use by plugins, but it needs to be improved and completed. Once it is fully working for plugins, it will be copied over to themes. The first deadline is set to December 2017.

Another question concerned what information or feedback the theme author needs after submitting a theme. The suggestion is that instead of showing a theme’s queue position, we should show the current status (pending -awaiting review, pending -awaiting update).

Most of the points above requires the backend to be complete, but we also discussed what the Theme Review Team could do short term.

The team would need to inform theme authors about the specific format for the readme file so that it can be parsed correctly when the backend is ready. The suggested format is the current plugin readme.

We briefly discussed Theme Review requirements and the .org theme previews. It was suggested that the reviewers should allow more minor content creation and also focus more on design.

Code Automation for Themes/Plugins

  • PHPCS’s problem requires certain functions and it can’t handle that.
  • Theme Check doesn’t have unit tests, so it rewrote it.
  • Dream: Checkboxes show green, yellow or red. Showing a theme/plugin health. Some required, some not.
  • Rank according to severity of issues.
  • Some people are overwhelmed with the requirements to be a TRT volunteer.
  • Humans would still be used to help with the quality of themes, but just from more people, not just contributors.
  • Three contexts: when developing, on upload, and continuous.
  • False positives are an issue at times.
  • Could be one backend, multiple front ends.
  • Tag errors so they’re suppressed if it’s not really an issue.
  • Local tool would help with false positives.
  • People could check in code, and when it passes, it could be made public to other people.
  • Huge opportunity for educating on best practices.
  • WordPress coding standards could be a check, but not required.
  • Plugins/Themes could include their own checks. Would need to be limited.
  • Checks could give compatibility for PHP7, etc.
  • Same check for WordPress versions. Knowing whether code generates warnings or errors would be helpful.
  • Searching for 500 errors.
  • Ticker for themes being activated WITH PHP errors.
  • This could improve directory interfaces for plugins and themes.
  • Can plugins be easily transferred. Need to know the expectations and norms. This way, plugins and themes could be more cared for.
  • Up to versions run now to tell people that’s not up to date, and it helps with updates.
  • Could be checks for mobile, etc. to push better themes to the top.
  • Probably need to start small. Up to checks and go from there.
  • Locally first, plugin, then server everywhere.
  • Reduce amount of manual checks for accessibility checks.
  • TRT is working on a lot of tools to start solving some of this.
  • Visual regression testing in themes has helped some developers.
  • Starter theme content could help with regression testing. What would be done with the differences? Users might want to know this.
  • Do the easy stuff first.

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?
  • 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: Attendees and Agenda Summary

The 2017 WordPress Community Summit (CS) is almost here. It will take place on Tuesday, June 13th and Wednesday, June 14th, the two days before contributor day at WordCamp Europe in Paris, France. All attendees should have received an email with venue and other important details. If you haven’t received such an email, or if you’re not able to attend, please let us know asap at

We would like to remind all teams and contributors the purpose and goal of the Community Summit:

“The main purpose of the summit is to move the WordPress 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”


How Attendees Were Selected

Unlike WordCamps or Contributor Days, the Community Summit has limited capacity both because of the venue size and the type of work that is required. The list of nominations was reviewed by a committee composed of experienced contributors, chosen for their broad overview of the project and its community: @aaroncampbell @petya @chanthaboune @helen @ipstenu and @_dorsvenabili

The committee reviewed the list of nominated contributors that we received from the original call for nominations (more info on the process and criteria).

In voting on each person, we kept several things in mind:

  • Active contributions to the project and that specific team
  • Influence/reach in the broader WordPress ecosystem (not just within
  • Employer (to prevent an overwhelming presence by one or few select companies)
  • Location (to have a decent international contingent and not be solely US-focused)
  • Differing Points of View (to ensure minority voices can be heard)



The list of attendees was formed from all those who were invited and confirmed their attendance:


@afercia @rianrietveld @davidakennedy @mor10 @samikeijonen


@schlessera @borekb @danielbachhuber @miyauchi


@andreamiddleton @andrescifuentesr @iaaxpage @mbigul @courtneypk @thewebprincess @jennybeaumont @emanuel_blagonic @francina @mayukojpn @hlashbrooke @ibonazkoitia @miss_jwo @kcristiano @lanche86 @travel_girl @markgazel @imath @paolal @remediosgraphic @sptorabi @_dorsvenabili @mahype @thabotswana @00sleepy @xibe


@adamsilverstein @boonebgorges @chriscct7 @desrosj @dd32 @iseulde @flixos90 @jjj @joehoyle @joemcgill @joen @johnbillion @kadamwhite @matt @marcs0h @matveb @voldemortensen @azaozz @swissspidy @rmccue @stevenkword @westonruter @peterwilsoncc @codebykat


@empireoflight @folletto @michael-arestad @melchoyce @saracannon @sonjanyc @karmatosed @liljimmi


@atachibana @kenshino @milana_cap


@aaroncampbell @andrewtaylor-1 @ddsucurinet @joostdevalk @mikehansenme @mikeschroder @stephdau


@tellyworth @coreymckrill @pento @iandunn @obenland @mapk


@catehstn @mbiais @kwonye


@ipstenu @otto42


@glueckpress @chiragpatel @carl-alberto @ocean90 @imnok @lasacco @openstream @petya @tacoverdo @vannkorn


@bethannon1 @cristianozanca @imazed @macmanx @clorith @sergeybiryukov @zoonini


@acalfieri @grapplerulrich @sakinshrestha @ionutn @poena


@wpaleks @chanthaboune


Summary of Community Summit Agenda

Day 1 (Tuesday, 13 June):

  • Individual team and cross-team discussions* which need in-person discussions

Day 2 (Wednesday, 14 June):

  • Continuing cross-team discussions*
  • Writing recaps for the make/summit p2 blog


Proposed Discussions

A few months ago, each team proposed topics that need in-person discussion ( List of proposed topics ). If teams need to amend or update their list, post any changes as a comment, please. The deadline is Friday, June 9th, at which point we will close comments and publish the list of topics for WordPress Community Summit 2017.


Travel Assistance Program Applicants

All guests, selected for the travel assistance program have been contacted via email by the organizing team, who will follow up in the next few days. Thanks so much to all our sponsors for making this Travel Assistance program possible!

#attendees, #summit-2017

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 130 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

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

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

Summary: Mobile Apps Discussion

There are 6 official mobile platforms for WordPress, most active being iOS and Android by far.

Mobile apps have been a place to experiment with native interfaces, like the dashboard layout in Android. Lately a move to the swiping sidebar, what’s nice about that is it scales up for example the panels in the iPad version, it’s like responsive design.

We’ve had a lot of issues finding contributors for native platforms because there is a specific set of skills. There are some issues around GPL and the app stores. There are also issues around APIs, more interested in a JSON-based API than using XML-RPC. JSON is lighter weight to parse, and usually lighter to send. REST is a different paradigm though which is more of a remote procedure call.

APIs should come from the mobile apps and UI features we want, not vice versa. It’s difficult for mobile devs to have to put everything through a long review, vs in core where we make the API at the same time. Perhaps we need APIs that we mark for first-party apps only (officially) so we don’t have to worry as much about mantaining things for ever.

Node has a system where different APIs indicate their rigidity, from raw to frozen.

On they can iterate a lot faster because they can co-develop and immediately deploy.

Mobile app sub-forums, we can arrange them however team wants. It’d be sweet if you could view / post in the support forums from directly within the app. Mobile app websites have forums, blog, homepage, download, and a get involved.

We have lots of mobile app sites, each with its own landing pages, download, blog, FAQ, forums. Bring all of that into

Apps on the download page? Consensus yes. (Action item for Isaac.)

Feedback for apps. “Moderating comments on iOS kind of sucks, because you can’t go back to see other comments on a post.” A uniform design language that can be used across all of the apps, whether in the dashboard or in the mobile apps. Been of the approach that you should follow platform UI guidelines and conventions first. Guidelines should probably go both directions.

What does native do that we don’t get on the web? Device-specific functionality, some is catching up, performance is the biggest thing. Animations, shadows, scrolling, getting data vs getting HTML with every pageload.

Stats are a great example of this, if there were a method for “fetch my stats” different plugins could hook into it. Backbone views are broken down and can be reused.

Two big issues: people in this room have things they want the apps to do, and we’re getting lots of 1-star reviews. Many of the crashes and bad ratings are from webviews, mostly things in One of the reasons we’ve been going native for some of the stuff.

Some feedback around the hierarchy of the sidebar menu. We don’t have universal swipe to the right, you have to swipe from the button. The apps are still blog-centric, even though there is some action-centric stuff. How can more people get involved with making the apps more stable? Perhaps an iOS shop needs WP help and we could trade.

iOS world is full of highly polished, very designed apps. Why have we struggled, what’s holding us back? Most apps are single-party — one host, one developer, one API.

This week action item: add app downloads to the page.


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.

Summary: Women in WordPress

Attendees: Cátia Kitahara (discussion leader), Erica Varlese, Helen Hou-Sandi, Aaron Jorbin, Sara Cannon, Christine, Amy Hendrix, Andrea Rennick, Rachel Baker, Mika Epstein, Matt Mullenweg, Siobhan, Jane Wells

It’s not just a WordPress problem, but more men and women working in tech. Only 12 out of 100 women here. There are more women involved, how do we get them here? Don’t want to feel like we’re here just because we’re women.

Follow the ADA initiative, get more WCs to follow the guidelines and everything they set up for events.

There’s a tendency for women to do lots of work but not call attention to it; don’t brag about it. “I’ve been told I was bragging and it was unseemly and it was coming across as too manly.” To be noticed in WordPress has been to keep people from knowing I was a women for as long as possible.

What I’m hearing from other women is they don’t think they’re smart enough; even though they’re doing amazing work, they feel like outsiders. Lots of women in themes or design who actually do development say they’re not a developer.

Some stories of being treated badly in tech support when they found out they were a woman. It’s also a big problem that women stereotype and mistreat other women in professional situations. But if people don’t know you’re a woman, it doesn’t encourage other women to get involved. Work twice as hard, half the credit, and 100% of the blame.

Zero-tolerance for people with bad manners. If you can’t respect everyone you’re not welcome in the community. Etiquette file used to be linked from forums. WP forums used to have a reputation of being a bit of a snakepit. Justin Tadlock of “what was the first question you asked on the forums?” Many were what we would now see as dumb questions. You can’t know what you don’t know. The moderators have changed their attitude, to not just keep off spam but really to set a good example.

There’s a WordCamp Code of Conduct. For website we prefer to be positive rather than “don’t don’t don’t.” Can we shift this conversation from what other people do wrong to what can we do right? Changing other people is futile. What kind of example can I set? Might need to put more effort into remembering to project, and be confident.

Something I’ve noticed with WordCamps I’ve attended is most of the people that apply to speak are male and on the developer track. Big opportunity. Need to reach out extra to include women speakers. Demographics of visitors are 61% male, 39% women — for users of WP software it’s probably more even. This event (summit) skews more developer-y.

I feel pressure to speak in the developer track, but I would rather go outside of my comfort zone for a user track presentation to set that example for the community at large. If we had more women involved there wouldn’t be that pressure. Women say no to speaking invitations more than men for tech conferences. Goes back to safe zone issue, stranger danger fear. Division of household duties can make it harder for a woman to go.

Every session doesn’t need to be the latest and greatest, some users just want to know how to edit CSS. Make it less intimidating to contribute. We get a lot of the same people giving similar presentations. Some of the exclusion isn’t necessarily gender but disposition, even the women we get tend to be a lot more assertive.

Not just having a hack day, but a contributing to WP day, rename hack day as contributing day? Lisbon had translation group, support group, documentation group, core group. Cross-functional groups means that a lot more can get done, than if it was just isolated developers, designers, or users.

The learning curve of WP isn’t straight, it’s easy easy easy BOOM.

I think it’s hard to learn to public speak well, I struggle with it and I’ve been doing it for four years. It’s a difficult skill, and is something above and beyond just having normal confidence. A mentorship program — a huge help is teaching, when you start teaching it goes a long way to being more comfortable.

Give positive reinforcement especially when code or anything is shared. Maybe it could be important to have some numbers, from the survey or something to have more what our baseline is and track our progress (or regression) over time.

Action item: ask for gender on survey? Don’t want to put the question in people might not want to identify. Maybe on .org profiles? Male, female, a LGBT dropdown, I don’t want to say. Important for moderators on forums to make the forums a safe space, IRC, Trac. Also important for WCs and meetups. There’s always that weird guy at a meetup.

I put a code of conduct in the badges for WCSF 2011, and everyone knows there’s a standard of behavior. OS Bridge has a great thing attached to their CoC that you could nominate people that are super-inclusive and recognize them publicly. Defcon had red cards, yellow cards, green cards. There are two types of people when it comes to code of conduct, those who don’t think it’s needed and have never dealt with it, and those who have dealt with it.

Proactive program to reach out to middle and high school programs for girls and women into the community, particularly on the engineering side. What are some things we could do to reach out to that group? Lots of non-profits and groups focused on this. When my kids were 12 we taught them HTML and CSS.

We haven’t had too many issues, mostly language based or language in a presentation, not usually downgrading but more objectifying from a sexual level. It’s the subtle things as much as the obvious things. We’ve also gotten feedback on women speakers who are too flirty or cutesy when presenting, not professional enough. When I see those turned away I introduce myself first to the person who was snubbed, say “probably just didn’t see you” and then re-get the speaker or person and say “this person was waiting for you and you didn’t notice them can I introduce you? This is so-and-so and from this town and really enjoyed your presentation.”

Be super-encouraging. Action item: should be everyone here should find a woman in their local community that really knows their stuff and get them to present at a local meetup.