diff --git a/docs/api/combineReducers.md b/docs/api/combineReducers.md
index ed3006a685..929193b5f0 100644
--- a/docs/api/combineReducers.md
+++ b/docs/api/combineReducers.md
@@ -80,7 +80,7 @@ Any reducer passed to `combineReducers` must satisfy these rules:
 
 - It must never return `undefined`. It is too easy to do this by mistake via an early `return` statement, so `combineReducers` throws if you do that instead of letting the error manifest itself somewhere else.
 
-- If the `state` given to it is `undefined`, it must return the initial state for this specific reducer. According to the previous rule, the initial state must not be `undefined` either. It is handy to specify it with ES6 optional arguments syntax, but you can also explicitly check the first argument for being `undefined`.
+- If the `state` given to it is `undefined`, it must return the initial state for this specific reducer. According to the previous rule, the initial state must not be `undefined` either. It is handy to specify it with ES2015 optional arguments syntax, but you can also explicitly check the first argument for being `undefined`.
 
 While `combineReducers` attempts to check that your reducers conform to some of these rules, you should remember them, and do your best to follow them. `combineReducers` will check your reducers by passing `undefined` to them; this is done even if you specify initial state to `Redux.createStore(combineReducers(...), initialState)`. Therefore, you **must** ensure your reducers work properly when receiving `undefined` as state, even if you never intend for them to actually receive `undefined` in your own code.
 
diff --git a/docs/faq/Actions.md b/docs/faq/Actions.md
index 8ce950fb8a..7768f70b88 100644
--- a/docs/faq/Actions.md
+++ b/docs/faq/Actions.md
@@ -114,7 +114,7 @@ There are [many async/side effect middlewares available](https://github.com/mark
 As a general rule of thumb:
 
 - Thunks are best for complex synchronous logic (especially code that needs access to the entire Redux store state), and simple async logic (like basic AJAX calls). With the use of `async/await`, it can be reasonable to use thunks for some more complex promise-based logic as well.
-- Sagas are best for complex async logic and decoupled "background thread"-type behavior, especially if you need to listen to dispatched actions (which is something that can't be done with thunks). They require familiarity with ES6 generator functions and `redux-saga`'s "effects" operators.
+- Sagas are best for complex async logic and decoupled "background thread"-type behavior, especially if you need to listen to dispatched actions (which is something that can't be done with thunks). They require familiarity with ES2015 generator functions and `redux-saga`'s "effects" operators.
 - Observables solve the same problems as sagas, but rely on RxJS to implement async behavior. They require familiarity with the RxJS API.
 
 We recommend that most Redux users should start with thunks, and then add an additional side effect library like sagas or observables later if their app really requires handling for more complex async logic.
@@ -131,7 +131,7 @@ Since sagas and observables have the same use case, an application would normall
 **Discussions**
 
 - [Reddit: discussion of using thunks and sagas together, and pros and cons of sagas](https://www.reddit.com/r/reactjs/comments/8vglo0/react_developer_map_by_adamgolab/e1nr597/)
-- [Stack Overflow: Pros/cons of using redux-saga with ES6 generators vs redux-thunk with ES2017 async/await](https://stackoverflow.com/questions/34930735/pros-cons-of-using-redux-saga-with-es6-generators-vs-redux-thunk-with-es2017-asy)
+- [Stack Overflow: Pros/cons of using redux-saga with ES2015 generators vs redux-thunk with ES2017 async/await](https://stackoverflow.com/questions/34930735/pros-cons-of-using-redux-saga-with-es6-generators-vs-redux-thunk-with-es2017-asy)
 - [Stack Overflow: Why use Redux-Observable over Redux-Saga?](https://stackoverflow.com/questions/40021344/why-use-redux-observable-over-redux-saga/40027778#40027778)
 
 ### Should I dispatch multiple actions in a row from one action creator?
diff --git a/docs/faq/General.md b/docs/faq/General.md
index 48c8d3761e..744247b168 100644
--- a/docs/faq/General.md
+++ b/docs/faq/General.md
@@ -104,7 +104,7 @@ Redux can be used as a data store for any UI layer. The most common usage is wit
 
 ## Do I need to have a particular build tool to use Redux?
 
-Redux is originally written in ES6 and transpiled for production into ES5 with Webpack and Babel. You should be able to use it regardless of your JavaScript build process. Redux also offers a UMD build that can be used directly without any build process at all. The [counter-vanilla](https://github.com/reduxjs/redux/tree/master/examples/counter-vanilla) example demonstrates basic ES5 usage with Redux included as a `<script>` tag. As the relevant pull request says:
+Redux is originally written in ES2015 and transpiled for production into ES5 with Webpack and Babel. You should be able to use it regardless of your JavaScript build process. Redux also offers a UMD build that can be used directly without any build process at all. The [counter-vanilla](https://github.com/reduxjs/redux/tree/master/examples/counter-vanilla) example demonstrates basic ES5 usage with Redux included as a `<script>` tag. As the relevant pull request says:
 
 > The new Counter Vanilla example is aimed to dispel the myth that Redux requires Webpack, React, hot reloading, sagas, action creators, constants, Babel, npm, CSS modules, decorators, fluent Latin, an Egghead subscription, a PhD, or an Exceeds Expectations O.W.L. level.
 >
diff --git a/docs/faq/ImmutableData.md b/docs/faq/ImmutableData.md
index a71f79a3cd..ff28c4181e 100644
--- a/docs/faq/ImmutableData.md
+++ b/docs/faq/ImmutableData.md
@@ -452,7 +452,7 @@ JavaScript was never designed to provide guaranteed immutable operations. Accord
 
 With JavaScript, you can accidentally mutate an object (such as the Redux state tree) quite easily without realizing it. For example, updating deeply nested properties, creating a new _reference_ to an object instead of a new object, or performing a shallow copy rather than a deep copy, can all lead to inadvertent object mutations, and can trip up even the most experienced JavaScript coder.
 
-To avoid these issues, ensure you follow the recommended [immutable update patterns for ES6](../usage/structuring-reducers/ImmutableUpdatePatterns.md).
+To avoid these issues, ensure you follow the recommended [immutable update patterns for ES2015](../usage/structuring-reducers/ImmutableUpdatePatterns.md).
 
 ### Verbose Code
 
@@ -470,7 +470,7 @@ In contrast, immutable libraries such as Immer can employ structural sharing, wh
 
 **Documentation**
 
-- [Immutable Update Patterns for ES6](../usage/structuring-reducers/ImmutableUpdatePatterns.md)
+- [Immutable Update Patterns for ES2015](../usage/structuring-reducers/ImmutableUpdatePatterns.md)
 
 **Articles**
 
diff --git a/docs/faq/ReactRedux.md b/docs/faq/ReactRedux.md
index cb3643fecf..fbfa02a283 100644
--- a/docs/faq/ReactRedux.md
+++ b/docs/faq/ReactRedux.md
@@ -57,7 +57,7 @@ It's important to remember that whenever you update a nested value, you must als
 Note that “updating data immutably” does _not_ mean that you must use [Immer](https://github.com/immerjs/immer), although that is certainly an option. You can do immutable updates to plain JS objects and arrays using several different approaches:
 
 - Copying objects using functions like `Object.assign()` or `_.extend()`, and array functions such as `slice()` and `concat()`
-- The array spread operator in ES6, and the similar object spread operator that is proposed for a future version of JavaScript
+- The array spread operator in ES2015, and the similar object spread operator from ES2018
 - Utility libraries that wrap immutable update logic into simpler functions
 
 #### Further information
diff --git a/docs/introduction/LearningResources.md b/docs/introduction/LearningResources.md
index 67c1bccf05..c57c55976a 100644
--- a/docs/introduction/LearningResources.md
+++ b/docs/introduction/LearningResources.md
@@ -341,7 +341,7 @@ _Patterns and practices for structuring larger Redux applications_
 
 - **Modern React with Redux, by Stephen Grider (paid)** <br/>
   https://www.udemy.com/react-redux/ <br/>
-  Master the fundamentals of React and Redux with this tutorial as you develop apps with React Router, Webpack, and ES6. This course will get you up and running quickly, and teach you the core knowledge you need to deeply understand and build React components and structure applications with Redux.
+  Master the fundamentals of React and Redux with this tutorial as you develop apps with React Router, Webpack, and ES2015. This course will get you up and running quickly, and teach you the core knowledge you need to deeply understand and build React components and structure applications with Redux.
 
 - **Redux, by Tyler McGinnis (paid)** <br/>
   https://tylermcginnis.com/courses/redux/ <br/>
@@ -353,7 +353,7 @@ _Patterns and practices for structuring larger Redux applications_
 
 ## More Resources
 
-- [React-Redux Links](https://github.com/markerikson/react-redux-links) is a curated list of high-quality articles, tutorials, and related content for React, Redux, ES6, and more.
+- [React-Redux Links](https://github.com/markerikson/react-redux-links) is a curated list of high-quality articles, tutorials, and related content for React, Redux, ES2015, and more.
 - [Redux Ecosystem Links](https://github.com/markerikson/redux-ecosystem-links) is a categorized collection of Redux-related libraries, addons, and utilities.
 - [Awesome Redux](https://github.com/xgrommx/awesome-redux) is an extensive list of Redux-related repositories.
 - [DEV Community](https://dev.to/t/redux) is a place to share Redux projects, articles and tutorials as well as start discussions and ask for feedback on Redux-related topics. Developers of all skill-levels are welcome to take part.
diff --git a/docs/style-guide/style-guide.md b/docs/style-guide/style-guide.md
index be16a22813..848cb9d651 100644
--- a/docs/style-guide/style-guide.md
+++ b/docs/style-guide/style-guide.md
@@ -237,7 +237,7 @@ As mentioned in [Reducers Should Own the State Shape](#reducers-should-own-the-s
 The key names in the object passed to `combineReducers` will define the names of the keys in the resulting state object. Be sure to name these keys after the data that is kept inside, and avoid use of the word "reducer" in the key names. Your object should look like `{users: {}, posts: {}}`, rather than `{usersReducer: {}, postsReducer: {}}`.
 
 <DetailedExplanation>
-ES6 object literal shorthand makes it easy to define a key name and a value in an object at the same time:
+ES2015 object literal shorthand makes it easy to define a key name and a value in an object at the same time:
 
 ```js
 const data = 42
diff --git a/docs/tutorials/essentials/part-1-overview-concepts.md b/docs/tutorials/essentials/part-1-overview-concepts.md
index a3b180d6a3..32614948e6 100644
--- a/docs/tutorials/essentials/part-1-overview-concepts.md
+++ b/docs/tutorials/essentials/part-1-overview-concepts.md
@@ -32,7 +32,7 @@ We've tried to keep these explanations beginner-friendly, but we do need to make
 :::important Prerequisites
 
 - Familiarity with [HTML & CSS](https://internetingishard.netlify.app/html-and-css/index.html).
-- Familiarity with [ES6 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
+- Familiarity with [ES2015 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
 - Knowledge of React terminology: [JSX](https://react.dev/learn/writing-markup-with-jsx), [State](https://react.dev/learn/state-a-components-memory), [Function Components](https://react.dev/learn/your-first-component), [Props](https://react.dev/learn/passing-props-to-a-component), and [Hooks](https://react.dev/reference/react)
 - Knowledge of [asynchronous JavaScript](https://javascript.info/promise-basics) and [making AJAX requests](https://javascript.info/fetch)
 
diff --git a/docs/tutorials/essentials/part-6-performance-normalization.md b/docs/tutorials/essentials/part-6-performance-normalization.md
index 4f04eead1d..9c0860d996 100644
--- a/docs/tutorials/essentials/part-6-performance-normalization.md
+++ b/docs/tutorials/essentials/part-6-performance-normalization.md
@@ -822,7 +822,7 @@ When we receive the `fetchPosts.fulfilled` action, we can use the `postsAdapter.
 
 When we receive the `addNewPost.fulfilled` action, we know we need to add that one new post object to our state. We can use the adapter functions as reducers directly, so we'll pass `postsAdapter.addOne` as the reducer function to handle that action.
 
-Finally, we can replace the old hand-written `selectAllPosts` and `selectPostById` selector functions with the ones generated by `postsAdapter.getSelectors`. Since the selectors are called with the root Redux state object, they need to know where to find our posts data in the Redux state, so we pass in a small selector that returns `state.posts`. The generated selector functions are always called `selectAll` and `selectById`, so we can use ES6 destructuring syntax to rename them as we export them and match the old selector names. We'll also export `selectPostIds` the same way, since we want to read the list of sorted post IDs in our `<PostsList>` component.
+Finally, we can replace the old hand-written `selectAllPosts` and `selectPostById` selector functions with the ones generated by `postsAdapter.getSelectors`. Since the selectors are called with the root Redux state object, they need to know where to find our posts data in the Redux state, so we pass in a small selector that returns `state.posts`. The generated selector functions are always called `selectAll` and `selectById`, so we can use ES2015 destructuring syntax to rename them as we export them and match the old selector names. We'll also export `selectPostIds` the same way, since we want to read the list of sorted post IDs in our `<PostsList>` component.
 
 ### Optimizing the Posts List
 
diff --git a/docs/tutorials/fundamentals/part-1-overview.md b/docs/tutorials/fundamentals/part-1-overview.md
index 19fd7183ac..297c0f109c 100644
--- a/docs/tutorials/fundamentals/part-1-overview.md
+++ b/docs/tutorials/fundamentals/part-1-overview.md
@@ -40,7 +40,7 @@ We've tried to keep these explanations beginner-friendly, but we do need to make
 :::important Prerequisites
 
 - Familiarity with [HTML & CSS](https://internetingishard.netlify.app/html-and-css/index.html).
-- Familiarity with [ES6 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
+- Familiarity with [ES2015 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
 - Understanding of [the array and object spread operators](https://javascript.info/rest-parameters-spread#spread-syntax)
 - Knowledge of React terminology: [JSX](https://react.dev/learn/writing-markup-with-jsx), [State](https://react.dev/learn/state-a-components-memory), [Function Components](https://react.dev/learn/your-first-component), [Props](https://react.dev/learn/passing-props-to-a-component), and [Hooks](https://react.dev/reference/react)
 - Knowledge of [asynchronous JavaScript](https://javascript.info/promise-basics) and [making AJAX requests](https://javascript.info/fetch)
diff --git a/docs/tutorials/fundamentals/part-3-state-actions-reducers.md b/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
index 0df4709ca2..0a09be2321 100644
--- a/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
+++ b/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
@@ -272,7 +272,7 @@ export default function appReducer(state = initialState, action) {
 }
 ```
 
-A reducer may be called with `undefined` as the state value when the application is being initialized. If that happens, we need to provide an initial state value so the rest of the reducer code has something to work with. **Reducers normally use ES6 default argument syntax to provide initial state: `(state = initialState, action)`**.
+A reducer may be called with `undefined` as the state value when the application is being initialized. If that happens, we need to provide an initial state value so the rest of the reducer code has something to work with. **Reducers normally use ES2015 default argument syntax to provide initial state: `(state = initialState, action)`**.
 
 Next, let's add the logic to handle the `'todos/todoAdded'` action.
 
diff --git a/docs/tutorials/fundamentals/part-4-store.md b/docs/tutorials/fundamentals/part-4-store.md
index 30541fb485..5384416f0f 100644
--- a/docs/tutorials/fundamentals/part-4-store.md
+++ b/docs/tutorials/fundamentals/part-4-store.md
@@ -449,7 +449,7 @@ You can give these middleware functions any names you want, but it can help to u
 
 :::
 
-Because these are normal functions, we can also write them using ES6 arrow functions. This lets us write them shorter because arrow functions don't have to have a `return` statement, but it can also be a bit harder to read if you're not yet familiar with arrow functions and implicit returns.
+Because these are normal functions, we can also write them using ES2015 arrow functions. This lets us write them shorter because arrow functions don't have to have a `return` statement, but it can also be a bit harder to read if you're not yet familiar with arrow functions and implicit returns.
 
 Here's the same example as above, using arrow functions:
 
diff --git a/docs/tutorials/fundamentals/part-8-modern-redux.md b/docs/tutorials/fundamentals/part-8-modern-redux.md
index 310bfe0eca..32ad8dfc19 100644
--- a/docs/tutorials/fundamentals/part-8-modern-redux.md
+++ b/docs/tutorials/fundamentals/part-8-modern-redux.md
@@ -801,7 +801,7 @@ export const selectFilteredTodoIds = createSelector(
 )
 ```
 
-We call `todosAdapter.getSelectors`, and pass in a `state => state.todos` selector that returns this slice of state. From there, the adapter generates a `selectAll` selector that takes the _entire_ Redux state tree, as usual, and loops over `state.todos.entities` and `state.todos.ids` to give us the complete array of todo objects. Since `selectAll` doesn't tell us _what_ we're selecting, we can use ES6 destructuring syntax to rename the function to `selectTodos`. Similarly, we can rename `selectById` to `selectTodoById`.
+We call `todosAdapter.getSelectors`, and pass in a `state => state.todos` selector that returns this slice of state. From there, the adapter generates a `selectAll` selector that takes the _entire_ Redux state tree, as usual, and loops over `state.todos.entities` and `state.todos.ids` to give us the complete array of todo objects. Since `selectAll` doesn't tell us _what_ we're selecting, we can use ES2015 destructuring syntax to rename the function to `selectTodos`. Similarly, we can rename `selectById` to `selectTodoById`.
 
 Notice that our other selectors still use `selectTodos` as an input. That's because it's still returning an array of todo objects this whole time, no matter whether we were keeping the array as the entire `state.todos`, keeping it as a nested array, or storing it as a normalized object and converting to an array. Even as we've made all these changes to how we stored our data, the use of selectors allowed us to keep the rest of our code the same, and the use of memoized selectors has helped the UI perform better by avoiding unnecessary rerenders.
 
diff --git a/docs/understanding/history-and-design/middleware.md b/docs/understanding/history-and-design/middleware.md
index 507037f11a..853f574a44 100644
--- a/docs/understanding/history-and-design/middleware.md
+++ b/docs/understanding/history-and-design/middleware.md
@@ -217,7 +217,7 @@ function logger(store) {
 }
 ```
 
-It's a [“we need to go deeper”](https://knowyourmeme.com/memes/we-need-to-go-deeper) kind of moment, so it might take a while for this to make sense. The function cascade feels intimidating. ES6 arrow functions make this [currying](https://en.wikipedia.org/wiki/Currying) easier on eyes:
+It's a [“we need to go deeper”](https://knowyourmeme.com/memes/we-need-to-go-deeper) kind of moment, so it might take a while for this to make sense. The function cascade feels intimidating. Arrow functions make this [currying](https://en.wikipedia.org/wiki/Currying) easier on eyes:
 
 ```js
 const logger = store => next => action => {
diff --git a/docs/usage/ServerRendering.md b/docs/usage/ServerRendering.md
index ce6c6a4d03..e4b17e61cf 100644
--- a/docs/usage/ServerRendering.md
+++ b/docs/usage/ServerRendering.md
@@ -39,7 +39,7 @@ npm install express react-redux
 
 The following is the outline for what our server side is going to look like. We are going to set up an [Express middleware](https://expressjs.com/guide/using-middleware.html) using [app.use](http://expressjs.com/api.html#app.use) to handle all requests that come in to our server. If you're unfamiliar with Express or middleware, just know that our handleRender function will be called every time the server receives a request.
 
-Additionally, as we are using ES6 and JSX syntax, we will need to compile with [Babel](https://babeljs.io/) (see [this example of a Node Server with Babel](https://github.com/babel/example-node-server)) and the [React preset](https://babeljs.io/docs/plugins/preset-react/).
+Additionally, as we are using ES2015 and JSX syntax, we will need to compile with [Babel](https://babeljs.io/) (see [this example of a Node Server with Babel](https://github.com/babel/example-node-server)) and the [React preset](https://babeljs.io/docs/plugins/preset-react/).
 
 ##### `server.js`
 
diff --git a/docs/usage/UsingObjectSpreadOperator.md b/docs/usage/UsingObjectSpreadOperator.md
index 0a813e660f..27b7b70a30 100644
--- a/docs/usage/UsingObjectSpreadOperator.md
+++ b/docs/usage/UsingObjectSpreadOperator.md
@@ -22,7 +22,7 @@ function todoApp(state = initialState, action) {
 
 While effective, using `Object.assign()` can quickly make simple reducers difficult to read given its rather verbose syntax.
 
-An alternative approach is to use the [object spread syntax](https://github.com/tc39/proposal-object-rest-spread) recently added to the JavaScript specification. It lets you use the spread (`...`) operator to copy enumerable properties from one object to another in a more succinct way. The object spread operator is conceptually similar to the ES6 [array spread operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator). We can simplify the `todoApp` example above by using the object spread syntax:
+An alternative approach is to use the [object spread syntax](https://github.com/tc39/proposal-object-rest-spread) recently added to the JavaScript specification. It lets you use the spread (`...`) operator to copy enumerable properties from one object to another in a more succinct way. The object spread operator is conceptually similar to the ES2015 [array spread operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator). We can simplify the `todoApp` example above by using the object spread syntax:
 
 ```js
 function todoApp(state = initialState, action) {
diff --git a/docs/usage/deriving-data-selectors.md b/docs/usage/deriving-data-selectors.md
index 87d27f0597..7de55125ce 100644
--- a/docs/usage/deriving-data-selectors.md
+++ b/docs/usage/deriving-data-selectors.md
@@ -379,7 +379,7 @@ While Reselect is the most widely used selector library with Redux, there are ma
 
 ### `proxy-memoize`
 
-`proxy-memoize` is a relatively new memoized selector library that uses a unique implementation approach. It relies on ES6 `Proxy` objects to track attempted reads of nested values, then compares only the nested values on later calls to see if they've changed. This can provide better results than Reselect in some cases.
+`proxy-memoize` is a relatively new memoized selector library that uses a unique implementation approach. It relies on ES2015 `Proxy` objects to track attempted reads of nested values, then compares only the nested values on later calls to see if they've changed. This can provide better results than Reselect in some cases.
 
 A good example of this is a selector that derives an array of todo descriptions:
 
@@ -411,7 +411,7 @@ It also has a built-in `size` option, which lets you set the desired cache size
 It has some tradeoffs and differences from Reselect:
 
 - All values are passed in as a single object argument
-- It requires that the environment supports ES6 `Proxy` objects (no IE11)
+- It requires that the environment supports ES2015 `Proxy` objects (no IE11)
 - It's more magical, whereas Reselect is more explicit
 - There are some edge cases regarding the `Proxy`-based tracking behavior
 - It's newer and less widely used
diff --git a/docs/usage/nextjs.mdx b/docs/usage/nextjs.mdx
index e24349a545..33a701d879 100644
--- a/docs/usage/nextjs.mdx
+++ b/docs/usage/nextjs.mdx
@@ -17,7 +17,7 @@ hide_title: true
 
 :::info Prerequisites
 
-- Familiarity with [ES6 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
+- Familiarity with [ES2015 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
 - Knowledge of React terminology: [JSX](https://reactjs.org/docs/introducing-jsx.html), [State](https://reactjs.org/docs/state-and-lifecycle.html), [Function Components, Props](https://reactjs.org/docs/components-and-props.html), and [Hooks](https://reactjs.org/docs/hooks-intro.html)
 - Understanding of [Redux terms and concepts](https://redux.js.org/tutorials/fundamentals/part-2-concepts-data-flow)
 - Working through the [Quick Start tutorial](../tutorials/quick-start.md) and [TypeScript Quick Start tutorial](../tutorials/typescript.md) is recommended, and ideally the full [Redux Essentials](https://redux.js.org/tutorials/essentials/part-1-overview-concepts) tutorial as well
diff --git a/docs/usage/side-effects-approaches.mdx b/docs/usage/side-effects-approaches.mdx
index 7964cbb469..afa75e30f7 100644
--- a/docs/usage/side-effects-approaches.mdx
+++ b/docs/usage/side-effects-approaches.mdx
@@ -85,7 +85,7 @@ We've intentionally designed the RTK listener middleware to be straightforward t
 
 We specifically recommend _against_ sagas or observables for most reactive logic for multiple reasons:
 
-- Sagas: require understanding ES6 generator function syntax as well as the saga effects behaviors; add multiple levels of indirection due to needing extra actions dispatched; have poor TypeScript support; and the power and complexity is simply not needed for most Redux use cases.
+- Sagas: require understanding ES2015 generator function syntax as well as the saga effects behaviors; add multiple levels of indirection due to needing extra actions dispatched; have poor TypeScript support; and the power and complexity is simply not needed for most Redux use cases.
 - Observables: require understanding the RxJS API and mental model; can be difficult to debug; can add significant bundle size
 
 ## Common Side Effects Approaches
diff --git a/docs/usage/structuring-reducers/BasicReducerStructure.md b/docs/usage/structuring-reducers/BasicReducerStructure.md
index 7b38720c62..17b81a5fcf 100644
--- a/docs/usage/structuring-reducers/BasicReducerStructure.md
+++ b/docs/usage/structuring-reducers/BasicReducerStructure.md
@@ -36,7 +36,7 @@ function counter(state, action) {
 
 Notice that this simple function fulfills all the basic requirements. It returns a default value if none exists, initializing the store; it determines what sort of update needs to be done based on the type of the action, and returns new values; and it returns the previous state if no work needs to be done.
 
-There are some simple tweaks that can be made to this reducer. First, repeated `if`/`else` statements quickly grow tiresome, so it's very common to use `switch` statements instead. Second, we can use ES6's default parameter values to handle the initial "no existing data" case. With those changes, the reducer would look like:
+There are some simple tweaks that can be made to this reducer. First, repeated `if`/`else` statements quickly grow tiresome, so it's very common to use `switch` statements instead. Second, we can use ES2015's default parameter values to handle the initial "no existing data" case. With those changes, the reducer would look like:
 
 ```js
 function counter(state = 0, action) {
diff --git a/docs/usage/structuring-reducers/InitializingState.md b/docs/usage/structuring-reducers/InitializingState.md
index 6b3ef0063b..e161a96801 100644
--- a/docs/usage/structuring-reducers/InitializingState.md
+++ b/docs/usage/structuring-reducers/InitializingState.md
@@ -6,13 +6,13 @@ description: 'Structuring Reducers > Initializing State: How Redux state is init
 
 # Initializing State
 
-There are two main ways to initialize state for your application. The `createStore` method can accept an optional `preloadedState` value as its second argument. Reducers can also specify an initial value by looking for an incoming state argument that is `undefined`, and returning the value they'd like to use as a default. This can either be done with an explicit check inside the reducer, or by using the ES6 default argument value syntax: `function myReducer(state = someDefaultValue, action)`.
+There are two main ways to initialize state for your application. The `createStore` method can accept an optional `preloadedState` value as its second argument. Reducers can also specify an initial value by looking for an incoming state argument that is `undefined`, and returning the value they'd like to use as a default. This can either be done with an explicit check inside the reducer, or by using the ES2015 default argument value syntax: `function myReducer(state = someDefaultValue, action)`.
 
 It's not always immediately clear how these two approaches interact. Fortunately, the process does follow some predictable rules. Here's how the pieces fit together.
 
 ## Summary
 
-Without `combineReducers()` or similar manual code, `preloadedState` always wins over `state = ...` in the reducer because the `state` passed to the reducer _is_ `preloadedState` and _is not_ `undefined`, so the ES6 argument syntax doesn't apply.
+Without `combineReducers()` or similar manual code, `preloadedState` always wins over `state = ...` in the reducer because the `state` passed to the reducer _is_ `preloadedState` and _is not_ `undefined`, so the ES2015 argument syntax doesn't apply.
 
 With `combineReducers()` the behavior is more nuanced. Those reducers whose state is specified in `preloadedState` will receive that state. Other reducers will receive `undefined` _and because of that_ will fall back to the `state = ...` default argument they specify.
 
@@ -59,7 +59,7 @@ const store = createStore(counter, 42)
 console.log(store.getState()) // 42
 ```
 
-Why is it `42`, and not `0`, this time? Because `createStore` was called with `42` as the second argument. This argument becomes the `state` passed to your reducer along with the dummy action. **This time, `state` is not undefined (it's `42`!), so ES6 default argument syntax has no effect.** The `state` is `42`, and `42` is returned from the reducer.
+Why is it `42`, and not `0`, this time? Because `createStore` was called with `42` as the second argument. This argument becomes the `state` passed to your reducer along with the dummy action. **This time, `state` is not undefined (it's `42`!), so ES2015 default argument syntax has no effect.** The `state` is `42`, and `42` is returned from the reducer.
 
 ### Combined Reducers
 
@@ -122,4 +122,4 @@ In this case, `state` was specified so it didn't fall back to `{}`. It was an ob
 
 ## Recap
 
-To sum this up, if you stick to Redux conventions and return the initial state from reducers when they're called with `undefined` as the `state` argument (the easiest way to implement this is to specify the `state` ES6 default argument value), you're going to have a nice useful behavior for combined reducers. **They will prefer the corresponding value in the `preloadedState` object you pass to the `createStore()` function, but if you didn't pass any, or if the corresponding field is not set, the default `state` argument specified by the reducer is chosen instead.** This approach works well because it provides both initialization and hydration of existing data, but lets individual reducers reset their state if their data was not preserved. Of course you can apply this pattern recursively, as you can use `combineReducers()` on many levels, or even compose reducers manually by calling reducers and giving them the relevant part of the state tree.
+To sum this up, if you stick to Redux conventions and return the initial state from reducers when they're called with `undefined` as the `state` argument (the easiest way to implement this is to specify the `state` ES2015 default argument value), you're going to have a nice useful behavior for combined reducers. **They will prefer the corresponding value in the `preloadedState` object you pass to the `createStore()` function, but if you didn't pass any, or if the corresponding field is not set, the default `state` argument specified by the reducer is chosen instead.** This approach works well because it provides both initialization and hydration of existing data, but lets individual reducers reset their state if their data was not preserved. Of course you can apply this pattern recursively, as you can use `combineReducers()` on many levels, or even compose reducers manually by calling reducers and giving them the relevant part of the state tree.
diff --git a/docs/usage/structuring-reducers/UsingCombineReducers.md b/docs/usage/structuring-reducers/UsingCombineReducers.md
index c32418fe59..2d9cff959b 100644
--- a/docs/usage/structuring-reducers/UsingCombineReducers.md
+++ b/docs/usage/structuring-reducers/UsingCombineReducers.md
@@ -26,9 +26,9 @@ There are several important ideas to be aware of when using `combineReducers`:
 
 There are two ways to define the initial shape and contents of your store's state. First, the `createStore` function can take `preloadedState` as its second argument. This is primarily intended for initializing the store with state that was previously persisted elsewhere, such as the browser's localStorage. The other way is for the root reducer to return the initial state value when the state argument is `undefined`. These two approaches are described in more detail in [Initializing State](./InitializingState.md), but there are some additional concerns to be aware of when using `combineReducers`.
 
-`combineReducers` takes an object full of slice reducer functions, and creates a function that outputs a corresponding state object with the same keys. This means that if no preloaded state is provided to `createStore`, the naming of the keys in the input slice reducer object will define the naming of the keys in the output state object. The correlation between these names is not always apparent, especially when using ES6 features such as default module exports and object literal shorthands.
+`combineReducers` takes an object full of slice reducer functions, and creates a function that outputs a corresponding state object with the same keys. This means that if no preloaded state is provided to `createStore`, the naming of the keys in the input slice reducer object will define the naming of the keys in the output state object. The correlation between these names is not always apparent, especially when using ES2015 features such as default module exports and object literal shorthands.
 
-Here's an example of how use of ES6 object literal shorthand with `combineReducers` can define the state shape:
+Here's an example of how use of ES2015 object literal shorthand with `combineReducers` can define the state shape:
 
 ```js
 // reducers.js
@@ -46,7 +46,7 @@ import theDefaultReducer, {
   secondNamedReducer
 } from './reducers'
 
-// Use ES6 object literal shorthand syntax to define the object shape
+// Use ES2015 object literal shorthand syntax to define the object shape
 const rootReducer = combineReducers({
   theDefaultReducer,
   firstNamedReducer,
@@ -58,7 +58,7 @@ console.log(store.getState())
 // {theDefaultReducer : 0, firstNamedReducer : 1, secondNamedReducer : 2}
 ```
 
-Notice that because we used the ES6 shorthand for defining an object literal, the key names in the resulting state are the same as the variable names from the imports. This may not always be the desired behavior, and is often a cause of confusion for those who aren't as familiar with ES6 syntax.
+Notice that because we used the ES2015 shorthand for defining an object literal, the key names in the resulting state are the same as the variable names from the imports. This may not always be the desired behavior, and is often a cause of confusion for those who aren't as familiar with ES2015 syntax.
 
 Also, the resulting names are a bit odd. It's generally not a good practice to actually include words like "reducer" in your state key names - the keys should simply reflect the domain or type of data they hold. This means we should either explicitly specify the names of the keys in the slice reducer object to define the keys in the output state object, or carefully rename the variables for the imported slice reducers to set up the keys when using the shorthand object literal syntax.
 
diff --git a/src/bindActionCreators.ts b/src/bindActionCreators.ts
index 3d63d7fe18..24e9c2050d 100644
--- a/src/bindActionCreators.ts
+++ b/src/bindActionCreators.ts
@@ -21,7 +21,7 @@ function bindActionCreator<A extends Action>(
  * and get a dispatch wrapped function in return.
  *
  * @param actionCreators An object whose values are action
- * creator functions. One handy way to obtain it is to use ES6 `import * as`
+ * creator functions. One handy way to obtain it is to use ES2015 `import * as`
  * syntax. You may also pass a single function.
  *
  * @param dispatch The `dispatch` function available on your Redux
diff --git a/src/combineReducers.ts b/src/combineReducers.ts
index 0a3c0b65b4..9c37a539c7 100644
--- a/src/combineReducers.ts
+++ b/src/combineReducers.ts
@@ -103,7 +103,7 @@ function assertReducerShape(reducers: {
  *
  * @param reducers An object whose values correspond to different reducer
  *   functions that need to be combined into one. One handy way to obtain it
- *   is to use ES6 `import * as reducers` syntax. The reducers may never
+ *   is to use ES2015 `import * as reducers` syntax. The reducers may never
  *   return undefined for any action. Instead, they should return their
  *   initial state if the state passed to them was undefined, and the current
  *   state for any unrecognized action.