Jonathan Desrosiers 2:16 am on September 6, 2023  

Community Summit Discussion Notes: Iterating on the Team Rep role

From the session schedule:

Today, each Make Team has a few Team Representatives (often referred to as “Team Reps”). Historically this role was not a leadership position, but designed to help facilitate communication across teams through weekly updates and cross-team discussions. Over the years, the Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. role has shifted and now differs from team to team: on some teams, Team Reps are only responsible for setting weekly agendas for meetings and posting recaps. On other teams, the Team Rep holds mentorship responsibilities. This discussion aims to a explore stronger definition for the Team Rep role, including responsibilities and what skills might be helpful, and where in the contributor journey they should be.

Facilitator: Angela Jin (@angelasjin)

Notetakers: Jonathan Desrosiers (@desrosj), Benjamin Evans (@bsanevans)

Discussion Objectives:

  • Create a stronger definition of the team rep role
  • Consider how team reps can be better supported
  • Consider how folks can be helped to become better team reps

Key Points

Community Summit 2012 is where the role was initially discussed, and should be revisited.

  • The role was originally in charge of communication and project management, and represented the team to the project.
  • Was not about prestige.
  • Considering the size of the project today, the role was created for a smaller subset of groups than what we have now.
  • Was created when 6-8 teams existed, at most.

What is a team rep?

  • We need standardization and a stronger definition of what we want/need the role to be.
    • Learn.WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ can be used for standardization.
    • At the same time, some teams have found the team rep role does not work.
    • Some think the rep role should be limited to admin tasks, while others think it should be limited to project wide communication.
    • Variation in the role definition is good (teams are making it work for them). But these differences need to be clearly documented.
  • Some folks do it because they want to serve, but sometimes also because there is a need.
    • Some people are rep for too long because they can’t pass it on.
    • Sometimes it is hard to make it look attractive.
  • For some teams, it’s very difficult to be an unsponsored contributor and serve as a team rep.
    • How can this barrier be removed?
  • It should be a role folks grow out of.
    • Teams should have a clear progression path (contribution ladder).
    • If folks are doing it for recognition, then there should be other means of recognition.
  • Projects need leads to get stuff done, but there is history behind not calling reps “leads”.
    • There is a difficult balance of democratizing, and pushing things forward.
  • Ideally, team reps shouldn’t need to know English
  • Having diverse reps can ensure global coverage.
  • Some teams require a higher level of trust and vetting, such as Security or 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 Review teams.

Teams can do better at setting reps up to succeed.

  • New team reps need onboarding.
  • Clearer expectations and outlined responsibilities.
  • Teams need documentation on the role, and also how succession is made.
  • Teams should strive towards a diverse group of team leads
    • Stagger term limits so that there is both an experienced and non-experienced person
    • Have reps from different time zones
  • Teams should have separate folks assigned to inter-team collaboration – such as project managers.
  • Keep working groups in mind when defining what a team lead is.
  • The project can empower new teams to get up and running with representation more quickly with stronger definitions and better documentation.

Improvement ideas for make.wordpress.org/updates/:

  • /updates/ was created as a place for reps to communicate with each other.
  • Access to the site needs to be managed better for new team reps.
  • This needs to be better marketed so that non-reps also know it and follow it.
  • Great spot to get the birds-eye view for what teams are working on.

Suggestions to improve the rep role:

  • Send Welcome packs to new reps, welcoming them to the role and setting out clear next-steps.
  • Have Rep/Lead Camp – a point of accountability and connection.
  • As there are many teams now, we should group teams and have someone represent the group.

Have the responsibilities outgrown a single role?

  • Is there a need for multiple kinds of reps (project manager, communications, etc.)
  • Is there a need for both internally and externally focused reps?
  • Does this involve directly responsible individuals? Another team is working on a proposal for what this could mean and how it could work.

Conclusions/Summary:

  • Most teams have the following needs. But how much falls under the responsibility of the team rep role, and how much is conducted by other active contributors, differs from team to team.
    • Team Representative
      • Represents the team to the wider Make project, and the project to the team.
    • Project Manager
      • Accountable to “get things done” within the team.
      • Aggregates ideas in the team in a format the whole team can follow easily.
    • Administrator
      • Conducts general administration for the team.
      • Collects stats about the team’s performance and projects.
    • Mentor
      • Onboards and mentors new contributors.
  • Teams need to clearly define the team rep role in their team and set up a succession/onboarding process.
    • Guidance or “templates” from the larger program could assist with this.
Weston Ruter 7:12 pm on August 22, 2023
Tags: , ,   

Community Summit Discussion Notes: Accessibility in the WordPress Project

From the schedule session:

How can WordPress adopt an accessible-first approach, and what would this mean for project development and decision-making? This discussion will center on 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) considerations in developing WordPress software and current friction points, and explore possible solutions and practices to incorporate.

Perspectives needed: Current and interested accessibility advocates, people interested in or currently involved in release cycles.

Facilitator: Joe Simpson, Jr (@joesimpsonjr)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Daniel Bachhuber (@danielbachhuber)

Continue reading →

#accessibility, #summit, #summit-2023

Felix Arntz 12:13 am on August 30, 2023
Tags: ,   

Community Summit Discussion Notes: PHP version support

Title of Session: PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. version support

Facilitator: @mikeschroder

Notetaker 1: @flixos90

Notetaker 2: @courane01

From the session schedule:

Currently, WordPress does not officially fully support PHP 8.0+. This discussion will focus on how WordPress can support and align with modern PHP versions, and how to drop support for PHP versions that are end-of-life (“EoL”). There is urgency to this as PHP 8.0 will be EoL in November, and PHP 7.4 reached EoL last November.

Raw Notes

  • Several hosting providers expressing support for running automated tests for PHP version support across hosting providers
  • Is WordPress 6.3 fully supporting PHP 8? – Basically yes (PHP 8.0 and 8.1 compatible with known exceptions, TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets available for all exceptions) https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/ 
  • PHP 8 “betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” tag was removed after WP 6.3 release https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/ 
  • Encourage/support plugins supporting it
  • Attention was raised for Juliette’s published post asking for support on WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards. May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. which is critical to facilitate PHP version support in the future https://make.wordpress.org/core/2023/08/21/wordpresscs-3-0-0-is-now-available/ 
  • Hosting team’s PHP test runner project (running coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. unit tests on several hosts) has issues with PHP 8 – who can help fix/maintain this project? https://make.wordpress.org/hosting/test-results/ 
  • PHP 5.6 support being dropped in WP 6.3 hopefully encourages hosting providers to jump up to supporting more recent PHP versions including 8+
  • PHP version usage of WP sites
  • Big push on GoDaddy to get sites on PHP 8+, vast majority of migrations (>70%) has gone smoothly (~18% marked as “high risk” updates)
  • Bluehost checking factors like closing body tags, document size changing etc.
  • Is there room to open-source tooling for checking that PHP update was successful or is causing errors on the site?
  • While there’s a desire in collaborating on tools across hosting providers, historically differences between platforms has hindered that → knowledge sharing rather than actual tooling
  • Users don’t care what version of PHP they are on, managed hosts manage that for them
  • Can we use WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ for supporting updates? Useful by hosts
  • Min/max for PHP for the plugins/themes
    • Max version hasn’t been needed before
    • List of deprecations that would cause PHP incompatibility, run a scanner. 
    • Max version puts the work on 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/theme maintainers, and less useful. 
  • Implement automated scanner in plugin and theme directories to detect PHP version issues → responsibility of metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team
  • Paid plugins have another issue: many sites no longer have active licenses and therefore don’t receive the updates that would add PHP 8+ support
  • WP plugin repository is not able to force-update premium plugins, particularly if they use the new upgrade URI headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. introduced a while ago (which bypasses wp.org completely)
  • Steps to encourage plugin support
    • email plugin authors prompting to update, but anticipate plugins to end 
    • display info on plugin page
    • integrate into Plugin 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., health check could warn them 
  • Security plugins could tackle Tide scores and compatibility – WP Scan mentioned as a possible option
  • Resources:
  • For the bulk of sites, ensuring PHP support of ~50 most popular plugins will be enough, then the long tail of 100s or 1000s of plugins only applies to a relatively smaller amount
  • What educational resources can LearnWP create to help educate on what/why/how to update? https://github.com/WordPress/Learn/issues/new?assignees=&labels=Awaiting+Triage%2C+Needs+Subject+Matter+Expert&projects=&template=topic-idea.md&title=Topic+Idea%3A+TOPIC+TITLE
    • How to start contributing to PHP areas 
  • Speed at which we drop older versions of PHP – can we correlate versions of WP with PHP?
    • Who can update the PHP? Often hosts deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. it
  • Current 5% rule is based on overall WP sites’ PHP version usage, could we make it based on only recent WP version sites’ PHP version usage? – That would not make a notable difference, there is not a real correlation between using old WP versions and PHP versions, which makes sense since the hosting provider controls PHP support regardless of WP. wp.org internally has that data available, and it’s only ~0.1% different from overall PHP version usage.
  • Extender ecosystem is waiting on Core
  • Bottleneck of keeping up 
  • How can we keep support financially or with labor long-term maintenance of the WPCS / PHP compatibility tooling?
    • Long-term additional contributors would be great, but short-term the barrier of entry to this work is so high that support of the existing contributors is essential
    • Generally, the WP project is focused on getting more contributors, but sometimes there may be more value in identifying and funding already experienced contributors, or attract specific contributors with specific expertise needed
    • mentorship for PHP niche areas, separated out from the rest of Core new contributor table 
  • Conclusion
    • Find funding for contributors and tooling, also mentoring
    • repo plugins to WP users
    • Hosting companies working together to find common versions encounter errors

#summit, #summit-2023

Sarah Norris 11:56 pm on August 28, 2023
Tags: ,   

Community Summit Discussion Notes: Can WordPress become the household name it deserves to be?

Title of Session: Can WordPress become the household name it deserves to be?

Facilitator: @dtsears

Notetaker 1: @mikachan

Notetaker 2: @jessibelle

From the session schedule:

WordPress is the internet’s best kept secret. What would it take for WordPress to be able to raise awareness about itself and elevate the value of the ecosystem, while being thoughtful on behalf of the community that surrounds it?

Key Points

  • We began the discussion by highlighting important historical events, starting with things that have encouraged market adoption, for example:
    • When Movable Type changed its license
    • When Custom Post Types were introduced
    • Adding import/export functionality
    • Ability to make multilingual sites
    • Amount of developer support, so easy for new users to pick up
  • We discussed the importance of WordPress being a household name, including the why and the how. Some highlights include:
    • WP levels the playing field for small businesses to have the same good quality websites as larger companies. The most important people are the people who don’t have big budgets.
    • The flexibility of WP means that it’s unlikely to be stopped by new trends.
    • Brand awareness – it is not self-sustaining and is sustained by the extremely active community.
    • Expanding the reach of WP – Lack of next-generation WP users. Explore the social side of WP – make it a social network? Connect things as part of the open web rather than the closed web. Elevate WP to provide exposure to content.
    • WP not seen as serious career option, but for some people its the beginning of their career.
  • We concluded by discussing current challenges and the next steps

Action Items/Next Steps:

  • Ideas to address different audience segments:
    1. Audience segmentation – create the top 8-10 audiences (developers, small-business, enterprise, marketers)
    2. Group the audiences into categories (end-users, makers)
    3. Segment messaging to those categories (lots of different pathways)
  • Tutorials need to be updated. Being out-of-date and inconsistent puts new users off and breaks trust. Backwards compatibility with tutorials – can we mark them as deprecated? Use Playground to keep tutorials up to date.
  • Teach new translators using better tutorials.
  • Make the process to update docs content more obvious. See Mozilla onboarding for documentation.
  • WordPress.tv – alleviate this tool we already have. Surface video content in the WP backend, along with docs and other content.
  • Use WP Playground more in tutorials
  • Improve onboarding on all levels (new users, new contributors). See Mozilla onboarding for a good example.

Raw Notes

Continue reading →

#summit, #summit-2023

Weston Ruter 9:37 pm on August 23, 2023
Tags: ,   

Community Summit Discussion Notes: What is the criteria for delaying the upgrade of foundational tech, and what triggers reconsideration?

From the schedule session:

From time to time, it’s necessary to delay adoption of newer versions of our underlying technology, either because our software isn’t yet fully compatible or we otherwise cannot recommend the use of the new technology. This is an appropriate measure to take when we are thinking through the promises we make to our users, but what should be the acceptance criteria for reconsidering a delay?

Facilitator: Marius L. J. (@clorith)

Notetaker: Weston Ruter (@westonruter)

Continue reading →

#summit, #summit-2023

annezazu 11:41 pm on August 23, 2023
Tags: ,   

Community Summit Discussion Notes: Ad hoc session on iterating on the Field Guide

This was a follow-up session over lunch building on the backwards compatibility session.

Date: August 23, 2023

Attendees: @ellatrix @mcsf @ndiego @clorith @bernhard-reiter @timothyblynjacobs @jorbin @priethor @annezazu @richtabor @gziolo. Everyone consented to being listed here since it was an ad hoc session.

Notes

History of Field Guide

Around 3.2 – 3.3, there was a field guide around backwards compatibility from Nacin. Around RC1, having an email to 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 developers came up and the email that was created was too much for an email, resulting in a post published on Make. This evolved to become the Field Guide process after being well received by the community. It has since grown in length every single version. When looking at a visual comparison, it is now 6 times as long in length just to look through, making it harder to scan.

Questions to frame the conversation

The following questions were used to guide and frame the conversation:

  • How can the content of the Field Guide by reformatted to improve developer messaging?
  • Is the Make blog the right channel for this resource for folks to engage with?

Developer blog discussion

Developer blog is relatively new and right now anyone in the community can contribute to it. It’s a small group of folks currently along with a monthly “what’s new” roll up that could be expanded and built upon. The original idea of the developer blog was to cut through the noise and provide valuable resources to extenders. This then reserves the Make Blog for folks who make WordPress. There’s more of a process with the dev blog currently that might make it trickier to stick to.

Information spread out

When googling for features or updates, there’s a confusing experience where what comes up could be something from 4-5 years ago rather than linking to documentation. This is due to posts being shared on Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that then start getting linked to and shared, causing the weighting of that post to go up and the first hit on Google is a dev note rather than documentation. We might need to return to dev notes after docs are updated to link to documentation as a way to redirect folks to the latest.

Specific to dev notes, there’s also an issue of dev note being a form of documentation and acting in place of documentation rather than “here’s what’s breaking”. Right now, dev notes are both acting as docs and breaking changes basically. 

If you go a step further to look at 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. editor handbook docs, it includes a mishmash of content. Work is underway right now to ensure learning/tutorials get into Learn WP and documentation remains in docs. Docs in general though are scattered in official blog posts, unofficial blog posts, dev notes, dev handbook, user facing docs, etc. It’s not necessarily bad that it’s in so many places but are things going to the right places or are things getting missed? This comes down to even basic formatting changes like labeling things as “breaking changes” or having a dedicated section for breaking/high impact changes. Right now, it’s broken down by component rather than priority for the Field Guide.

Content reformatting

When thinking about the format and approach of the Field Guide the following questions were thrown around when thinking about the persona of a person using the Field Guide: Are there big UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. changes to inform customers about or update plugin around? Are there things that might break and what do I need to do about it? What are the big things in the release? Where can I get more information? This led to an idea of two Field Guides with different approaches:

  • A hyper focused version with more curated info. 
  • A longer, more robust version. 

Right now, separating out a curated source requires a level of expertise to determine what’s most relevant that isn’t widespread in the project.

Pain points in getting early feedback from extenders

We talked about the general process before a release and getting folks to test, give feedback, etc as part of the broader process of sharing dev notes. Before a release, there are alpha/betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. forums where you can get some feedback but it doesn’t often go anywhere. Developers are more likely to use TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. and 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 be the repository owner. https://github.com/ so we can point them more in that direction to get feedback. In general, getting devs to beta test or RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. test is very hard. 

Iframing the editor example

To ground the conversation in a specific example, we talked in depth about work around iframing. For some plugins, they didn’t reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. because they felt there would be a fix in the future for iframing rather than taking action and reporting something on. We can’t make changes if we don’t know about the feedback though!

The WordPress Developer Blog would be a good way to surface issues like iframing and go in depth about ways to overcome different pathways for adopting. If this effort is backed up with documentation, it could help cover the big, breaking topics nicely.

We went on a bit of tangent around how we could use Site Health with lack of iframing to help encourage folks adopting. In general, for larger changes like iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., we need to think of communication plans as part of the effort. For iframe, every situation is quite different so it’s tricky to get right. Developer Relations should be able to help here. DevRel is tricky within open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. since it’s typically going to have to be sponsored by a company, which then brings in bias and questions around motive for amplifying certain changes. At the same time, we need folks who are doing the outreach and engaging.

Motivation to adapt to changes

Part of what has to be considered is what the sell is to update things, especially if there aren’t clear benefits. This can be metered against having things in Site Health that informs users that plugins might not be doing their work to keep up to date. Having warnings could help encourage better practices and have folks address problems. The more we can make it visible, the more it will reinforce updating.

Deprecation strategies

The topic of deprecations came up: When we deprecate something, when does it get removed? We should look at timeframes for figuring out how best to handle and communicate. This can be tough for implementors and has been in the past when things are changing so fast. This came up when the 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/ plugin first came out and work was done to encourage folks to build with it while things were also changing so quickly. This led to some mistrust and frustration. We still have things from PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. from 0.7.1 that we deprecated but didn’t remove so this is a larger problem. Some inelegant solutions were thrown around before focusing back on the main topic of communicating and the Field Guide.

Documentation and Dev notes

Dev notes in general are rough to find and some of this could be improved with WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ website redesign. Dev notes should feed documentation that gets regularly updated and maintained. We talked about application passwords work where the info is only in a dev note rather than in docs and how that’s a problem. 

A more limited set of folks can write documentation places but it’s fairly open to write on the Make Network. For developers, it becomes easier to just do dev notes rather than helping with docs. The documentation team should be able to handle these doc updates from dev notes though. The docs team has a repo where you can create a ticket and they can handle changes, except for the block editor handbook which is handled on GitHub. In theory, a step could be just to create a GitHub issue of the dev note changes and have those docs updated.

Timeline of dev notes

We talked about how dev notes require submissions by a certain timeline but, in truth, things get done throughout the release sometimes as late as RC4. At the same time, dev notes are useful for comments/feedback and iterating on the messaging. If the updates were moved straight to docs, you would miss that engagement and opportunity to do better.

Next steps: 

  • Propose that the responsibility of docs lead could be to help ensure dev notes get into dev docs. 
  • Update dev notes after when docs are updated to help with SEO problems. 
  • Go through dev note tracking issue (example) in GitHub for priority/sense of breaking changes and explore the idea of having a dedicated “breaking changes” section in the Field Guide.
  • Explore the idea of two Field Guides: A hyper focused version with more curated info & a longer, more robust version. 
  • Do a theme author email similar to plugin author to communicate breaking changes. 
  • Re-think dev notes and see what can be evolved in the handbook since the first introduction. 
  • Create a pattern for dev notes to create more consistency and ease of writing. 
  • Ship dedicated developer blog post for breaking changes that get deeper into the changes. 

#summit, #summit-2023

david wolfpaw 7:03 pm on August 23, 2023
Tags: ,   

Community Summit Discussion Notes: Handling Trust & Safety (“T&S”) in the WordPress ecosystem: content moderation and sensitive content

From the session schedule:

WordPress has many community-led initiatives and directories with user-submitted content, like the Pattern Directory, the Photo Directory, Openverse, Themes, Plugins, and Support Forums. These areas hold user-submitted content, whether text or other media. However, each team has its own methods to evaluate its content, and its own moderation practices. This discussion aims to better understand current practices across teams towards establishing project-wide best practices and clear guidelines that prioritize safety and equitable moderation.

Facilitator: Kathryn Presner (@zoonini)

Notetaker: david wolfpaw (@wolfpaw)

Raw Notes

  • There are areas where users can submit media, and each team has protocols on how people moderate content. What are other teams doing, what can we learn for each other, and what are best practices that we can bring that are safe and equitable.
  • Openverse is a search engine for open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. media that is integrated in WordPress as of v6.2 to add content to blogs. It is an aggregator of creative commons licensed content. Openverse is an aggregator, unlike Photos team, where people upload things specifically
  • Having aggregated content makes it so that things are not consistent between platforms that are aggregated from. Do we use our own guidelines on how we moderate content that comes in.
  • Are there trust and safety courses on WordPress Learn? It is doubtful since it is a niche area of needs.
  • The community team has resources for de-escalation but there are not a lot specific to our community
  • Are there ways to report content from within WordPress – yes, there is in 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/, but what is the mechanism that is triggered when
  • Openverse comes across content that is sensitive in searches and reporting, and they are working on mechanisms to handle this
  • A lot of people who use Openverse are using it in an education context
  • It’s a difficult problem because you cannot apply a one-size-fits approach to moderation
  • If you pt that to one group of people, no one has all insight to things that are offensive in some cultures but not offensive to others.
  • There are legal restrictions in some countries that go against legal requirements in other countries
  • Openverse is in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., so the software is from a foundation based in the US, so do we have to legally comply with what other countries do?
  • Private companies like WordPress.com abide by US law when it comes to trust and safety issues
  • Sometimes outsourcing happens for moderation, and that includes for different cultures
  • If a country decides to 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. Openverse for not meeting their requirements, it is up to a website owner to determine to manage that accordingly when making their website
  • Some people say, “keep politics out of tech”, but there have to be defaults on some things, and we don’t know how to reach consensus on it, drawing a line in the sand as the WordPress project. It’s good to have options, but most people don’t change defaults.
  • Support has a bunch of things that could be useful for other teams. One thing is that every forum topic has a report this topic button, and people have to choose why to report a topic
  • previously you had to add “mod-look” to a forum to get into the queue of support
  • Content that can be marked as unsafe for everyone,
  • We can flag folks for mod-watch in forums, and they cannot post or make topics without being manually approved by moderators. Volunteers go through that queue to approve. This can be automated depending on what people type, such as “security vulnerability”, or spam checks on their profile and forum replies
  • Things like mature content are also not indexed from the forums so when you search for support it won’t come up top
  • There’s no prioritization on the queue by topic, just by chronological time of adding
  • People can also be moderated manually, with a flag on their posts to be pre-moderated
  • Notes can be left to review about users, and this can be used to unflag people
  • Teams like Support and Openverse could share their T&S guidelines with other teams, though a lot of them are case-specific.
  • We need to have language about calling something sensitive, and then the reasons that they are called sensitive, such as things that are “mature” or not.
  • Basing things on a blocklist can have cultural issues, like names and words that are commonplace or not sensitive in one location but are in others. For instance, the use of “nonce” in American tech culture, versus British English.
  • The sensitive terms list of Openverse is public as file for indexing and reference
  • We don’t obfuscate all content, but you can set limits for what is returned when you search for sensitive content. For instance, blurring search results for images of sensitive content unless you opt not to. We don’t want to stop what people search for, but providing consent on what you will see when you do a search. If you are looking for sensitive content and is relevant we want to acknowledge that while making the platform safe to use
  • Various different categories of sources for content to aggregate to OpenVverse, there are different levels of trust on content. So like in Gutenberg we don’t return searches for Flickr and Wikimedia, which are more akin to social media. They are still available on Openverse, but not in this context
  • In the theme and 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 space, there are some trust and safety issues that arise. For instance a plugin that was blown up and escalated overnight that was in support of the Russian war. It was a bigger deal than it might have been because there was no formal process for it.
  • Is there some form of record keeping of trust and safety related for when there are problems
  • The people who are most equipped to handle subtle problems with moderation are not always supported with things like mental health, and have to deal with the worst things
  • Doing trust and safety and moderation in a community level is quite different from doing it from a corporate level
  • There are opportunities to build a network to support people at a community level for mental health
  • Is there room for a Trust and Safety Make team that is cross-funtional with other Make teams on ensuring that they have support for this topic.
  • We would like to have someone pursue a cross-functional Make team, and getting sponsored volunteers for moderation.

#summit, #summit-2023

Ryan McCue 3:56 pm on August 24, 2023
Tags: security, , , wpscan   

Community Summit Discussion Notes: Building trust in WordPress CMS and plugin security

Community Summit Discussion Notes

Title of Session: Building trust in WordPress CMS and 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 security

Facilitator: Peter Wilson

Notetaker 1: Ryan McCue

Notetaker 2: Weston Ruter

Notetaker 3: Jason Coleman

Key Points

  • Communication of security practices:
    • Organization
      • The security page on WordPress.org needs to be refreshed with a clearer message – this will benefit WordPress from an external perspective, and can be a jumping off point internally too
      • This can point out to the various handbooks (security, plugin, theme, hosting)
      • The whitepaper is also heavily out-of-date and needs refreshing
    • WordPress as a project should be “owning” the security conversation, rather than leaving to third-parties
    • Documentation can be improved, but is “passive” – active communication (i.e. marketing) must also take place. Other teams (docs and marketing) are able and willing to help if the raw communication is available, and can share some of this communication burden.
  • Responsibility and ecosystem:
    • WordPress decided to provide plugin functionality, so must take responsibility for the security of it – we cannot say that this is the ecosystem’s problem alone to solve
    • The ecosystem is broader than just the .org repository, so security cannot be “controlled” through the repository alone
      • Tools such as scanners could potentially be built into WordPress itself, mirroring operating system virus scanners eg
      • A “safe mode” could be added to disable all plugins (eg), but this is often one of the first things to be bypassed – external tools (such as those operated by hosts) are likely to be a safer way to achieve this
    • Tools are available to the ecosystem (autoupdates via the plugin team, eg) but awareness of these is low. These are available for authors of non-trivial usage plugins (e.g. something like 20k+ installs would be a workable threshold)
    • Documentation exists around how to write secure code, but there isn’t sufficient or sufficiently-known documentation on procedure of how to deal with vulnerabilities, how to issue security releases, and how to communicate
      • Make it clear to ecosystem authors that vulnerabilities will happen, and destigmatize the process
      • A “what to do if your plugin has a vulnerability” guide could bring this information together
    • Documentation needs to be clearly findable and approachable for the ecosystem, and can tie in to the refreshed page

Action Items/Next Steps:

  • Refresh the .org security page
  • Refresh the security whitepaper
  • Write documentation on procedure for dealing with vulnerabilities

Raw Notes

Continue reading →

#security, #summit, #summit-2023, #wpscan

Weston Ruter 5:19 pm on August 23, 2023
Tags: gutenberg, ,   

Community Summit Discussion Notes: Addressing backwards compatibility in Gutenberg

From the schedule session:

This discussion aims to explore the challenge of backwards compatibility in 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/. and PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. APIs from the 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/ project into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Currently, there is little clarity around maintenance of backward compatibility across the project, resulting in confusion for developers and performance issues. There are two focus areas:

  1. Depreciating officially stable APIs that have been replaced
  2. Depreciating unstable, experimental, or internal APIs that have been shipped in WordPress.

Perspectives needed: Senior WordPress Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org./committers with deep knowledge of past lessons learned around backwards compatibility, Gutenberg contributors with working knowledge around processes and decision making.

Facilitator: Marius L. J. (@clorith)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: K. Adam White (@kadamwhite)

Continue reading →

#gutenberg, #summit, #summit-2023

Weston Ruter 10:03 pm on August 23, 2023
Tags: ,   

Community Summit Discussion Notes: Unifying development tooling for contribution

From the schedule session:

Today, the local development tooling for contribution to WordPress is fragmented. Contributors use tools such as VVV/Vagrant, Docker, and Playground, but each have limitations and may not be endorsed for contributions. Additionally, some tools require specific set ups, making it challenging for contributors to get started. This discussion will explore how we can unify tooling to provide clarity around recommended tooling and process for contributors.

Facilitator: Aaron Jorbin (@jorbin)

Notetaker 1: Weston Ruter (@westonruter)

Notetaker 2: Emma Sophie Young (@emmaht)

Continue reading →

#summit, #summit-2023