diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index b0e14d19..28473a0a 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -13,6 +13,12 @@ contact_links: - name: Support request url: https://forum.arduino.cc/ about: We can help you out on the Arduino Forum! + - name: Issue report guide + url: https://github.com/arduino/tooling-project-assets/blob/main/docs/contributor-guide/issues.md#issue-report-guide + about: Learn about submitting issue reports to this repository. + - name: Contributor guide + url: https://github.com/arduino/tooling-project-assets/blob/main/docs/CONTRIBUTING.md#contributor-guide + about: Learn about contributing to this project. - name: Discuss development work on the project url: https://groups.google.com/a/arduino.cc/g/developers about: Arduino Developers Mailing List diff --git a/.github/workflows/check-community-health-sync.yml b/.github/workflows/check-community-health-sync.yml index e962c5f0..9285c258 100644 --- a/.github/workflows/check-community-health-sync.yml +++ b/.github/workflows/check-community-health-sync.yml @@ -13,12 +13,16 @@ on: - ".github/workflows/check-community-health-sync.ya?ml" - "Taskfile.ya?ml" - ".github/ISSUE_TEMPLATE/**" + - "docs/**" + - "documentation-templates/**" - "issue-templates/**" pull_request: paths: - ".github/workflows/check-community-health-sync.ya?ml" - "Taskfile.ya?ml" - ".github/ISSUE_TEMPLATE/**" + - "docs/**" + - "documentation-templates/**" - "issue-templates/**" schedule: # Run periodically to catch breakage caused by external changes. diff --git a/.markdown-link-check.json b/.markdown-link-check.json index ea266716..bd9245f1 100644 --- a/.markdown-link-check.json +++ b/.markdown-link-check.json @@ -12,7 +12,19 @@ "aliveStatusCodes": [200, 206], "ignorePatterns": [ { - "pattern": "^CONTRIBUTING\\.md#building-the-source-code$" + "pattern": "^../development\\.md#development-guide$" + }, + { + "pattern": "^contributor-guide/beta-testing\\.md#beta-testing-guide$" + }, + { + "pattern": "^development\\.md#building-the-project$" + }, + { + "pattern": "^development\\.md#development-guide$" + }, + { + "pattern": "^issues\\.md#issue-report-guide$" }, { "pattern": "/TODO_REPO_NAME/" diff --git a/Taskfile.yml b/Taskfile.yml index be860107..21fc920f 100644 --- a/Taskfile.yml +++ b/Taskfile.yml @@ -453,9 +453,19 @@ tasks: github:sync: desc: Sync GitHub community health files vars: + DOCUMENTATION_INSTALLATION_PATH: "./docs" + DOCUMENTATION_TEMPLATES_PATH: "./documentation-templates" ISSUE_TEMPLATES_INSTALLATION_PATH: "./.github/ISSUE_TEMPLATE" ISSUE_TEMPLATES_PATH: "./issue-templates" cmds: + - | + cp \ + "{{.DOCUMENTATION_TEMPLATES_PATH}}/contributor-guide/general/CONTRIBUTING.md" \ + "{{.DOCUMENTATION_INSTALLATION_PATH}}" + - | + cp \ + "{{.DOCUMENTATION_TEMPLATES_PATH}}/contributor-guide/general/contributor-guide/assets/"* \ + "{{.DOCUMENTATION_INSTALLATION_PATH}}/contributor-guide/assets/" - | cp \ "{{.ISSUE_TEMPLATES_PATH}}/minimal/bug-report.md" \ diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md new file mode 100644 index 00000000..0d7ad214 --- /dev/null +++ b/docs/CONTRIBUTING.md @@ -0,0 +1,27 @@ + + +# Contributor Guide + +Thanks for your interest in contributing to this project! + +There are several ways you can get involved: + +| Type of contribution | Contribution method | +| ----------------------------------------- | -------------------------------------------------------------------------------- | +| - Support
- Question
- Discussion | Post on the [**Arduino Forum**][forum] | +| - Bug report
- Feature request | Issue report (see the guide [**here**][issues]) | +| Testing | Beta testing, PR review (see the guide [**here**][beta-testing]) | +| - Bug fix
- Enhancement | Pull request (see the guide [**here**][prs]) | +| Monetary | - [Donate][donate]
- [Sponsor][sponsor]
- [Buy official products][store] | + +[forum]: https://forum.arduino.cc +[issues]: contributor-guide/issues.md#issue-report-guide +[beta-testing]: contributor-guide/beta-testing.md#beta-testing-guide +[prs]: contributor-guide/pull-requests.md#pull-request-guide +[donate]: https://www.arduino.cc/en/donate/ +[sponsor]: https://github.com/sponsors/arduino +[store]: https://store.arduino.cc + +## Resources + +- [**Development Guide**](development.md#development-guide) diff --git a/docs/contributor-guide/assets/checks.png b/docs/contributor-guide/assets/checks.png new file mode 100644 index 00000000..888e711b Binary files /dev/null and b/docs/contributor-guide/assets/checks.png differ diff --git a/docs/contributor-guide/beta-testing.md b/docs/contributor-guide/beta-testing.md new file mode 100644 index 00000000..c5237335 --- /dev/null +++ b/docs/contributor-guide/beta-testing.md @@ -0,0 +1,51 @@ + + +# Beta Testing Guide + +Beta testing of development versions is a valuable contribution to the project. You can help to ensure the quality of the production release that will be distributed to the user community. + +--- + +❗ Make sure to always download the newest available development version of the project in order to ensure effective results from your beta testing efforts. + +--- + +Beta testing is done during both the pull request and pre-release phases of development: + +## Testing Pull Requests + +The project's open pull requests are listed here: + +https://github.com/arduino/tooling-project-assets/pulls + +Testing and review is always welcome. + +### Feedback + +Feedback after beta testing a pull request is always valuable, regardless of which categories your findings fall under: + +- working as expected +- problems encountered +- areas for improvement + +Please submit feedback related to the changes made in the pull request as a PR review: + +https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews + +--- + +If you discover problems or areas for improvement that are unrelated to the changes made by the PR (i.e., they also occur when using the [pre-release](#testing-pre-release) version), please submit that feedback as an issue report instead of a review. + +[More information on issue reports](issues.md#issue-report-guide) + +## Testing Pre-Release + +This repository is the central point of maintenance of the reusable assets, from which they continuously propagate to the "downstream" projects". + +See the documentation associated with the specific assets of interest to learn more about their usage. + +### Feedback + +If you discover any problems or areas for improvement please submit an issue report. + +[More information on issue reports](issues.md#issue-report-guide) diff --git a/docs/contributor-guide/issues.md b/docs/contributor-guide/issues.md new file mode 100644 index 00000000..df31d911 --- /dev/null +++ b/docs/contributor-guide/issues.md @@ -0,0 +1,32 @@ + + +# Issue Report Guide + +--- + +❗ Do you need help or have a question about using this project? Support requests should be made to the [Arduino Forum](https://forum.arduino.cc). + +--- + +High quality bug reports and feature requests are valuable contributions to this project. These can be made by submitting an issue report to the project's GitHub repository: + +https://github.com/arduino/tooling-project-assets/issues/new/choose + +## Before Reporting an Issue + +- Give the latest version of the asset from the `main` branch of this repository a test drive to see if your issue was already resolved. +- Search [existing pull requests and issues](https://github.com/arduino/tooling-project-assets/issues?q=) to see if it was already reported.
+ If you have additional information to provide about an existing issue, please comment there instead of creating a duplicate. You can use [GitHub's "Reactions" feature](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) if you only want to express support 👍. + +## Qualities of an Excellent Report + +- Concise and descriptive issue title.
+ Vague titles make it difficult to decipher the purpose of the issue when looking through the list of reports, which might result in your issue not being given proper attention. +- Describe the issue and what behavior you were expecting.
+ Include the full and exact text of any relevant error or warning messages you might have encountered. +- Provide a full set of steps necessary to reproduce the issue.
+ Demonstration code or commands should be complete and simplified to the minimum necessary to reproduce the issue. +- Be responsive.
+ We may need you to provide additional information in order to investigate and resolve the issue.
+ Make sure your GitHub account is configured so that you will receive notifications of responses to your issue report. +- If you find a solution to your problem, please comment on your issue report with an explanation of how you were able to fix it, then close the issue. diff --git a/docs/contributor-guide/pull-requests.md b/docs/contributor-guide/pull-requests.md new file mode 100644 index 00000000..c8c7767e --- /dev/null +++ b/docs/contributor-guide/pull-requests.md @@ -0,0 +1,199 @@ + + +# Pull Request Guide + +A [**pull request**](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) is the mechanism used to propose changes to the content of this project's repository. + +If you are looking for ideas of what to work on, check [the list of open issue reports](https://github.com/arduino/tooling-project-assets/issues). Pull requests addressing any of those bug reports and feature requests are welcome. + +## Contribution Workflow + +Each contribution travels through a formal process which allows it to be efficiently incorporated into the project. + +### 1. Plan + +#### Research + +Start by searching the repository for existing pull requests and issues related to your planned contribution so you can see any related conversations and proposals and avoid duplicate effort: + +https://github.com/arduino/tooling-project-assets/issues?q= + +#### Discussion + +It can sometimes be useful to get feedback from others during the planning process. There are a couple good options for discussing planned development work: + +- Talk with the user community on the [Arduino Forum](https://forum.arduino.cc/). +- Talk with Arduino developers on the [Arduino Developers Mailing List](https://groups.google.com/a/arduino.cc/g/developers). + +### 2. Fork + +Forking a GitHub repository creates a copy of it under your account. You will stage contributions in your fork of this project. + +[More information about forking repositories](https://docs.github.com/get-started/quickstart/fork-a-repo) + +#### Enabling CI in Your Fork + +The repository is configured to run automated [continuous integration](https://wikipedia.org/wiki/Continuous_integration) (CI) checks and tests. It's a good idea to enable CI in your fork so you can make sure your work will pass the checks before you submit a pull request: + +1. Open the homepage of your fork in the browser. +1. Click the "**Actions**" tab. +1. Click the **I understand my workflows, go ahead and enable them** button. +1. Some of the workflows will now need to be activated individually. Perform the following steps for each of the useful workflows listed on the left side of the page that have a "**!**" icon: + 1. Click on the workflow name. + 1. Click the **Enable workflow** button. + +### 3. Clone + +Cloning a repository creates a copy of it on your computer. + +It is possible to make simple changes to your repository using the GitHub web interface without cloning the repository. However, the GitHub web interface is quite limiting so you will likely find the need to work with a clone (using **Git** directly or your choice of [Git client software](https://git-scm.com/downloads/guis)) for any significant development work. + +[More information about cloning repositories](https://git-scm.com/docs/git-clone) + +### 4. Branch + +Create a branch in your fork to contain the changes for your contribution. You must make a separate branch in your fork for each pull request you submit. + +[More information about branches](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) + +### 5. Make a change + +Some things to keep in mind: + +- Make sure your change complies with the project's established style conventions. +- Remember to also update the documentation content in the repository if required by your changes. +- If the project contains a test suite, update or add tests according to your change as appropriate. + +See [the development guide](../development.md#development-guide) for more information. + +### 6. Test + +Test your change carefully to make sure it works correctly and did not break other components of the project. + +As a supplement for general testing, the project is set up with automated checks and tests to facilitate development. + +See [the development guide](../development.md#development-guide) for instructions. + +### 7. Commit + +Once the work on your change is complete, add it to the revision history of the Git repository by making a commit. + +Make sure to follow the [Commit Guidelines](#commit-guidelines). + +[More information about commits](https://git-scm.com/docs/git-commit) + +### 8. Push + +If you're working from a [clone](#3-clone), you will need to push your commit to your fork on GitHub. + +[More information about pushing commits](https://git-scm.com/docs/git-push) + +#### Checking CI Results + +If you have [enabled CI in your repository](#enabling-ci-in-your-fork), GitHub will run the relevant checks automatically every time you push a commit to your fork. + +You can see the results of these checks by doing either of the following: + +- Clicking the status icon (✔️ or ❌) shown to the right of a commit. +- Opening the repository's "**Actions**" tab. + +### 9. Pull request + +A pull request (PR) is a proposal to make a change in a repository. The repository maintainer is able to accept the changes you propose in a pull request by simply clicking a button. + +[More information about pull requests](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) + +#### Scope + +Each pull request should address a single bug fix or enhancement. If you have multiple unrelated fixes or enhancements to contribute, submit them as separate pull requests. + +#### Description + +Pull request title and description should follow [the same guidelines as commit messages](#commit-message). + +If your pull request fixes an issue in the issue tracker, use [a closing keyword](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in the body to indicate this. + +In some cases, it might make sense to request feedback on a proposal before it is ready to be merged. You can indicate this by starting the pull request title with **[WIP]** (work in progress). Once the pull request is ready to be merged, edit the title and remove the "[WIP]". + +#### Cross-repository Contributions + +Some proposals may require changes to multiple repositories. Pull requests should be submitted in parallel to each repository. + +Clearly note any dependencies on other PRs in the description so that these can be evaluated by the reviewer and the merges coordinated. + +--- + +Please check whether any changes are required to the related documentation content hosted in the separate dedicated repositories: + +- [**arduino/docs-content**](https://github.com/arduino/docs-content) +- [**arduino/help-center-content**](https://github.com/arduino/help-center-content) + +### 10. Resolve CI failures + +Relevant checks will run automatically once you have submitted the pull request. Once these checks are finished, you can see a summary of the results near the bottom of the pull request page: + +![checks](assets/checks.png) + +Failed checks will be indicated with an ❌. If any checks failed, please fix whatever caused it to fail. Click the "**Details**" link to the right of the check name to open the logs, which provide details about the failure. + +--- + +**ⓘ** In some rare cases, a CI failure may be unrelated to the changes made in your pull request. So if the information in the logs doesn't seem relevant, please comment on the pull request to ask a maintainer to take a look. + +--- + +When you push to the branch of your fork the pull request was submitted from, the commit is automatically added to the pull request. Don't create a new pull request to fix problems; update the existing pull request. + +### 11. Resolve changes requested from reviews + +Interested parties may review your pull request and suggest improvements. + +To act on general review suggestions, you can add commits to the branch you submitted the pull request from, which will automatically be added to the pull request. Don't create a new pull request to act on review suggestions; update the existing pull request. + +Reviewers may suggest specific changes, which can be applied by [clicking the **Commit suggestion** button](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request#applying-suggested-changes). + +[More information about pull request reviews](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) + +### 12. Merge + +One of the repository maintainers can now choose to accept your proposed change. Once the pull request is [merged](https://docs.github.com/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request), you can delete the branch you created in your fork for the pull request and delete the fork as well if you like. + +Thanks so much for your contribution! + +--- + +It is possible that the maintainers may decide a pull request doesn't align with Arduino's goals for the project and close it rather than merging. A record of the proposed changes will always be available on GitHub for future reference. If you think your modifications will be of use to others, you are welcome to maintain your own fork of the repository. + +--- + +## Commit Guidelines + +The commit history of a repository is an important resource for developers. Repositories may accumulate thousands of commits over the course of decades. Each individual commit contributes either to the commit history being pleasant and efficient to work with, or to it being a confusing mess. For this reason, it's essential for contributors to create clean, high quality commits. + +### Scope + +Commits must be "atomic". This means that the commit completely accomplishes a single task. Each commit should result in fully functional code. Multiple tasks should not be combined in a single commit, but a single task should not be split over multiple commits (e.g., one commit per file modified is not a good practice). + +[More information about atomic commits](https://www.freshconsulting.com/insights/blog/atomic-commits/) + +### Commit Message + +The commit message documents what the change was and why it was done. A little effort now writing a good commit message can save future developers from wasted time and frustration trying to understand the purpose of a poorly documented commit. + +#### Commit Message Title + +- Use the [imperative mood](https://cbea.ms/git-commit/#imperative) in the title.
+ For example: + > Use LED_BUILTIN macro in LED pin definition +- Capitalize the title. +- Do not end the title with punctuation. +- Do not use GitHub's default commit titles (e.g., "Update examples/Foo/Foo.ino"). + +#### Commit Message Body + +- Separate title from the body with a blank line. If you're committing via GitHub or [GitHub Desktop](https://desktop.github.com/) this will be done automatically. +- Wrap body at 120 characters. +- Completely explain the purpose of the commit.
+ Include a rationale for the change, any caveats, side-effects, etc. + +[More information on commit messages](https://cbea.ms/git-commit/) diff --git a/docs/development.md b/docs/development.md new file mode 100644 index 00000000..b0a5ccc7 --- /dev/null +++ b/docs/development.md @@ -0,0 +1,44 @@ + + +# Development Guide + +## Prerequisites + +The following development tools must be available in your local environment: + +- [**Node.js** / **npm**](https://nodejs.org/en/download/) - Node.js dependencies management tool + - + This project uses Node.js 16.x +- [**Python**](https://wiki.python.org/moin/BeginnersGuide/Download) + - + This project uses Python 3.9.x +- [**Poetry**](https://python-poetry.org/docs/#installation) - Python dependencies management tool +- [**Task**](https://taskfile.dev/installation/) - task runner tool + +## Building the Project + +You can build the project by running this command from the root folder of the project: + +```text +task build +``` + +## Running Checks + +Checks and tests are set up to ensure the project content is functional and compliant with the established standards. + +You can run the checks by running this command from the root folder of the project: + +```text +task check +``` + +## Automatic Corrections + +Tools are provided to automatically bring the project into compliance with some of the required checks. + +You can make these automatic fixes by running this command from the root folder of the project: + +```text +task fix +``` diff --git a/documentation-templates/README.md b/documentation-templates/README.md new file mode 100644 index 00000000..e7847834 --- /dev/null +++ b/documentation-templates/README.md @@ -0,0 +1,75 @@ +# Documentation Templates + +## Contributor Guide + +The file `CONTRIBUTING.md` serves as an entry point to the content. This file is given special treatment by GitHub, which presents it to potential contributors: + +https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors + +### Installation + +Install the files and folders from [`contributor-guide/general/`](contributor-guide/general/) to the `docs/` subfolder of the repository. + +#### Beta Testing Guide + +An additional file named `beta-testing.md` must be added to the `docs/contributor-guide/` subfolder of the repository. + +##### Application Projects + +If tester builds are generated for the project, use the template files from [`contributor-guide/application/contributor-guide/beta-testing.md`](contributor-guide/application/contributor-guide/beta-testing.md). + +The project is assumed to use a workflow with the standardized name "**Publish Tester Build**" to produce tester builds for pull requests. + +A workflow template for Go-based projects is available [here](../workflow-templates/publish-go-tester-task.md). + +##### Other Projects + +A basic template providing the standardized structure for the document is available at [`contributor-guide/other/contributor-guide/beta-testing.md`](contributor-guide/other/contributor-guide/beta-testing.md). + +#### Development Guide + +An additional file named `development.md` must be added to the `docs/` subfolder of the repository. + +##### Task-Based Projects + +For projects which use the standardized Task-based approach to project management, use the template file from [`contributor-guide/task/development.md`](contributor-guide/task/development.md). + +The taskfile must contain the following standardized "umbrella" tasks: + +- `build` - build the project +- `check` - run all tasks that check for problems with the project +- `fix` - run all tasks that make automated corrections to the project's files + +##### Other Projects + +A basic template providing the standardized structure for the document is available at [`contributor-guide/other/development.md`](contributor-guide/other/development.md). + +#### Configuration + +"**TODO**" comments and placeholders mark the locations in the documents where project-specific adjustments or additions should be made. + +### Commit message + +```text +Add a project contributor guide + +Documentation of how to contribute to the project gives everyone the opportunity to participate, while also reducing +maintenance effort and increasing quality of contributions. + +This guide documents the various ways of contributing to the project. + +It takes advantage of GitHub's "contributing guidelines" feature to increase the visibility of the information to +prospective contributors. The promoted "CONTRIBUTING.md" file is used as an entry point to the guide, with links from +there leading to dedicated guides for each specific type of contribution. In this way, the contributor is only presented +with relevant information, improving the approachability and readability of the content. +``` + +### PR message + +```markdown +Documentation of how to contribute to the project gives everyone the opportunity to participate, while also reducing maintenance effort and increasing quality of contributions. + +This guide documents the various ways of contributing to the project. + +It takes advantage of [GitHub's "contributing guidelines" feature](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors) to increase the visibility of the information to prospective contributors. The promoted `CONTRIBUTING.md` file is used as an entry point to the guide, with links from there leading to dedicated guides for each specific type of contribution. In this way, the contributor is only presented with relevant information, improving the approachability and readability of the content. +``` diff --git a/documentation-templates/contributor-guide/application/contributor-guide/assets/checks-tab.png b/documentation-templates/contributor-guide/application/contributor-guide/assets/checks-tab.png new file mode 100644 index 00000000..bfb2b029 Binary files /dev/null and b/documentation-templates/contributor-guide/application/contributor-guide/assets/checks-tab.png differ diff --git a/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-artifacts.png b/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-artifacts.png new file mode 100644 index 00000000..ecea9d6d Binary files /dev/null and b/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-artifacts.png differ diff --git a/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-link.png b/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-link.png new file mode 100644 index 00000000..62be4174 Binary files /dev/null and b/documentation-templates/contributor-guide/application/contributor-guide/assets/tester-build-link.png differ diff --git a/documentation-templates/contributor-guide/application/contributor-guide/beta-testing.md b/documentation-templates/contributor-guide/application/contributor-guide/beta-testing.md new file mode 100644 index 00000000..1b76d4e1 --- /dev/null +++ b/documentation-templates/contributor-guide/application/contributor-guide/beta-testing.md @@ -0,0 +1,75 @@ + + +# Beta Testing Guide + +Beta testing of development versions is a valuable contribution to the project. You can help to ensure the quality of the production release that will be distributed to the user community. + +Builds of the project are automatically created after every relevant change to the project in order to make it easy for anyone to participate in the testing effort. + +--- + +❗ Make sure to always download the newest available tester build in order to ensure effective results from your beta testing efforts. + +--- + +Beta testing is done during both the proposal (pull request) and pre-release (nightly build) phases of development: + +## Testing Pull Requests + +Tester builds are automatically created for every [pull request](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) that proposes a relevant change. + +The builds are updated if the author pushes changes to the PR. + +### Installation + +The tester build for a PR can be downloaded by following these instructions: + +1. Sign in to your [**GitHub**](https://github.com/) account.
+ (GitHub only allows downloads of the tester builds when you are signed in.) +1. Open the PR you are interested in.
+ They are listed here:
+ https://github.com/arduino/TODO_REPO_NAME/pulls +1. Click the "**Checks**" tab at the top of the PR's page. +1. From the list on the left side of the page, click on "**Publish Tester Build**". +1. From the "**Artifacts**" section of the page that opens, click the download link for your operating system.
+ **ⓘ** For example, if you are using Windows, click the "**Windows_X86-64_zip**" link. +1. Wait for the download to finish. +1. Extract or install the downloaded file as usual. + +![checks tab](assets/checks-tab.png) + +![tester build link](assets/tester-build-link.png) + +![tester build artifacts](assets/tester-build-artifacts.png) + +### Feedback + +Feedback after beta testing a pull request is always valuable, regardless of which categories your findings fall under: + +- working as expected +- problems encountered +- areas for improvement + +Please submit feedback related to the changes made in the pull request as a PR review: + +https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews + +--- + +If you discover problems or areas for improvement that are unrelated to the changes made by the PR (i.e., they also occur when using the [nightly build](#testing-nightly-build)), please submit that feedback as an issue report instead of a review. + +[More information on issue reports](issues.md#issue-report-guide) + +## Testing Nightly Build + +Builds of the project's production branch are produced daily. This build represents the current pre-release state of the project, which is planned for distribution in the next release. + +### Installation + + + +### Feedback + +If you discover any problems or areas for improvement please submit an issue report. + +[More information on issue reports](issues.md#issue-report-guide) diff --git a/documentation-templates/contributor-guide/general/CONTRIBUTING.md b/documentation-templates/contributor-guide/general/CONTRIBUTING.md new file mode 100644 index 00000000..0d7ad214 --- /dev/null +++ b/documentation-templates/contributor-guide/general/CONTRIBUTING.md @@ -0,0 +1,27 @@ + + +# Contributor Guide + +Thanks for your interest in contributing to this project! + +There are several ways you can get involved: + +| Type of contribution | Contribution method | +| ----------------------------------------- | -------------------------------------------------------------------------------- | +| - Support
- Question
- Discussion | Post on the [**Arduino Forum**][forum] | +| - Bug report
- Feature request | Issue report (see the guide [**here**][issues]) | +| Testing | Beta testing, PR review (see the guide [**here**][beta-testing]) | +| - Bug fix
- Enhancement | Pull request (see the guide [**here**][prs]) | +| Monetary | - [Donate][donate]
- [Sponsor][sponsor]
- [Buy official products][store] | + +[forum]: https://forum.arduino.cc +[issues]: contributor-guide/issues.md#issue-report-guide +[beta-testing]: contributor-guide/beta-testing.md#beta-testing-guide +[prs]: contributor-guide/pull-requests.md#pull-request-guide +[donate]: https://www.arduino.cc/en/donate/ +[sponsor]: https://github.com/sponsors/arduino +[store]: https://store.arduino.cc + +## Resources + +- [**Development Guide**](development.md#development-guide) diff --git a/documentation-templates/contributor-guide/general/contributor-guide/assets/checks.png b/documentation-templates/contributor-guide/general/contributor-guide/assets/checks.png new file mode 100644 index 00000000..888e711b Binary files /dev/null and b/documentation-templates/contributor-guide/general/contributor-guide/assets/checks.png differ diff --git a/documentation-templates/contributor-guide/general/contributor-guide/issues.md b/documentation-templates/contributor-guide/general/contributor-guide/issues.md new file mode 100644 index 00000000..0e99c088 --- /dev/null +++ b/documentation-templates/contributor-guide/general/contributor-guide/issues.md @@ -0,0 +1,33 @@ + + +# Issue Report Guide + +--- + +❗ Do you need help or have a question about using this project? Support requests should be made to the [Arduino Forum](https://forum.arduino.cc). + +--- + +High quality bug reports and feature requests are valuable contributions to this project. These can be made by submitting an issue report to the project's GitHub repository: + +https://github.com/arduino/TODO_REPO_NAME/issues/new/choose + +## Before Reporting an Issue + +- Give the latest development version a test drive to see if your issue was already resolved:
+ +- Search [existing pull requests and issues](https://github.com/arduino/TODO_REPO_NAME/issues?q=) to see if it was already reported.
+ If you have additional information to provide about an existing issue, please comment there instead of creating a duplicate. You can use [GitHub's "Reactions" feature](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) if you only want to express support 👍. + +## Qualities of an Excellent Report + +- Concise and descriptive issue title.
+ Vague titles make it difficult to decipher the purpose of the issue when looking through the list of reports, which might result in your issue not being given proper attention. +- Describe the issue and what behavior you were expecting.
+ Include the full and exact text of any relevant error or warning messages you might have encountered. +- Provide a full set of steps necessary to reproduce the issue.
+ Demonstration code or commands should be complete and simplified to the minimum necessary to reproduce the issue. +- Be responsive.
+ We may need you to provide additional information in order to investigate and resolve the issue.
+ Make sure your GitHub account is configured so that you will receive notifications of responses to your issue report. +- If you find a solution to your problem, please comment on your issue report with an explanation of how you were able to fix it, then close the issue. diff --git a/documentation-templates/contributor-guide/general/contributor-guide/pull-requests.md b/documentation-templates/contributor-guide/general/contributor-guide/pull-requests.md new file mode 100644 index 00000000..7b67554a --- /dev/null +++ b/documentation-templates/contributor-guide/general/contributor-guide/pull-requests.md @@ -0,0 +1,199 @@ + + +# Pull Request Guide + +A [**pull request**](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) is the mechanism used to propose changes to the content of this project's repository. + +If you are looking for ideas of what to work on, check [the list of open issue reports](https://github.com/arduino/TODO_REPO_NAME/issues). Pull requests addressing any of those bug reports and feature requests are welcome. + +## Contribution Workflow + +Each contribution travels through a formal process which allows it to be efficiently incorporated into the project. + +### 1. Plan + +#### Research + +Start by searching the repository for existing pull requests and issues related to your planned contribution so you can see any related conversations and proposals and avoid duplicate effort: + +https://github.com/arduino/TODO_REPO_NAME/issues?q= + +#### Discussion + +It can sometimes be useful to get feedback from others during the planning process. There are a couple good options for discussing planned development work: + +- Talk with the user community on the [Arduino Forum](https://forum.arduino.cc/). +- Talk with Arduino developers on the [Arduino Developers Mailing List](https://groups.google.com/a/arduino.cc/g/developers). + +### 2. Fork + +Forking a GitHub repository creates a copy of it under your account. You will stage contributions in your fork of this project. + +[More information about forking repositories](https://docs.github.com/get-started/quickstart/fork-a-repo) + +#### Enabling CI in Your Fork + +The repository is configured to run automated [continuous integration](https://wikipedia.org/wiki/Continuous_integration) (CI) checks and tests. It's a good idea to enable CI in your fork so you can make sure your work will pass the checks before you submit a pull request: + +1. Open the homepage of your fork in the browser. +1. Click the "**Actions**" tab. +1. Click the **I understand my workflows, go ahead and enable them** button. +1. Some of the workflows will now need to be activated individually. Perform the following steps for each of the useful workflows listed on the left side of the page that have a "**!**" icon: + 1. Click on the workflow name. + 1. Click the **Enable workflow** button. + +### 3. Clone + +Cloning a repository creates a copy of it on your computer. + +It is possible to make simple changes to your repository using the GitHub web interface without cloning the repository. However, the GitHub web interface is quite limiting so you will likely find the need to work with a clone (using **Git** directly or your choice of [Git client software](https://git-scm.com/downloads/guis)) for any significant development work. + +[More information about cloning repositories](https://git-scm.com/docs/git-clone) + +### 4. Branch + +Create a branch in your fork to contain the changes for your contribution. You must make a separate branch in your fork for each pull request you submit. + +[More information about branches](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) + +### 5. Make a change + +Some things to keep in mind: + +- Make sure your change complies with the project's established style conventions. +- Remember to also update the documentation content in the repository if required by your changes. +- If the project contains a test suite, update or add tests according to your change as appropriate. + +See [the development guide](../development.md#development-guide) for more information. + +### 6. Test + +Test your change carefully to make sure it works correctly and did not break other components of the project. + +As a supplement for general testing, the project is set up with automated checks and tests to facilitate development. + +See [the development guide](../development.md#development-guide) for instructions. + +### 7. Commit + +Once the work on your change is complete, add it to the revision history of the Git repository by making a commit. + +Make sure to follow the [Commit Guidelines](#commit-guidelines). + +[More information about commits](https://git-scm.com/docs/git-commit) + +### 8. Push + +If you're working from a [clone](#3-clone), you will need to push your commit to your fork on GitHub. + +[More information about pushing commits](https://git-scm.com/docs/git-push) + +#### Checking CI Results + +If you have [enabled CI in your repository](#enabling-ci-in-your-fork), GitHub will run the relevant checks automatically every time you push a commit to your fork. + +You can see the results of these checks by doing either of the following: + +- Clicking the status icon (✔️ or ❌) shown to the right of a commit. +- Opening the repository's "**Actions**" tab. + +### 9. Pull request + +A pull request (PR) is a proposal to make a change in a repository. The repository maintainer is able to accept the changes you propose in a pull request by simply clicking a button. + +[More information about pull requests](https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) + +#### Scope + +Each pull request should address a single bug fix or enhancement. If you have multiple unrelated fixes or enhancements to contribute, submit them as separate pull requests. + +#### Description + +Pull request title and description should follow [the same guidelines as commit messages](#commit-message). + +If your pull request fixes an issue in the issue tracker, use [a closing keyword](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in the body to indicate this. + +In some cases, it might make sense to request feedback on a proposal before it is ready to be merged. You can indicate this by starting the pull request title with **[WIP]** (work in progress). Once the pull request is ready to be merged, edit the title and remove the "[WIP]". + +#### Cross-repository Contributions + +Some proposals may require changes to multiple repositories. Pull requests should be submitted in parallel to each repository. + +Clearly note any dependencies on other PRs in the description so that these can be evaluated by the reviewer and the merges coordinated. + +--- + +Please check whether any changes are required to the related documentation content hosted in the separate dedicated repositories: + +- [**arduino/docs-content**](https://github.com/arduino/docs-content) +- [**arduino/help-center-content**](https://github.com/arduino/help-center-content) + +### 10. Resolve CI failures + +Relevant checks will run automatically once you have submitted the pull request. Once these checks are finished, you can see a summary of the results near the bottom of the pull request page: + +![checks](assets/checks.png) + +Failed checks will be indicated with an ❌. If any checks failed, please fix whatever caused it to fail. Click the "**Details**" link to the right of the check name to open the logs, which provide details about the failure. + +--- + +**ⓘ** In some rare cases, a CI failure may be unrelated to the changes made in your pull request. So if the information in the logs doesn't seem relevant, please comment on the pull request to ask a maintainer to take a look. + +--- + +When you push to the branch of your fork the pull request was submitted from, the commit is automatically added to the pull request. Don't create a new pull request to fix problems; update the existing pull request. + +### 11. Resolve changes requested from reviews + +Interested parties may review your pull request and suggest improvements. + +To act on general review suggestions, you can add commits to the branch you submitted the pull request from, which will automatically be added to the pull request. Don't create a new pull request to act on review suggestions; update the existing pull request. + +Reviewers may suggest specific changes, which can be applied by [clicking the **Commit suggestion** button](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request#applying-suggested-changes). + +[More information about pull request reviews](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) + +### 12. Merge + +One of the repository maintainers can now choose to accept your proposed change. Once the pull request is [merged](https://docs.github.com/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request), you can delete the branch you created in your fork for the pull request and delete the fork as well if you like. + +Thanks so much for your contribution! + +--- + +It is possible that the maintainers may decide a pull request doesn't align with Arduino's goals for the project and close it rather than merging. A record of the proposed changes will always be available on GitHub for future reference. If you think your modifications will be of use to others, you are welcome to maintain your own fork of the repository. + +--- + +## Commit Guidelines + +The commit history of a repository is an important resource for developers. Repositories may accumulate thousands of commits over the course of decades. Each individual commit contributes either to the commit history being pleasant and efficient to work with, or to it being a confusing mess. For this reason, it's essential for contributors to create clean, high quality commits. + +### Scope + +Commits must be "atomic". This means that the commit completely accomplishes a single task. Each commit should result in fully functional code. Multiple tasks should not be combined in a single commit, but a single task should not be split over multiple commits (e.g., one commit per file modified is not a good practice). + +[More information about atomic commits](https://www.freshconsulting.com/insights/blog/atomic-commits/) + +### Commit Message + +The commit message documents what the change was and why it was done. A little effort now writing a good commit message can save future developers from wasted time and frustration trying to understand the purpose of a poorly documented commit. + +#### Commit Message Title + +- Use the [imperative mood](https://cbea.ms/git-commit/#imperative) in the title.
+ For example: + > Use LED_BUILTIN macro in LED pin definition +- Capitalize the title. +- Do not end the title with punctuation. +- Do not use GitHub's default commit titles (e.g., "Update examples/Foo/Foo.ino"). + +#### Commit Message Body + +- Separate title from the body with a blank line. If you're committing via GitHub or [GitHub Desktop](https://desktop.github.com/) this will be done automatically. +- Wrap body at 120 characters. +- Completely explain the purpose of the commit.
+ Include a rationale for the change, any caveats, side-effects, etc. + +[More information on commit messages](https://cbea.ms/git-commit/) diff --git a/documentation-templates/contributor-guide/other/contributor-guide/beta-testing.md b/documentation-templates/contributor-guide/other/contributor-guide/beta-testing.md new file mode 100644 index 00000000..b0a4d9d8 --- /dev/null +++ b/documentation-templates/contributor-guide/other/contributor-guide/beta-testing.md @@ -0,0 +1,45 @@ + + +# Beta Testing Guide + +Beta testing of development versions is a valuable contribution to the project. You can help to ensure the quality of the production release that will be distributed to the user community. + +--- + +❗ Make sure to always download the newest available development version of the project in order to ensure effective results from your beta testing efforts. + +--- + +Beta testing is done during both the pull request and pre-release phases of development: + +## Testing Pull Requests + + + +### Feedback + +Feedback after beta testing a pull request is always valuable, regardless of which categories your findings fall under: + +- working as expected +- problems encountered +- areas for improvement + +Please submit feedback related to the changes made in the pull request as a PR review: + +https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews + +--- + +If you discover problems or areas for improvement that are unrelated to the changes made by the PR (i.e., they also occur when using the [pre-release](#testing-pre-release) version), please submit that feedback as an issue report instead of a review. + +[More information on issue reports](issues.md#issue-report-guide) + +## Testing Pre-Release + + + +### Feedback + +If you discover any problems or areas for improvement please submit an issue report. + +[More information on issue reports](issues.md#issue-report-guide) diff --git a/documentation-templates/contributor-guide/other/development.md b/documentation-templates/contributor-guide/other/development.md new file mode 100644 index 00000000..9f039538 --- /dev/null +++ b/documentation-templates/contributor-guide/other/development.md @@ -0,0 +1,25 @@ + + +# Development Guide + +## Prerequisites + +The following development tools must be available in your local environment: + + + +## Building the Project + + + +## Running Checks + +Checks and tests are set up to ensure the project content is functional and compliant with the established standards. + + + +## Automatic Corrections + +Tools are provided to automatically bring the project into compliance with some of the required checks. + + diff --git a/documentation-templates/contributor-guide/task/development.md b/documentation-templates/contributor-guide/task/development.md new file mode 100644 index 00000000..52233c87 --- /dev/null +++ b/documentation-templates/contributor-guide/task/development.md @@ -0,0 +1,45 @@ + + +# Development Guide + +## Prerequisites + +The following development tools must be available in your local environment: + + + +- [**Task**](https://taskfile.dev/installation/) - task runner tool + +## Building the Project + +--- + +**ⓘ** If you only want to test an existing version of the project, automatically generated builds are available for download without building from source. See the instructions in the [**beta testing guide**](contributor-guide/beta-testing.md#beta-testing-guide). + +--- + +You can build the project by running this command from the root folder of the project: + +```text +task build +``` + +## Running Checks + +Checks and tests are set up to ensure the project content is functional and compliant with the established standards. + +You can run the checks by running this command from the root folder of the project: + +```text +task check +``` + +## Automatic Corrections + +Tools are provided to automatically bring the project into compliance with some of the required checks. + +You can make these automatic fixes by running this command from the root folder of the project: + +```text +task fix +``` diff --git a/issue-templates/template-choosers/general/config.yml b/issue-templates/template-choosers/general/config.yml index a967c310..6ae7499f 100644 --- a/issue-templates/template-choosers/general/config.yml +++ b/issue-templates/template-choosers/general/config.yml @@ -11,6 +11,14 @@ contact_links: - name: Support request url: https://forum.arduino.cc/ about: We can help you out on the Arduino Forum! + - name: Issue report guide + # TODO: Replace TODO_REPO_OWNER/TODO_REPO_NAME with the repository owner and name + url: https://github.com/TODO_REPO_OWNER/TODO_REPO_NAME/blob/main/docs/contributor-guide/issues.md#issue-report-guide + about: Learn about submitting issue reports to this repository. + - name: Contributor guide + # TODO: Replace TODO_REPO_OWNER/TODO_REPO_NAME with the repository owner and name + url: https://github.com/TODO_REPO_OWNER/TODO_REPO_NAME/blob/main/docs/CONTRIBUTING.md#contributor-guide + about: Learn about contributing to this project. - name: Discuss development work on the project url: https://groups.google.com/a/arduino.cc/g/developers about: Arduino Developers Mailing List diff --git a/issue-templates/template-choosers/github-actions/config.yml b/issue-templates/template-choosers/github-actions/config.yml index 54565e3c..8abf02d2 100644 --- a/issue-templates/template-choosers/github-actions/config.yml +++ b/issue-templates/template-choosers/github-actions/config.yml @@ -14,6 +14,14 @@ contact_links: - name: Support request url: https://forum.arduino.cc/ about: We can help you out on the Arduino Forum! + - name: Issue report guide + # TODO: Replace TODO_REPO_OWNER/TODO_REPO_NAME with the repository owner and name + url: https://github.com/TODO_REPO_OWNER/TODO_REPO_NAME/blob/main/docs/contributor-guide/issues.md#issue-report-guide + about: Learn about submitting issue reports to this repository. + - name: Contributor guide + # TODO: Replace TODO_REPO_OWNER/TODO_REPO_NAME with the repository owner and name + url: https://github.com/TODO_REPO_OWNER/TODO_REPO_NAME/blob/main/docs/CONTRIBUTING.md#contributor-guide + about: Learn about contributing to this project. - name: Discuss development work on the project url: https://groups.google.com/a/arduino.cc/g/developers about: Arduino Developers Mailing List diff --git a/other/installation-script/installation.md b/other/installation-script/installation.md index 3359a802..1a564dc8 100644 --- a/other/installation-script/installation.md +++ b/other/installation-script/installation.md @@ -93,4 +93,4 @@ Checksums for the nightly builds are available at ## Build from source If you're familiar with Golang or if you want to contribute to the project, you will probably build TODO_PRODUCT_NAME locally -with your Go toolchain. See the ["How to contribute"](CONTRIBUTING.md#building-the-source-code) page for instructions. +with your Go toolchain. See the ["How to contribute"](development.md#building-the-project) page for instructions. diff --git a/workflow-templates/check-go-dependencies-task.md b/workflow-templates/check-go-dependencies-task.md index 700fa92c..b5359424 100644 --- a/workflow-templates/check-go-dependencies-task.md +++ b/workflow-templates/check-go-dependencies-task.md @@ -65,7 +65,9 @@ A dependency might use a license type that can not be allowed globally via the ` In this case, the dependency's identifier must be added to the `reviewed.[*]` key in the `.licensed.yml` configuration file. -### Readme badge +### Documentation + +#### Readme badge Markdown badge: @@ -85,6 +87,26 @@ image:https://github.com/{repository-owner}/{repository-name}/actions/workflows/ Define the `{repository-owner}` and `{repository-name}` attributes and use them throughout the readme ([example](https://raw.githubusercontent.com/arduino-libraries/WiFiNINA/master/README.adoc)). +#### Development Guide + +Add the following under the "**Running Checks**" section of the project's development documentation (template available [here](../documentation-templates/contributor-guide/task/development.md)): + +````markdown +### Dependency License Metadata + +Metadata about the license types of all dependencies is cached in the repository. To update this cache, run the following command from the repository root folder: + +```text +task general:cache-dep-licenses +``` + +The necessary **Licensed** tool can be installed by following [these instructions](https://github.com/github/licensed#as-an-executable). + +Unfortunately, **Licensed** does not have Windows support. + +An updated cache is also generated whenever the cache is found to be outdated by the by the "**Check Go Dependencies**" CI workflow and made available for download via the `dep-licenses-cache` [workflow artifact](https://docs.github.com/actions/managing-workflow-runs/downloading-workflow-artifacts). +```` + ## Commit message ``` diff --git a/workflow-templates/check-npm-dependencies-task.md b/workflow-templates/check-npm-dependencies-task.md index 4b8f133c..5535e4d4 100644 --- a/workflow-templates/check-npm-dependencies-task.md +++ b/workflow-templates/check-npm-dependencies-task.md @@ -90,7 +90,9 @@ ignore: | /.licenses/ ``` -### Readme badge +### Documentation + +#### Readme badge Markdown badge: @@ -110,6 +112,26 @@ image:https://github.com/{repository-owner}/{repository-name}/actions/workflows/ Define the `{repository-owner}` and `{repository-name}` attributes and use them throughout the readme ([example](https://raw.githubusercontent.com/arduino-libraries/WiFiNINA/master/README.adoc)). +#### Development Guide + +Add the following under the "**Running Checks**" section of the project's development documentation (template available [here](../documentation-templates/contributor-guide/task/development.md)): + +````markdown +### Dependency License Metadata + +Metadata about the license types of all dependencies is cached in the repository. To update this cache, run the following command from the repository root folder: + +```text +task general:cache-dep-licenses +``` + +The necessary **Licensed** tool can be installed by following [these instructions](https://github.com/github/licensed#as-an-executable). + +Unfortunately, **Licensed** does not have Windows support. + +An updated cache is also generated whenever the cache is found to be outdated by the by the "**Check Go Dependencies**" CI workflow and made available for download via the `dep-licenses-cache` [workflow artifact](https://docs.github.com/actions/managing-workflow-runs/downloading-workflow-artifacts). +```` + ## Commit message ``` diff --git a/workflow-templates/deploy-cobra-mkdocs-versioned-poetry.md b/workflow-templates/deploy-cobra-mkdocs-versioned-poetry.md index 6239e5e0..5aa4417a 100644 --- a/workflow-templates/deploy-cobra-mkdocs-versioned-poetry.md +++ b/workflow-templates/deploy-cobra-mkdocs-versioned-poetry.md @@ -89,7 +89,9 @@ Add the following to `.gitignore`: ``` 1. Follow the remaining setup steps from the ["Deploy Website" workflow (versioned, MkDocs, Poetry) documentation](deploy-mkdocs-versioned-poetry.md#setup). -### Readme badge +### Documentation + +#### Readme badge Markdown badge: @@ -109,6 +111,10 @@ image:https://github.com/{repository-owner}/{repository-name}/actions/workflows/ Define the `{repository-owner}` and `{repository-name}` attributes and use them throughout the readme ([example](https://raw.githubusercontent.com/arduino-libraries/WiFiNINA/master/README.adoc)). +#### Development Guide + +See the ["Deploy Website" workflow (MkDocs, Poetry) documentation](deploy-mkdocs-poetry.md#development-guide) + ## Website versioning See the ["Deploy Website" workflow (versioned, MkDocs, Poetry) documentation](deploy-mkdocs-versioned-poetry.md#website-versioning) for an explanation of how the versioning works. diff --git a/workflow-templates/deploy-mkdocs-poetry.md b/workflow-templates/deploy-mkdocs-poetry.md index 3d273328..df38903a 100644 --- a/workflow-templates/deploy-mkdocs-poetry.md +++ b/workflow-templates/deploy-mkdocs-poetry.md @@ -53,7 +53,9 @@ Add entries for each website source file to the `nav` array in `mkdocs.yml`, or Reference: https://www.mkdocs.org/user-guide/configuration/ -### Readme badge +### Documentation + +#### Readme badge Markdown badge: @@ -73,6 +75,24 @@ image:https://github.com/{repository-owner}/{repository-name}/actions/workflows/ Define the `{repository-owner}` and `{repository-name}` attributes and use them throughout the readme ([example](https://raw.githubusercontent.com/arduino-libraries/WiFiNINA/master/README.adoc)). +#### Development Guide + +Add the following to the project's development documentation (templates available [here](../documentation-templates/README.md#development-guide)): + +````markdown +## Documentation + +The [Markdown](https://www.markdownguide.org/basic-syntax/) files under the `docs` subfolder of the repository are the source content for the project's documentation website. + +When working on the documentation, it may be useful to see the effect the changes will have on the generated documentation website. You can build the documentation website and serve it from your personal computer by running this command from the project root: + +```text +task website:serve +``` + +The website will now build. If you don't see any error, open `http://127.0.0.1:8000` in your browser to load the local copy of the documentation site. +```` + ## Commit message ``` diff --git a/workflow-templates/deploy-mkdocs-versioned-poetry.md b/workflow-templates/deploy-mkdocs-versioned-poetry.md index 363b0ca8..8384fbdc 100644 --- a/workflow-templates/deploy-mkdocs-versioned-poetry.md +++ b/workflow-templates/deploy-mkdocs-versioned-poetry.md @@ -89,7 +89,9 @@ This will do the following: After this initial deployment, all further website updates will be handled automatically by the "Deploy Website" workflow. -### Readme badge +### Documentation + +#### Readme badge Markdown badge: @@ -109,6 +111,10 @@ image:https://github.com/{repository-owner}/{repository-name}/actions/workflows/ Define the `{repository-owner}` and `{repository-name}` attributes and use them throughout the readme ([example](https://raw.githubusercontent.com/arduino-libraries/WiFiNINA/master/README.adoc)). +#### Development Guide + +See the ["Deploy Website" workflow (MkDocs, Poetry) documentation](deploy-mkdocs-poetry.md#development-guide) + ## Website versioning This system is designed for projects that use release branches. The website versioning is based on branch names: