sysopsandClaude Sonnet 5
867dc7740a
The from-scratch Go rewrite had unresolved bugs (missing go.sum, UI 404s, path issues) from being built without a working local Go toolchain to verify against. Switching strategy: use the actual upstream wireguard-ui codebase (proven, battle-tested single-server manager) as the base, and extend it for multi-server support instead of re-deriving everything from zero. Kept our own installers (bootstrap.sh, update.sh, scripts/install.sh, scripts/proxmox-install.sh) - these still apply, just need updating to build/install the upstream module layout instead of the old cmd/wireguard-ui-multi structure. Module path intentionally left as upstream's own (github.com/ngoduykhanh/wireguard-ui) for now to avoid touching every internal import; revisit if this needs to be fully rebranded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
68 lines
2.5 KiB
Markdown
68 lines
2.5 KiB
Markdown
# Contributing Guidelines
|
|
|
|
Thank you for your interest in contributing to my project. Whether it's a bug report, new feature, correction, or additional
|
|
documentation, I greatly value feedback and contributions from my community.
|
|
|
|
Please read through this document before submitting any issues or pull requests to ensure I have all the necessary
|
|
information to effectively respond to your bug report or contribution.
|
|
|
|
## Reporting Bugs/Feature Requests
|
|
|
|
I welcome you to use the GitHub issue tracker to report bugs or suggest features.
|
|
|
|
When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already
|
|
reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
|
|
|
|
- A reproducible test case or series of steps
|
|
- The version of my code being used
|
|
- Any modifications you've made relevant to the bug
|
|
- Anything unusual about your environment or deployment
|
|
|
|
## Contributing via Pull Requests
|
|
|
|
### Discussion of New Features
|
|
Before initiating the implementation of a new feature, I encourage contributors to open a discussion by creating a new GitHub issue. This allows me to provide feedback, share insights, and ensure alignment with the project's direction and save your time.
|
|
|
|
#### Process for Discussing New Features:
|
|
|
|
1. **Create an Issue:**
|
|
- Go to the "Issues" tab in the repository.
|
|
- Click on "New Issue."
|
|
- Clearly describe the proposed feature, its purpose, and potential benefits.
|
|
|
|
2. **Engage in Discussion:**
|
|
- Respond promptly to comments and feedback from the community.
|
|
- Be open to adjusting the feature based on collaborative input.
|
|
|
|
3. **Consensus Building:**
|
|
- Strive to reach a consensus on the proposed feature.
|
|
- Ensure alignment with the overall project vision.
|
|
|
|
### Bug Fixes and Improvements
|
|
|
|
For bug fixes, documentation improvements, and general enhancements, feel free to submit a pull request directly.
|
|
|
|
#### Pull Request Guidelines:
|
|
|
|
1. **Fork the Repository:**
|
|
- Fork the repository to your GitHub account.
|
|
|
|
2. **Create a Branch:**
|
|
- Create a new branch for your changes.
|
|
|
|
3. **Make Changes:**
|
|
- Make your changes and ensure they adhere to coding standards.
|
|
|
|
4. **Submit a Pull Request:**
|
|
- Submit a pull request to the main repository.
|
|
|
|
5. **Engage in Review:**
|
|
- Be responsive to feedback and address any requested changes.
|
|
|
|
6. **Merge Process:**
|
|
- Once approved, your changes will be merged into the main branch.
|
|
|
|
## Licensing
|
|
|
|
See the [LICENSE](LICENSE) file for my project's licensing.
|