Revised suggested roadmap for Gutenberg and Customization

Gutenberg is about to reach a milestone of having the technical and design vision in place. I know that we’re a little off from the existing roadmap, so I’d like to suggest an update to the milestones going forward.

The milestones below are based on information from the focus leads about who will be available and when. As with all things in open source, these are best guesses and I encourage everyone to join us in being flexible as we keep creating:

  • Aug 2017 (late): Technical and design vision complete, iteration begins. This is in progress.
  • Aug 2017 (late): Testing plan begins: this will start with a public meeting.
  • Aug 2017 (late): Promotional page goes live for Gutenberg. This is in progress.
  • Sep 2017: Potential *.1 release with banner to encourage use of and feedback for Gutenberg
  • Nov 2017: 4.9 release
  • Dec 2017: Begin merge proposal for Gutenberg
  • Jan 2018: Gutenberg —> Customizer crossover (switching the focus)

It should be clear this is not set in stone. Gutenberg is not ready to merge and as a result giving it this time is important to iterate and respond to feedback. Beyond the merge proposal it’s also difficult to predict, so the roadmap to 5.0 isn’t being predicted here, that will depend on the proposal.

#gutenberg

Dev Chat Summary: August 9th (4.9 week 2)

This post summarizes the dev chat meeting from August 9th (agendaSlack archive).

4.8.1 release feedback

  • Forums team hasn’t had to update the “4.8 Master List” post with any problems, a relatively smooth release altogether
  • No concerns identified that would require a subsequent immediate minor release

4.9 goals

  • @melchoyce and @westonruter have assembled a list 4.9 goals
  • @kadamwhite would like to see movement on REST API backlog tickets, specifically meta registration for object subtypes (#38323) and media permissions (#41445)
  • REST API roadmap document still being assembled, but not yet published
  • “Updating a plugin or theme via a ZIP file” and “drag and drop uploading of themes and plugins” are going to need support from contributors to the Upgrade/Install component
  • If you have interest in helping maintain the Upgrade/Install component (or any others) please reach out to @drewapicture

General announcements

#4-8, #4-8-1, #4-9, #dev-chat, #summary, #translation

New Contributors Meeting Recap – August 2nd

Yesterday, the new weekly contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @asalce @azerial @chetan200891 @circlecube @clorith @desrosj @dipeshkakadiya @dnavarrojr @e_baker @helen @jdmensing @johnbillion @jorbin @josiahsprague @joyously @kelseyfecho @linsoftware @luckyankit @milindmore22 @mte90 @nabil_kadimi @proscriptsell @punit5658 @stevenkword @t-rave @welcher @zakkath

Discussion Highlights

Before Creating Tickets

  • Before creating a ticket, there are a few things you should do:
    • Ensure you are running the latest version of WordPress (if reporting a bug).
    • Search Trac to make sure a ticket for your bug or enhancement.
  • Creating a duplicate ticket is ok, as long as you did your best to find a pre-existing ticket.

Writing a Title

  • A good ticket title should accurately summarize the problem the ticket addresses.
  • Someone should be able to see the title and get the general idea of what the ticket is trying to solve, not the solution.

Writing a Description

  • A ticket description should include:
    • A description of the behavior you expect and why
    • A description of the behavior you are seeing
    • Steps to reproduce the behavior so other contributors can see it for themselves and track down the source.
    • If an enhancement ticket, describe what it improves upon and why this is beneficial.
  • If it involves something else (like a specific browser, or server type), make sure to detail that as well.
  • If applicable, screenshots are also very helpful.
    • Screenshots are best uploaded directly to Trac. This prevents images from becoming dead links when removed from external image sources.
  • Always try to focus on the problems being solved, even if it’s an enhancement, you are trying to solve a problem of some sort.

Examples of tickets with good titles and descriptions: #41525, #37013.

What is the difference between Core and Meta Trac?

Core Trac is meant for tickets relating to the WordPress software you install and run (including unit tests). Meta Trac is meant for a bunch of other things, but mainly things that are WordPress.org related. There is a full list at the top of the Meta Trac home page.

Security Vulnerabilities

It is very important that any issues with security implications be reported through responsible disclosure privately. For more information on reporting security vulnerabilities, see the WordPress Handbook.

What is considered “enough testing”?

  • This will vary based on the ticket and what problem is being solved.
  • Testing may span multiple releases for complex problems.
  • It also is up to the committer that chooses to take ownership of the ticket. They need to be completely comfortable with the change, and confident that there is little to no potential for issues.
  • Once committed, the testing does not end. Testing continues by using trunk.
  • After that, the alpha, beta, and RC releases are in place to catch anything that might have been missed.

Is there a protocol for old tickets that have become stagnant?

  • Check that the problem or enhancement in the ticket is still relevant.
  • Test any patches on the ticket to ensure they still apply cleanly.
  • Test that the patch still solves the issue.
  • Add the needs-refresh tag if not.
  • Stagnant tickets can be frustrating, but remember, no one is purposefully ignoring your efforts. Most (if not all) of the folks here are volunteers working in their free time.

Tickets discussed

  • #39535 – Canonical redirects disallow tag named comments
  • #37057 – Creation of an esc_html functions for _n(), _nx(), _ex(), and number_format_i18n()
  • #41521 – Menu list with dropdown icon alignment bug in responsive.
  • #41497 – Menu has style problem in listing on admin menu page

Next Week’s Meeting

The next meeting will take place in the #core slack channel on Wednesday, August 9, 19:00 UTC. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @stevenkword, @welcher) with questions on Slack.

#new-contributors, #summary

Dev Chat Summary: August 2nd (4.9 week 1)

This post summarizes the dev chat meeting from August 2nd (agendaSlack archive).

4.8.1 RC2 feedback & planned release post-devchat

  • 4.8.1 includes fixes for the text widget, delayed yesterday due to performance issues identified
  • 4.8.1RC2 on WordPress.com stable, no longer experiencing the performance issues
  • No noticeable feedback in the forums regarding the text widget changes, Trac has been quiet in the widgets component
  • #41373 reported against 4.8, doesn’t seem to be a new regression introduced by 4.8.1 or a blocker
  • No concerns with the plan to release 4.8.1 after devchat

4.9 kickoff

  • 4.9 release schedule page is available, with particular highlights:
    • WordPress 4.9 will be the second “major” release of 2017 with the theme of editing code, managing plugins and themes, a user-centric way to customize a site, and polishing some recently added features over this last year.
    • October 4, 2017 is Beta 1 and feature project merge deadline.
    • October 30, 2017 is Release candidate and soft string freeze.
    • November 14, 2017 is 🎶 Target date for release of WordPress 4.9. 🎶
    • @melchoyce and @westonruter are co-Release Leads. 🎉
  • Updated set of goals for the 4.9 release and updates to the stale Customize component page coming soon (but first, release 4.8.1)

Editor / Gutenberg updates

Call for Component Maintainers

  • @drewapicture completed annual audit of Component Maintainers, some areas where new maintainers could be useful
  • The list on Make/Core reflects the most current list of maintainers
  • Please reach out if you’re interested in becoming a component maintainer

General announcements

  • @jorbin: submissions open for Kim Parsell Memorial Scholarship for WordCamp US
    • WordPress Foundation gives out a scholarship that covers the cost of hotel, transportation and a ticket for WordCamp US
    • Must be: person who self-identifies as female, active contributor to WordPress via a contributor team or a local meetup or WordCamp organizer, has financial need, and has never attended WordCamp US
    • No age limit on this scholarship, though older women are especially encouraged to apply
    • If you fit the requirements, please apply. If you know someone that qualifies, please encourage them to apply.

#4-8, #4-8-1, #4-9, #components, #core-editor, #core-restapi, #dev-chat, #gutenberg, #maintainership, #summary, #wordcamp

Dev Chat Summary: June 21st (4.8.1 week 1)

This post summarizes the dev chat meeting from June 21st (agendaSlack archive).

4.9 ideas and brainstorm

  • No immediate 4.9 timeframe, but the planned timing for 4.9 will come shortly after we confirm the major focuses of 4.9 and will be closer to 3 months than 9 months in duration
  • @jorbin: Scheduled customizer changesets going live could be a big win
  • @westonruter: adding statuses for changesets: being able to draft a changeset to come back to later, and then to be able to schedule it to go live.
  • @youknowriad: We have some REST API needs in Gutenberg:
    • Retrieving The permalink using the API (making more things available from wp-json/wp/v2/settings)
    • An API endpoint to save/get random settings (we’d use it to save some layout options)
  • @androb: Expanding link boundary behavior in TinyMCE to other inline elements
  • @androb: TinyMCE has a new mobile-optimized UX that will also result in a responsive toolbar, this should land in the 4.9 time frame
  • @androd: tweak the TinyMCE UI to be closer to Gutenberg (e.g. toolbar color, default font) to get users used to the Gutenberg UI before releasing that in WordPress 5.0
  • @saracannon: look at customizer revisions in a way that we might want to look at Gutenberg revisions in the future from a visual standpoint and start making progress there (@melchoyce: see mockup for customizer revisions on #21666)
  • @melchoyce: code editing improvements across core — CSS editing, the plugin/theme code editor, etc. Making it better to use and harder to mess up and break your site (see #31779)
    • @clorith: As soon as we do this, we need to handle the issue of lacking forked plugins, lacking child theming etc
    • @westonruter: add a warning to encourage people to be aware of the dangers of editing code without version control (see #41078)
  • @melchoyce: evisions for everything – Customizer revisions, page/post revisions, code editor revisions…
  • @hugobaeta: reduce the amount of declared colors (namely shades of gray) in the admin, more info on codepen and a little backstory on this flash talk at WCUS last year
  • @melchoyce: some in-progress tickets for improving theme switching: #39692, #39693
  • @melchoyce: also Customizer menu improvement – #40104
  • @melchoyce: automated testing in place for theme switching (@netweb to work on this)
  • @melchoyce: making “page on front” less confusing (again)
    • @westonruter: harmonizing with menus and page hierarchies. Merging those concepts together
  • @melchoyce: finish the gallery widget (@m1tk00 to work on this)

4.8.1 agenda

  • @westonruter: resolve text widget removing code issue (see #40951) alongside implementing HTML code widget (see #40907), three options proposed, one recommended
  • a11y bug-scrub will happen next Monday, will focus on 4.8.1 milestoned tickets
  • approaching 4.8.1 tickets as more traditional regression types of issues
  • Tentative timeline for 4.8.1 last week of July

#4-8, #4-8-1, #4-9, #core, #dev-chat, #summary

Dev Chat Summary: June 7th (4.8 week 6)

This post summarizes the dev chat meeting from June 7th (agendaSlack archive).

4.8 timing recap and Pre-Final Release & Dry Run checklist items

  • Beta 1 went out on Friday, May 12th; Beta 2 went out on Monday, May 22nd
  • RC1 went out on Thursday, May 25th; RC2 went out on Thursday, June 1st
  • 4.8 is scheduled for June 1, 2017 at 9am EDT
  • Events widget looks ready
  • Credits API to be updated by @ocean90 tomorrow morning
  • About page update for responsive, CDN-hosted images coming from @melchoyce
  • Announcement post draft is ready to go; @jorbin & @ocean90 to help provide contributor & language count as input
  • Announcement email being drafted by @matt
  • Codex page to be updated by @jbpaul17
  • Agreed to remove “partial back to IE8” from Browser support page in Design handbook
  • tinymce/plugins/wpembed to be added to $_old_files by @ocean90
  • No new default theme, so $_new_bundled_files is fine
  • Updates to default themes and submission to repo to be done by @davidakennedy, committed by @ocean90
  • Hosts email to be drafted by @jbpaul17, email to be reviewed & sent by @jorbin
  • Systems to be covered by @vnsavage
  • grunt prerelease check for tests & standards to be run by @jorbin

4.8 Bug Scrub

  • Reviewing four tickets in Defects Awaiting Review, reported against trunk section from Report 40
  • #40929: relates to improved translator docs, punting to next minor release (4.8.1)
  • #40932: moved to Future Release
  • #40927: not a regression, moved to Future Release
  • #40906: marked as a dupe of #40685, not a blocker for 4.8

Other News

  • Customize: looking for a new contributor to work on the HTML/Code widget, a good-first-bug, please chat in #core-customize if you’re interested
  • Editor: working to get the plugin in the plugin repo so that more people can review it and provide feedback. Goal is this week.
  • Devchat coordination: will be covered in upcoming devchat

#4-8, #core, #core-editor, #dev-chat, #summary

JavaScript Chat Summary for May 16th

Below is a summary of the conversation from today’s JavaScript Chat (agenda, Slack archive):

Build Tools for Code Standards

  • There’s a desire to replace the current JSHint configuration with an ESLint solution (#31823)
  • @netweb shared a number of ESLint-related projects targeting parity with existing JSHint and JSCS configuration
  • JSHint was mainly designed to identify potentially erroneous code. ESLint builds upon this with support for style and custom rule enforcement
  • What steps do we then take to extend the ruleset to meet the remainder of the JavaScript Coding Standards? Parity with .jshintrc has the benefit of serving as a drop-in replacement, but legacy code and existing patches may be impacted by broader rule enforcement.
  • Options for incremental adoption of rules: first configure rules as warnings, or attempt to lint only lines modified in proposed change (as in PHPCS, or Calypso’s git-based eslines)
  • Alternatively, forgo incremental adoption and instead make a single pass to fix offending code, using ESLint’s fixer or prettier (discussion ticket to be created), at the cost of potential disruption to existing patches by conflicts introduced. This appears to be the favored path.
  • How do we reconcile a desire to retroactively fix coding offenses with our guidelines explicitly forbidding this sort of refactoring? The guideline was revised with an ending note about internal consistency. @jorbin later remarked that exceptions have been made in the past for allowing JSHint-based refactoring.

General Remarks on JavaScript Standards

  • @aduth raised a concern of the difficulty in following spacing exceptions on function arguments, arguing that the mental overhead in understanding how context varies application of the rule could explain why it’s followed inconsistently.

Tickets

  • @adamsilverstein requested feedback on a ticket proposing to make two utility functions specific to Press This more widely available (#40635)

Open Discussion

  • A meeting topic was proposed: Module patterns to extend or replace Browserify and make internal utilities more broadly available. Special attention will need to be made for interoperability with existing patterns for declaring script dependencies.
  • A meeting topic was proposed: Making a decision on a framework to use in place of Backbone, based on consensus from last week that a replacement is needed.

#javascript, #summary

Dev Chat Summary: March 15th (4.7.4 week 2)

This post summarizes the dev chat meeting from March 15th (agendaSlack archive).

4.7.4 Planning

Browser support

  • Additional dev chat earlier today on topic of Browser support (Slack archive)
  • After some discussion, we arrived at the following strategy.
    • A “text” editor available to everyone is the best fallback – the new visual editor will leave old browsers behind.
    • Some form of the current version of the editor can be packaged into a plugin. Sites with users requiring a more advanced editor experience for older browsers can install this plugin.
    • The WordPress admin screen will display a notice of some sort to users with older browsers explaining the changes and how they can install the plugin for the experience they were used to (possibly utilizing BrowseHappy).
    • The editor team will use their research for the new editor to determine which buttons need to remain in the “text” editor with support for older browsers.
    • A more general discussion about browser support policies is slated to be had at the Community Summit before WordCamp EU. But this discussion can start before that (@jorbin is working on a Make post to start that conversation).
  • Any additional feedback from anyone who could not attend then is welcomed!

Core team reps

  • Last week we had nominations for @jorbin and @afercia.
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @afercia not currently scheduled to be at summit, but would like to
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Customize team

REST API team

  • Day of REST event was successful, but delayed continuing bug triage, will pick back up on 4.7.4 to make sure we keep solving the critical pieces
  • @jnylen0 & others resolved issue with tests & daylight savings time
  • due to bandwidth the existing REST API contributor group is fully occupied with the API itself
  • existing REST API contributor group have neither the bandwidth nor the domain expertise to also be leading the WP Admin implementations that will consume the REST API
  • @adamsilverstein lead the charge with Quick Draft, and work has begun in several parallel channels, but as of right now there’s nothing that appears to have momentum
  • We need help to drive adoption of the REST API within WP Admin, please come chat in #core-restapi any time
  • We need more explicit awareness of how the other feature teams want to use the REST API, or volunteers to lead separate implementations to move away from admin-ajax where it introduces inconsistency
  • If you’re not able to lead the separate implementations, then please chime in on component tickets as they’re opened to help us triage the pain points

General announcements

  • PHPunit tests (#39265: Missing @covers and @uses in the comments block in phpunt test for wordpress)
    • @pbearne: I am trying to do is get support to have @cover and @uses required for PHPunint tests
    • @pbearne: Willing to work through the old tests to add the missing comments
    • @pbearne: I would like to propose that we require for all new / updated tests and that the code committers commit updates with these added ASAP
    • How would we use that information going forward?
    • @pbearne: add to WordPress.org as way of show code quality and tell how well we are doing
    • What would be a realistic number we’d want to achieve?
    • @pbearne: anything over 80%
  • If you use the editor, please look to complete the Editor Experience Survey.

#4-7, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #dev-chat, #summary

Dev Chat Summary: March 8th (4.7.4 week 1)

This post summarizes the dev chat meeting from March 8th (agendaSlack archive).

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

#4-7, #4-7-3, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary