Part 1 - Required information
One paragraph explanation of the feature.
Why are we doing this? What use cases does it support? What is the expected outcome?
Explain the proposal as if it was already implemented in the GitHub package and you were describing it to an Atom user. That generally means:
- Introducing new named concepts.
- Explaining the feature largely in terms of examples.
- Explaining any changes to existing workflows.
- Design mock-ups or diagrams depicting any new UI that will be introduced.
Part 2 - Additional information
Why should we not do this?
- Why is this approach the best in the space of possible approaches?
- What other approaches have been considered and what is the rationale for not choosing them?
- What is the impact of not doing this?
- What unresolved questions do you expect to resolve through the Feature Request process before this gets merged?
- What unresolved questions do you expect to resolve through the implementation of this feature before it is released in a new version of the package?
- What related issues do you consider out of scope for this Feature Request that could be addressed in the future independently of the solution that comes out of this Feature Request?
- Can this functionality be introduced in multiple, distinct, self-contained pull requests?
- A specification for when the feature is considered "done."
- When this feature is shipped, what would we like to say or show in our Atom release blog post (example: http://blog.atom.io/2018/07/31/atom-1-29.html)
- Feel free to drop ideas and gifs here during development
- Once development is complete, write a blurb for the release coordinator to copy/paste into the Atom release blog