|
| 1 | +# Contributing to MyXstack |
| 2 | + |
| 3 | +Thank you for contributing to MyXstack! This guide will help you understand our contribution process and conventions. |
| 4 | + |
| 5 | +## Pull Request Guidelines |
| 6 | + |
| 7 | +### PR Title Format |
| 8 | + |
| 9 | +We follow the [Conventional Commits](https://www.conventionalcommits.org/) format for PR titles. This helps us automatically generate changelogs and understand the nature of changes at a glance. |
| 10 | + |
| 11 | +**Format**: `<type>(<scope>): <description>` |
| 12 | + |
| 13 | +**Types**: |
| 14 | +- `feat`: A new feature |
| 15 | +- `fix`: A bug fix |
| 16 | +- `docs`: Documentation changes only |
| 17 | +- `style`: Code style changes (formatting, semicolons, etc.) that don't affect functionality |
| 18 | +- `refactor`: Code changes that neither fix bugs nor add features |
| 19 | +- `perf`: Performance improvements |
| 20 | +- `test`: Adding or updating tests |
| 21 | +- `chore`: Maintenance tasks, dependency updates |
| 22 | +- `ci`: Changes to CI/CD configuration |
| 23 | +- `build`: Changes to build system or dependencies |
| 24 | +- `revert`: Reverting a previous commit |
| 25 | + |
| 26 | +**Scope** (optional): The area of the codebase affected (e.g., `agent`, `xapi`, `grok`, `mcp`) |
| 27 | + |
| 28 | +**Examples**: |
| 29 | +- `docs: update README.md and simplify xAI instructions` |
| 30 | +- `feat(agent): add autonomous reply functionality` |
| 31 | +- `fix(xapi): correct mention polling interval` |
| 32 | +- `chore: update dependencies to latest versions` |
| 33 | +- `ci: add PR validation workflow` |
| 34 | + |
| 35 | +### PR Description |
| 36 | + |
| 37 | +- Provide a clear description of what the PR does (minimum 20 characters) |
| 38 | +- Reference related issues using `#issue-number` |
| 39 | +- Explain the motivation for the change |
| 40 | +- List any breaking changes |
| 41 | +- Include testing steps if applicable |
| 42 | + |
| 43 | +### PR Size |
| 44 | + |
| 45 | +- Try to keep PRs focused and under 500 lines of changes |
| 46 | +- Large PRs (>500 lines) will trigger a warning |
| 47 | +- Consider breaking large changes into smaller, reviewable chunks |
| 48 | +- If a large PR is unavoidable, provide extra context in the description |
| 49 | + |
| 50 | +## Code Style |
| 51 | + |
| 52 | +Follow the guidelines in `.github/copilot-instructions.md`: |
| 53 | +- Use TypeScript strict mode |
| 54 | +- Prefer async/await over raw promises |
| 55 | +- Always wrap API calls in try-catch blocks |
| 56 | +- Use explicit types; avoid `any` |
| 57 | +- Follow naming conventions: |
| 58 | + - Classes: PascalCase (e.g., `XAPIClient`) |
| 59 | + - Functions: camelCase (e.g., `fetchMentions`) |
| 60 | + - Constants: UPPER_SNAKE_CASE (e.g., `DEFAULT_POLLING_INTERVAL`) |
| 61 | + |
| 62 | +## Testing |
| 63 | + |
| 64 | +- Run `npm run build` to verify TypeScript compilation |
| 65 | +- Test changes in simulation mode when possible |
| 66 | +- Ensure existing tests pass before submitting |
| 67 | + |
| 68 | +## Questions? |
| 69 | + |
| 70 | +If you have questions, feel free to: |
| 71 | +- Open an issue for discussion |
| 72 | +- Ask in your PR comments |
| 73 | +- Check the existing documentation in `ARCHITECTURE.md` or `USAGE.md` |
0 commit comments