You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**TRUST THESE INSTRUCTIONS**: Only search if instructions are incomplete or incorrect. Commands here are validated and work.
107
107
108
+
## Pull Request Guidelines
109
+
110
+
When creating or updating pull requests, follow these requirements:
111
+
112
+
**Always Include QA Steps**:
113
+
- Every PR description **must** include clear "How to QA" instructions
114
+
- QA steps should be specific, actionable, and enable reviewers to verify the changes
115
+
- Include all necessary setup steps (e.g., environment variables, database setup, specific URLs to visit)
116
+
- For UI changes: Specify what to click, what to look for, and expected behavior
117
+
- For API changes: Include example requests/responses or curl commands
118
+
- For bug fixes: Include reproduction steps for the original issue and how to verify it's fixed
119
+
- For refactoring: Explain how to verify behavior hasn't changed (e.g., which tests to run)
120
+
121
+
**QA Steps Format**:
122
+
```markdown
123
+
## How to QA
124
+
1. Start the app: `dotrun`
125
+
2. Navigate to: [specific URL or path]
126
+
3.[Specific action to take]
127
+
4. Verify: [Expected outcome]
128
+
5.[Additional steps as needed]
129
+
```
130
+
131
+
**Required Context**:
132
+
- Link to the issue or card being addressed
133
+
- Brief explanation of what changed and why
134
+
- Any prerequisites or dependencies
135
+
- Screenshots for visual changes
136
+
- Warnings about breaking changes or migrations
137
+
- If testing requires specific app state or data shape, include instructions to achieve this (e.g., config changes, code modifications, database setup). Note that temporary changes should be removed after testing.
138
+
108
139
## Code Review Guidelines
109
140
110
141
When reviewing pull requests, be a constructive and helpful reviewer:
111
142
143
+
**Verify QA Steps (CRITICAL)**:
144
+
-**Always check** that the PR description includes "How to QA" instructions
145
+
- If QA steps are missing or incomplete, request them before proceeding with review
146
+
-**Attempt to run** the QA steps whenever possible:
147
+
- Follow the provided steps exactly as written
148
+
- Report any steps that don't work or are unclear
149
+
- Verify that the expected outcomes actually occur
150
+
- Test edge cases mentioned in the QA steps
151
+
- For UI changes: Follow QA steps and take screenshots to verify behavior
152
+
- For API/backend changes: Run provided curl commands or test scripts
153
+
- For bug fixes: Verify the original issue is resolved using the QA steps
154
+
- Document your QA results in the review (e.g., "✅ Followed QA steps, verified expected behavior")
155
+
112
156
**Verify Best Practices**:
113
157
- Check that code follows patterns documented in this file (build sequence, testing requirements, etc.)
114
158
- Ensure changes follow conventions in README.md, HACKING.md, and CONTRIBUTING.md
@@ -124,12 +168,14 @@ When reviewing pull requests, be a constructive and helpful reviewer:
124
168
- Don't suggest changes to areas you're uncertain about - ask questions instead
125
169
126
170
**Highlight Areas Needing Attention**:
171
+
- Point out missing or incomplete QA steps in PR descriptions
127
172
- Point out code that lacks tests or has insufficient test coverage
128
173
- Flag changes that might have security implications (authentication, data validation, etc.)
129
174
- Note when changes affect critical paths (authentication, payment flows, data integrity)
0 commit comments