Community Summit Role: Taking Stack and Keeping Time

Each Community Summit discussion will have:

  1. One Facilitator
  2. Two Notetakers (read about the Notetaker role)
  3. One Stack Keeper/Time Keeper

Please familiarize yourself with the Stack Keeper/Time Keeper role in advance, so you’re ready to volunteer!

Purpose: The purpose of taking stack is to ensure that all participants’ voices can be heard in the discussion. Otherwise, an individual or a small group of people could easily dominate the discussion and shut out other participants.

The role of Stack Keeper: At the beginning of each discussion, the Facilitator will request a volunteer to be the Stack Keeper. It is the Stack Keeper’s responsibility to structure and order the dialogue. “The Stack” is the order of participants who are speaking. If a participant raises their hand to say something, the Stack Keeper puts them on “Stack.” That is, the Stack Keeper puts their name at the bottom of the stack list. When the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and announces who the next two participants on stack are. The Stack Keeper should also make sure that people who have spoken before come after folks who have been added to the Stack for the first time.

Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack Keeper must constantly be paying attention and scanning the room to see who wants to speak. In addition to these duties, both the Facilitator and Stack Keeper may also contribute normally to the discussion.

Keeping time: The Stack Keeper is also responsible for keeping time during the discussion. It’s important that the Stack Keeper/Time Keeper let the Facilitator know when it’s time to wind down the discussion and shift to Next Steps and Action Items (at least 5 minutes before the scheduled end-time). This will help avoid an abrupt end to the discussion, and ensure that the group has clearly identified next steps before the discussion concludes.

Community Summit Non-Attribution Guideline

As we prepare for the Community Summit, we’d like to share the important guideline of non-attribution, to ensure productive and open discussions.

While we welcome and encourage you to share the content and insights from our discussion with others, we kindly request that you practice non-attribution. This means that outside the Summit you can discuss the general ideas and themes that arise, but please refrain from directly quoting or attributing specific comments to individual participants.

Our goal is to create a safe, inclusive and collaborative environment where everyone feels encouraged to brainstorm, share their thoughts, and speak their minds. By not attributing comments to specific individuals, we hope to foster a space where participants don’t have to worry about their words being taken out of context or used against them outside of the Summit discussions.

In the spirit of non-attribution, we request the following:

  • Stay Present: We kindly ask that you refrain from posting on social media during Summit discussions. This helps ensure that everyone is actively engaged and present in the moment.
  • Photos: You’re welcome to take photos, but please ensure they align with our non-attribution guideline. This means avoiding photos that tie specific comments or ideas to particular individuals.
  • Recaps & Summaries: You are welcome to share post-event recaps. However, please ensure that these do not attribute specific comments or viewpoints to individual participants.

Thanks for your understanding and cooperation. We’re excited to dive into these discussions together!

Join Us as a Notetaker at the 2023 Community Summit

Community Summit attendees are invited to fill an important role as a Notetaker for one or more Community Summit discussions. Read a description of this role on the Community Summit site.

If you’re willing to serve as a Notetaker, please let us know by this Thursday, August 17. To do so, comment here, email communitysummit@wordcamp.org, or send a direct message to @julia in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/, and specify which of the 26 sessions you’re available to note-take (view the schedule here). Please offer to serve as Notetaker only for topics with terminology that will be familiar to you.

Thank you! With your help, we’ll ensure that the Community Summit has a lasting impact on the future of WordPress.

What to Expect at the 2023 Community Summit

Please check out the recent post with important information about what to expect at the 2023 Community Summit.

Additionally, the 2023 Community Summit schedule is now available.

X-post: Suggest Topics for the 2023 WordPress Community Summit

X-comment from +make.wordpress.org/community: Comment on Suggest Topics for the 2023 WordPress Community Summit

X-post: Apply to Attend the 2023 Community Summit

X-comment from +make.wordpress.org/community: Comment on Apply to Attend the 2023 Community Summit

X-post: Potential addition of a new Onboarding Team

X-comment from +make.wordpress.org/community: Comment on Potential addition of a new Onboarding Team

Accessibility Team Community Summit Notes

Review and update the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) 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 HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.
  • ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org 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 GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/, 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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. things? Are we okay with keeping that statement: WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 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-CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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-APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and the Mobile Apps

Currently the apps use WPCOM API and XML-RPC. WP-API works just like any REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/, but the big problem for the apps is Authentication. The discussion focused on that.

  • SSLSSL Secure Socket Layer - Encryption from the server to the browser and back. Prevents prying eyes from seeing what you are sending between your browser and the server.
  • 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. initially, so the apps can’t rely on it existing – at least 6 months out (feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins)
  • 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 JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com, 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?
    • TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post. would need to be automated and added.
    • Articulate the problems with themes.
    • Use different devices at WordCamps.
    • Needs to be in user’s face – WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. 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