public repo template 1.0.0 version

* first version of the public template

* added ISSUE templates and fix typos

* Update CONTRIBUTING.md

Signed-off-by: Ziegler András <[email protected]>

* Update README.md

Signed-off-by: Ziegler András <[email protected]>

* Update README.md

Signed-off-by: Ziegler András <[email protected]>

* fixed findings
broken readme links, removed .md from contributing, moved pr template

* put the md  suffix everywhere

---------

Signed-off-by: Ziegler András <[email protected]>

Author: AndrasZiegler

.github/CONTRIBUTING.md

@@ -1,57 +1,135 @@
-# Contributing Guideline - Internal Repository
+# Contributing Guideline
+As an open-source project, we welcome and encourage the community to submit patches directly to the project.  
+In our collaborative open-source environment, standards and methods for submitting changes help reduce  
+the chaos that can result from an active development community.
+
+This document explains how to participate in project conversations, log bugs and enhancement requests,  
+and submit patches to the project so your patch will be accepted quickly into the codebase.
+
+## Prerequisites
+You should be familiar with Git and GitHub. [Getting started](https://docs.github.com/en/get-started)  
+If you haven't already done so, you'll need to create a (free) GitHub account at https://github.com  
+and have Git tools available on your development system. You also need to add your email address to your account.
+
+As a contributor, you'll want to be familiar with the Silicon Labs tooling:
+- [Simplicity Studio](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-overview/)  
+- [Platform](https://docs.silabs.com/gecko-platform/latest/platform-overview/)  
+- [Simplicity Commander](https://docs.silabs.com/simplicity-commander/latest/simplicity-commander-start/)  
+
+Read the Silicon Labs [coding guidelines](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/coding_standard.md).  
+## Git Setup
+We need to know who you are, and how to contact you. Please ass the following information to your Git installation:
+```
+git config --global user.name "FirstName LastName"
+git config --global user.email "[email protected]"
+```
+set the Git configuration variables user.name to your full name, and user.email to your email address.
+The user.name must be your full name (first and last at minimum), not a pseudonym or hacker handle.  
+The email address that you use in your Git configuration must match the email address you use to sign your commits.  
+
+If you intend to edit commits using the Github.com UI, ensure that your github profile email address and profile name also match those used in your git configuration  
+(user.name & user.email).
 
-## Branch Naming Convention
+### Set up GitHub commit signature
 
-Refer to the Developer Services Branching Policy and Git User [Guide](https://confluence.silabs.com/pages/viewpage.action?pageId=315870645).
+**command line setup**
 
-Use lowercase letters and hyphens (`-`) as delimiters.  
-Google search treats a hyphen as a word separator, which helps improve the visibility of public repositories.  
-We should structure our internal repository as if it were a public one.
+The repository requires signed off commits. Follow this [guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) how to set it up.
+1. Generate a gpg key [howto](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key)
+2. Configure your local repository with the gpg key. [guide]whttps://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key)
+3. Configure your GitHub account with the gpg key [guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/associating-an-email-with-your-gpg-key)
 
-Branch name should be short and clear. If possible it can be the JIRA ticket name.
-Also it is recommended to include the JIRA ticket number. 
-Example:
+**Command line steps:**  
+Use the git-bash and navigate into your local repo.
+1. disable all the gpg signature globally. (Optional)
+```
+$ git config --global --unset gpg.format
+```
+2. Create a gpg-key
+```
+$ gpg --full-generate-key
+```
+3. Configure the local repo with your new key.
+```
+$ gpg --list-secret-keys --keyid-format=long
+gpg: checking the trustdb
+gpg: marginals needed: 3  completes needed: 1  trust model: pgp
+gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+/c/Users/silabsuser/.gnupg/pubring.kbx
+------------------------------------
+sec   rsa3072/1234567891234567 2025-04-09 [SC]
+      ABDGDGFDGFDGDHHSRGRG12345667912345678981
+uid                 [ultimate] Firstname Lastname <[email protected]>
+ssb   rsa3072/11098765432110981 2025-04-09 [E]
+
+$ git config user.signingkey 1234567891234567
+```
+4. Force every commit to be signed
+```
+$ git config commit.gpgsign true
+```
+5. Export your gpg key
 ```
-IOT_DS-123-update-sdk-version
+$ gpg --armor --export 888BA795B7085898
 ```
+Make sure your email address is verified by GitHub before committing anything.
 
-## Commit Message Format
+## Licensing
+Please check the [Licensing.md](../LICENSE.md) for more details.
 
-We use [smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/) to sync GitHub commits with our JIRA server.  
-This requires the JIRA ticket number in the commit message.  
-The first line is the commit message, and the next lines provide the description.  
-The commit message should be short and clear, and it must contain the JIRA ticket number.  
-You can add more details in the description.
+## Contributor License Agreement
+When a project receives a contribution, it must be clear that the contributor has the rights to contribute the content and that the project then has the rights to use and otherwise operate with the content (e.g., relicense or distribute). A Contributor License Agreement (CLA) is a legal document establishing these rights and defining the terms under which a license is granted by a contributor to an open-source project. A CLA clarifies that any contribution was authorized (not contributing someone else’s code without permission or without legal authority to contribute) and protects the project from potential future legal challenges.
 
-**Command Line:**
-```
-git commit -m "IOT_DS-1234 initial version of SDK 4.4.3 is committed" -m "Not final version. Several compiler warnings need to be addressed."
-```
+Please check Silicon Labs [CLA document](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/contributor_license_agreement.md).  
+During the pull request review, every new contributor must sign the CLA document. It can be signed as an individual or on behalf of a company.  
+Signatures have a 6-month expiration period.
 
-**VS Code:**  
-The first line is the commit message, and the next lines are the commit description.
+## Contribution process
+### Creating an Issue
+Please follow the official GitHub [guide](https://opensource.guide/how-to-contribute/#opening-an-issue).
 
-## Pull Request Guideline
+### Fork the repository
+When you created an issue and based on the discussion you want to contribute with your source-code.
+Branching is disabled on the public Silicon Labs repositories. You need to fork your own repo first.
+Please follow the official GitHub [guide](https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project).
+You can create your branch on your own forked repo now.
 
-Refer to the general pull request [guideline](https://opensource.guide/how-to-contribute/#opening-a-pull-request) from GitHub.
+### Branch Naming Convention
+Branch naming shall follow the following template: *IssueNumber-issue-title-goes-here*  
+Example branch name:
+```
+99-bootloader-implementation
+```
+Issue number is necessary to maintain tracebility.
+Now you have a branch. You can start committing your code onto it.
 
-### As a Developer
+## Commit Messages
 
-What to consider when raising a Pull Request:
+Silicon Labs repositories require signed-off commits. 
+Every commit represents a change inside the repository. Every change needs to be documented extensively.  
+```
+Issuenumber-summary-of-changes
 
-1. **Pull Request Naming**  
-   By default, GitHub uses the branch name as the pull request title. If the branch naming guideline was followed, no changes are needed here.
+Detailed description what was implemented.
+Another line of really good description
+```
 
-2. **Check the Reviewer List**  
+## Pull Request Guideline
+Okay you finished your work committed all your changes to your branch. Time to create a pull request.  
+Refer to the general pull request [guideline](https://opensource.guide/how-to-contribute/#opening-a-pull-request) from GitHub.  
+What to consider when raising a Pull Request:  
+1. **Pull Request Naming**  
+   By default, GitHub uses the branch name as the pull request title. If the branch naming convention was followed, no changes are needed here.
+2. **Create Description**
+   Fill out the pull request template.
+3. **Check the Reviewer List**  
    GitHub assigns reviewers based on the [CODEOWNERS](CODEOWNERS) file.  
    Add more reviewers if needed. Do not remove reviewers from the PR. Ask the repository owner for updates to the code owners.
-
-3. **Evaluate the Action Workflow Results**  
+4. **Evaluate the Action Workflow Results**  
    The following workflows are included in every repository:
    - **[Coding Convention Check](workflows/00-Check-Code-Convention.yml)**: Analyzes the code formatting and fails if any rules are broken.
    - **[Firmware Build](workflows/02-Build-Firmware.yml)**: Builds the firmware inside the [Dockerfile](../Dockerfile).  
    - **[Secret Scanner](workflows/04-TruffleHog-Security-Scan.yml)**: Runs the TruffleHog security scanner to look for API keys and committed secrets.
-   - **[SonarQube Analysis](workflows/zz-sonarqube-analysis.yml)**: Runs SonarQube analysis on the project. Refer to the related [Confluence page](https://confluence.silabs.com/display/IoTApps/SQA+-+SonarQube+howTo).
 
 ### As a Reviewer
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,21 @@
+## Description
+<!-- Provide a brief description of the changes in this pull request. -->
+
+## Related Issue
+<!-- If this pull request addresses an issue, link to it here. -->
+Closes #<issue_number>
+
+## Changes Made
+<!-- List the changes made in this pull request. -->
+- 
+
+## Checklist
+- [ ] I have read the [Contributor License Agreement](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/contributor_license_agreement.md).
+- [ ] I have followed the repository's [coding guidelines](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/coding_standard.md) .
+- [ ] I have checked the action workflow results and they are all passed.
+
+## Screenshots (if applicable)
+<!-- Add screenshots to help explain the changes (if applicable). -->
+
+## Additional Notes
+<!-- Add any additional information or context. -->

.github/sonar-project.properties

@@ -1,13 +1,12 @@
 name: 01-CLA-Assistant
-## This workflow is used only for public repositories
-## uncomment the other trigger conditions for public repositories
+## This workflow is used to check the CLA validation for the pull requests.concurrency: 
+## Source: https://github.com/SiliconLabsSoftware/action-cla-assistant/tree/silabs_flavour_v2
 
 on:
-  workflow_dispatch:
-# issue_comment:
-#   types: [created]
-# pull_request_target:
-#   types: [opened,closed,synchronize,reopened]
+  issue_comment:
+    types: [created]
+  pull_request_target:
+    types: [opened,closed,synchronize,reopened]
 
 # explicitly configure permissions, in case your GITHUB_TOKEN workflow permissions are set to read-only in repository settings
 permissions:
@@ -18,19 +17,19 @@ permissions:
 
 jobs:
   CLAAssistant:
-    runs-on: ubuntu-24.04
+    runs-on: ubuntu-latest
     steps:
       - name: "CLA Assistant"
         if: ${{ contains(github.event.comment.body, 'I have read the CLA Document and I hereby sign the CLA') }} || github.event_name == 'pull_request_target'
-        uses: SiliconLabsWorkflows/cla-assistant@silabs_flavour_v2
+        uses: SiliconLabsSoftware/action-cla-assistant@silabs_flavour_v2
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           # the below token should have repo scope and must be manually added by you in the repository's secret
           # This token is required only if you have configured to store the signatures in a remote repository/organization
           PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
         with:
           path-to-signatures: "cla_signatures_db.json"
-          path-to-document: "https://github.com/SiliconLabsSoftware/bluetooth-AoA-example/blob/main/cla.md"
+          path-to-document: "https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/contributor_license_agreement.md"
           # branch should not be protected
           branch: 'cla-database'
           allowlist: silabs-*,bot*

.github/workflows/01-CLA-Assistant.yml

@@ -1,7 +1,5 @@
 name: 02-Build-Firmware
-## By default this workflow runs on Github hosted runners. This is not free for internal and private repositories
-## It is recommended to run this job on a self-hosted runner for non public repository
-## Uncomment the needed runs-on command.
+
 on:
   pull_request:
     branches:
@@ -15,9 +13,7 @@ on:
 
 jobs:
   FW_build:
-    # Choose a runner type here by commenting out the not needed one.
     runs-on: ubuntu-24.04
-    #runs-on: devs-self-hosted-runner
     steps:
       - name: Checkout code
         uses: actions/checkout@v4

.github/workflows/02-Build-Firmware.yml

@@ -30,9 +30,3 @@
 *.xlsx
 *.xls
 *.html
-
-
-
-#code convention tool gitignore
-code-convention-tool/
-**/venv/

.github/workflows/zz-sonarqube-analysis.yml

@@ -0,0 +1,2 @@
+# Silicon Labs Contributor License Agreement
+Follow the link for the official Silicon Labs [Contributor License Agreement](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/contributor_license_agreement.md).

.gitignore

@@ -1,17 +1,17 @@
 # Developer Services template project
-** TODO **Put project introduction here. 1-2 sentence about the project.
+** TODO ** Put project introduction here. 1-2 sentence about the project.
 ## How to use the template
-1. Create your sw projects under "projects/" folder.
-2. Check .gitignore file and modify it if it is necessary
-3. Check the [./Dockerfile](./Dockerfile) and extend it if necessary
-4. Make sure that the whole project can be compiled with a single "make all" command.  
+1. Import the [basic ruleset](https://github.com/SiliconLabsSoftware/devs-template/blob/main/.github/rulesets/Silabs-basic-public-ruleset.json). Follow the official GitHub [guide](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization#importing-a-ruleset).
+2. Update if necessary the [issue_templates](.github/ISSUE_TEMPLATE/) and the [pull request template](./.github/PULL_REQUEST_TEMPLATE.md)
+3. Create your sw projects under [projects/](projects/) folder.
+4. Check [.gitignore](.gitignore) file and modify it if it is necessary
+5. Check the [./Dockerfile](./Dockerfile) and extend it if necessary
+6. Make sure that the whole project can be compiled with a single "make all" command.  
    also implement "make clean"
-5. Fill out the [CODEOWNERS](./.github/CODEOWNERS) file. Here is the official github [guide](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
-6. Update and extend if needed the [sonar project file](./.github/sonar-project.properties) .
-7. **Internal projects only** Add a self-hosted runner with "devs-self-hosted-runner" name. [guide](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners)
-8. Secrets, add your sonarqube token and for  **public repositores** add github personal access token.
-9. Check the workflow and adjust them according to the repo types (internal of public)
-10. Update this Readme file and rempve this list from it.
+7. Fill out the [CODEOWNERS](./.github/CODEOWNERS) file. Here is the official github [guide](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
+8. Add github personal access token named "PERSONAL_ACCESS_TOKEN" as a repository secret. It is necessary for CLA signature workflow.
+9. Check the available [workflows](./.github/workflows) and adjust them according to the repo types (internal or public)
+10. Update this Readme file and remove this list from it.
 
 ## Table of Contents
 - [Developer Services template project](#developer-services-template-project)
@@ -47,7 +47,7 @@ Using Docker for the build environment has several advantages:
 To set up the Docker-based build environment, follow these steps:
 1. Install Docker on your machine. Only Linux and MacOS platforms are supported for now.
 2. Clone the repository.
-3. Build the Docker image using the provided [Dockerfile](./.github/Dockerfile).
+3. Build the Docker image using the provided [Dockerfile](./Dockerfile).
 4. Run the Docker container with the necessary configurations.
 
 ### Windows
@@ -63,7 +63,7 @@ To set up the Docker-based build environment, follow these steps:
 **TODO**
 Explain how can a developer debug this software project. Pictures are recommended.
 ## Contributing
-Please follow the [CONTRIBUTING](./.github/CONTRIBUTING) guideline-
+Please follow the [CONTRIBUTING](./.github/CONTRIBUTING.md) guideline.
 
 ## License
 See the [LICENSE.md](./LICENSE.md) file for details.