Merge branch 'master' of github.com:gatsbyjs/gatsby into hooks

* 'master' of github.com:gatsbyjs/gatsby:
  feat(cache-dir): Add a button for custom 404s in development (gatsbyjs#8548)
  fix: add ecosystem team for starters YAML
  fix: fix displaying and hydrating 404 page in production builds (gatsbyjs#8510)
  fix: don't expect `application/json` type nodes to be files (gatsbyjs#8544)
  Delete cds-takeaways.md (gatsbyjs#8552)
  chore(release): Publish
  chore: remove npm-run-all dep and update deps in e2e tests (gatsbyjs#8529)
  [www] Site/Starter Showcase refactor, rinse II (gatsbyjs#8411)
  Rfc process doc (gatsbyjs#8537)
  [www] a11y improvements (gatsbyjs#8536)
  Update the GraphQL stitching blog post & docs (gatsbyjs#8516)
  fix: change teams to reduce noise for people

CODEOWNERS

@@ -3,17 +3,20 @@
 
 # These files have the highest likelihood to cause chaos, so we require an
 # admin to review and approve pull requests that affect these.
-/packages/gatsby/                               @gatsbyjs/admin
-/packages/babel-plugin-remove-graphql-queries/  @gatsbyjs/admin
-/packages/gatsby-link/                          @gatsbyjs/admin
-/packages/gatsby-dev-cli/                       @gatsbyjs/admin
-/packages/gatsby-cli/                           @gatsbyjs/admin
+/packages/gatsby/                               @gatsbyjs/core
+/packages/babel-plugin-remove-graphql-queries/  @gatsbyjs/core
+/packages/gatsby-link/                          @gatsbyjs/core
+/packages/gatsby-dev-cli/                       @gatsbyjs/core
+/packages/gatsby-cli/                           @gatsbyjs/core
 
 # We also need to be careful with CI/CD and repo config files.
-.circleci/                                      @gatsbyjs/admin
-.travis.yml                                     @gatsbyjs/admin
-appveyor.yml                                    @gatsbyjs/admin
-.github/                                        @gatsbyjs/admin
+.circleci/                                      @gatsbyjs/core
+.travis.yml                                     @gatsbyjs/core
+appveyor.yml                                    @gatsbyjs/core
+.github/                                        @gatsbyjs/core
+
+# The ecosystem files are error-prone, so we require an extra set of eyes on them.
+/docs/starters.yml                              @gatsbyjs/ecosystem
 
 # The website auto-deploys, so we need an extra check to avoid shenanigans.
 /www/                                           @gatsbyjs/website

docs/blog/2018-09-25-announcing-graphql-stitching-support/index.md

@@ -0,0 +1,87 @@
+---
+title: Announcing support for natively querying 3rd-party GraphQL APIs with Gatsby
+date: "2018-09-25"
+author: "Mikhail Novikov"
+tags: ["graphql", "plugin", "source"]
+---
+
+When Gatsby was started 3.5 years ago, [GraphQL](https://www.graphql.com/) was still an internal project at Facebook and had yet to be open sourced.
+
+Since being open sourced, GraphQL's usage has exploded and [1000s of companies use it to power critical apps and websites](https://www.graphql.com/case-studies/).
+
+Gatsby's vision is to be the integration layer for modern websites gluing together data and code into highly performant websites and apps. GraphQL is integral to this vision.
+
+Gatsby v1 shipped last year with a plugin-powered data layer that let you easily pull data from any source using GraphQL. At the time, there was still very few public GraphQL schemas so we built a system that let plugins transform data from REST APIs into a GraphQL schema.
+
+But in the last year, a lot has changed. More and more services are shipping with native GraphQL APIs. CMSs like [GraphCMS](https://graphcms.com/), [AppSync](https://aws.amazon.com/appsync/), and [TakeShape](https://www.takeshape.io/) all have launched GraphQL APIs. [Contentful](https://www.contentful.com/) is launching a [native GraphQL API as well soon](https://www.contentful.com/blog/2018/07/04/graphql-abstract-syntax-tree-new-schema/).
+
+Watching the spread of GraphQL has all been incredibly exciting to watch and a fullfillment of our vision for the future of the web where sites easily stitch together data from many sources.
+
+But unfortunately, these new GraphQL APIs have been awkward to use inside Gatsby as you first had to wrap the API inside a Gatsby source plugin before you could query the data from your components.
+
+To fix this, [Gatsby 2.0](/blog/2018-09-17-gatsby-v2/) adds experimental support for schema stitching of external GraphQL APIs to its internal schema. Schema stitching allows merging multiple GraphQL schemas together, which greatly simplifies working with third-party GraphQL APIs. Along with low-level support for stitching in general, we are shipping an official [gatsby-source-graphql](https://www.gatsbyjs.org/packages/gatsby-source-graphql/) plugin, which enables connecting to an arbitrary GraphQL API with just a few lines of configuration!
+
+# Getting started
+
+Gatsby's data model is powered by an internal GraphQL API. It is a great abstraction that allows you to define the data requirements of your app, be it some files in the filesystem or a third-party API.
+
+Previously, when you wanted to add a 3rd-party GraphQL API, you needed to write a custom source plugin. But now, you simply add a small bit of config to your site's gatsby-config.js. The following example adds the Star Wars GraphQL API:
+
+```js
+// In your gatsby-config.js
+module.exports = {
+  plugins: [
+    {
+      resolve: "gatsby-source-graphql",
+      options: {
+        // This type will contain the remote schema Query type
+        typeName: "SWAPI",
+        // This is the field under which it's accessible
+        fieldName: "swapi",
+        // URL to query from
+        url: "https://api.graphcms.com/simple/v1/swapi",
+      },
+    },
+  ],
+}
+```
+
+After this you will have a field named `swapi` in your Gatsby GraphQL and you can query it.
+
+```graphql
+{
+  # Field name parameter defines how you can access third party API
+  swapi {
+    allSpecies {
+      name
+    }
+  }
+
+  # Other Gatsby querying works normally
+  site {
+    siteMetadata {
+      siteName
+    }
+  }
+}
+```
+
+# Why is it needed?
+
+To understand why a separate new plugin is needed, let's dive into how Gatsby source plugins work. Gatsby's GraphQL schema can be extended with source plugins. Source plugins can extend the schema by adding _nodes_ - objects that have some kind of global id. This way a `gatsby-source-filesystem` plugin can add all the files from a directory as nodes. Gatsby introspects the nodes that it gets and creates a GraphQL schema which you can use to fetch all those nodes.
+
+This system works really well for many cases and it's very intuitive, you don't need to care about creating a GraphQL schema or types for the nodes, any objects can be used. However, this is a limitation when using existing GraphQL APIs. First of all, you won't be able to use the same API as the one provided by the third-party API, because it will be replaced by Gatsby's internal node API. This can be confusing, because you can't consult the third-party API's documentation. Secondly, the plugin needs to proactively fetch all the possible data from the API, which can be complicated because the plugin author would have to predict which data might be needed.
+
+When there weren't many existing GraphQL APIs in the wild, that wasn't that much of a problem. For the few available APIs there was a source plugin. With the rise of both public GraphQL APIs, like GitHub or Shopify, and with so many more people having a GraphQL API of their own (or using one of the GraphQL solutions like Prisma, GraphCMS or AppSync), writing a plugin for each one became unfeasible. Meet `gatsby-source-graphql`.
+
+# How does it work?
+
+Instead of creating nodes for all potential items in a third-party API, `gatsby-source-graphql` uses schema stitching to combine the schema of a third-party API with the Gatsby schema. Schema stitching combines multiple GraphQL schemas into one, [read more about it here](https://www.apollographql.com/docs/graphql-tools/schema-stitching.html).
+
+The plugin puts the full third-party GraphQL API under one field in Gatsby's API. This way any types or fields of that API can be queried. There is no need to prefetch that data beforehand to create nodes, because the data will be fetched on-demand as required by the page queries.
+
+The actual stitching happens on the Gatsby level. There is a new action, [`addThirdPartySchema`](/docs/actions/#addThirdPartySchema), that can be used to add arbitrary schemas for stitching. It's a deliberately low-level API that we hope other plugin authors can use in the future to implement some mind-blowing GraphQL functionality.
+
+# Conclusions
+
+`gatsby-source-graphql` is part of [Gatsby's 2.0 release](/blog/2018-09-17-gatsby-v2/). Try it out now! [Check out the docs](/docs/third-party-graphql) or [a sample project using GitHub's GraphQL API](https://github.com/freiksenet/gatsby-github-displayer).

docs/docs/add-404-page.md

@@ -12,5 +12,5 @@ site another way, you'll need to setup a custom rule to serve this file for 404
 errors.
 
 When developing, Gatsby adds a default 404 page that overrides your custom 404
-page. But you can still visit the exact url for your 404 page to verify it's
-working as expected.
+page. But you can still preview your 404 page by clicking "Preview custom 404
+page" to verify it's working as expected.

docs/docs/rfc-process.md

@@ -2,7 +2,130 @@
 title: RFC process
 ---
 
-This is a stub. Help our community expand it.
+## What is the RFC process?
 
-Please use the [Gatsby Style Guide](/docs/gatsby-style-guide/) to ensure your
-pull request gets accepted.
+Many changes, including bug fixes and documentation improvements can be
+implemented and reviewed via the normal GitHub pull request workflow.
+
+Some changes, however, are "substantial", and we ask that these be put through
+a bit of a design process and produce a consensus among the Gatsby core team.
+
+The "RFC" (request for comments) process is intended to provide a consistent
+and controlled path for new features to enter the project.
+
+[Active RFC List](https://github.com/gatsbyjs/rfcs/pulls)
+
+Gatsby is still **actively developing** this process, and it will still change
+as more features are implemented and the community settles on specific
+approaches to feature development.
+
+## When to follow this process
+
+You should consider using this process if you intend to make "substantial"
+changes to Gatsby or its documentation. Some examples that would benefit from
+an RFC are:
+
+- A new feature that creates new API surface area, and would
+  require a feature flag if introduced.
+- The removal of features that already shipped as part of the release
+  channel.
+- The introduction of new idiomatic usage or conventions, even if they
+  do not include code changes to Gatsby itself.
+
+The RFC process is a great opportunity to get more eyeballs on your proposal
+before it becomes a part of a released version of Gatsby. Quite often, even
+proposals that seem "obvious" can be significantly improved once a wider group
+of interested people have a chance to weigh in.
+
+The RFC process can also be helpful to encourage discussions about a proposed
+feature as it is being designed, and incorporate important constraints into the
+design while it's easier to change, before the design has been fully
+implemented.
+
+Some changes do not require an RFC:
+
+- Rephrasing, reorganizing or refactoring addition or removal of warnings
+- Additions that strictly improve objective, numerical quality
+  criteria (speedup, better browser support)
+- Additions only likely to be _noticed by_ other implementors-of-Gatsby,
+  invisible to users-of-Gatsby.
+
+## What the process is
+
+In short, to get a major feature added to Gatsby, one usually first gets the
+RFC merged into the RFC repo as a markdown file. At that point the RFC is
+'active' and may be implemented with the goal of eventual inclusion into
+Gatsby.
+
+- Fork the RFC repo http://github.com/gatsbyjs/rfcs Copy `0000-template.md` to
+- `text/0000-my-feature.md` (where
+  'my-feature' is descriptive. Don't assign an RFC number yet).
+- Fill in the RFC. Put care into the details: **RFCs that do not
+  present convincing motivation, demonstrate understanding of the impact of the
+  design, or are disingenuous about the drawbacks or alternatives tend to be
+  poorly-received**.
+- Submit a pull request. As a pull request the RFC will receive design
+  feedback from the larger community, and the author should be prepared to revise
+  it in response.
+- Build consensus and integrate feedback. RFCs that have broad support
+  are much more likely to make progress than those that don't receive any
+  comments.
+- Eventually, the team will decide whether the RFC is a candidate
+  for inclusion in Gatsby.
+- RFCs that are candidates for inclusion in Gatsby will enter a "final comment
+  period" lasting 3 calendar days. The beginning of this period will be signaled
+  with a comment and tag on the RFCs pull request.
+- An RFC can be modified based upon feedback from the team and community.
+  Significant modifications may trigger a new final comment period.
+- An RFC may be rejected by the team after public discussion has settled
+  and comments have been made summarizing the rationale for rejection. A member
+  of the team should then close the RFCs associated pull request.
+- An RFC may be accepted at the close of its final comment period. A team
+  member will merge the RFCs associated pull request, at which point the RFC will
+  become 'active'.
+
+## The RFC life-cycle
+
+Once an RFC becomes active, then authors may implement it and submit the
+feature as a pull request to the Gatsby repo. Becoming 'active' is not a rubber
+stamp, and in particular still does not mean the feature will ultimately be
+merged; it does mean that the core team has agreed to it in principle and are
+amenable to merging it.
+
+Furthermore, the fact that a given RFC has been accepted and is 'active'
+implies nothing about what priority is assigned to its implementation, nor
+whether anybody is currently working on it.
+
+Modifications to active RFCs can be done in followup PRs. We strive to write
+each RFC in a manner that it will reflect the final design of the feature; but
+the nature of the process means that we cannot expect every merged RFC to
+actually reflect what the end result will be at the time of the next major
+release; therefore we try to keep each RFC document somewhat in sync with the
+language feature as planned, tracking such changes via followup pull requests
+to the document.
+
+## Implementing an RFC
+
+The author of an RFC is not obligated to implement it. Of course, the RFC
+author (like any other developer) is welcome to post an implementation for
+review after the RFC has been accepted.
+
+If you are interested in working on the implementation for an 'active' RFC, but
+cannot determine if someone else is already working on it, feel free to ask
+(e.g. by leaving a comment on the associated issue).
+
+## Reviewing RFCs
+
+Each week the team will attempt to review some set of open RFC pull requests.
+
+We try to make sure that any RFC that we accept is accepted at the weekly team
+meeting. Every accepted feature should have a core team champion, who will
+represent the feature and its progress.
+
+**Gatsby's RFC process owes its inspiration to the [React RFC process], [Yarn
+RFC process], [Rust RFC process], and [Ember RFC process]**
+
+[react rfc process]: https://github.com/reactjs/rfcs
+[yarn rfc process]: https://github.com/yarnpkg/rfcs
+[rust rfc process]: https://github.com/rust-lang/rfcs
+[ember rfc process]: https://github.com/emberjs/rfcs