Updates around how we are thinking about improving the process

Release-planning-process.md

@@ -2,7 +2,7 @@ We often get questions about how we choose specific features to go into a partic
 
 Of course we have a [roadmap](roadmap), which defines a set of important features we want to support, and we have [a backlog milestone in our issue tracker](https://github.com/aspnet/EntityFrameworkCore/issues?q=is%3Aopen+is%3Aissue+milestone%3ABacklog+sort%3Areactions-%2B1-desc) in which issues can be up-voted, and a few other sources of ideas like [our UserVoice page](https://data.uservoice.com/forums/72025-entity-framework-core-feature-suggestions), but that doesn't automatically translate into a release plan.
 
-Our own planning process evolves, but here are some common questions we try to answer when deciding what to work on next:
+It is difficult to detail here the whole process we follow to plan a release, partly because a lot of it is discussing the specific features, opportunities and priorities, and partly because the process itself usually evolves with every release. However, it is relatively easy to summarize the common questions we try to answer when deciding what to work on next:
 
 1. **How many developers we think will use the feature and how much better will it make their applications/experience?** We aggregate feedback from many sources into this—Comments and votes on issues is one of those sources.
 
@@ -15,3 +15,5 @@ Our own planning process evolves, but here are some common questions we try to a
 5. **What is the synergy of the feature when used in combination with other products?** We tend to favor features that allow EF Core to be used with other products or to significantly improve the experience of using other products, such as .NET Core, the latest version of Visual Studio, Microsoft Azure, etc.
 
 6. **What are the capabilities of the people available to work on a feature, and how to best leverage these resources?** Each member of the EF team and even our community contributors have different amounts of experience in different areas and we have to plan accordingly. Even if we wanted to have “all hands on deck” to work on a feature like GroupBy translations, or many-to-many, that wouldn’t be practical.
+
+In the future we would like to add more opportunities for members of the developer community to provide an input into release plans, e.g. by making it easier to review proposed drafts of the features and of the release plan itself.