enso-org/enso
1
1
Fork 0
mirror of https://github.com/enso-org/enso.git synced 2024-12-23 07:12:20 +03:00
Code Issues Projects Releases Wiki Activity

Miscellaneous documentation fixes (#770)

Browse Source
This commit is contained in:
Ara Adkins 2020-05-20 12:21:52 +01:00 committed by GitHub
parent bcbed0e232
commit 55f0839c39
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 399 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
.github/settings.yml vendored
View File

@ -161,11 +161,35 @@ labels:
- name: "Type: Question"
color: "#ede2fe"
description: A question about Enso
- name: "Type: RFC"
color: "#ede2fe"
description: An RFC proposing a change to Enso
- name: "RFC: Active"
color: "#e4decb"
description: An RFC being actively implemented
- name: "RFC: Discussion"
color: "#e4decb"
description: An RFC preliminarily complete
- name: "RFC: FCP"
color: "#e4decb"
description: An RFC in the final comment period
- name: "RFC: Accepted"
color: "#e4decb"
description: An RFC accepted into Enso
- name: "RFC: Rejected"
color: "#e4decb"
description: An RFC rejected for inclusion in Enso
- name: "RFC: Postponed"
color: "#e4decb"
description: An RFC that has been postponed
# Teams configuration
teams:
- name: developers
permission: push
- name: moderators
permission: maintain
# Branch protection
branches:

104
docs/CODE_OF_CONDUCT.md
View File

@ -7,90 +7,106 @@ order: 3
---
# The Enso Code of Conduct
This document contains the code of conduct for _all_ venues associated with the
Enso project.
<!-- MarkdownTOC levels="2,3" autolink="true" -->
- [Conduct](#conduct)
- [Moderation](#moderation)
- [Moderators](#moderators)
- [Credit](#credit)
<!-- /MarkdownTOC -->
## Conduct
**Contact**: [luna-mods@luna-lang.org](mailto:luna-mods@luna-lang.org)
**Contact**: [moderators@enso.org](mailto:moderators@enso.org)
- We are committed to providing a friendly, safe and welcoming environment for
- We are committed to providing a friendly, safe and welcoming environment for
all, regardless of level of experience, gender identity and expression, sexual
orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, nationality, or other similar characteristic.
- On Discord, please avoid using overtly sexual nicknames or other nicknames
- On Discord, please avoid using overtly sexual nicknames or other nicknames
that might detract from a friendly, safe and welcoming environment for all.
- Please be kind and courteous. There's no need to be mean or rude.
- Respect that people have differences of opinion and that every design or
implementation choice carries a trade-off and numerous costs. There is seldom
- Respect that people have differences of opinion and that every design or
implementation choice carries a trade-off and numerous costs. There is seldom
a right answer.
- Please keep unstructured critique to a minimum. If you have solid ideas you
- Please keep unstructured critique to a minimum. If you have solid ideas you
want to experiment with, make a fork and see how it works.
- We will exclude you from interaction if you insult, demean or harass anyone.
- We will exclude you from interaction if you insult, demean or harass anyone.
That is not welcome behaviour. We interpret the term "harassment" as including
the definition in the
[Citizen Code of Conduct](http://citizencodeofconduct.org/); if you have any
lack of clarity about what might be included in that concept, please read
their definition. In particular, we don't tolerate behaviour that excludes
the definition in the
[Citizen Code of Conduct](http://citizencodeofconduct.org/). If you have any
lack of clarity about what might be included in that concept, please read
their definition. In particular, we don't tolerate behaviour that excludes
people in socially marginalized groups.
- Private harassment is also unacceptable. No matter who you are, if you feel
you have been or are being harassed or made uncomfortable by a community
member, please contact one of the moderators or any of the
[Enso moderation team][mod_team] immediately. Whether you're a regular
contributor or a newcomer, we care about making this community a safe place
for you and we've got your back.
- Likewise any spamming, trolling, flaming, baiting or other attention-stealing
- Private harassment is also unacceptable. No matter who you are, if you feel
you have been or are being harassed or made uncomfortable by a community
member, please contact one of the [moderators](#moderators) immediately, or
send an email to the [moderator team](#mod_team).
Whether you're a regular contributor or a newcomer, we care about making this
community a safe place for you and we've got your back.
- Likewise any spamming, trolling, flaming, baiting or other attention-stealing
behaviour is not welcome.
## Moderation
These are the policies for upholding our community's standards of conduct. If
you feel that a thread needs moderation, please contact the
[Enso moderation team][mod_team].
These are the policies for upholding our community's standards of conduct. If
you feel that a thread needs moderation, please contact the
[Enso moderation team](#moderators).
1. Remarks that violate the Enso standards of conduct, including hateful,
hurtful, oppressive, or exclusionary remarks, are not allowed. Cursing is
1. Remarks that violate the Enso standards of conduct, including hateful,
hurtful, oppressive, or exclusionary remarks, are not allowed. Cursing is
allowed, but never targeting another user, and never in a hateful manner.
2. Remarks that moderators find inappropriate, whether listed in the code of
2. Remarks that moderators find inappropriate, whether listed in the code of
conduct or not, are also not allowed.
3. Moderators will first respond to such remarks with a warning.
4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of
4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of
the communication channel to cool off.
5. If the user comes back and continues to make trouble, they will be banned,
5. If the user comes back and continues to make trouble, they will be banned,
i.e., indefinitely excluded.
6. Moderators may choose at their discretion to un-ban the user if it was a
6. Moderators may choose at their discretion to un-ban the user if it was a
first offense and they offer the offended party a genuine apology.
7. If a moderator bans someone and you think it was unjustified, please take it
up with that moderator, or with a different moderator, **in private**.
7. If a moderator bans someone and you think it was unjustified, please take it
up with that moderator, or with a different moderator, **in private**.
Complaints about bans in-server are not allowed.
8. Moderators are held to a higher standard than other community members. If a
moderator creates an inappropriate situation, they should expect less leeway
8. Moderators are held to a higher standard than other community members. If a
moderator creates an inappropriate situation, they should expect less leeway
than others.
In the Enso community we all aim to go the extra mile and look out for each
In the Enso community we all aim to go the extra mile and look out for each
other. We don't just aim to be technically unimpeachable, but we try to be our
very best selves. In particular, avoid flirting with offensive or sensitive
very best selves. In particular, avoid flirting with offensive or sensitive
topics, particularly if they're off-topic. Doing so all too often leads to
unnecessary fights, hurt feelings and damaged trust; worse, it can drive people
away from the community entirely.
If someone takes issue with something you said or did, resist the urge to be
defensive. Just stop what it was they complained about and apologise. Even if
you feel that you were misinterpreted or unfairly accused, it is likely that
If someone takes issue with something you said or did, resist the urge to be
defensive. Just stop what it was they complained about and apologise. Even if
you feel that you were misinterpreted or unfairly accused, it is likely that
there was something you could've communicated better — remember it is _your_
responsibility to make your fellow Enso contributors comfortable. Everyone wants
to get along, and everyone in this community is here first and foremost to talk
about cool technology! You will find that people will be eager to assume good
intent and forgive as long as there is an atmosphere of trust.
about cool technology! You will find that people will be eager to assume good
intent and forgive as long as there is an atmosphere of trust.
The enforcement policies listed above apply to all official Enso venues. This
includes the official discord and GitHub repositories under `luna`.
_Adapted from the_
_[Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling)_
_as well as the_
_[Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/)._
> Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling)
> as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).
[mod_team]: [luna-mods@luna-lang.org](mailto:luna-mods@luna-lang.org)
### Moderators
The following members of the Enso organisation can be contacted as moderators:
## Credits
- [`@joenash`](https://github.com/joenash)
- [`@iamrecursion`](https://github.com/iamrecursion)
Alternatively, you can send an email to the moderation team at
[moderators@enso.org](mailto:moderators@enso.org).
## Credit
This code of conduct is adapted from the [Rust](https://rust-lang.org) code of
conduct. Many thanks to the Rust community for being such an exemplar of the
open-source spirit!

59
docs/CONTRIBUTING.md
View File

@ -28,7 +28,7 @@ sections of this document are linked below:
<!-- /MarkdownTOC -->
All contributions to Enso should be in keeping with our
[Code of Conduct](https://github.com/luna/luna/blob/CODE_OF_CONDUCT.md).
[Code of Conduct](./CODE_OF_CONDUCT.md).
## The Contributor License Agreement
As part of your first contribution to this repository, you need to accept the
@ -42,17 +42,28 @@ The CLA you sign applies to all repositories associated with the Enso project,
so you will only have to sign it once at the start of your contributions.
## Issues
If you are looking for somewhere to start, check out the `Help Wanted` tag in
the following repositories:
- [Enso](https://github.com/luna/enso/labels/Status%3A%20Help%20Wanted)
- [Enso Studio](https://github.com/luna/ide/labels/Status%3A%20Help%20Wanted)
If you're wanting to get involved with Enso's development and are looking for
somewhere to start, you can check out the following tags in our issues:
- [Good First Issue](https://github.com/luna/enso/labels/Status%3A%20Good%20First%20Issue)
- [Help Wanted](https://github.com/luna/enso/labels/Status%3A%20Help%20Wanted)
You can use the "Size" and "Difficulty" labels that should be assigned to every
issue to get a better idea of how much work a given issue might be.
## Feature Enhancements
If you feel like you have a suggestion for a change to the way that Enso works
as a language, please open an issue in our
[RFCs Repository](https://github.com/luna/luna-rfcs), rather than in this one!
New features and other significant language changes must go through the RFC
process so they can be properly discussed.
as a language, please take a look at the
[Enso RFC process](./rfcs/README.md) to learn how to file an RFC for the
project.
In essence, the RFC process provides a way to propose major changes to the
language, the compiler, and the runtime in a way that ensures that they get
seen and discussed by all the major stakeholders involved.
If, on the other hand, you're asking for a smaller feature, please feel free to
submit a [feature request](https://github.com/luna/enso/issues/new?assignees=&labels=Type%3A+Enhancement&template=feature-request.md&title=)
to the repository.
## Bug Reports
While it's never great to find a bug, they are a reality of software and
@ -61,7 +72,7 @@ about, so report as many bugs as you can! If you're not sure whether something
is a bug, file it anyway!
**If you are concerned that your bug publicly presents a security risk to the
users of Enso, please look at our [security guidelines](./security.md).**
users of Enso, please look at our [security guidelines](./SECURITY.md).**
Even though GitHub search can be a bit hard to use sometimes, we'd appreciate if
you could
@ -70,7 +81,8 @@ your issue before filing a bug as it's possible that someone else has already
reported the issue. We know the search isn't the best, and it can be hard to
know what to search for, so we really don't mind if you do submit a duplicate!
Opening an issue is as easy as following [this link](https://github.com/luna/enso/issues/new?template=bug-report.md)
Opening an issue is as easy as following
[this link](https://github.com/luna/enso/issues/new?template=bug-report.md)
and filling out the fields. The template is intended to collect all the
information we need to best diagnose the issue, so please take the time to fill
it out accurately.
@ -91,7 +103,7 @@ look at the design documentation for the language. These files explain provide
both a rigorous specification of Enso's design, but also insight into the _why_
behind the decisions that have been made.
These can be found in [`doc/design/`](doc/design/), and are organised by the
These can be found in [`docs/design/`](docs/design/), and are organised by the
part of the compiler that they relate to.
### System Requirements
@ -277,7 +289,7 @@ getting the project into a working state in IntelliJ.
with an open SBT shell, which can be interacted with as described above. You
will want to use scalafmt for formatting of Scala code, and install Google
Java Format for formatting Java code. For more information see the relevant
[Style Guides](doc/).
[Style Guides](docs/style-guide).
However, as mentioned in the [Troubleshooting](#troubleshooting) section below,
the forked nature of execution in the SBT shell means that we can't trivially
@ -381,8 +393,8 @@ Please make all pull requests against the `master` branch.
the tests yourself locally first! This can be done by running `test` in the
`enso` project in sbt.
- Additionally, please ensure that your code conforms to the Enso style guides,
particularly the [Scala Style Guide](./doc/scala-style-guide.md) and the
[Java Style Guide](./doc/java-style-guide.md).
particularly the [Scala Style Guide](./docs/style-guide/scala.md) and the
[Java Style Guide](./docs/style-guide/java.md).
Make sure you perform these checks before _every_ pull request. You can even add
[git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) before
@ -403,12 +415,13 @@ please feel free to discuss the suggestions and comments! We can only achieve
the best results through open collaboration.
## Documentation
Documentation improvements are very welcome! The source for the Enso, Book can be
found in [`luna/luna-book`](https://github.com/luna/luna-book), but most of the
API documentation is generated directly from the code!
Documentation improvements are very welcome! For now, the main documentation
available is the _developer_ documentation for the language, which can be found
at the [dev docs site](https://dev.enso.org). The source for this documentation
is found in the [`docs/`](./docs/) folder, and can be altered from there.
Documentation pull requests are reviewed in exactly the same way as normal pull
requests.
Documentation pull requests will be reviewed in exactly the same way as normal
pull requests.
To find documentation-related issues, sort by the
[Category: Documentation](hhttps://github.com/luna/enso/labels/Category%3A%20Documentation)
@ -431,7 +444,8 @@ If you're looking for somewhere to start, take a look at the
[Difficulty: Beginner](https://github.com/luna/enso/labels/Difficulty%3A%20Beginner)
issue label, as well as the
[Status: Help Wanted](https://github.com/luna/enso/labels/Status%3A%20Help%20Wanted)
label.
and
[Status: Good First Issue](https://github.com/luna/enso/labels/Status%3A%20Good%20First%20Issue) labels.
## Out-of-Tree Contributions
As helpful as contributing to Enso directly is, it can also be just as helpful
@ -444,5 +458,6 @@ to contribute in other ways outside this repository:
For people new to Enso, and just starting to contribute, or even for more
seasoned developers, some useful places to look for information are:
- The [design documentation](doc/design/).
- The [design documentation](docs/).
- The community! Don't be afraid to ask questions.

1
docs/README.md
View File

@ -32,6 +32,7 @@ It is broken up into categories as follows:
server, its protocol, and how it integrates with the runtime.
- [**Polyglot:**](./polyglot) Information on Enso's polyglot functionality, and
how it is integrated into the surface Enso language.
- [**RFCs:**](./rfcs) RFCs for Enso's development and evolution.
- [**Runtime:**](./runtime) Specification and documentation of the way that the
Enso runtime is designed and implemented.
- [**Semantics:**](./semantics) A specification of Enso's semantics.

4
docs/language-server/README.md
View File

@ -1,12 +1,12 @@
---
layout: section-summary
title: Language Server Documentation
title: Language Server
category: language-server
tags: [language-server, readme]
order: 0
---
# Language Server Documentation
# Language Server
The Enso Language Server is responsible for providing language services to the
Enso IDE (and other clients). This mainly involves speaking the Enso protocol
and orchestrating the runtime in response to this. It is responsible for:

87
docs/rfcs/0001-rfc-template.md Normal file
View File

@ -0,0 +1,87 @@
---
layout: developer-doc
title: RFC Template
category: rfcs
tags: [rfcs, specification]
order: 1 # Should match the RFC Number
---
---
> **Feature Name:** A unique name for the feature
> **Start Date:** Today's date (YYYY-MM-DD)
> **Change Type:** Breaking / Non-Breaking (delete as appropriate)
> **RFC Dependencies:** List any RFCs that this one depends on.
> **RFC PR:** Leave Empty
> **Enso Issue:** Leave Empty
> **Implemented:** Leave blank, this will be filled with the first version of
the relevant tool where it is implemented.
# Summary
A one-paragraph, high-level summary of the proposal.
# Motivation
Why should we make this change? What use-cases does it support? What benefits
does it bring to the ecosystem? Explain why the status quo is insufficient or
not ideal.
# Guide-Level Explanation
Explain the proposal as if teaching the feature(s) to a newcomer to Enso. This
should usually include:
- Introduction of any new named concepts.
- Explaining the feature using motivating examples.
- Explaining how Enso programmers should _think_ about the feature, and how it
should impact the way they use the language. This should aim to make the
impact of the feature as concrete as possible.
- If applicable, provide sample error messages, deprecation warnings, migration
guidance, etc.
- If applicable, describe the differences in teaching this to new Enso
programmers and experienced Enso programmers.
For implementation-oriented RFCs, this section should focus on how contributors
to the project should think about the change, and give examples of its concrete
impact. For policy-level RFCs, this section should provide an example-driven
introduction to the policy, and explain its impact in concrete terms.
# Specification-Level Explanation
This is the technical portion of the RFC and should be written as a
specification of the new feature(s). It should provide a syntax-agnostic
description of the planned feature, and include sufficient detail to address the
following points:
- Impact on existing feature(s) or functions.
- Interactions with other features.
- A clear description of how it should be implemented, though this need not
contain precise references to internals where relevant.
- An explanation of all corner cases for the feature, with examples.
This section should be written in comprehensive and concise language, and may
include where relevant:
- The grammar and semantics of any new constructs.
- The types and semantics of any new library interfaces.
# Drawbacks
A description of why we _should not_ do this. Write this section as if you are
picking apart your proposal.
# Rationale and Alternatives
A few paragraphs addressing the rationale for why this design is the best
possible design for this feature in its design space. It should address how the
proposed design resolves the motivating factors.
A few paragraphs addressing alternative designs for the feature, and the reasons
for not choosing them.
A paragraph or two addressing the impact of not including this feature.
# Unresolved Questions
This section should address any unresolved questions you have with the RFC at
the current time. Some examples include:
- What parts of the design will require further elaboration before the RFC is
complete?
- Which portions of the design will need resolution during the implementation
process before the feature is made stable.
- Are there any issues related to this RFC but outside its scope that could be
addressed in future independently of this RFC? If so, what are they?

188
docs/rfcs/README.md Normal file
View File

@ -0,0 +1,188 @@
---
layout: section-summary
title: Enso RFC Process
category: runtime
tags: [rfcs, readme]
order: 0
---
# The Enso RFC Process
Like any Open Source language, Enso welcomes interaction from the community, as
we believe that only through the community's suggestions and feedback can we
make Enso the best it can be.
To this end, this repository defines a process to be followed for those people
that want to make 'substantial' changes to the Enso language, the Enso compiler
and runtime, or even this RFC process itself. What we define as a 'substantial'
change is in flux based on community norms and in relation to the portion of
the ecosystem being changed.
Substantial changes may thus include the following:
- Semantic or syntactic changes to Enso that aren't related to fixing a
pre-existing bug.
- Adding or removing language features.
- Changes to the interface between the language and its standard library.
- Additions to and removals from the standard library.
The following are examples of changes that do not need to follow the RFC
process:
- Refactoring of the compiler or libraries that does not change any semantics.
- Additions or alterations that improve numerical metrics (e.g. performance
improvements, error detection, ergonomics improvements).
- Additions invisible to the users of the language (e.g. new APIs internal to
the compiler that do not fall under the categories for 'substantial' changes
listed above).
Before contributing an RFC, please ensure that you have read and agree with the
[licensing terms](#../../LICENSE) under which this repository operates, and that
you have signed the [CLA](../CONTRIBUTING.md#the-contributor-license-agreement).
<!-- MarkdownTOC levels="2,3" autolink="true" -->
- [Creating an RFC](#creating-an-rfc)
- [Before Creating an RFC](#before-creating-an-rfc)
- [The RFC Process](#the-rfc-process)
- [Reviewing RFCs](#reviewing-rfcs)
- [The RFC Life-Cycle](#the-rfc-life-cycle)
- [Active RFCs](#active-rfcs)
- [RFC Implementation](#rfc-implementation)
- [RFC Postponement](#rfc-postponement)
- [Credits](#credits)
<!-- /MarkdownTOC -->
## Creating an RFC
While informal, we do aim to provide a basic outline for the process of creating
an RFC. The intention of this process is that RFCs arrive in a state with enough
detail to spark discussion, and then evolve through discussion with all
interested parties.
### Before Creating an RFC
Keep in mind that a hastily-created RFC can hurt discussion and its chances of
being accepted, even if the idea proposed is excellent! A half-baked proposal,
a previously-rejected idea, or a feature that doesn't align with our vision for
Enso could be rejected swiftly, making the unprepared contributor feel
demotivated. Doing a little bit of preparatory legwork can make the RFC process
that much more smooth.
While there is no specific process for submitting an RFC, we do recommend that
you talk to other members of the community to find out whether your proposal
would have support, and fits with the broader vision for Enso as a whole.
If the idea receives encouraging feedback from the core team, as well as the
community, it is an indication that the RFC is worth pursuing.
### The RFC Process
To summarise the end goal of the RFC process, the aim is to merge the proposal
(as a markdown file) into the RFC Repository. At this point, the RFC becomes
'Active', and may then be implemented.
If this is your first contribution to the Enso RFC process, please ensure that
you have signed the Enso Contributor License Agreement.
The process for creating an RFC can be outlined as follows:
1. Fork this repository.
2. Copy [`0001-rfc-template.md`](./0001-rfc-template.md) to a new file
`0000-my-proposal.md`, where `my-proposal` is a short and descriptive name
for the feature.
3. Fill in the RFC Template for your feature. Take care with the details as RFCs
that don't put thought into the design or its impacts, or are disingenuous
about the drawbacks or alternatives are likely to meet a poor reception. One
of the key points for considering RFCs is how they fit with the vision for
Enso as a whole.
4. Submit a [Pull Request](https://github.com/luna/enso/pulls). Please give
the PR a descriptive title (`RFC: My Feature`). The Pull Request will be
open for feedback and discussion from the community and core team, and the
author should be open to revising it in response to this feedback. The RFC
will be assigned a shepherd from the core team who will be responsible for
managing the RFC alongside the author.
5. Evolve the RFC. Build consensus around the feature through your revisions.
Feel free to reach out to the shepherd assigned to your proposal for
discussion, as well as help identifying the key stakeholders and obstacles.
6. The core team will participate in the discussion on the PR thread, and will
summarise any offline discussion in the same thread.
7. Once the RFC has reached a stable point, the shepherd will propose that the
RFC enters the Final Comment Period (FCP), as well as a disposition for the
RFC: _Accept_, _Close_ or _Postpone_. It should be noted that taking this
step does not require consensus, and should include a summary of the previous
discussion and changes.
8. The FCP lasts for 10 calendar days. This gives all stakeholders an ample
chance to raise any final objections or comments before a decision is made.
If substantial new arguments emerge during the FCP, the FCP may be cancelled.
9. The RFC has a final decision reached, and is either Accepted (where it is
merged into the repository after having an RFC number assigned to it),
Postponed, where the PR is tagged and closed, or Rejected and closed.
### Reviewing RFCs
While the RFC pull request is under discussion, the shepherd may organise
meetings with the author and stakeholders to discuss the issue(s) in more
detail. A summary from this meeting will be compiled by the shepherd and posted
back to the pull request.
## The RFC Life-Cycle
RFCs proceed through their life-cycle in this repository as follows:
1. The Pull Request is submitted. The repository manager assigns appropriate
labels to the RFC so that the relevant stakeholders can find it. It is also
assigned a shepherd and tagged for discussion.
2. Once discussion has stabilised, the RFC is proposed for the Final Comment
Period, and tagged as such.
3. At the end of the FCP, the RFC will be tagged with the decision made.
4. If the RFC is accepted, it is then marked as [Active](#active-rfcs) and can
be merged into this repository.
5. Once merged, implementation can be commenced and pull requested.
### Active RFCs
An RFC being 'Active' should not be viewed as a rubber stamp, and in particular
it does _not_ mean that the feature will be ultimately merged into Enso. It does
mean that, in principle, stakeholders are in agreement on the feature and are
amenable to it being merged.
Being accepted doesn't mean that there is a priority assigned to its
implementation, or a developer dedicated to implementing it. While it is _not_
necessary (and in some cases not recommended) for the RFC author to write the
implementation, it is likely to result in the RFC being seen to completion more
swiftly than it otherwise would be.
Once accepted and active, small modifications to the RFC can be made via
follow-on pull requests. While we usually intend for RFCs to reflect the final
design, interim changes may necessitate small alterations to keep the RFC in
sync with the final implementation.
Please note that the RFC should not be substantially changed at this point. If
substantial changes are required, they should take place as a new RFC, linked to
and from the old.
### RFC Implementation
Some accepted RFCs are vital features that need to be implemented as soon as
possible, while others can wait until a so-inclined developer comes along. Every
accepted RFC is assigned a tracking issue in the
[Luna](https://github.com/luna/enso/) repository, and is then assigned a
priority via the Enso repository triage process.
The author of an RFC is not obligated to implement it. Of course, the RFC author
(like any other developer) is welcome to post an implementation for review after
the RFC has been accepted.
If you are interested in working on the implementation for an "active" RFC, but
cannot determine if someone else is already working on it, feel free to ask
(e.g. by leaving a comment on the associated issue).
### RFC Postponement
Some RFC pull requests are tagged with the 'Postponed' label when they are
closed (as part of the rejection process). This label implies that we neither
want to think about evaluating the proposal or implementing it until some time
in the future. These pull requests may be re-opened when the time is right.
RFCs are usually postponed after some evaluation has taken place, and the label
is usually given because the time is not right to consider or implement such a
feature for now.
## Credits
This repository and process takes significant inspiration from the
[Rust RFCs](https://github.com/rust-lang/rfcs) process, and the
[GHC Proposals](https://github.com/ghc-proposals/ghc-proposals) process, so
thank you to both communities for inspiring us!