chore: update issue template for feature proposal

Author: anikethsaha

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,25 +1,97 @@
----
-name: Feature request
-about: Suggest an idea for this project
+<!-- This is taken from https://github.com/eslint/rfcs -->
 
----
-<!-- Please don't delete this template or we'll close your issue -->
-<!-- Please use English language -->
-<!-- Before creating an issue please make sure you are using the latest version of Docsify. -->
-<!-- Please ask questions on StackOverflow 👉 https://stackoverflow.com/questions/ask?tags=docsify -->
+# (title goes here)
 
-## Feature request
+## Summary
 
-#### What problem does this feature solve?
+<!-- One-paragraph explanation of the feature. -->
 
+## Motivation
 
+<!-- Why are we doing this? What use cases does it support? What is the expected
+outcome? -->
 
-#### What does the proposed API look like?
+## Detailed Design
 
+<!--
+   This is the bulk of the RFC.
+   Explain the design with enough detail that someone familiar with docsify
+   can implement it by reading this document. Please get into specifics
+   of your approach, corner cases, and examples of how the change will be
+   used. Be sure to define any new terms in this section.
+-->
 
+## Documentation
 
-#### How should this be implemented in your opinion?
+<!--
+    How will this RFC be documented?
+-->
 
+## Drawbacks
 
+<!--
+    Why should we *not* do this? Consider why adding this into Docsify
+    might not benefit the project or the community. Attempt to think 
+    about any opposing viewpoints that reviewers might bring up. 
 
-#### Are you willing to work on this yourself?
+    Any change has potential downsides, including increased maintenance
+    burden, incompatibility with other tools, breaking existing user
+    experience, etc. Try to identify as many potential problems with
+    implementing this proposal as possible.
+-->
+
+## Backwards Compatibility Analysis
+
+<!--
+    How does this change affect existing Docsify users? Will any behavior
+    change for them? If so, how are you going to minimize the disruption
+    to existing users?
+-->
+
+## Alternatives
+
+<!--
+    What other designs did you consider? Why did you decide against those?
+    This section should also include prior art, such as whether similar
+    projects have already implemented a similar feature.
+-->
+
+## Open Questions
+
+<!--
+    This section is optional, but is suggested for a first draft.
+    What parts of this proposal are you unclear about? What do you
+    need to know before you can finalize this Proposal?
+
+    List the questions that you'd like reviewers to focus on. When
+    you've received the answers and updated the design to reflect them, 
+    you can remove this section.
+-->
+
+## Help Needed
+
+<!--
+    This section is optional.
+
+    Are you able to implement this Proposal on your own? If not, what kind
+    of help would you need from the team?
+-->
+
+## Frequently Asked Questions
+
+<!--
+    This section is optional but suggested.
+
+    Try to anticipate points of clarification that might be needed by
+    the people reviewing this Proposal. Include those questions and answers
+    in this section.
+-->
+
+## Related Discussions
+
+<!--
+    This section is optional but suggested.
+
+    If there is an issue, pull request, or other URL that provides useful
+    context for this proposal, please include those links here.
+-->