Accessibility Team Community Summit Notes

Review and update the accessibility coding Standards

Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding Standards.

Announcing dynamic content

We have:

For complex interaction wp.a11y.speak() may not be the best solution. When in doubt discuss solutions with the a11y team.

Resources

  • Accessibility handbook has not enough recourses
  • How to handle ARIA for screen readers
  • Fact is that traditional web apps reload gives feedback, that JS only apps can not provide. Are there tools we can leverage to help standards adoption?
  • JS interfaces still should be build with semantic HTML
  • React tends to use divs, but that’s not React itself, that’s bad programming
  • 10UP now released a complete library for WP . It’s in Github, so this is expandable
  • For the handbook we should refer to existing libs or someone to build them
  • There is a need for good information and components that are accessible

Workflow

Important: The a11y team needs to do more teaching and sharing, instead of fixing things themselves. Specifications within accessibility tickets should contain code examples

  • We should share accessible components
  • Is it possible to abstract cases and give examples of good practices
  • Part of the standard tooling should be testing software react/axe
  • Give 10 point list of things to check
  • We should publish about for example audio feedback, focus management, ARIA

Discussion

  • Should we block things? Are we okay with keeping that statement: WCAG 2.0.
  • Have things met the standard? Probably not.
  • What happens in tickets if it’s raised that it doesn’t work for WCAG?
  • How do we help in that situation? Someone should review major patches.
  • We don’t want to be a blocker. Accessibility has purification levels. Shoot high, but compromise.
  • What happens when someone blocks a ticket. It depends, no one really has.
  • Where’s the acceptable bar? Should work with keyboard only (arrow keys, etc. too). Semantic elements too. Labeled. This is a baseline expectation.
  • Struggled to know when/where discussions take place sometimes.

How to involve more developers with accessibility tickets

  • This is about how to bring more people into this team?
  • Why do some people stick around and others not stick around? Interesting, important. Time is valuable.
  • How do we maximize people’s time? Maybe story points, like in Scrum.
  • People don’t know how best to contribute.
  • Something like “good first bug” but for accessibility.
  • Short interview/onboarding for people interested.
  • Better way to manage priorities. Maybe spreadsheet to try it?
  • Non-Core items: Testing, theme reviews, tickets, documentation, support, education
  • Maybe use more keywords for this? Make list public so people know.
  • Best way to address is when teams ask for help.
  • Accessibility slows progress down when it comes at the end.
  • We need a mental shift of where accessibility fits. We need to let them know they can do it.
  • Works properly vs. get working.
  • Get people from outside community. Make a list and ask. Things they can do and achieve. Make a list of people we could bring in.
  • MITs: Settings API, Gutenberg, Media Views, Unified Search – Who?

How to proceed with the handbook

  • Make two pages: Tools and resources. Also, how to get involved.
  • Would potentially be easier to maintain.
  • Has been hard to get done because everyone is busy.

Good examples of ARIA, etc.

  • How to test resources.
  • List of what we’re working on.

What topics?

  • ARIA
  • Keyboard accessibility
  • Color contrast
  • Semantics

How should we divide topics?

  • By topic or need? Probably both.
  • Try to find resources that go beyond accessibility as it relates to disabilities.

Who can work on this?

  • Make small workgroup
  • Do Google Spreadsheet

Summary on make/accessibility

Takeaways from Paris

#accessibility, #summit-2017

Mobile Team Community Summit Notes

WP-API and the Mobile Apps

Currently the apps use WPCOM API and XML-RPC. WP-API works just like any REST API, but the big problem for the apps is Authentication. The discussion focused on that.

  • SSL
  • Need a centralized server
  • Ultimately: we are going to (probably) use “”The Broker””
    • Multiple centrally-hosted OAUTH providers (.org, .com)
    • .org could be the basic case (default)
    • In interim we can hardcode a client ID for the app – once we move to the broker we can move it over (will not require app update).
    • Q: does this require connecting .org accounts to individual sites? A: no
  • oAuth2 support is in progress for WP-API
  • Concerns about The Broker as a security vulnerability
    • Is it possible to de-trust the broker itself?
  • This will be a plugin initially, so the apps can’t rely on it existing – at least 6 months out (feature plugin)
  • Right now any (non-authenticated) public stuff – apps can start moving over.
  • WPCOM is already running WP-API & starting to migrate over

Idea: magic login links for apps in WP new user email?

Mobile Views on Sites

We’re probably failing users on mobile because most views on sites probably aren’t coming from mobile.

  • AMP may be making people lazy.
  • AMP, responsive themes is the view.
  • Exciting things, like JavaScript, overshadow  mobile.
  • Show ways people can gain, like PWA.
  • Performance is necessary for developing countries.
  • TRT will meet with Google about performance, etc.
  • How do we carrot/stick people?
    • How do we help them?
    • Matt Marquis doing some interesting work here.
  • Make speed cool.
    • Helps with page rank.
    • Make a hangout.
    • Reframe as performance.
    • Do some different benchmarking with top themes. Top 10 themes. .Org/.Com – but it on ThemeShaper.com
  • TRT has too many rules and they’re trying to reduce the burdens.
    • Theme creators are a skillset that’s vast.
    • Don’t know what the baseline is for a good mobile theme.
    • Could use theme preview on .Org.
  • How do we seek out people to talk about performance?
    • How do we get them thinking about mobile and performance?
    • Tag would need to be automated and added.
    • Articulate the problems with themes.
    • Use different devices at WordCamps.
    • Needs to be in user’s face – WordCamp talks?

#mobile

Design Team Community Summit 2017 Recap

The design team made several posts from the focus team sessions and we are sharing them here as part of the recap. Each of these contains more details about what occurred and the decisions made on the day:

#design, #summit-2017

Plugins Team Community Summit 2017 Recap

While a recap of our various talks (including hallway) have been collected in the link below, our primary conversations revolved around the following:

  • New Reviewers: There are some technical issues we’re working on that must be resolved before we can add new people. They include security ones, but also our rather archaic SupportPress tool. This is the biggest and has a lot of small steps and some weirdly large ones (like the idea of a dashboard, automated security checks, and more) so it’s not going to be anywhere near as fast as I want… Well. Release and iterate.
  • How to safely publicly disclose plugin closures (without dog shaming developers). This is logistically something to be concerned over, as the last thing we want to do is make WP and users a bigger target.
  • How to allow frameworks with the least pain for end-users as possible.

In order to meet our goals, we’re going to be discussing the improvements on many fronts at once, and I’m planing out times and dates for meetings for everyone to come and talk about one at a time. Think of it like town-halls.  You can read the details of everything in the linked post:

2017 Community Summit Notes

#plugins, #summit-2017

WP-CLI conversations at the Community Summit

We had two WP-CLI conversations at the Community Summit:

Check out those links for the full summary. Thanks!

Support Team Community Summit 2017 Summary

Getting More Support Contributors

@bethannon1 is now our official Volunteer Coordinator, and she’ll be taking point welcoming new volunteers to our support community. We have received a fair amount of negative feedback about our “somewhat robotic” handbook links for new channel joiners, so instead, Bet will now be reaching out to new joiners directly with a more personal welcome.

A new Forum Welcome (now live), which will be far less guidelines-based than the current Forum Welcome, will be a huge help here too. We will maintain a separate page for the guidelines (also now live).

Later on, we’ll be exploring adding some sort of call to join the meetings which appears to WordPress.org users after a certain number of support replies, and also email notifications to plugin/theme developers when their support forums fill up.

As for meetings, let’s open them with a note to clarify that everyone watching is welcome to participate, and on low-agenda days include community-building items like “What cool things have you done with WordPress?”

We’re taking steps to become a more international community overall, rather than separate communities of separate languages. To start off, we’ll be referring to the “English Forums” as the “International Forums” from here on out. We’ll no longer immediately redirect questions asked in other languages. Instead, try to answer them yourself in your native language if you can successfully translate the question. If you can’t do that, and the question goes unanswered for more than a day, use the pre-defined reply under “Non-English Support Request”. In the future, we’ll add language tagging once tagging is fixed so that we can tag topics without replying to them.

As for meetings, all languages are now welcome. We all know how to use translators, so we should allow everyone to participate in their own native languages. Additionally, sarcasm and cliches don’t translate well, so we should avoid those from now on.
We won’t be getting rid of specific locales, participation in the overall International Forums and meeting is only a recommendation.

@bethannon1 will also be taking the lead on organizing monthly volunteer orientations, geared as both an introduction for new volunteers and a reminder for established volunteers. They will cover a training-like Handbook walkthrough, sample questions with group answers and feedback, and an overview of cultural tone differences when it comes to English.

We’ll also be planning monthly plugin/theme support workshops, led by representatives from some very recognizable names in the WordPress community (a different one each month). The workshops will be held at a time that is comfortable for the leader and cover how they provide support for their plugins/themes. The first such workshop has been scheduled for August 23.

Support Style Guide

After a good discussion, we decided not to pursue a style guide. Instead, best practices will be conveyed as part of the monthly volunteer orientations and plugin/theme support workshops.

We also plan to encourage collaboration via Slack when an issue could be between two items (conflicting plugins and/or themes for example), and may consider exploring joining Slack as a requirement for having a plugin or theme hosted at WordPress.org.

The remainder of this session was largely a re-hash of the plugin/theme support workshops that we discussed in a previous session, including how we’d schedule them (that will be up to each person running each session) and how we’d announce them (on the applicable Make P2s and hopefully get some help from WP news sites).

Remaining Forum Fixes

We managed to knock down our previous very large list of things we miss from bbPress 1 and new things we need down to this much smaller (and far more possible to complete) list sorted by priority:

  1. Allow moderators to add notes to users – 2272 (Finished)
  2. All w.org users should be able to report posts or topics – 1956 (Bring back ability to add a tag (including the special “”modlook”” tag to flag issues for moderator attention) without having to add a reply, as was the case in bbPress 1. Fixing this would also allow posts in languages other than English to be specially tagged for polyglot volunteers.)
  3. Forum RSS Feed Issues – 2204 (There are multiple issues in this ticket, Meta – please let Support know if any items should be split out into separate tickets. Especially important: include replies in RSS Feeds, include plugin & theme name in subject (as in bbPress 1). @sergeybiryukov will look into how feasible are replies in RSS re: performance.)
  4. Add a way to sort topics in forum profiles by recent activity – 2470 (Finished)
  5. Option to set default value of “Notify me of follow-up posts via email” in profile – 6 (Finished)
  6. Old topics are no longer automatically closed after 1 year – 2265 (Finished)
  7. Moving a topic from one forum to another forum results in a 500 error – 1955
  8. Last Post ignores post status – 2043 (Finished)
  9. Add support for custom titles on support forums – 1950 (Finished)
  10. Moderators should have a way to edit user profiles – 1985 (Finished)
  11. Spamming a user should flag topics and replies as spam and remove custom profile data – 1960

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.

Community Summit 2017 recaps will be posted here soon

As a few weeks have passed since Community Summit 2017, we’ve gathered some notes of the discussions that took place during the Summit (although we haven’t received notes of all discussions yet).

We’ve sent the notes we received so far to the respective team leads, and asked them to publish a post with their recaps on this make/summit p2 blog (if you haven’t being pinged already, this means that we haven’t received notes related to your team’s topics).

The Community Summit team would like to ask the team leads for the following:

A) If you haven’t published already a recap in your team’s p2:
Please publish a p2 post on this make/summit blog with a recap of all the discussions related to your team at the Summit.

or

B) If you have published already a recap in your team’s p2:
Please publish a p2 post on this make/summit blog with a link to that published recap.

Pinging some team reps who attended:
Rian Rietveld: @rianrietveld – Accessibility
Daniel Bachhuber – @danielbachhuber – CLI
Jonathan Desrosiers and Adam Silverstein – @desrosj @adamsilverstein – Core
Mike Schroder – @mikeschroder – Hosting
Jon Kenshino – @kenshino – Docs
Cate Huston – @catehstn – Mobile
Mika Epstein – @ipstenu – Plugins
James Huff – @macmanx – Support
Ulrich – @grapplerulrich – Themes
Tammie Lister – @karmatosed – Design
Francesca Marrano and Hugh Lashbrooke – @francina @hlashbrooke – Community
Petya Raykovska – @petya – Polyglots

Note: If you’re not an Author in this p2 already, please ping @andrescifuentesr or @milana_cap and they will give you access to it.

Thank you all! 🙂

2017 schedule

Please use this link to find the schedule for the two days.

 

https://docs.google.com/spreadsheets/d/1uTJKx31elVdYvbROUpadA7RCA41qWMq4TegCbItoRkg/edit?usp=sharing

 

Remember NO posting of anything such a pictures, notes  or conversations on any social media.

WordPress Community Summit 2017: Final list of topics

The 2017 WordPress Community Summit (CS) in Paris (Tuesday, June 13th – Wednesday, June 14th) is less than 5 days away and here is the final list of topics submitted by teams.

Core

  • 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)

Design

  • 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?

Mobile

  • 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)

Accessibility

  • 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
  • Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding standards

Polyglots

  • 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

Support

  • 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.

Themes

  • 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

Docs

  • 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)
  • Discuss opportunities for leadership and retainment of contributors to ensure longevity of Docs Team goals

Community

  • Paying for speaker travel – following on from our existing discussion and reaching a consensus.
  • Regional camps – following on from our existing discussion and reaching a consensus.
  • WordCamps and Money – discussing guidelines for responsible use of funds and clearly outlining what will and will not pay for. Also looking at how this affects in-kind types of sponsorships.
  • Code of Conduct and harassment reports – Establishing a plan for training for organisers on how to deal with CoC violations, as well as reviewing the CoC to be more inclusive (possibly to be concluded at Contributor Day).
  • Marketing & Engagement – discussing a general marketing plan for WordCamp and meetups, especially to engage people outside of the WordPress bubble – (Marketing)
  • The 80/20 rule for local/international speakers – this is a sticking point for many camps and it will be worth defining what we mean and where the line is for this.
  • Communication tools for WordCamp organisers – discussion on how to handle third party newsletter tools/services and how organisers can more effectively communicate with their community.

Plugins

  • 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)

Training

  • None

Meta

  • Translation of documentation on WordPress.org, 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

TV

  • None

Flow / Test

  • None

CLI

  • 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
  • Problem in detecting updates of manually packaged WordPress (Meta, Core)

Marketing

  • None

Hosting

  • 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)

Thank you to all teams for great topics lists. We wish you wonderful and productive Summit and see you all next week in Paris.

“Such wow. So excited. Much joy.”

– friendly robot Pierre