Eta Proposals

Instructions to propose changes to Eta.

Eta Proposals

Eta Proposals (EPs)

The Eta Programming Language development process is community-driven. Significant changes to the language, tools and the ecosystem must be discussed and documented before they can be implemented.

This document contains the process for Eta Proposals (EPs) that specify precise changes to Eta and it's infrastructure.

Starting an EP

When you have an idea for a major change and you are interested in writing a detailed proposal for it, you proceed as follows:

  1. Post on the various communication channels to solicit feedback on the initial sketch of your idea, such as:
  2. This step is not required, but it is a good way to test the waters before devoting time to contemplating a design and/or implementation plan for your idea.

  3. If the feedback seems pretty positive, file an issue here and the core Eta developers and other stakeholders will provide further feedback. Once it's clear that the proposal is desirable and feasible, a member of the TypeLead organization will give the go ahead to write a detailed proposal.
  4. To write a proposal, you should:
    • Fork this repository.
    • Copy the template proposals/ to proposals/EP000-[proposal-title].md where [proposal-title] should be an informative but concise title that describes the contents of the proposal.
    • Address the questions in the template in a clear and detailed manner.
    • Submit a pull request once you are done.

Lifecycle of an EP

Once you have submitted a pull request, the Eta Proposal Process starts.

  1. Your proposal will receive feedback from the community and you should revise the proposal accordingly. TypeLead members may organize meetings over Skype/Hangouts if the proposal has large tradeoffs.
  2. If it is clear the proposal will not be beneficial to the Eta ecosystem, a TypeLead member will close the pull request with a reason.
  3. If it is clear that the proposal, if implemented, can improve the user experience of the Eta ecosystem, and the proposal is complete, a TypeLead member will merge the pull request.

Implementing an EP

Once a proposal has been merged, it can be in one of two states (indicated by a label): active or proposed.

If it is active, it means the EP can be implemented in the near future. Proposals in this category will also be assigned one of three priority labels:

  1. low : Indicates that the proposal is relatively unimportant and can be implemented at any time.
  2. medium : Indicates that the proposal may be implemented in the coming weeks.
  3. high : Indicates that the proposal may be implemented within the next couple of days or within the next week.

If it is postponed, it means the EP will not be implemented in the near future, but the status may change to active if conditions permit.

Moreover, if an implementation plan has not been specified in the proposal, a TypeLead member will provide a brief sketch of the implementation plan.

Commenting on an EP

When commenting on a proposal, the following guidelines should be followed:

  1. React to posts. Use GitHub's reactions to posts if you have nothing substantial to say.
  2. Be respectful about potential flaws. Do not try to bring down the proposal creator or other commentors.
  3. Give a proper arguments.Your arguments should be straight to the point.


If you have any questions about the process, please:

  1. file an issue.
  2. discuss with us on Gitter