The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.
TL;DR: FLoC places people in groups based on their browsing habits to target advertising.
Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.
This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.
So What Now?
WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with a few lines of codeLines of CodeLines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses.:
Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.
Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.
What Do You Mean By “Treat It Like A Security Concern”?
Include the patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. the next minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., rather than waiting for the next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.;
Back-port the patch to previous versions of WordPress.
Why Treat It That Way? Why Not Just Wait For The Next Major Release?
Well, keep your eyes peeled, because there is a ticketticketCreated for both bug reports and feature development on the bug tracker. for future releases on its way!
While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.
Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.
Request For Comment
Please join the discussion below!
Whether want to show support, disagree vehemently, or just want to make the implementation the best that it can possibly be, please have your voice be heard.
I’m aware that there is a lot of discussion on other platforms, including Twitter on this matter, but we won’t see all of it, so in addition to spreading the conversation there, please comment here too, so that it can be considered when this is discussed at development meetings and when the ticket is created (consensus building first – and that is done here 😉 )
YOU DO NOT HAVE TO BE A DEVELOPER TO PARTICIPATE. There will be a ticket on core.trac.wordpress.orgWordPress.orgThe 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/ where we will discuss all of the technical stuff. I’m tremendously grateful that there are so many developers, Core, MetaMetaMeta 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. and others, around, but blogblog(versus network, site) posts on make.wordpress.org are the places that are accessible to techies and non-techies alike 🙂
Version Control:
1. Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).
2. Code snippet updated based on suggestions below. Thank you to Tom for the snippet and to everyone who suggested conditionally appending, rather than replacing.
Added some more info to the Request for Comment.
The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-privacy team are currently working on three modular, but complementary initiatives, with the aim of merging into 5.6. These are: The Consent APIAPIAn 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. (website visitor level privacy); the Disclosures Tab (site-level privacy) and collaborating with the core-media team on the Local AvatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Project.
The Consent API in its current form does not distinguish between consent preferences for users who are registered and logged in, vs. those who are either not registered, or registered, but not logged in. This means that all consent preferences are currently saved in cookies.
This means that there are two approaches available to the team. Either we can use the wp_set_consent() function from the user’s profile page to allow them to manage their preferences and prevent unnecessary API calls (proposal 1 – status quo), or we can let the database be the ultimate source of truth to provide a more robust API, rather than an interface for an analytics opt-out (proposal 2).
There has been a lot of discussion in the channel lately. I will post a separate P2P2A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. post for discussions such as prompting logged in users who previously opted in for consent again if new cookies are added – or at the very least least providing the necessary hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and filters for plugins to do so. Those are concerns can be realistically and effectively addressed in the UIUIUser interface design requirements.
This is a fundamental design choice and while the window is wide open now, it will not remain so for long, as 5.6. approaches. For purposes of this discussion, we please need input on the following, so that we can take the matter to dev chat: 1. Should consent preferences for registered users (applicable when logged in) be saved in cookies, or should they be saved in the database? If consent preferences are saved in cookies, these could be displayed (and updated) in the user profile, but the choice would be transient and would effectively need to revert to site defaults every time the cookie is cleared. 2. If they are saved in the database, should the REST APIREST APIThe 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/. be used to expose the logged in user’s consent preference on the front end? 3. If the REST API is used, should a new REST endpoint be created, or should register_meta() be used instead? 4. Should the consent preference be exposed on the front end using wp.data? The trade-off being that this provides nicer abstraction and makes it easier to move towards object-oriented, rather than event-orientated programming, but adds a few KB to the front-end? 5. If wp.data is used, should only this be used, or should the consent preference still be exposed to the front end by a method in point 3?
Thank you for everyone who has participated in this discussion on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. so far. I intentionally did not include who made which proposals for this P2 post, in order to focus on the merits of the alternative solutions, but will credit participants in tickets if those need to be created. Participants in the Slack discussion are of course very welcome to express their opinions here! 😀
The Consent APIAPIAn 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.:
The Consent API is the oldest of the privacy initiatives currently under active development, not yet merged into CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. It was created in response to the following ticketticketCreated for both bug reports and feature development on the bug tracker.: https://core.trac.wordpress.org/ticket/44043 (Framework for logging/retrieving a user’s consent state) The proposed feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. can be found here: https://wordpress.org/plugins/wp-consent-api/ The code is extremely light-weight (13KB, excluding the readme.txt and the licence). The Consent API could greatly benefit from a wp_set_cookie(); function in WordPress Core, which would make adoption by pluginPluginA 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 and theme developers more likely than the current has_consent(‘type’) approach. These two items have natural synergies and would do well scoped together. In its current form, the Consent API does not have any User Interface. However, it would be more valuable to allow registered users to save their consent (functional, preferences, anonymous statistics, statistics and marketing) more permanently under their profile page for when they are logged in. There could also be settings for whether or not to make the profile visible to search engines, etc. Logged out users, or users who are not signed up for an account, would not have a UIUIUser interface in Core, but instead their UI would be provided via a cookie banner or comprehensive consent management plugin.
The Disclosures Tab:
The Disclosures Tab is intended to aggregate the information collected from individual disclosures.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. files in individual plugins, themes and Core. Compiling a disclosures.json file for Core would be a significant undertaking, as, among other things, it is intended to disclose any external references (calls to other sites, available APIs, feeds, etc.) The intention of the tab is to help site owners and admins to understand what information their site collects, where it is stored and where it is sent. This will help site owners / admins to make more informed privacy-related choices and understand their privacy risk profile. Any actual “controlling” (the Permissions Tab) is likely more suited as an optional plugin. The Disclosures tab would require creating a JSON schema and writing a function (first in a plugin and then in core) to validate the schema. The UI would most likely exist as a new tab under the Settings tab.
Enter the Local AvatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Project:
CNDs have privacy considerations in that, at least in theory, it is possible for the CDN to track users across sites. Some CDNs do use data obtained this way as a source of marketing analytics data. Furthermore, the hashing that is used can be brute-forced, which may lead to unwanted disclosures of someone’s identity.
The Local Avatar Project has tremendous value as a case study in best practices. Avatars are a highly relatable way to explain complex privacy concepts to users and developers like. Furthermore, it has tremendous persuasive potential for achieving developer buy-in, as a common refrain includes “But avatars do the same thing!”
The UI for registered users would be located on the user’s profile page. This UI would allow a registered user to upload an avatar (and could be extended by plugin to allow for more options, like selecting from a pre-set). The UI for authorized users would be located as a new tab under the Media tab. The UI for site-level settings would be located where the avatar settings are currently located, as this would most likely be the most intuitive for users.
Vision:
Each of the above projects can be developed in a modal way in order to achieve a cohesive privacy-by-design vision. This would require distinct, but complimentary education drives for developers and for site owners / admins.
@paaljoachim has asked what the UI needs to look like for a Privacy screen in Core. You can read the conversation here: https://wordpress.slack.com/archives/C9695RJBW/p1597418745430800 (a Slack account is needed)
Site-level privacy Initiatives: 1.) Disclosures and Permissions Tab; 2.) Local AvatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Project (in collaboration with the #core-media team)
The DPT would require writing a JSONJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. schema, as well as a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. function to validate it (hopefully in collaboration with the #core-restapi team). The UIUIUser interface would most likely be under Settings -> Privacy. This interface should help site owners / admins understand what information their site collects (by means of individual plugins, themes, as well as Core), where it is stored and where it is sent. Ideally, this would provide a mechanism for the site owner to prevent data from being transmitted off-site / make choices with regards to third party access.
Part of the Local Avatar Project would overlap with site-level privacy in the following areas: Settings, Permissions and Library. There is currently still a discussion as to whether a fully-fledged library is needed (defined as that image metaMetaMeta 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.-data needs to be edit-able).
Website-visitor level privacy Initiatives: 1.) Consent APIAPIAn 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.; 2.) Local Avatar User Upload Screen
The Consent API in its current form is not intended to have any UI. This is due to the fact that website visitors who are not registered / not logged in still need to be able to exercise privacy choices. However, it may be nice to allow logged-in users to save their privacy choices on a more permanent basis, perhaps by making use of user_meta. In this case, there would need to be a UI on the user’s profile screen to support this. There would presumably still be no UI for users who are not logged in. A UI could be provided by means of a consent management pluginPluginA 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.
Additionally, the Team needs to discuss which filters / functions may be necessary in Core in order to convert the Consent API feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. into a more fully-fledged API, e.g. wp_set_cookie();
Part of the Local Avatar Project would overlap with website-visitor level privacy. This would mainly be in the following area(s): User Profiles. For example, users may want to indicate that they do not wish for their avatars to be indexed by search engines.
Please join us for this week’s office hours to discuss what these solutions may look like!
The Difficulty:GutenbergGutenbergThe 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/ development happens on GitHubGitHubGitHub 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/, instead of on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (which allows for “needs-privacy-review” to be added to the workflow of any ticketticketCreated for both bug reports and feature development on the bug tracker.). This makes it very difficult for other teams to keep up with changes that have a potential significant impact on their team. The Gutenberg repository is huge and it is simply not possible for those working on smaller teams to keep up with all issues / PRs while trying to run their own teams and dealing with other responsibilities.
Other Solutions We Have Considered: We have considered subscribing the #core-privacy channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to GitHub. The rest-api channel did this, but it leads to some flooding and does not work when labels are added later on (which would usually be the case with privacy).
So What Do We DO? All triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. volunteers on the Gutenberg repository on GitHub should please consider whether a particular issue touches on any of the following. If it does, the issue should not proceed / the PR should not be committed, before the Privacy team has been given a meaningful opportunity to consult. If you find such an issue, please post a link here, so we can have a look. Please also make use of the #core-privacy channel on Slack if you need our help. We rely on the Gutenberg triage volunteers’ assistance in this matter.
Issues / PRs that are considered to affect privacy:
1. If the issue / PR suggests that an external call should be made from the site owners’ WordPress installation to any other external site (whether PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher / JavaScriptJavaScriptJavaScript 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/. / CSSCSSCascading Style Sheets.), even if this site is WordPress.orgWordPress.orgThe 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/;
2. If an account with a third party would be needed in order to utilize any functionality (basically SaaS – I do not expect that this is likely to happen, but I am including it here for the sake of completeness);
3. Calls to any APIs (including, but not limited to calls to external APIs for the purposes of updates);
4. Use of any remote assets (e.g. images / JavaScript libraries / fonts hosted elsewhere);
5. Any cookies are proposed / use of local browser storage, or similar;
6. If the editor proposes to write any information to the DB (other than content like posts explicitly generated by the user);
7. If new Custom Post Types are proposed;
8. If new custom tables are proposed;
9. If any PPI (Protected Personal Information) may be stored;
10. If any e-mails will be sent by the code;
11. If there will be any advertisements in wp-adminadmin(and super admin) (again, not something I think is likely, just including it for completeness);
12. If any backlinks are requested (again, probably unlikely for Gutenberg).
Please also report any items not listed here, which you think may affect the privacy component.
Thank you for your co-operation and transparency in this matter.
There will be two working groups: – Coding working group (coordinated by @garrett-eclipse); – Non-coding working group (coordinated by @carike).
Pre-event office hours:
– 3 June 2020 at 10:00 UTC; – 3 June 2020 at 19:00 UTC.
Pre-event office hours are to help onboard new contributors. This primarily involves making sure that they have access to the tools necessary for the day.
StreamYard: Privacy Policy: https://streamyard.com/resources/docs/privacy/ Terms of Service: https://streamyard.com/resources/docs/tos/ We will be using StreamYard, as a number of experienced contributors in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-privacy have expressed an unwillingness to use Zoom due to privacy considerations.
Core TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (coding working group): Privacy Policy: https://wordpress.org/about/privacy/
GitHubGitHubGitHub 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/ (coding working group): Privacy Policy: https://help.github.com/en/github/site-policy/github-privacy-statement Terms of Service: https://help.github.com/en/github/site-policy/github-terms-of-service
How to participate:
As a host: If you are interested in hosting one or more topics, please comment below. You can contact @carike on Slack if you would like more information.
As a guest via StreamYard: You DO NOT need to register a StreamYard account in order to enter the stream as a guest. You DO NOT need to download any program in order to use StreamYard. It is an in-browser solution. You DO NOT need to appear on-screen if that is not something you are comfortable with. An audio-only option is available. We’re going to be using a very practical approach, so I’m going to be screen-sharing most of the time anyway. We will provide new contributors with instructions on joining StreamYard as a guest via e-mail. Instructions can also be found here: Guest Instructions: https://streamyard.com/resources/docs/guest-instructions/ We will provide new contributors with a link to join the stream via Direct Message (DM) on Slack, as there can only be six contributors “onscreen” (or via audio) at any one time (i.e. two hosts and four new contributors), with up to four additional new contributors in the “waiting room”.
As a guest via YouTube: You DO NOT need to register an account with YouTube in order to watch the stream. You DO need to register an account and be logged in to YouTube in order to participate in the live chat. StreamYard supports integrating live chat messages from YouTube. This will allow for more real-time input and also allow participation among those who do not want to use audio, or appear onscreen. We are trying to recruit experienced contributors to help moderate the YouTube live chat to ensure compliance with the WCEU Code of Conduct, as well as to highlight any questions, comments and suggestions to the hosts. Please comment below if you are able to help with YouTube live chat moderation. You can find a copy of the WordCampWordCampWordCamps 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. Europe Online 2020 here: https://2020.europe.wordcamp.org/code-of-conduct/
Via Trac (coding working group): You DO need to register an account with WordPress.orgWordPress.orgThe 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/ in order to comment on Trac tickets.
Via GitHub (coding working group): You DO need to register an account with GitHub in order to create / comment on issues or to create / comment on Pull Requests (PRs).
On the day:
Coding working group:
13:00 – 16:00 UTC (coding working group) Garrett will be available on Slack during this time.
The coding working group will participate via Slack, Core Trac and GitHub. @garrett-eclipse is going through the list of privacy-related tickets to mark them with the “good first bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.” tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) where applicable. For the more adventurous, there is the option to contribute to “help wanted” tickets for the next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. (WordPress 5.5.). An overview of current privacy tickets can be found here: https://make.wordpress.org/core/components/privacy/
Non-coding working group:
The non-coding working group will have two two-hour sessions.
13:30 – 15:00 UTC How to market without destroying user privacy (working title only). Hosts: @carike and @jonoaldersonwp During this session, we hope to identify online marketing best-practices that can be implemented even when users have opted-out (or not opted-in, depending on the jurisdiction) to being tracked with the view of creating actionable Trac tickets and / or to provide a resource for content marketing. Topics will include: – What is informed consent in a marketing context? – Which digital marketing strategies were employed pre-the-ability-to-track-across-platforms and how may we able to adapt these? – Which data points may still remain available for analytics if a user opts out of / does not opt in to the collection of their PPI. Jono is “special ops” at Yoast SEO and we are very excited to have him participate.
16:00 – 18:00 UTC A case study in the application of the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs. Hosts: @carike and @pepe In this session, we will be attempting to harmonize the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs and apply them practically to the WP Job Manager pluginPluginA 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. The desired outcome for this session is an action plan for an education drive among plugin and theme authors regarding the proposed disclosures.json file. Pepe has previously presented at WordCamp, is very involved with the #core-privacy team and was helped to create the draft Privacy Workflow Document. His insight will be invaluable to this session.
You can view the Slack logs here: https://wordpress.slack.com/archives/C9695RJBW/p1589396619341400 In order to view the logs, you will first need a WordPress.org account: https://login.wordpress.org/register You will then need to register a Slack account: https://make.wordpress.org/chat/
Change log: 14 May 2020 at 14:15 UTC – @carike added GitHub information. 14 May 2020 at 17:45 UTC – @carike updated formatting in the Slack links. 16 May 2020 at 11:35 UTC – @carike switched out the non-coding session starting at 16:00 UTC, as Pepe has agreed to co-host. 18 May 2020 at 18:05 UTC – @carike added the times Garrett will be available on Contributor Day. 1 June 2020 at 13:55 UTC – @carike changed the start time for the first non-coding session in order to accommodate the WCEU introductions. 3 June 2020 at 19:40 UTC – @carike added details for the workgroup sessions and removed the third session.
