| 1 | # Tauri Plugin Admob Contributing Guide |
| 2 | |
| 3 | Hi! We, the maintainers, are really excited that you're interested in contributing to Tauri Plugin Admob. Before submitting your |
| 4 | contribution though, please make sure to take a moment and read through the [Code of Conduct](CODE_OF_CONDUCT.md), as |
| 5 | well as the appropriate section for the contribution you intend to make: |
| 6 | |
| 7 | - [Issue Reporting Guidelines](#issue-reporting-guidelines) |
| 8 | - [Development Guide](#development-guide) |
| 9 | - [Pull Request Guidelines](#pull-request-guidelines) |
| 10 | |
| 11 | **We strongly advise you to join the [DreamingCodes Discord](https://discord.gg/MehYjUJGpA) to discuss your contribution |
| 12 | with the community.** |
| 13 | |
| 14 | ## Issue Reporting Guidelines |
| 15 | |
| 16 | - The issue list of this repo is **exclusively** for bug reports and feature requests. Non-conforming issues will be |
| 17 | closed immediately. |
| 18 | |
| 19 | - If you have a question, you can get quick answers from the [DreamingCodes Discord](https://discord.gg/MehYjUJGpA). |
| 20 | |
| 21 | - Try to search for your issue, it may have already been answered or even fixed in the development branch (`main`). |
| 22 | |
| 23 | - Check if the issue is reproducible with the latest stable version. If you're using a pre-release, please |
| 24 | indicate the specific version you're using. |
| 25 | |
| 26 | - It is **required** that you clearly describe the steps necessary to reproduce the issue you're running into. Although |
| 27 | we would love to help our users as much as possible, diagnosing issues without clear reproduction steps is extremely |
| 28 | time-consuming and simply not sustainable. |
| 29 | |
| 30 | - Use only the minimum amount of code necessary to reproduce the unexpected behavior. A good bug report should isolate |
| 31 | specific methods that exhibit unexpected behavior and precisely define how expectations were violated. What did you |
| 32 | expect the method or methods to do, and how did the observed behavior differ? The more precisely you isolate the |
| 33 | issue, the faster we can investigate. |
| 34 | |
| 35 | - Issues with no clear repro steps will not be triaged. If an issue labeled "need repro" receives no further input from |
| 36 | the issue author for more than 5 days, it will be closed. |
| 37 | |
| 38 | - If your issue is resolved but still open, don’t hesitate to close it. In case you found a solution by yourself, it |
| 39 | could be helpful to explain how you fixed it. |
| 40 | |
| 41 | - Most importantly, we beg your patience: the team must balance your request against many other responsibilities — |
| 42 | fixing other bugs, answering other questions, new features, new documentation, etc. The issue list is not paid |
| 43 | support, and we can't make guarantees about how fast your issue can be resolved. |
| 44 | |
| 45 | ## Development Guide |
| 46 | |
| 47 | Is this repository we stick to the following branch structure: |
| 48 | |
| 49 | | Branch | Description | |
| 50 | |-|-| |
| 51 | | `main` | The develop branch is where all the working branches are merged. It's not possible to push code directly here, not even for a maintainer. Everything in `main` must come from a pull request after a code review. | |
| 52 | | `<working>` | Working branches are always created from `main` and to `main` shall return! Only working branches should be merged in to the develop branch after a code review. | |
| 53 | |
| 54 | ## Pull Request Guidelines |
| 55 | |
| 56 | You must read the [Development Guide](#development-guide) section before proceeding with the pull request guidelines. |
| 57 | |
| 58 | In this project we stick to the following naming convention for the Pull Request title: |
| 59 | |
| 60 | ```yml |
| 61 | <type>: <short summary> |
| 62 | │ │ |
| 63 | │ └─⫸ Summary: Present tense. Not capitalized. No period at the end. |
| 64 | │ |
| 65 | └─⫸ Type: build|ci|docs|feat|fix|perf|refactor |
| 66 | ``` |
| 67 | |
| 68 | ##### Type must be one of the following: |
| 69 | >* **build**: Changes that affect the build system or external dependencies (example scopes: gradle) |
| 70 | >* **ci**: Changes to our CI configuration files and scripts (examples: Github Actions) |
| 71 | >* **docs**: Documentation only changes |
| 72 | >* **feat**: A new feature |
| 73 | >* **fix**: A bug fix |
| 74 | >* **perf**: A code change that improves performance |
| 75 | >* **refactor**: A code change that neither fixes a bug nor adds a feature |
| 76 | |
| 77 | ##### Summary |
| 78 | >Use the summary field to provide a succinct description of the change: |
| 79 | > |
| 80 | >* use the imperative, present tense: "change" not "changed" nor "changes" |
| 81 | >* don't capitalize the first letter |
| 82 | >* no dot (.) at the end |
| 83 | |
| 84 | **You must follow this convention also for the working branch name: `<type>/<summary>`, e.g. `build/migrate_gradle`.** |
| 85 | |
| 86 | ##### Some clarifications |
| 87 | >- It's OK to have multiple small commits as you work on the PR – We will let GitHub automatically squash it before |
| 88 | > merging. (That is why we're restrictive about the title of the PR) |
| 89 | > |
| 90 | >- If adding new feature: |
| 91 | > |
| 92 | > - Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it |
| 93 | > greenlighted before working on it. |