|
2 | 2 |
|
3 | 3 | 🙌 Thanks for your interest in contributing to EUI! 🙌 |
4 | 4 |
|
5 | | -If there isn't an associated feature request or bug report in EUI's backlog yet, [please create an issue](https://github.com/elastic/eui/issues/new) so that you get a chance to discuss the changes you have in mind with the EUI team. This helps the team scope out your work and provide guidance & recommendations. |
| 5 | +We welcome and encourage contributions. |
6 | 6 |
|
7 | | -## Process |
| 7 | +However, because EUI has a large footprint in Elastic products, we must maintain a high standard of quality and due diligence for contributions. The guidance below outlines our expectations. **While we'd hate to turn away any contribution, PRs that deviate from this guidance will most likely be rejected.** |
| 8 | +**** |
| 9 | +## Who can contribute |
8 | 10 |
|
9 | | -### Who can contribute? |
| 11 | +- **Elastic employees** — EUI is built primarily for Elastic products; maintainers prioritize internal roadmap work first. If your need isn't currently a priority, feel free to contribute the solution yourself. |
| 12 | +- **Community** — Outside contributions are welcome and merged on a **best-effort** basis. |
10 | 13 |
|
11 | | -EUI is built primarily by and for employees of Elastic. We align our features and roadmap with the needs of our products internally. |
| 14 | +## What to contribute |
12 | 15 |
|
13 | | -While EUI's primary customer is Kibana and other Elastic products, open source is a part of our DNA at Elastic, and commmunity contributions from outside of Elastic are welcome. These contributions are typically reviewed and merged on a best-effort basis and must generally align with the overall objectives of this project. |
| 16 | +- **Bug fixes** — Especially clear, scoped fixes for reproducible issues. |
| 17 | +- **[Help wanted](https://github.com/elastic/eui/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)** — Issues with this label are meant for community pickup: we’ve checked that they fit our roadmap and aren’t blocked on private internal planning. |
14 | 18 |
|
15 | | -In general, once on Github, any issue can be worked on by the community. If you find an issue that is not assigned, assume that you are welcome to work on it and can submit a pull request. We recommend that you leave us a comment indicating your intent before starting work to avoid potential conflict. We do not, as a policy, assign issues to community members and we usually reserve larger projects or ones that are core to our roadmap or design to be done internally. |
| 19 | +## What not to contribute |
16 | 20 |
|
17 | | -Our best PRs tend to come from existing users whom have a challenge they are attempting to overcome and wish to help us solve it. If you are new to open source and looking for a good project to start making contributions, this project may not be a good fit. We have an extensive backlog in which you'll likely encounter outdated issues and issues lacking the appropriate context to get started. |
| 21 | +Unless agreed upon previously: |
18 | 22 |
|
19 | | -### How to ensure the timely review of pull requests |
| 23 | +- **Large or core roadmap work** — Often handled internally so architecture, accessibility, and downstream coordination stay aligned. |
| 24 | +- **Style or design changes** — These require alignment with design teams at Elastic. |
| 25 | +- **High-impact changes** - Even small code changes can have a large impact on Kibana, requiring significant testing and review. |
20 | 26 |
|
21 | | -To help the maintainers of EUI better respond to your pull requests please try to adhere to the following: |
| 27 | +## How to contribute |
22 | 28 |
|
23 | | -1. Follow the guidelines outlined in this wiki folder, from [development](./developing) to [documentation](./documenting) to [testing](./testing). |
24 | | -2. Prefer [atomic commits and small pull requests](https://learning-notes.mistermicheels.com/processes-techniques/small-commits-pull-requests/). Try to limit each commit and each PR to one concern/one issue only. PRs will be significantly easier to QA and review this way. |
25 | | -3. Include screenshots and a summary of your changes in the PR description |
26 | | -4. Fill out the checklist, using ~strikethroughs~ to mark any items that are not applicable |
27 | | -5. Make sure your changes are documented on the demo site and include code comments for unintuitive changes |
28 | | -6. Treat each other professionally and assume best intent in each others work and suggestions |
| 29 | +- **Comment before you start** — Note your intent on the issue to avoid duplicate work. We don’t assign issues to community members by policy. |
| 30 | +- **No matching issue yet?** **[Open one](https://github.com/elastic/eui/issues/new)** first so maintainers can scope the change before you invest in a PR. |
29 | 31 |
|
30 | | -Generally you can expect feedback and a review of your pull request from our team within a week. Contributors should limit themselves to three or less active PRs at any one time, which helps us focus review time towards PRs that are close to a merge event. Sometimes it is unclear who has the next step in getting a pull request over the line and the review can lag as a result. If this is the case, feel free to leave a new comment and ask for guidance. |
| 32 | +## Pull requests |
31 | 33 |
|
32 | | -### Feel free to submit pull requests in draft stages |
| 34 | +- **Use this wiki** — [Developing](./developing), [Documenting](./documenting), [Testing](./testing). |
| 35 | +- **Keep PRs small** — Prefer **[atomic commits and focused PRs](https://learning-notes.mistermicheels.com/processes-techniques/small-commits-pull-requests/)** (one concern per commit and per PR when you can). |
| 36 | +- **Review timing** — We aim to respond within **about a week**. |
| 37 | +- **Concurrency** — Please limit open PRs so review stays focused. |
| 38 | +- **Due diligence** — Follow the PR template (summary, impact, screenshots, checklists, QA notes). |
| 39 | +- **Draft PRs** — We don’t review drafts by default. When you want feedback or help, **comment and ping `@eui-team`** (same idea as the note at the top of the PR template). |
33 | 40 |
|
34 | | -EUI has strict quality and testing standards due to its large downstream footprint and accessibility requirements. Don't feel intimidated and think you need to submit perfect PRs because of this. We welcome draft PRs to show conceptual ideas or enhancements you would like to see. The EUI team normally engages on these PRs in one of two ways, which is largely up to you. |
| 41 | +## Stale PRs |
35 | 42 |
|
36 | | -1. We can provide review and guidance for how to get the PR up to the library's standards. (slower, but you might enjoy this) |
37 | | -2. We can commit directly to your PR to get it over the finish line. (faster) |
| 43 | +Inactive PRs (~**3 months**) may be closed by GitHub’s **[stale workflow](https://github.com/actions/stale)**. |
38 | 44 |
|
39 | | -If you have a preference, let us know when you make your PR, but never feel guilty about just handing it off. We're here to help. |
40 | | - |
41 | | -### Stale PRs |
42 | | - |
43 | | -Stale PRs will be automatically closed by Github's [actions/stale workflow](https://github.com/actions/stale) if they are inactive for ~3 months. If the ball is in EUI's court in terms of review, please feel free to ping us to get the feedback round back in motion. |
44 | | - |
45 | | -If the ball is in your court in terms of feedback given and changes requested, and the PR ends up auto-closing due to inactivity, the EUI team may take over your PR either by pushing to it directly or closing your PR and opening another that branches off your existing work. |
| 45 | +- If **we** owe review, ping us to get things moving again. |
| 46 | +- If **you** owed changes and the PR auto-closed, we may push to your branch or close it and continue in a new PR based on your work. |
0 commit comments