45 lines
1.5 KiB
Markdown
45 lines
1.5 KiB
Markdown
# 🤝 Contributing to Plexus
|
|
|
|
We maintain high standards for code quality and documentation. Please follow this workflow for all contributions.
|
|
|
|
## 🔄 Development Workflow
|
|
|
|
### 1. Pick a Task
|
|
Before coding, ensure you are working on an assigned task.
|
|
- List tasks: `make task-list`
|
|
- Add a task: `make task-add title="Your Task"`
|
|
- Mark as in-progress: (Update manually in `tasks/tasks.duckdb` or via CLI if implemented).
|
|
|
|
### 2. Implementation
|
|
- Write clean, modular code.
|
|
- Follow the existing design patterns (Vue 3 Composition API, Pinia, Socket.io).
|
|
- Ensure UI changes are mobile-friendly and follow the Discord-inspired aesthetic.
|
|
|
|
### 3. Verification
|
|
Before committing, you **must** verify your changes:
|
|
- Run linting: `make lint`
|
|
- Run tests: `make test`
|
|
- Manual check: Verify the feature in the browser.
|
|
|
|
### 4. Commit
|
|
We use **Husky** and **lint-staged** to enforce quality.
|
|
- Your commit will fail if linting or tests do not pass.
|
|
- Use descriptive commit messages (e.g., `feat: add user profiles`, `fix: message alignment`).
|
|
|
|
### 5. Documentation
|
|
If your change affects the architecture, data model, or API:
|
|
- Update the relevant file in `docs/`.
|
|
- Ensure the root `README.md` is still accurate.
|
|
|
|
### 6. Finalize Task
|
|
Mark the task as done:
|
|
- `make task-done id=X`
|
|
|
|
## 🛠 Tooling
|
|
- **Linting**: ESLint for JS/Vue, Ruff for Python.
|
|
- **Testing**: Mocha for backend integration tests.
|
|
- **Automation**: Use the `Makefile` for all common operations.
|
|
|
|
---
|
|
Thank you for helping make Plexus better!
|