mirror of
https://github.com/zjs81/meshcore-open.git
synced 2026-04-20 22:13:48 +00:00
71 lines
3 KiB
Markdown
71 lines
3 KiB
Markdown
# How to contribute to Meshcore Open
|
|
|
|
Before submitting any pull requests (PR), please review the following information.
|
|
|
|
Unsolicited PRs without previous discussion or open issues may be
|
|
rejected. As may changes that are too broad (i.e. 100 files changed) or that
|
|
cover too many separate changes. If the changes are clearly AI generated they
|
|
may also be rejected. [See more](#ai-use)
|
|
|
|
## First Step Checklist
|
|
|
|
### **Did you find a bug?**
|
|
|
|
* **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/zjs81/meshcore-open/issues).
|
|
|
|
* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/zjs81/meshcore-open/issues/new).
|
|
Be sure to include a **title and clear description**, as much relevant
|
|
information as possible, and a **code sample** or an **executable test case**
|
|
demonstrating the expected behavior that is not occurring. You can also include
|
|
screenshots or video.
|
|
|
|
* DO NOT start work and submit a PR at this time, please discuss the issue and
|
|
your implementation plan first.
|
|
|
|
### **Did you fix whitespace, format code, or make a purely cosmetic patch?**
|
|
|
|
Changes that are cosmetic in nature and do not add anything substantial to the
|
|
stability, functionality, or testability of the application will generally not
|
|
be accepted.
|
|
|
|
### **Do you intend to add a new feature or change an existing one?**
|
|
|
|
* Suggest your change in a new issue as a feature request.
|
|
|
|
* DO NOT start work and submit a PR at this time, please discuss the change and
|
|
your implementation plan first.
|
|
|
|
* After it is generally decided that the feature or change fits the goals of the
|
|
project you can start work or open a PR if you have already started.
|
|
|
|
## Submitting your patch
|
|
|
|
* All changes should be based on the `dev` branch. When creating your PR please
|
|
be sure to change the target to merge into dev, and when starting work on a new
|
|
branch be sure to start on latest `dev`.
|
|
|
|
* Ensure the PR description clearly describes the problem and solution. Include
|
|
the relevant issue number if applicable.
|
|
|
|
* The PR should contain **one commit** only, the commit message should have a
|
|
clear title followed by a new line and then brief description if needed. PR with
|
|
multiple commits will be squashed into one before merging if required. See
|
|
[Git Mastery](https://git-mastery.org/lessons/commitMessage/) for more
|
|
information on good commit messages.
|
|
|
|
* **Before committing changes** on your branch, be sure to run both
|
|
`dart format .` and `flutter analyze`. The continuous development checks will
|
|
fail if issues here are not addressed before hand.
|
|
|
|
## AI-use
|
|
|
|
Everyone loves some help, AI agents are a tool in many of our belts. The project
|
|
is not anti-AI.
|
|
|
|
There are some limits to acceptable use however. Generally:
|
|
|
|
* All code generated by AI should be thoroughly reviewed by the contributor.
|
|
* The changes should be tightly controlled to not change anything out of scope
|
|
for the patch, bug fix, etc.
|
|
* The contributor should have a good understanding of what the code does and how
|
|
the application works in order to effectively be able to manage the agent.
|