@@ -1,93 +0,0 @@
1−# How to make a Feature Request
2−
3−Adding features is hard work and has long term implications for Elm.
4−If you think your particular feature is important, help make it happen
5−by doing some of the background work that goes into actually adding it.
6−
7−### Before making a Request / Formatting:
8−
9− - Make sure your feature has not already been requested. Look through the
10− email list to find similar requests.
11− - Submit feature requests by emailing the list. This allows the broadest
12− discussion and does not clutter up the GitHub repository with speculative
13− issues. I'd prefer to use the GitHub issue tracker for bug tracking and
14− issues with the existing code base.
15− - Label all feature requests with a subject like "Request: _____". For
16− example, if you want to be the umpteenth person to request type classes,
17− you would use the subject "Request: Type Classes".
18−
19−### Body of the Request:
20−
21−Your request should address all of the following issues:
22−
23−**General Problem:** Clearly define the purpose of adding the feature.
24−What general problem do you want to solve? Why is that problem important?
25−Why is it important for a functional GUI language?
26−
27−**Specific Use-Cases:** What are the specific cases when the general problem
28−is actually an issue? How often does this case come up? Why are these cases
29−important to easily designing graphical user interfaces? Why are existing
30−solutions in Elm unsuitable?
31−
32−**Background Materials:** Are there relevant papers on the topic? Are there
33−languages or libraries that already have this feature? Organize this material
34−and provide a concise and helpful overview.
35−
36−**Alternatives:** What are all the ways to address the general problem or a
37−closely related problem? For example, the semantic flexibility of type classes
38−can be largely replicated with a module system in the style of ML.
39−What are the strengths and weakness of each of the alternative solutions?
40−
41−**Suggested Approach:** Outline your specific approach. How does it address
42−the general problem? How does it work? How hard is it going to be to add?
43−What other language features does it depend on that need to be added first?
44−Try to take a look at the relevant code to see if it would require significant
45−changes. If you are suggesting an API or library changes, include an interface
46−(a list of type signatures) for the functions you would like to add (perhaps
47−multiple interfaces if there are many good approaches).
48−
49−**Known Issues:** Search for issues that people have already found. Think of
50−any other possible downside and list them too. For example, one downside of
51−typeclasses is that they are globally defined for each type, so you cannot
52−have multiple `Ord` instances for Strings. This can lead to namespace pollution
53−within a project. In general you can only implement an "interface" once per
54−type, so it is very tricky to get the flexibility of ML's module functors.
55−
56−**Justification:** Why is the added complexity of your feature worth it? Discuss
57−both implementation complexity in the compiler, and conceptual complexity that
58−users must deal with. Why is your feature better than the alternative solutions?
59−Why is it okay to ignore the known issues? Is there any way to overcome the known
60−issues? Will it be difficult or confusing for users coming from JavaScript?
61−
62−### Some final notes:
63−
64−If for some reason you cannot provide details for some of these categories,
65−explain why the category is not applicable.
66−
67−Re-read before posting. Is your request constructive? Is it well organized?
68−Are there any details you forgot? Can anything be clarified or trimmed down?
69−Considering a request takes time, so be considerate about how much work a
70−reader has to do to take it seriously.
71−
72−A feature request is not an opportunity to be sassy or glib. Try to present
73−the information and argument clearly, concisely, thoroughly, and in an unbiased
74−manner.
75−
76−This is likely to be an iterative process. People will have comments and
77−questions. Everyone please be kind. Commenters, if you think you have a
78−concern, raise it as a question: "But what happens when you do blah?" instead
79−of "This will break when you do blah". Assume you have misunderstood their
80−proposal or only have a shallow understanding of it. Seek clarification, not victory.
81−
82−Comments are not a place for flame wars. Discuss specific issues. Vague
83−complaining and unsupported claims should either be forgotten or developed
84−into specific and well-supported concerns.
85−
86−I am always working hard to add cool stuff to Elm, and it is a lot of work.
87−I must prioritize issues to focus on the things that have the highest impact
88−for improving the quality of Elm, addressing the concerns of current users,
89−and making Elm more appealing for new users. I do not have infinite time,
90−so some things must receive more attention than others. I apologize in advance.
91−
92−And to summarize, just be cool! I want Elm to be really fun and easy to use,
93−and I want your projects to be amazing!