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

Team Reps

Note from Jane: These notes are from the team rep summit that happened the weekend before #wpcs. More information about the outcome of this talk will be posted soon to

How were people chosen to be team reps?

Every contributor group were surveyed (via p2 and/or mailing list) to choose team reps (primary and backup). The UI team was slightly different in that the group was not very active at that time, so the responses were low, but the selection was Jane and Helen as second. Since Jane was organizing it, Helen was chosen as a Core team rep, and the UI team had devolved into mostly CSS (dev), no UI team reps were assigned.

Core devs have team reps including long-time core committers, highly experienced devs with commit access, experienced devs without commit access, and devs new to contributing. This overweighted the team rep group in favor of core devs. Also, since people were voted in, roles have changed. Agreed to reduce the number of core dev reps to two, just like all other groups.

Sometimes roles change (like Mika, who’s been working on plugins as well as support). People should, ideally, just be responsible for one thing. How regularly should we revisit who the reps are? Should we time it with release cycle, or make it time-based? 6 months, timed with calendar, not release cycle seems most attractive.

After the summit, Jane will post about another voting round – whittle down the core dev reps, revisit UI/events/etc, and announce the new round of elections.

Term limits. Is it best to switch team reps every term? This can be a good way to encourage people in your team to step up. Another idea is to have a team rep and a rep-in-training, so that the alternate rep can be learning and training before they take on the team rep responsibilities.

Do you lose team rep status based on poor performance? If team reps miss weekly updates or monthly chats, should they be asked to step down? Alternate reps should represent the team if a team rep can’t make a monthly hangout or weekly update. If the whole team can’t post/represent for 2 weeks straight, then they need to re-assess the reps.

What teams are light and need to be recruited for? Mobile, international, accessibility, and security (new team!).

Are there any teams we don’t have that we should? team (Meta) for sure. UI could use more designers. Support could use more people and documentation writers. It would be a good idea to make documentation a separate group.

Agreed to close voting on December 14 for the next round of team reps to start on January 1, allowing for a 2-week orientation and training/getting up to speed.

It needs to be emphasized to the community that the team rep position is more about communication and project management, not necessarily prestige. Let’s keep assessing our processes and structure, and make iterative improvements.

#contributor-groups, #team-reps, #teams