# 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.