[docs] Bring back README intro

README.md

@@ -1,12 +1,18 @@
-# React Native’s Release Process
+# React Native Releases
+
+[![GitHub Issues](https://img.shields.io/github/issues/react-native-community/releases.svg)](https://github.com/react-native-community/releases/issues) ![Contributions welcome](https://img.shields.io/badge/contributions-welcome-orange.svg)
+
+Stay up-to-date with the release activities of [React Native](https://github.com/facebook/react-native/) by [watching](https://github.com/react-native-community/releases/subscription) for [status reports](https://github.com/react-native-community/releases/issues?q=is%3Aopen+is%3Aissue+label%3A%22release+status%22). Or you can follow along as the release notes are prepared and help reviewing the overall [changelog](https://github.com/react-native-community/releases/blob/master/CHANGELOG.md).
+
+## React Native’s Release Process
 
 At Facebook React Native is not consumed via released versions, instead they always consume the latest version of the `master` branch. This means that they are able to iterate fast for _their_ needs; if something is broken the fix is a single commit away.
 
 External users are of course similarly able to consume the latest `master` version, however this is most likely a too fast moving target for most–aside from turn around to get a fix in being longer.
 
 To reconcile these two different use-cases, React Native’s release process is a different one from the one many users are familiar within the JavaScript ecosystem.
 
-## The process at a high-level
+### The process at a high-level
 
 1. A branch for a new version is created from `master`–hereafter referred to as “the stable branch”. [⇒](./docs/release-process.md#initialize-the-process-for-a-new-version)
 1. A [release candidate][rc] is released from the stable branch, allowing the community to try it out and provide feedback–hereafter referred to as “the RC”. [⇒](./docs/release-process.md#publish-the-release-candidate)