Skip to main content

Contributing to Glass

Thank you for helping us make Glass better! Glass is a fork of Zed, built to provide a powerful code editing experience.

Contributing Philosophy

Glass values working code and synchronous conversations over long discussion threads. The best way to get us to take a look at a proposed change is to send a pull request.

What We Love

We especially appreciate contributions that are:
  • Fixing or extending the docs - Help others understand Glass better
  • Fixing bugs - Making Glass more stable and reliable
  • Small enhancements - Making features work for more people (across platforms, modes, etc.)
  • Small extra features - Keybindings or actions you miss from other editors

Finding Contribution Ideas

Looking for concrete ideas?

Contribution Guidelines

Making Your PR Successful

While we review all pull requests, PRs have the best chance of being merged when they:
1

Ensure the change is desired

We’re always happy to accept bugfixes. For features, confirm with us first to avoid wasted effort. If there isn’t already a GitHub issue with staff confirmation, start with a discussion rather than a PR.
2

Include a clear description

Explain what you’re solving and why it’s important. Help reviewers understand the context and motivation.
3

Include tests

Add unit tests for logic changes. For UI changes, consider updating visual regression tests (macOS only).
4

Attach screenshots or recordings

If it changes the UI, visual context helps reviewers understand the impact.
5

Keep it focused

Make the PR about one thing only. If it’s a bugfix, don’t add two features and a refactoring on top.
Keep AI assistance under your judgment and responsibility. It’s unlikely we’ll merge a vibe-coded PR that the author doesn’t understand.

Reviewer Guidelines

The internal advice for reviewers is:
  • If the fix/feature is obviously great and the code is great: Hit merge
  • If the fix/feature is obviously great and the code is nearly great: Send PR comments or offer to pair to get things perfect
  • If the fix/feature is not obviously great or the code needs rewriting: Close the PR with a thank you and explanation

Getting Help

If you need more feedback:
  • Be responsive to GitHub comments
  • Offer time to pair with maintainers
  • Open a PR early if you need help deciding how to fix a bug or implement a feature

What We Won’t Merge

Typically we don’t merge:
  • Extension-provided functionality - New languages or themes belong in extensions (extension docs)
  • New file icons - Glass’s icon theme is hand-designed for cohesion
  • Low-benefit complexity - Features where the extra complexity isn’t worth it for the number of people who benefit
  • Giant refactorings - Large-scale rewrites are difficult to review and maintain
  • Non-trivial changes without tests - Tests ensure quality and prevent regressions
  • Stylistic-only changes - Reducing allocations or fixing typos is great; making code “more readable” may not be
  • AI-generated code without understanding - Contributors must understand what they’re submitting

Code of Conduct

All activity in Glass forums is subject to our Code of Conduct. Additionally, contributors must sign our Contributor License Agreement before their contributions can be merged.

Next Steps

Development Setup

Set up your development environment

Guidelines & Standards

Learn our code standards and conventions

Testing Practices

Understand how to write and run tests

Build docs developers (and LLMs) love