GDPR and privacy improvements to WordPress.org

As you might know, GDPR is coming, and the Meta team has been hard at work ensuring WordPress.org, WordCamp.org, and other hosted community sites are compliant with the new privacy and data handling requirements. We’re also making an effort to ensure that we go beyond the minimum standard set by GDPR, and ensure our retention of data and handling of privacy is in line with the expectations of the WordPress community.
Here’s a broad outline of what we’re planning on rolling out:

1. Subject Access Requests (SAR).

By filling in a form and authenticating your email address, you will be able to download a copy of all of the relevant data WordPress.org has stored about you. That will include things like:

  • The contents of your user profile.
  • Your favourites, ratings, and reviews.
  • Support forum activity.
  • SupportPress activity.
  • WordCamp.org activity, including attendance at WordCamps.
  • Submissions to other sites such as Rosetta, Showcase, etc.

2. Erasure.

By filling in a form and authenticating, regular users will be able to delete their accounts and all of the private data associated with it, with a few exceptions necessary for the ongoing stability of WordPress as a community project. Data deleted will include:

  • The contents of your user profile.
  • Favourites, ratings, and reviews.
  • Personal data held by WordCamp.org, such as shirt size and meal preference.
  • Personal data such as email addresses stored generally in non-critical tables such as comments.

Things not deleted will include:

  • Public posts and comments on make.wordpress.org, WordCamp.org and support forums. Your email address will be removed, but public content will remain.
  • Subversion commits, Trac tickets, and Trac comments.
  • Administrative records from WordCamp.org which must be retained for legal and financial reasons.
  • Themes, plugins, and showcase submissions. Your email address and any other personal details will be removed where possible.
  • Generally, content that has been made freely available to the public.

Deletion for most users will be self-service, with the final erasure and permanent account closure happening automatically a day or so after the request.

Significant users will not be able to delete their accounts and data without manual intervention. That means accounts with special access privileges, Subversion committers, plugin and theme authors, authors of Make WordPress blog posts and other content. These users will be asked to pass additional authentication steps, and confirm exactly what data they’re requesting to have deleted. Data that is necessary to the archives or historical records of the WordPress open source project will not be available for erasure.

3. Data retention.

We’re in the process of eliminating the storage and tracking of unnecessary data through a combination of means:

  • Erasing old and unnecessary data.
  • Anonymizing sensitive data.
  • Reducing the amount of data that we retain.

As part of this, we’re developing a new stats system that can record usage stats without storing any identifiable user data.

4. A new privacy policy.

The policy will describe what we do and don’t retain, and help ensure we’re meeting expectations. Users will be advised of cookie usage and changes to the privacy policy.

We’ve done our best to make sure that all Meta sites will be compliant with the GDPR. You can help us to make sure we’re keeping up with community expectations.

New About pages on all Rosetta sites

Thanks to the hard work of many contributors, the new WordPress.org About page is now available across the Rosetta network. This means the content is consistent, easily translatable and updateable – all local WordPress.org sites will have current content and information. Many thanks to the Polyglots who have been busy translating all the content.

We’ll be bringing further enhancements to all local sites soon.

Two Factor Authentication on WP.org

(Beta1). Based on the Two Factor plugin, a feature project for WordPress Core, a first trial version of 2FA is now available on WordPress.org. While it’s not in a state yet suitable for rollout across the network, it is ready to be tested by a subset of users—based on ease of segmentation that’s Core Committers and users that are Super Admins. During the testing period it is only in place on login.wordpress.org and does not yet protect other parts of the network such as SVN or Trac.

Since 2FA is part of account security, the UI to enable it will live in the support forum’s profile page. From there, users can enable and disable it, as well as generate backup codes (alongside updating their password to a more secure one, generated by their favorite password manager).

Two Factor Authentication on WordPress.org will use a Time-based One-time Password Algorithm as the primary authentication method. Popular apps for that method are Authy or Google Authenticator, which make it easy to manage multiple accounts that are 2FA enabled. Secondary methods (in case users don’t have access to their phone) will be via email, Slack (if 2FA is enabled there too), or printable backup codes.

All code is open-sourced and the work on this feature is trac’d in #77-meta, where you can follow along with the latest updates to this feature. In case there are not too many bugs uncovered during this first trial period, the current plan is to improve this enhancement over the next few weeks, and make it available to all users eventually.

+make.wordpress.org/core +make.wordpress.org/community +make.wordpress.org/test

New About page

@tellyworth, @dd32, and I compiled a list of the remaining tasks for #3046. To help with transparency and community feedback, I’ll repost those here as well.

  • New logo page redesign – implementation done this week (@obenland)
  • Navigation – decide on the design and implement (@obenland)
  • Enable main theme on w.org (@dd32)
  • Replace prefixed translation strings (@dd32)
  • Decide how to keep new pages in sync, and implement (@dd32)
  • Write a script to add pages to Rosetta sites (@dd32)
  • Back up old About page images (@dd32)
  • Find a way to add links to About page into main Rosetta navigation (@dd32)
  • Make sure navigation works for extra child pages on Rosetta sites (@dd32)
  • Decide on how to handle translated slugs, and implement (@dd32)

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

X-post: Marketing Support Request

X-post from +make.wordpress.org/marketing: Marketing Support Request

Enterprise Growth Council Meeting – January

The Enterprise Growth Council met for the second time on January 25th, 2018. (We previously met in December for an initial intros call but didn’t take notes). We’ll be meeting monthly going forward and will be posting notes here.

What is the Enterprise Growth Council?

Read Matt’s original introduction to the WP Growth Council from late 2016 and watch him talk about it again at WCUS in the State of the Word.

The Enterprise Growth Council is a group of representatives from several companies who are focused on marketing, delivering and using WordPress as an enterprise-grade CMS. We’re meeting monthly to share the work we’re each doing as well as discussing things we could do better as a community or via wordpress.org.

Current Council Members: @matt, Alexa Scordato (Stack Overflow), Anil Gupta (Multidots), Bradford Campeau-Laurion (Alley Interactive), Cameron Barrett (SchoolPresser), Chris Taylor (Automattic), Edd Hurst (Pragmatic), Jake Goldman (10up), Jason Cohen (WP Engine), John Eckman (10up), Nick Gernert (Automattic), Tom Willmot (Human Made). This may change week to week as people swap out or availability changes.

Meeting notes

  • Chris, Alexa and Matt also sit on the Consumer Growth Council and we started off with a quick catchup on the work they’re doing including discussions around:
    • Creating guides on .org for things like how to start a blog, app, shop, site, etc.
    • A directory of professionals that could help you with the above.
    • An SEO review (Wix is ranking above us for the term “create a blog”.
    • A separate group is going to split out to work on the broader brand strategy.
  • At this stage of the discussion, we have a lot more questions than answers.
  • We talked about the major competitors to WordPress in the enterprise space.
    • Adobe Experience Manager
    • Sitecore
    • Acquia / Drupal
    • Episerver (in Europe)
    • Contentful (Headless)
    • Arc (Washington Post)
    • The bespoke CMS
    • Umbraco
  • There is a challenge for us to decide whether we try to compete in the niches or whether we try to compete more generally.
  • At the moment we really don’t have much of an enterprise story on  WordPress.org.
    • We discussed potential first steps there including a wordpress.org/enterprise page, whitepaper and case study content etc.
  • We explored ideas we each had for initial projects we could tackle on the enterprise side.
    • We could contribute or collaborate on a selection of whitepapers.
    • Is there a place for generic enterprise case studies?
      • We weren’t in agreement as to whether there is specific value to having them on .org (lots already exist elsewhere). There was a sense that we already have this content and the issue is more to do with getting WordPress in front of the decision makers at large enterprise. We really need to step back and map out the buyer journey, what’re the sales funnels? How do buyers make decisions? At what point in the process is a case study (or whitepaper) useful, what are the other tactics that could help move that buyer forward?
      • We could potentially look to sanitise some enterprise RFP’s and build a library of common needs, questions, use cases etc.
      • We need to strike the right balance between tackling low hanging fruit and not getting trapped being too tactical vs strategic.
    • We also want to tackle the broader brand strategy and a sub-group agreed to own this and report back on the Feb call. It’s likely that we’ll want to coordinate with the consumer council as we get into things.
  • We discussed the different audiences that exist within Enterprise and that we’ll want to treat each of them as different buyer personas:
    • Developer (used WordPress, evangelises internally)
    • Marketing (CMO)
    • IT department (CTO)
    • Compliance (often a gatekeeper)
    • Likely others
  • We talked about the taxonomy, language, buzzwords of the enterprise CMS space. Does WordPress need to use them, are we a CMS or a Digital Experience Platform? Something to continue to discuss and explore.
    • WordPress is one part of a suite of products that deliver digital services/functionality
    • Should WordPress try to compete at that level or stick to the CMS
    • Jason explained WP Engine’s rationale for their use of “Digital Experience Platform” as a way to bring together all their various tools and services, one of which is WordPress Core under an umbrella term that they see being used in the industry.
    • Alexa felt that it’s not really a buzzword, but how marketing, sales, support think about their function and how they relate together.
    • The term “Digital Experience Platform” is about speaking to the fact that marketers or content creators now need lots of tools that cover all the aspects of their job. WordPress can only do some of these and requires lots of technical experience to build out the others. An all in one ecosystem makes it much easier for someone who doesn’t have a technical partner who can build all the integrations they need.
    • WordPress does have plugins or services in its ecosystem that can do the things a digital experience platform needs to do, how do we tell that story?
      • If we can collect the things together that serve those needs then we can list them on wordpress.org/enterprise
      • They also want someone to talk too, an account manager etc. Where do they get that.
      • We have a bunch of the constituent parts but we don’t tell a cohesive story that brings them together in a way that is discoverable.
      • We can distribute the work required to keep up with changes in the needs of the industry we’re serving by relying on the wider ecosystem of plugins to fill changing needs
    • Cameron would like to see a functionality matrix/table that breaks down which plugins or services fill which needs, we talked about this being a potential task we could tackle later.
    • We talked about how we could collaborate to agree on a set of “enterprise ready” plugins and services, perhaps as part of a path to core adoption or at least focusing community effort around a common set.

Action Items

  1. Tom is going to take a look at updating the WordPress Security Whitepaper.
  2. Alexa is going to lead a buyers journey/brand strategy workshop with Nick.
  3. Brad is going to have a go at wireframing or taking a look at a content strategy for a potential wordpress.org/enterprise page.
  4. We each going to inventory the content that we could contribute to wordpress.org, be that whitepapers, case studies, or anything else that seems relevant.

We’ll meet again on Feb 19th.

Agenda for WordCamp.org ticket scrub on January 16th

This bi-weekly WordCamp.org ticket scrub will happen on 2018-01-16 19:00 UTC in #meta-wordcamp.

The focus is on Meta tickets with the WordCamp Site & Plugins component.

Specific tickets

Other items?

Comment below if there’s any other ticket or topic you’d like to discuss.

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

#1097-meta, #3202-meta, #3283-meta

Recap of WordCamp.org ticket scrub on December 19th

#3309-meta

We talked through the details of a patch to prevent a WordCamp site’s RSS feeds from exposing content while the site is in Coming Soon mode. @casiepa is working on the patch.

#3259-meta

We clarified that the unique identifiers in the Feedback email subject lines should be the feedback post’s ID, rather than a random string. @casiepa is working on a patch.

#2720-meta

We discussed the problems with the Meetup API that are holding up progress on this ticket (maybe causing the issue in the first place?) We discovered that there is a related issue in the Meetup API GitHub repo.

Meta Environment updates

Thanks to @grapplerulrich, The Meta Environment has been updated to conform with the TLD restrictions recently implemented in most major browsers (.dev can no longer be used). So all of the sites in the Meta environment now use .test, which is what the rest of VVV now uses as well.

So, as a PSA, make sure you re-provision your Meta Environment! It might be a good opportunity to also pull the latest from VVV and just do a clean build of everything.

The next WordCamp.org Ticket Scrub meeting will be after the winter break, 2018-01-16 19:00 UTC, in #meta-wordcamp.

#recap #ticket-scrub #wordcamp

+make.wordpress.org/community

#2720-meta, #3259-meta, #3309-meta

Agenda for WordCamp.org ticket scrub on December 19th

This bi-weekly WordCamp.org ticket scrub will happen on 2017-12-19 19:00 UTC in #meta-wordcamp.

The focus is on Meta tickets with the WordCamp Site & Plugins component.

Information

  • Updates to Meta Environment

Specific tickets

Other items?

Comment below if there’s any other ticket or topic you’d like to discuss.

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

#1097-meta, #3111-meta, #3202-meta, #3259-meta