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)

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

@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.

@jorbin: I’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

@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

@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.

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.

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.