docs: new “Getting Started” section

docs/start/community.md

@@ -0,0 +1,45 @@
+---
+title: Community
+description: Community resources for learning Remix and related technologies
+order: 5
+---
+
+# Community
+
+We work hard to keep the Remix community a friendly place where people want to hang out, help, and be helped. We're all here just trying to build great websites and make the web better.
+
+To that end, please keep in mind [our code of conduct][our-code-of-conduct].
+
+- [Remix Discord][remix-discord-server] - A great place to have conversations, ask and answer questions, all about Remix.
+
+- [GitHub Discussions][git-hub-discussions-forum] - This is the best place to propose changes to Remix. The team uses it to gauge interest and understand use cases.
+
+- [Remix Twitter][twitter] - Tips, updates, and news about Remix from the team.
+
+- [Examples][the-examples-repository] - Dozens of Remix examples from the team and community.
+
+- [Remix Conf][remix-conf] - A yearly conference all about Remix with talks primarily from the community.
+
+- [Remix Mailing List][official-remix-team-mailing-list] - Not-so-regular email from the Remix team letting you know what the team is up to.
+
+- [Meetups][the-remix-meetup-page] - There are Remix Meetups all over the world with thousands of members. Some online, some in person, and some a hybrid of the two.
+
+- [Remix Guide][remix-guide] - A wonderful community site that gathers together everything that's going on in the Remix ecosystem: online courses, blog posts, app templates, events and more.
+
+- [Moulton][moulton] - Community Remix newsletter
+
+- [Releases on GitHub][releases-on-git-hub] - Not a bad idea to subscribe to Remix releases so you know what's coming.
+
+[our-code-of-conduct]: https://github.com/remix-run/remix/blob/main/CODE_OF_CONDUCT.md
+[remix-discord-server]: https://rmx.as/discord
+[git-hub-discussions-forum]: https://github.com/remix-run/remix/discussions
+[the-examples-repository]: https://github.com/remix-run/examples
+[official-remix-team-mailing-list]: https://remix.run/newsletter
+[moulton]: https://www.readmoulton.com
+[releases-on-git-hub]: https://github.com/remix-run/remix/releases
+[official]: ../tutorials/blog
+[tutorials]: ../tutorials/jokes
+[remix-conf]: /conf
+[the-remix-meetup-page]: https://rmx.as/meetup
+[remix-guide]: https://remix.guide
+[twitter]: https://twitter.com/remix_run

docs/start/development.md

@@ -0,0 +1,29 @@
+---
+title: API Development Strategy
+---
+
+# API Development Strategy
+
+Our goals for major releases are:
+
+- Developers can opt-in to new features and changes individually as they are released _in the current major version_ instead of everything all at once in a new major release.
+- Having opted-in to features ahead-of-time, developers can upgrade to new major versions without making changes to application code.
+
+## Unstable APIs and Future Flags
+
+New features are introduced with `unstable_feature` flags and API prefixes.
+
+- This allows us to iterate on the API with early adopters with breaking changes between minor releases while the API is marked unstable.
+- It avoids churning the API for all users and arriving at better APIs in the stable releases.
+- When an unstable feature is ready, the prefix is removed and the feature is shipped in the next minor release. The API will no longer change between minor releases.
+
+If you are using `unstable_*` future flags or APIs, it's important to check the release notes of every minor release because the behavior or API could change. It's also important to gives us feedback so we can make it better before the final release!
+
+## Breaking Changes and Future Flags
+
+Breaking changes are introduced in the current major version behind a future flag. If we are on `v2` then a breaking future flag would be something like `v3_somethingDifferent`.
+
+- Both versions work in parallel: the current `v2` behavior as well as the new `v3_somethingDifferent` behavior.
+- This allows apps to update one change at a time in the current major release, instead of everything all at once in the next major release. Update on your schedule.
+- If you have all `v3_*` future flags enabled, then upgrading to `v3` when it is released shouldn't require any changes to your code.
+- Some breaking future flags start as `unstable_*` flags and may change between minor releases. After they become `v3_*` future flags the API should no longer change.

docs/start/index.md

@@ -0,0 +1,4 @@
+---
+title: Getting Started
+order: 1
+---