|
|
# How to contribute a new feature to GHC
|
|
|
|
|
|
We welcome your involvement in making GHC able to do more.
|
|
|
|
|
|
* Proposals for a change to the libraries should be sent to the relevant library maintainer (or the [Core Libraries Committee](https://github.com/haskell/core-libraries-committee) for changes to `base`).
|
|
|
|
|
|
We welcome your involvement in making GHC able to do more. Here's how to do it. Note that proposals for a change to the libraries (including base) should be send to the [libraries mailinglist](http://haskell.org/haskellwiki/Library_submissions).
|
|
|
* Proposals for language extensions and significant new user-facing features should be sent to the [GHC Steering Committee](https://github.com/ghc-proposals/ghc-proposals/) and follow the proposals process. (It is fine to open a [feature request](https://gitlab.haskell.org/ghc/ghc/issues) **issue** on the GitLab issue tracker as well, especially if you are unsure whether a ghc-proposal is required for a minor feature request.)
|
|
|
|
|
|
Here's how to contribute a feature:
|
|
|
|
|
|
1. Open a [feature request](https://gitlab.haskell.org/ghc/ghc/issues) **issue** on GitLab issue tracker.
|
|
|
1. Write down the **specification** of the feature! Specifying before implementing is obviously a good idea; and it makes it possible for others to comment on your design before you invest heavily in building the feature.
|
|
|
|
|
|
- *Alternatively*: Create a Pull Request on [GitHub (ghc-proposals)](https://github.com/ghc-proposals/ghc-proposals/).
|
|
|
1. Get **feedback** by raising a GHC proposal or opening a feature request issue. Often you'll get useful ideas. Update the specification as needed.
|
|
|
|
|
|
1. Write down the **specification** of the feature and create a Wiki [page](proposal) for it. Specifying before implementing is obviously a good idea; and it makes it possible for others to comment on your design before you invest heavily in building the feature.
|
|
|
1. You are welcome to **implement** your proposed feature at any stage, but bear in mind that until the proposal has been accepted by the GHC Steering Committee, there is no guarantee that a patch will be accepted.
|
|
|
|
|
|
1. Get **feedback** by emailing a suitable list (`ghc-devs` for nitty-gritty GHC internals, `glasgow-haskell-users` for user-visible features). Often you'll get useful ideas. Update the wiki page as needed.
|
|
|
|
|
|
1. Put a link and a **summary** to the discussion in the GitLab issue.
|
|
|
|
|
|
1. For language extensions, **wait for approval** by GHC HQ.
|
|
|
|
|
|
1. Follow the instructions for **[contributing a patch](/Contributing-a-Patch#merge-request-workflow)**.
|
|
|
1. Once your proposal has been accepted and the implementation is ready, follow the instructions for **[contributing a patch](/Contributing-a-Patch#merge-request-workflow)**.
|
|
|
|
|
|
1. Include updates to the **user manual** that documents your feature. For features that introduce a new flag, at least two sections need to be updated:
|
|
|
|
... | ... | |