[misc] Submitting a proposal updates

contributing/proposing-features/submitting-a-proposal.md

@@ -1,46 +1,24 @@
 # Submitting a proposal
 
-Before submitting a new proposal, please consider the following:
+Before you begin the process of submitting a proposal, please give the information in [Proposing features and enhancements](https://sailsjs.com/documentation/contributing/proposing-features-enhancements) a read. It could save you a lot of time!
 
-Many individuals and companies (large and small) are happily using Sails in production projects (both greenfield and mature) with the currently-released feature set today, as-is.  A lot of the reason for this is that Sails was built while the core team was running a development shop, where it was used to take many different kinds of applications from concept to production, and then to serve as the backend for those applications as they were maintained over the next few years.
+Now that you're certain a proposal is necessary, here's how to create one: 
 
-Much like the canonical case of Ruby on Rails, this means that Sails was designed from the beginning to be both developer-friendly and enterprise-friendly using a convention over configuration methodology.  **Conventions** make it quick and easy to build new Sails apps and switch between different existing Sails apps, while **configurability** allows Sails developers to be flexible and customize those apps as they mature using the full power of the underlying tool chain (configuration, plugins/overrides, Express, Socket.io, Node.js, and JavaScript).
+First, navigate to the Sails repository and do a search in the open pull requests and issues to make sure that somebody else hasn't already proposed your feature. 
++ Many Sails contributors receive GitHub notifications every time a new comment is posted; out of consideration for these individuals, please do not `*bump*` or `:+1:` feature proposals. Instead, write a concise (3-5 sentences) explanation of your real-world use case for the feature.
 
-Over the first year of Sails's life, the **configurability** requirement became even more important.  As the user base grew and Sails started to be used on all sorts of different projects, and by developers with all sorts of different preferences, the number of feature requests skyrocketed.  Sails solved this in 2013 by rewriting its core and becoming innately interoperable:
+If there is no existing pull request or issue for the feature you would like to add, please create an issue in the main Sails repository. 
++ Please make sure that your issue addresses the proposal _exclusively_. Mixing proposals with questions or bug fixes (or both!) is a great way to delay the resolution of all components of the issue. If you have a patch or question—related to the proposal or not—please address it in its own issue or pull request as appropriate.
++ The title of the issue should be a brief description of the proposed feature. See the title guidelines on the [Issue contributions](https://sailsjs.com/documentation/contributing/issue-contributions) page for guidance.
++ The description field of the issue should include the following:
+  - A concise (3-5 sentences), high-level summary of the feature you are proposing, in which you describe a real-world use case where the Sails app you are building or maintaining would be improved by your proposed feature or change. 
+  - A description in clear prose, and with links to relevant code files, of exactly why it is impossible (or burdensome to the point of absurdity) to implement your feature without changing Sails core. If this is not the case—that is, if it is possible to implement this feature as a plugin—please reconsider your proposed feature, as it is unlikely to be accepted by the core team. If you are the author of one or more plugins and feel that you or other users would benefit from having your work in Sails core, please contact the core team directly.
+  - If possible, a specification for this feature, including its configuration, usage, and implementation. If you don't have time to write out a thorough specification, please mention this in your proposal; it should be made clear that the task of specification would fall to another contributer with a similar use case. 
 
-+ Since Sails apps are just Node apps, you can take advantage of any of the [millions](bit.ly/npm-numbers) of NPM packages on http://npmjs.org.  (And more recently, you can also take advantage of any of the hundreds of automatically-documented machine functions curated from NPM at http://node-machine.org)
-+ Since Sails uses the same req/res/next pattern as Express and Connect, you can take advantage of any middleware written for those middleware frameworks in your app, such as Lusca (security middleware from Paypal) or morgan (HTTP logging util).
-+ Since Sails uses [Consolidate](https://github.com/tj/consolidate.js/), you can use any of the view engines compatible with Express such as Jade, Dust or Handlebars.
-+ Since Sails uses a familiar MVC project structure, you and/or other developers on your team can quickly get up to speed with how the app works, the database schema, and even have a general notion of where common configuration options live.
-+ Since Sails uses Grunt, you can install and use any of the thousands of available Grunt plugins on http://gruntjs.com/plugins in your app.
-+ Sails's hook system allows you to disable, replace, or customize large swaths of functionality in your app, including pieces of Sails core, such as replacing Grunt with Gulp.
-+ Waterline's adapter interface allows you to plug your models into any database such as Oracle, MSSQL, or Orient DB.
-+ Skipper's adapter interface allows you to plug your incoming streaming file uploads into any blob storage container such as S3, GridFS, or Azure.
-+ Sails's generator system allow you to completely control all files and folders that the Sails command-line tool generates when you run `sails new` or `sails generate *`.
 
-It is important to realize that today, most (but certainly not all) new features in Sails can be implemented using one or more of the existing plugin interfaces, rather than making a change to core.  If the feature you are requesting is an exception to that rule, then please proceed-- but realize that perhaps the most important part of your proposal is a clear explanation of why what you're suggesting is not possible today.
+Proposals that do not meet these guidelines will be closed with a response asking that the submitter review this contribution guide.  If this happens to you, please understand that _it is nothing personal_ and that it may even happen again.  Please realize that a tremendous amount of effort has been put into the existing plugin systems in Sails, so any proposed change to core must be carefully considered in relation to how it would affect existing plugins, apps, and future development of the framework.  Many Sails contributors have become intimately familiar with how the various systems in Sails interact and will be willing to help you out, but in order for that process to be efficient, it is important that all new features and enhancements follow a common set of ground rules.
 
-The core maintainers of Sails review all feature proposals, and we do our best to participate in the discussion in these PRs.  However, many of these proposals can sometimes involve back and forth discussion that could require them to be open for months at a time.  So it is important to understand going in that if you are proposing a feature, the onus is on you to fully specify how that feature would work; i.e. how it would be used, how it would be configured, and in particular its implementation-- that is, which modules would need to change to make it a reality, how it would be tested, whether it would be a major or minor-version breaking change, and the additions and/or modifications that would be necessary to the official Sails documentation.
-
-With that in mind, to submit a proposal for a new feature, or an extension to an existing feature, please take the following steps:
-
-
-0. First, look at the `backlog` table in [ROADMAP.MD](https://github.com/balderdashy/sails/blob/master/ROADMAP.md) and also search open pull requests in that file to make sure your change hasn't already been proposed.
-  - If the PR (pull request) has been merged, it means that a core maintainer has (A) looked over the proposal and discussion in the pull request, (B) personally agreed to him or herself that the feature would be a good fit for Sails core, and (C) confirmed the decision with [@mikermcneil](https://github.com/mikermcneil).  It also means that the proposal is now in the backlog in ROADMAP.md, which means that the core team would be willing to merge a pull request with code changes adding the feature to Sails core (assuming that pull request follows our coding style conventions and the guidelines in this section).
-  - If the PR has been closed without being merged, it means that the core team has decided that the feature request should not be a part of Sails core.  Just because the proposal is closed does not mean the feature will never be achievable in Sails, it just means that (A) it would need to be specced differently to be merged or (B) it would need to be implemented as a plugin (i.e. a hook, adapter, generator, view engine, grunt/gulp task, etc.)
-  - If the PR is _open_, it means that either (A) it was recently posted, (B) there is still an active discussion in progress, (C) that a core maintainer has not had time to look into it yet, or most commonly (D) that one or more core maintainers have looked at and potentially even responded to the proposal, but the team decided there wasn't enough information to make a firm "yes" or "no" judgement call.  This fourth scenario is quite common, since it sometimes takes a great deal of time to develop a specification that is thorough enough to merge into the backlog.  The core maintainers review and contribute to proposals as much as time allows, but ultimately it is the responsibility of the developers requesting a feature to do the work of fully speccing it out.
-  - While some of Sails's core maintainers carefully filter email from GitHub (because they also like to get other email sometimes), many contributors receive GitHub notifications every time a new comment is posted.  Out of respect for them, please do not `*bump*` or `:+1:` feature proposals.   Instead, write a concise (3-5 sentences) explanation of your real-world use case for the feature.
-1. If it doesn't already exist, create a pull request editing [ROADMAP.MD](https://github.com/balderdashy/sails/blob/master/ROADMAP.md) (the easiest way to do this is opening ROADMAP.md while logged in to GitHub and clicking the "Edit" button).
-2. Add a new row to the **Backlog** table with a very short description of the feature, then submit the change as a pull request (the easiest way to do this is to use the GitHub UI as discussed above, make your changes, then follow the on-screen instructions).
-3. In the description for your pull request:
-  - First, write out a high-level summary of the feature you are proposing as a concise description (3-5 sentences) focused around a convincing real-world use case where the Sails app you are building or maintaining for your job, your clients, your company, your non-profit work, or your independent hobby project would be made easier by this feature or change.
-  - Next, describe in clear prose with relevant links to code files exactly why it would be difficult or impossible to implement the feature without changing Sails core (i.e. using one or more of the existing plugin mechanisms).  If this is not the case, and this feature could be implemented as a plugin, then please reconsider writing your proposal (it is unlikely the core team will be able to accept it).  If you are the author of one or more plugins, and feel that you or other users would benefit from having your work in Sails core, please contact the core team directly (see the instructions for submitting "high-level questions or concerns about the project" above).
-  - Finally, if you have time, take a first pass at proposing a spec for this feature (its configuration, usage, and how it would be implemented).  If you do not have time to write out a first draft of a thorough specification, please make that point in your feature request, and clarify that it would be up to other contributors with the same or a similar use case to finish this proposal.
-
-
-Proposals which do not meet these guidelines will be closed with a response asking that the submitter review this contribution guide.  If this happens to you, _realize it is nothing personal_ and that it may even happen again.  Please consider that a tremendous amount of effort has been put into the existing plugin systems in Sails, and so any proposed change to core must be carefully considered in relation to how it would affect existing plugins, existing apps, and future development of the framework.  Many Sails contributors have become intimately familiar with how the various systems in Sails interact and will be willing to help you out; but in order for that process to be efficient, it is important that all new features and enhancements follow a common set of ground rules.
-
-> ###### If your feature proposal is merged...
-> Having your proposal merged does not necessarily mean that you are responsible for _implementing_ the feature; and you certainly won't be responsible for _maintaining_ future changes which might affect that feature for all eternity.  _That_ privilege is reserved for Mike and the rest of the core team; which is why it is so important to spec out the vision for the usage, configuration, and implementation of your proposed feature from day 1.  Working out this sort of a detailed proposal is not an easy task, and often involves more effort than the actual implementation.  But if a proposal is accepted, it becomes part of the project's mission: which means once it is implemented and merged, the core team is committed to maintaining it as a part of Sails.
+> ###### If your feature proposal is accepted...
+> Having your proposal accepted does not necessarily mean that you are responsible for _implementing_ the feature, and you certainly won't be responsible for _maintaining_ future changes which might affect that feature for all eternity.  _That_ privilege is reserved for Mike and the rest of the core team, which is why it is so important to spec out the vision for the usage, configuration, and implementation of your proposed feature from day one.  Working out this sort of a detailed proposal is not an easy task, and often involves more effort than the actual implementation.  If a proposal is accepted, it becomes part of the project's mission, and once a proposal is implemented and merged, the core team is committed to maintaining it as a part of Sails.
 
 <docmeta name="displayName" value="Submitting a proposal">