You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: .github/CONTRIBUTING.md
+39
Original file line number
Diff line number
Diff line change
@@ -14,3 +14,42 @@ If you don't have a known good BLE device that's easy to use for testing, consid
14
14
You can create a virtual device like a Polar HR Sensor in the app. Then use the manual test to connect to the virtual device and read GATT characteristics.
15
15
16
16
Also see the [README's Tips](../README.md#tips).
17
+
18
+
## Overview
19
+
20
+
Linux.Bluetooth is an open-source project. We encourage community members like yourself to contribute.
21
+
22
+
You can contribute today by creating a **feature request**, **issue**, or **discussion** on the forum. From there we can have a brief discussion as to where this fits into the backlog priority. If this is something that fits within the architecture, we'll kindly ask you to create a **Pull Request**. Any PR made without first having an issue/discussion may be closed.
23
+
24
+
Issues posted without a description may be closed immediately. Use the discussion boards if you have a question, not Issues.
25
+
26
+
We will close your _PR_ if it doesn't have an approved issue / feature request.
27
+
28
+
We reserve the right to close your "_issue_" or feature request if:
29
+
30
+
* It's an inquiry, not an issue.
31
+
* Error in your code for not following the documentation
32
+
* Not providing a description and steps to reproduce
33
+
* Not providing a sample when asked to do so
34
+
35
+
## "Keep It Simple Sally"
36
+
37
+
There have been requests in the past where individuals wanted changes for the sake of personal ease rather than how it would affect the ecosystem compatibility. This project should maintain compatibility with Linux distros supported by .NET, be careful of _one-offs_.
38
+
39
+
## Branching Strategy
40
+
41
+
Below is a basic branching hierarchy and strategy.
42
+
43
+
| Branch | Purpose
44
+
|-|-|
45
+
| `master` | All releases are tagged published using the `master` branch
46
+
| `develop` | The **default** & active development branch. When a feature set is completed and ready for public release, the `develop` branch will be merged into `master` and a new NuGet package will be published.
47
+
| `feature/*` | New feature branch. Once completed, it is merged into `develop` and the branch must be deleted.
48
+
| `stable/*` | Stable release base build which shares cherry-picked merges from `develop`. This branch **must not** be deleted.
We as members, contributors, and leaders pledge to make participation and knowledge readily available to others. We inspire everyone to learn from one another, to share ideas, and help grow the community.
6
+
7
+
## Our Standards
8
+
9
+
* Focus on what is best to improve the project's codebase
10
+
* Give constructive feedback
11
+
* Be respectful towards one another
12
+
* Feedback is welcome
13
+
* Jokes are welcomed - _don't like it, rub dirt on it_
14
+
*_Keep political views out of code_
15
+
16
+
After all, we're all human.. _except for AI, that's just an algorithm_.
0 commit comments