Prepare feature projects for merge consideration

[noisysocks]

This issue is for researching these two items in the spreadsheet:

Feature projects should prepare for merge consideration in the beginning of a release cycle

Merge proposals should be created and reviewed during this time.

[noisysocks]

I started researching this by doing an initial round of "discovery". I pinged four Core contributors with these two questions:

• What are some recent feature projects that have been merged into Core?
• Who was involved?

My notes from the answers:

• Site Health - @clorith
  • "Site Health started as a plugin, so I guess that counts even if it wasn't titled as such."
• REST API - @rmccue, @kadamwhite, @joehoyle, @rachelbaker, Daniel Bachhuber
  • https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/
  • https://make.wordpress.org/core/2016/10/08/rest-api-merge-proposal-part-2-content-api/
  • Sentiment that this took a long time to get in because leadership wanted Core to be using the REST API before they were included in Core.
• Gutenberg - @mtias, @youknowriad, lots of others
  • This was a plugin but didn't follow all of the 'feature plugin' flows.
• @swissspidy has a merge proposal for language updates
• MP6 - @melchoyce
  • https://make.wordpress.org/core/2013/10/23/mp6-3-8-proposal/
• Responsive images - @joemcgill
• oEmbed - @swissspidy, @pento
• Emoji - @pento
• https://make.wordpress.org/core/2018/08/30/merge-proposal-dark-mode/
  • "This was a particularly poor contributor experience using the feature plugin path."
• GDPR was not a feature plugin because it had a real world deadline.
• There is a list of feature plugins on w.org: https://make.wordpress.org/core/features/
  • It's hard to find this page.

I sensed that it had been a while since a merge proposal has been seen, so I asked some of my interviewees this follow-up question:

• I detect that it’s been a while since Core has properly done the whole ‘feature plugin’ process. Is that correct? Any thoughts on that, or why?

My notes from the answers:

• "Yeah it has been. I'm not sure why, whether a lack of interest or the people interested in such things are busy working on Gutenberg."
• "I think that once Gutenberg was announced as the priority everyone gave up on making new feature plugins, and before Gutenberg there were the 3 priorities (Customizer, Editor, and REST API), and all of those were in core so no new feature plugins were created."
• "I think it’s not clear who has the authority to announce a feature plugin. And it’s hard to gauge if the effort will actually result in merge to core. So people are hesitant to invest the time."
• Pros of the feature plugin model:
  • Gives space for an idea to be fleshed. Feature plugins that aren't merged can still live on as plugins.
  • Allows plugins to use the tooling and environment that's right for the plugin.
  • Can work in GitHub where it's easier to rapidly iterate on an idea, as opposed to wrangling a big Trac patch.
• Cons of the feature plugin model:
  • Burden is shifted to the author of the merge proposal.
  • Feature plugins can grow quite large and end up having substantial workarounds for things that aren't in Core. This then makes it hard to merge into Core.

I've pinged the authors of the merge proposals mentioned in this "discovery" round with some questions about the experience. More to come!