|
| 1 | +# Contributing to CommDesk |
| 2 | + |
| 3 | +Thank you for your interest in contributing to CommDesk. |
| 4 | + |
| 5 | +***CommDesk*** is a desktop platform for *communities*, *clubs*, *organizations*, and *event teams*. Contributions that improve *usability*, *reliability*, *documentation*, *maintainability*, and *developer experience* are welcome. |
| 6 | + |
| 7 | +## Before You Start |
| 8 | + |
| 9 | +Before making changes, please review the **existing documentation** and **project structure** to understand the current scope of the repository. |
| 10 | + |
| 11 | +This repository includes: |
| 12 | +- A *React* + *TypeScript* **frontend** |
| 13 | +- A *Tauri* **desktop application** layer |
| 14 | +- A *Rust* backend under `src-tauri` |
| 15 | +- *Documentation* for project scope, implementation status, and release flow |
| 16 | + |
| 17 | +## Prerequisites |
| 18 | + |
| 19 | +To work on this project, you should have the following installed: |
| 20 | + |
| 21 | +- **Node.js 20** or later |
| 22 | +- **pnpm 10** or later |
| 23 | +- **Rust stable** (`rustup`, `cargo`) |
| 24 | +- The platform-specific dependencies required by **Tauri** |
| 25 | + |
| 26 | +For *Linux*, *macOS*, and *Windows*, please ensure the appropriate system dependencies are installed before building the project. |
| 27 | + |
| 28 | +## Getting Started |
| 29 | + |
| 30 | +1. Fork the repository. |
| 31 | +2. Clone your fork locally. |
| 32 | +3. Install dependencies. |
| 33 | +4. Start the development environment. |
| 34 | +5. Make your changes in a feature branch. |
| 35 | +6. Test thoroughly before opening a pull request. |
| 36 | + |
| 37 | +### Installation |
| 38 | + |
| 39 | +```git |
| 40 | +git clone https://github.com/NexGenStudioDev/CommDesk.git |
| 41 | +cd CommDesk |
| 42 | +pnpm install |
| 43 | +```` |
| 44 | +
|
| 45 | +### Run the Application |
| 46 | +
|
| 47 | +For local development: |
| 48 | +
|
| 49 | +```bash |
| 50 | +pnpm tauri dev |
| 51 | +``` |
| 52 | + |
| 53 | +If you need to work on the frontend separately: |
| 54 | + |
| 55 | +```bash |
| 56 | +pnpm dev |
| 57 | +``` |
| 58 | + |
| 59 | +## Branch Naming |
| 60 | + |
| 61 | +Use a *descriptive branch name* for your work. |
| 62 | + |
| 63 | +Recommended formats: |
| 64 | + |
| 65 | +* `feature/<short-description>` |
| 66 | +* `fix/<short-description>` |
| 67 | +* `docs/<short-description>` |
| 68 | +* `refactor/<short-description>` |
| 69 | + |
| 70 | +Examples: |
| 71 | + |
| 72 | +* `feature/member-search` |
| 73 | +* `fix/login-error` |
| 74 | +* `docs/update-readme` |
| 75 | + |
| 76 | +## Coding Standards |
| 77 | + |
| 78 | +Please follow the existing *code style* and *project conventions*. |
| 79 | + |
| 80 | +General expectations: |
| 81 | + |
| 82 | +* Keep changes focused and minimal |
| 83 | +* Write clear, readable, and maintainable code |
| 84 | +* Follow the current folder structure and architecture |
| 85 | +* Avoid introducing unnecessary dependencies |
| 86 | +* Prefer small, reusable components and functions |
| 87 | +* Keep frontend and backend changes consistent with the existing design |
| 88 | + |
| 89 | +Before submitting, format and lint your code where applicable. |
| 90 | + |
| 91 | +## Testing |
| 92 | + |
| 93 | +All contributions should be tested locally before submission. |
| 94 | + |
| 95 | +At minimum, verify: |
| 96 | + |
| 97 | +* The application starts successfully |
| 98 | +* The change works as intended |
| 99 | +* Existing functionality is not broken |
| 100 | +* The project passes linting and build checks where relevant |
| 101 | + |
| 102 | +Useful commands: |
| 103 | + |
| 104 | +```bash |
| 105 | +pnpm lint |
| 106 | +pnpm build |
| 107 | +pnpm tauri dev |
| 108 | +``` |
| 109 | + |
| 110 | +If your contribution affects desktop packaging or Rust functionality, test the relevant Tauri or `src-tauri` workflow as well. |
| 111 | + |
| 112 | +## Reporting Issues |
| 113 | + |
| 114 | +Before opening a new issue: |
| 115 | + |
| 116 | +* Search existing issues to avoid duplicates |
| 117 | +* Use a clear and descriptive title |
| 118 | +* Include steps to reproduce the problem |
| 119 | +* Add screenshots, logs, or environment details when relevant |
| 120 | + |
| 121 | +A good bug report should explain: |
| 122 | + |
| 123 | +* What you expected to happen |
| 124 | +* What actually happened |
| 125 | +* How to reproduce the issue |
| 126 | +* Which platform and version you used |
| 127 | + |
| 128 | +## Pull Request Guidelines |
| 129 | + |
| 130 | +When opening a pull request, please ensure that: |
| 131 | + |
| 132 | +* The pull request has a clear title |
| 133 | +* The description explains what was changed and why |
| 134 | +* Related issues are linked when applicable |
| 135 | +* The changes are limited to a single purpose where possible |
| 136 | +* The branch is up to date with the target branch before submission |
| 137 | + |
| 138 | +A strong pull request should include: |
| 139 | + |
| 140 | +* A short summary of the change |
| 141 | +* Screenshots or recordings for UI updates |
| 142 | +* Testing notes |
| 143 | +* Any relevant context for reviewers |
| 144 | + |
| 145 | +## Commit Messages |
| 146 | + |
| 147 | +Use concise and meaningful commit messages. |
| 148 | + |
| 149 | +Recommended style: |
| 150 | + |
| 151 | +* `feat: add member search` |
| 152 | +* `fix: resolve updater issue` |
| 153 | +* `docs: improve contribution guide` |
| 154 | +* `refactor: simplify event module` |
| 155 | + |
| 156 | +## Security and Secrets |
| 157 | + |
| 158 | +Do not commit secrets, private keys, or environment-specific credentials. |
| 159 | + |
| 160 | +If your change requires configuration values, update the example environment file or documentation instead of exposing sensitive data. |
| 161 | + |
| 162 | +## Community Standards |
| 163 | + |
| 164 | +Please keep discussions respectful, constructive, and professional. |
| 165 | + |
| 166 | +Be considerate in: |
| 167 | + |
| 168 | +* Issues |
| 169 | +* Pull requests |
| 170 | +* Code reviews |
| 171 | +* Documentation discussions |
| 172 | + |
| 173 | +This project follows a [code of conduct](CODE_OF_CONDUCT.md). All contributors are expected to follow it. |
| 174 | + |
| 175 | +## Maintainers |
| 176 | + |
| 177 | +Maintainers may request changes before merging a pull request. Please respond to review feedback promptly and keep discussions focused on the proposed change. |
| 178 | + |
| 179 | +## License |
| 180 | + |
| 181 | +**By contributing to CommDesk, you agree that your contributions will be made under the same [License](LICENSE) as the project.** |
0 commit comments