1# Contributing to Zed
 2
 3Thank you for helping us make Zed better!
 4
 5All activity in Zed forums is subject to our [Code of
 6Conduct](https://zed.dev/code-of-conduct). Additionally, contributors must sign
 7our [Contributor License Agreement](https://zed.dev/cla) before their
 8contributions can be merged.
 9
10## Contribution ideas
11
12Zed is a large project with a number of priorities. We spend most of
13our time working on what we believe the product needs, but we also love working
14with the community to improve the product in ways we haven't thought of (or had time to get to yet!)
15
16In particular we love PRs that are:
17
18- Fixes to existing bugs and issues.
19- Small enhancements to existing features, particularly to make them work for more people.
20- Small extra features, like keybindings or actions you miss from other editors or extensions.
21- Work towards shipping larger features on our roadmap.
22
23If you're looking for concrete ideas:
24
25- Our [top-ranking issues](https://github.com/zed-industries/zed/issues/5393) based on votes by the community.
26- Our [public roadmap](https://zed.dev/roadmap) contains a rough outline of our near-term priorities for Zed.
27
28## Sending changes
29
30The Zed culture values working code and synchronous conversations over long
31discussion threads.
32
33The best way to get us to take a look at a proposed change is to send a pull
34request. We will get back to you (though this sometimes takes longer than we'd
35like, sorry).
36
37Although we will take a look, we tend to only merge about half the PRs that are
38submitted. If you'd like your PR to have the best chance of being merged:
39
40- Include a clear description of what you're solving, and why it's important to you.
41- Include tests.
42- If it changes the UI, attach screenshots or screen recordings.
43
44The internal advice for reviewers is as follows:
45
46- If the fix/feature is obviously great, and the code is great. Hit merge.
47- If the fix/feature is obviously great, and the code is nearly great. Send PR comments, or offer to pair to get things perfect.
48- If the fix/feature is not obviously great, or the code needs rewriting from scratch. Close the PR with a thank you and some explanation.
49
50If you need more feedback from us: the best way is to be responsive to
51Github comments, or to offer up time to pair with us.
52
53If you are making a larger change, or need advice on how to finish the change
54you're making, please open the PR early. We would love to help you get
55things right, and it's often easier to see how to solve a problem before the
56diff gets too big.
57
58## Things we will (probably) not merge
59
60Although there are few hard and fast rules, typically we don't merge:
61
62- Anything that can be provided by an extension. For example a new language, or theme. For adding themes or support for a new language to Zed, check out our [docs on developing extensions](https://zed.dev/docs/extensions/developing-extensions).
63- New file icons. Zed's default icon theme consists of icons that are hand-designed to fit together in a cohesive manner, please don't submit PRs with off-the-shelf SVGs.
64- Giant refactorings.
65- Non-trivial changes with no tests.
66- Stylistic code changes that do not alter any app logic. Reducing allocations, removing `.unwrap()`s, fixing typos is great; making code "more readable" — maybe not so much.
67- Features where (in our subjective opinion) the extra complexity isn't worth it for the number of people who will benefit.
68- Anything that seems completely AI generated.
69
70## Bird's-eye view of Zed
71
72We suggest you keep the [Zed glossary](docs/src/development/glossary.md) at your side when starting out. It lists and explains some of the structures and terms you will see throughout the codebase.
73
74Zed is made up of several smaller crates - let's go over those you're most likely to interact with:
75
76- [`gpui`](/crates/gpui) is a GPU-accelerated UI framework which provides all of the building blocks for Zed. **We recommend familiarizing yourself with the root level GPUI documentation.**
77- [`editor`](/crates/editor) contains the core `Editor` type that drives both the code editor and all various input fields within Zed. It also handles a display layer for LSP features such as Inlay Hints or code completions.
78- [`project`](/crates/project) manages files and navigation within the filetree. It is also Zed's side of communication with LSP.
79- [`workspace`](/crates/workspace) handles local state serialization and groups projects together.
80- [`vim`](/crates/vim) is a thin implementation of Vim workflow over `editor`.
81- [`lsp`](/crates/lsp) handles communication with external LSP server.
82- [`language`](/crates/language) drives `editor`'s understanding of language - from providing a list of symbols to the syntax map.
83- [`collab`](/crates/collab) is the collaboration server itself, driving the collaboration features such as project sharing.
84- [`rpc`](/crates/rpc) defines messages to be exchanged with collaboration server.
85- [`theme`](/crates/theme) defines the theme system and provides a default theme.
86- [`ui`](/crates/ui) is a collection of UI components and common patterns used throughout Zed.
87- [`cli`](/crates/cli) is the CLI crate which invokes the Zed binary.
88- [`zed`](/crates/zed) is where all things come together, and the `main` entry point for Zed.
89
90## Packaging Zed
91
92Check our [notes for packaging Zed](https://zed.dev/docs/development/linux#notes-for-packaging-zed).