Skip to content

Commit ebac5ca

Browse files
feat: streamline contributing guide (#1571)
* feat: streamline contributing guide * feat: add assignment priority and anti-spam rules * docs: add prompt response requirement for maintainer comments
1 parent 53e73ac commit ebac5ca

1 file changed

Lines changed: 49 additions & 180 deletions

File tree

CONTRIBUTING.md

Lines changed: 49 additions & 180 deletions
Original file line numberDiff line numberDiff line change
@@ -1,209 +1,78 @@
1-
# CONTRIBUTING.md
1+
# Contributing to Lingo.dev
22

3-
Thank you for contributing to Lingo.dev! We're an exciting open source project and we love having you contribute!
3+
Thank you for contributing! We maintain high standards for code quality and design.
44

5-
Here are some resources and guidance to help you get started:
5+
**IMPORTANT: Every requirement below is critical. If any requirement is not met, your issue or PR will be automatically rejected by the bots.**
66

7-
1. [Getting Started](#getting-started)
8-
2. [Issues](#issues)
9-
3. [Pull Requests](#pull-requests)
10-
4. [Release Process](#release-process)
7+
## Before You Start
118

12-
## Getting Started
9+
1. **Find or create an issue** - Search [existing issues](https://github.com/lingodotdev/lingo.dev/issues) first
10+
2. **Wait to be assigned** - Comment on the issue and wait for assignment before starting work. Assignment priority:
11+
- First: Issue creator
12+
- Second: First volunteer commenter
13+
- **Submitting a PR without assignment will result in automatic rejection**
14+
3. **Discuss approach** - Align on implementation details before coding
1315

14-
Here's how to get the project running locally:
16+
## Pull Request Requirements
17+
18+
### Must Have
19+
20+
- **Linked issue** - Reference the issue in your PR (e.g., "Closes #123")
21+
- **Valid title** - Use [Conventional Commits](https://www.conventionalcommits.org/): `feat:`, `fix:`, `chore:`, etc.
22+
- **Tests** - Unit tests for main code paths
23+
- **Changeset** - Run `pnpm new` from repo root
24+
- **Passing checks** - All CI checks must pass
25+
26+
### Standards
27+
28+
- **Surgical PRs** - One clear objective per PR
29+
- **Clean code** - Elegant, well-reasoned implementation
30+
- **Meaningful changes** - No low-effort, cosmetic, or trivial edits made only to gain contributions
31+
- **No duplicate work** - Check if someone else already opened a PR
32+
33+
## Local Development
1534

1635
### Prerequisites
1736

18-
- **Node.js**: Make sure you have Node.js version 18 or higher installed.
19-
- **pnpm**: You can install using this command `npm install -g pnpm` or by following [this guide](https://pnpm.io/installation)
20-
- **AI API Key**:
21-
Currently, Groq, Google, and Mistral are supported.
22-
- **GROQ API Key**: You can get one by signing up at [Groq](https://console.groq.com/)
23-
- **GOOGLE API Key**: You can get one in the [Google AI Studio](https://aistudio.google.com/apikey)
24-
- **MISTRAL API Key**: You can get one by signing up at [Mistral AI](https://console.mistral.ai)
37+
- Node.js 18+
38+
- pnpm (`npm install -g pnpm`)
39+
- AI API key (Groq, Google, or Mistral) - [setup guide](https://lingo.dev/en/cli/quick-start#step-2-authentication)
2540

2641
### Setup
2742

28-
To set up the project, clone the repository and install the dependencies:
29-
3043
```bash
3144
git clone https://github.com/lingodotdev/lingo.dev
3245
cd lingo.dev
3346
pnpm install
47+
pnpm turbo build
3448
```
3549

36-
Next, configure an AI API key. You can use either a Lingo.dev API key or one of the supported LLM model providers.
37-
38-
Please refer to our docs on how to set this up: https://lingo.dev/en/cli/quick-start#step-2-authentication
39-
40-
_Note:_ When loading LLM API keys (both Lingo.dev and other LLM model providers like Groq or Mistral), the Lingo.dev Compiler checks the following sources in order of priority:
41-
42-
1. Environment variables (via `process.env`)
43-
2. Environment files (`.env`, `.env.local`, `.env.development`)
44-
3. Lingo.dev configuration
45-
46-
Next, you can run the project using the following commands:
50+
### Run Locally
4751

4852
```bash
49-
# start the build process
50-
pnpm turbo build
51-
52-
# in terminal window 1 - watch for CLI code changes
53+
# Terminal 1 - watch CLI changes
5354
cd packages/cli
5455
pnpm run dev
5556

56-
# in terminal window 2 - test the CLI
57+
# Terminal 2 - test CLI
5758
cd packages/cli
58-
pnpm lingo.dev --help # this command will use the current CLI code + demo config from ./packages/cli/i18n.json
59+
pnpm lingo.dev --help
5960
```
6061

61-
Feel free to ask questions on our [Discord server](https://lingo.dev/go/discord)!
62-
63-
## Adding a New LLM Provider
64-
65-
Want to add support for a new LLM provider to Lingo.dev? Here's a checklist to help you get started:
66-
67-
1. **Add Your Dependency**
68-
69-
- Install the relevant SDK/package for your provider in the necessary `package.json` (usually `cli` and/or `compiler`). Lingo.dev uses the [AI SDK](https://ai-sdk.dev) and its [providers](https://ai-sdk.dev/providers/ai-sdk-providers), so check first to make sure the AI SDK supports your provider.
70-
71-
2. **Update the Config Schema**
72-
73-
- Edit [`packages/spec/src/config.ts`](./packages/spec/src/config.ts) and update the list of allowed provider `id` values to include your new provider.
74-
75-
3. **Provider Details**
76-
77-
- Add your provider to [`packages/compiler/src/lib/lcp/api/provider-details.ts`](./packages/compiler/src/lib/lcp/api/provider-details.ts) with name, env var, config key, API docs, and signup link.
78-
79-
4. **API Key Handling**
80-
81-
- Update [`packages/compiler/src/utils/llm-api-key.ts`](./packages/compiler/src/utils/llm-api-key.ts) to add functions for getting the API key from environment/config.
82-
83-
5. **CLI and Compiler Logic**
84-
85-
- Update the CLI (e.g., [`packages/cli/src/cli/localizer/explicit.ts`](./packages/cli/src/cli/localizer/explicit.ts), [`packages/cli/src/cli/processor/index.ts`](./packages/cli/src/cli/processor/index.ts)) to support your provider.
86-
- Update the compiler's translation logic to instantiate your provider's client (see [`packages/compiler/src/lib/lcp/api/index.ts`](./packages/compiler/src/lib/lcp/api/index.ts)).
87-
88-
6. **Error Handling**
89-
90-
- Ensure user-facing error messages are updated to mention your provider where relevant (API key checks, troubleshooting, etc).
91-
92-
7. **Test and Document**
93-
- Add or update tests to cover your provider.
94-
- Update documentation and this contributing guide as needed.
62+
### Run Checks
9563

96-
**Tip:**
97-
Look at how existing providers like "groq", "google", and "mistral" are implemented for reference. Consistency helps us maintain quality and predictability!
98-
99-
## Issues
100-
101-
If you find a bug, please create an Issue and we'll triage it.
102-
103-
- Please search [existing Issues](https://github.com/lingodotdev/lingo.dev/issues) before creating a new one
104-
- Please include a clear description of the problem along with steps to reproduce it. Exact steps with screenshots and URLs really help here
105-
- Before starting work on an issue, please comment on it and wait for it to be assigned to you. This prevents multiple people from working on the same issue simultaneously
106-
- Let's discuss implementation details in the issue comments or Discord before starting work, to ensure alignment between contributors and the Lingo.dev team
107-
108-
---
109-
110-
## 🧩 Issue Assignment Rules
111-
To maintain fairness and quality in our open-source contributions, we follow these rules for issue assignment:
112-
113-
### 🧠 Issue Assignment Priority
114-
1. **First priority:** The person who opened the issue.
115-
2. **Second priority:** The first commenter who volunteers to work on it (if the issue creator is not working on it).
116-
117-
> ❌ Submitting a PR without being assigned may result in rejection — even if it solves the issue.
118-
119-
---
120-
121-
### 🚀 Pull Request Etiquette
122-
123-
- Avoid submitting **low-effort or spammy PRs** (e.g., cosmetic or trivial edits made only to gain contributions).
124-
- Use **Conventional Commit** titles: `feat:`, `fix:`, `docs:`, `chore:`, etc.
125-
- Provide a **clear and meaningful PR description** linking to the related issue.
126-
- Make sure your PR passes all CI checks and formatting standards.
127-
128-
> ✅ Ideal PRs are thoughtful, well-tested, and make meaningful improvements to the codebase.
129-
130-
131-
## Pull Requests
132-
133-
We love your Pull Requests! However, we maintain extremely high standards for code quality and design. We are looking for elegant, 12/10, beautiful code and deeply weighted system design decisions.
134-
135-
### Our Standards
136-
137-
- **Surgical PRs**: Pull requests must be surgical and extremely single-purposed. One clear objective per PR.
138-
- **Elegant Code**: We expect beautifully crafted, elegant code that demonstrates mastery of the language and patterns.
139-
- **Deep Design Thinking**: System design decisions must be deeply considered and well-reasoned.
140-
- **Comprehensive Testing**: Must include tests that surgically test both positive and negative paths of the code.
141-
- **Uncompromising Quality**: We prefer fewer, higher-quality contributions over numerous mediocre ones.
142-
143-
A couple of things to keep in mind before you submit:
144-
145-
### Before you open a pull request
146-
147-
- GitHub Issue
148-
- Make sure the fix or feature is sufficiently documented and discussed in advance in an existing [GitHub Issue](https://github.com/lingodotdev/lingo.dev/issues)
149-
- If there are no related issues, **we strongly suggest you [create a new Issue](https://github.com/lingodotdev/lingo.dev/issues/new)** and discuss your feature or proposal with the Lingo.dev team
150-
- If there is a Discord thread already, please summarize it in a GitHub Issue. This helps to keep everyone in the loop, including open-source contributors and Lingo.dev team members not part of the original conversation. It also serves as documentation for future decisions.
151-
- README update
152-
- If applicable, please add a section with the CLI commands introduced in your PR (what their purpose is and how to use them)
153-
- It is not necessary to update the README file for every change, oftentimes a comprehensive description in the Issue or PR description is enough
154-
- Tests
155-
- Your changes should include unit tests for the main code paths, to make sure nothing breaks
156-
- Changeset
157-
- Add a [changeset](https://github.com/changesets/changesets) for your feature or fix (run `pnpm new` from the repo root)
158-
- PR checks
159-
- Make sure all checks pass
160-
- You can run the checks locally in repo root:
161-
```sh
162-
pnpm install --frozen-lockfile
163-
pnpm format:check
164-
pnpm turbo build --force
165-
pnpm turbo test --force
166-
pnpm changeset status --since origin/main
167-
```
168-
...or let GitHub run it in the PR for you.
169-
170-
### Opening a pull request
171-
172-
- GitHub Issue
173-
- Make sure to link your PR to the existing Issue(s)
174-
- We may not be able to accept new features without existing Issues
175-
- This does not apply to smaller fixes with sufficient description in the PR
176-
- Existing PRs
177-
- Make sure someone else hasn't already created a PR fixing the same issue.
178-
- PR title
179-
- The title should be [a valid Conventional Commit title](https://github.com/amannn/action-semantic-pull-request?tab=readme-ov-file#action-semantic-pull-request)
180-
- Should start with `feat:`, `fix:`, `chore:`, etc.
181-
- PR description
182-
- Should contain sufficient description of your PR (unless the linked Issue already does)
183-
- _💡 Tip:_ Oftentimes less is more. Try to write in your own words; real humans are reviewing your PR.
184-
- Demo video
185-
- For larger features we would really appreciate a quick screen recording showing it in action
186-
- It helps make the review process faster
187-
- You can use [open-source Cap](https://github.com/CapSoftware/Cap), [QuickTime on Mac](https://support.apple.com/guide/quicktime-player/record-your-screen-qtp97b08e666/mac), or any other software you prefer
188-
189-
### Review Process
190-
191-
- We will always try to accept the first viable PR that resolves the Issue
192-
- Please discuss implementation approach beforehand to avoid having PRs rejected
193-
- Please actively discuss with the Lingo.dev team in the PR and related Issue(s)
194-
195-
#### Automated Code Review
196-
197-
We use Claude Code to provide automated code reviews on all pull requests. This helps ensure:
198-
199-
- Code quality and maintainability
200-
- Security best practices
201-
- Performance considerations
202-
- Proper test coverage
203-
- Documentation completeness
64+
```bash
65+
pnpm install --frozen-lockfile
66+
pnpm format:check
67+
pnpm turbo build --force
68+
pnpm turbo test --force
69+
pnpm changeset status --since origin/main
70+
```
20471

205-
The automated review will post comments on your PR with suggestions and feedback. While these are helpful guidelines, human reviewers will make the final decisions. If Claude Code identifies critical security issues, please address them promptly.
72+
## Review Process
20673

207-
---
74+
- Automated code review by AI bots provides suggestions
75+
- Human reviewers make final decisions
76+
- **Address maintainer comments promptly** - PRs with unaddressed comments will be closed to keep the repo clean. Feel free to recreate once issues are resolved.
20877

209-
Thank you!
78+
Questions? Join our [Discord](https://lingo.dev/go/discord)!

0 commit comments

Comments
 (0)