Applications

La Distribution

WordCamps are informal, community-organized events that are put together by a team of local WordPress users who have a passion for growing their communities. They are born out of active WordPress meetup groups that meet regularly and are able to host an annual WordCamp event. This has worked very well in many communities, with over 120 WordCamps being hosted around the world in 2017.

Sometimes though, passionate and enthusiastic community members can’t pull together enough people in their community to make a WordCamp happen. To address this, we introduced the WordCamp Incubator program in 2016.

The goal of the incubator program is to help spread WordPress to underserved areas by providing more significant organizing support for their first WordCamp event. In 2016, members of the global community team worked with volunteers in three cities — Denpasar, Harare and Medellín — giving direct, hands-on assistance in making local WordCamps possible. All three of these WordCamp incubators were a great success, so we're bringing the incubator program back for 2018.

Where should the next WordCamp incubators be? If you have always wanted a WordCamp in your city but haven’t been able to get a community started, this is a great opportunity. We will be taking applications for the next few weeks, then will get in touch with everyone who applied to discuss the possibilities. We will announce the chosen cities by the end of March.

To apply, fill in the application by March 15, 2018. You don’t need to have any specific information handy, it’s just a form to let us know you’re interested. You can apply to nominate your city even if you don’t want to be the main organizer, but for this to work well we will need local liaisons and volunteers, so please only nominate cities where you live or work so that we have at least one local connection to begin.

This is a proposed roadmap for adding privacy tools to core. The plan is to finalize it at the next #gdpr-compliance chat in Slack.

Main goal

Add tools to help site owners comply with the GDPR and other privacy laws and requirements.

Add notices for both registered users and commenters on what data is collected in core by default, and why.

Shorter texts in core with links to more information. Needs text.

Create these “more information” pages on WordPress.org. Needs text.

Create some guidelines for plugins on how to get compliant.

A page (or several pages) on WordPress.org. Needs text.

Add tools to core to facilitate compliance, and privacy in general.

There are few plugins that have started implementing these tools, so we have a nice head start.

The requests to see, download and delete/anonymize private data have to be with a confirmation (double opt-in) to avoid misuse. One possible solution would be to send a token by email when a user or a commenter has requested access to or deletion/anonymization of their private data. Then they will have to submit that token as a confirmation of their request.

TBD: shall we make this process automatic or should a site owner perform the action upon receiving the confirmed request?

For commenters. The stored private data is emails and IP addresses, the rest is public.

Dialog for requesting to see and download their private data.TBD: should that data also contain the public portion?

Dialog for requesting deletion/anonymization of the data.TBD: Deletion or anonymization? Or both and let the site owner decide?

Ask for consensus for storing commenter cookies. This can be a (checked) checkbox under the comments form, something like “Save my name, email and site URL in my browser for next time I post a comment. More information”.

For registered users. All of the data stored by default is already visible in the user profile (except IP addresses if they have commented on the site), and most can be edited or deleted from there.

Button for downloading their private data, including IP addresses if they have commented. Again, should that also contain the public data?

Button for requesting deletion/anonymization of their account.

Add documentation/help for site owners on how to use these tools.

This should probably be another page under the Tools menu and contain short explanation of what privacy tools are available and how to use them. It could also contain the actual tools, for example an input field for anonymizing commenters by email address.

There are a few things that need clarification:

IP addresses may be considered personal data so they need to be deleted or anonymized. However do they need to be sent to the user when requesting to see or download their personal data? They are essentially third-party tokens used temporarily to access the Internet and the users have no control over them. Do other websites make them available?

Who are considered “controllers”? All admins on single install and all superadmins on multisite? Are admins on multisite controllers for their own site?

Please post your suggestions in comments so we can finalize the roadmap at the next #gdpr-compliance chat on Wednesday. Thanks @casiepa for helping with this!

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 15, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Gutenberg

Add block playlist: A discussion took place around how mediaElement should be added to Gutenberg. The two options discussed were to include it in the npm package list or make a global instance of Core's mediaElement Library. Consensus was to go with Core's implementation. @antpb is blocked on the playlist block with lack of mediaElement component. He is working on building a mediaElement REACT component that will need to be utilized in the audio and video blocks. Before this is complete enough to merge, he'll need some help understanding how to make the Core library globally accessible in Gutenberg.

5.0 Tickets

Discussion around how granular gallery filters should be. With #3379 we gain a filter to add styles individually per item in the Gallery. It was discussed that we will need tickets to add more granular filters going forward for captions and other image attributes. From @desrosj : "Currently the shortcode builds the HTML string as it goes. I think if the attributes were built in an associative array, that could just be filtered, and then the element built at the end. That could allow additional attributes to be added, widths to be changed for specific images making it easier to do different grid layouts." This sparked the question above around how Gutenberg will handle backwards compatibility with filtered attributes.

Next Meeting

This belated release brings support for nested blocks into Gutenberg. The list of changes is rather big, so it's broken up into sections. It also has a new Columns block that leverages nested blocks to operate — it is labeled experimental, though, as it needs further work and has some browser hiccups.

Most notably to the user experience, we are introducing block shortcuts on empty paragraph blocks to streamline the process of inserting content that is not text, while also optimizing for the writing experience. The global inserter, featured at the top of the editor, is meant to become more of a primary way to add content when the user is not writing. Getting this balance right between block creation and the writing flow is crucial and we'll continue testing with users to refine it.

We are also making changes to how text is synced to the application state, which improves the reliability of the "unsaved" state, the undo mechanism, the ability to dismiss the publish sidebar automatically as soon as you make another edit, and so on.

2.2

Highlights

Block Nesting is live! It comes with an experimental Columns block. (Note: converting a nested block into a reusable block is disabled on this first version.) Furthermore, this is not a specific implementation for columns alone — any block author can take advantage of defining nested areas.

Refined block insertion experience:

Introduce block shortcuts on every empty paragraph block. This also temporarily disables the sibling inserter as we work on refining this interaction.

New features

Support unwrapped paragraph text via native block deprecation mechanism. (Ensures paragraphs without p tags are correctly interpreted.) Also readdresses code that was applying autop selectively on the server for posts made with gutenberg as it is handled at the block level when needed.

This first GDPR Compliance Chat started by people introducing themselves. There was a nice mix of core comitters, developers, lawyers (or law-lovers), contributors, trainers, project managers, testers, people enrolled in privacy roles in companies, etc.

The main question was what is personal data and where it is stored. Most of it might be in user_meta, but there is personal data everywhere!

For the exporting part, all data needs to be considered, so probably also from all privacy impacting plugins.

What does the web owner need to do? And what part can WordPress Core take care of?

Proposal for a new column (is_personal_data) in all tables to indicate clearly the personal data, but of course data could be serialized and contain both. So interfaces and hooks might be a better way to go.

Could some developers share what privacy impacting data some of their own plugins collect and see if a pattern emerges?

Data stored on backups have to be deleted too.

Is a public post "personal data" if the user posted something that is considered personal? So how far is deletion inside posts needed? And what about quotes?

For plugins: a Privacy Impact Assessment is required by the GDPR for data intensive projects. It would be nice to get a tab in the plugin repo noting every plugin's data flows, including collection, retention, cookies, telemetry.

Updates from focus leads and component maintainers

The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.

The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.

Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

Questions or comments about the meeting? Topics you would like to request be covered? Want to help out with this meeting? Any other feedback? Feel free to post in the comments below or reach out to one of the moderators on Slack. We hope to see you there!