-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Rework pages, navbar, update deps, custom version dropdown. * Add flash_nuke and force_webconfig to static assets * Fix tons of broken links and anchors, improve css
- Loading branch information
Showing
201 changed files
with
5,663 additions
and
6,943 deletions.
There are no files selected for viewing
110 changes: 55 additions & 55 deletions
110
...-0.7.7/development/contribution-guide.mdx → development/contribution-guide.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,55 +1,55 @@ | ||
| --- | ||
| title: How to Contribute | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to contribute to the GP2040-CE Project" | ||
| --- | ||
|
|
||
| # How to Contribute | ||
|
|
||
| Thank you for taking the time to read this and contributing to the project! | ||
|
|
||
| Third-party contributions help us grow and improve GP2040-CE. We want to make the pull request and contribution process useful and easy for both contributors and maintainers. | ||
|
|
||
| To this end we’ve put together some guidelines for contributors to help your pull request be accepted without major changes. | ||
|
|
||
| ## Project Overview | ||
|
|
||
| GP2040-CE is largely written in C/C++, with a significant portion of the web configurator written in JavaScript within a React framework. | ||
|
|
||
| ## How do I make a contribution? | ||
|
|
||
| Never made an open source contribution before? Wondering how contributions work in GP2040-CE? Here’s a quick rundown! | ||
|
|
||
| 1. Sign up for a GitHub account. | ||
| 2. Find an issue you are interested in addressing, or a feature you would like to add. | ||
| 3. Fork the repository associated with the issue to your GitHub account. This means that you will have a copy of the repository under `your-GitHub-username/GP2040-CE`. | ||
| 4. Clone the repository to your local machine using `git clone https://github.com/OpenStickCommunity/GP2040-CE` | ||
| 5. If you’re working on a new feature consider opening an issue to talk with us about the work you’re about to undertake. | ||
| 6. Create a new branch for your fix using `git checkout -b branch-name-here`. | ||
| 7. Make the appropriate changes for the issue you are trying to address or the feature that you want to add. | ||
| 8. Use `git add insert-paths-of-changed-files-here` to add the file contents of the changed files to the “snapshot” git uses to manage the state of the project, also known as the index. | ||
| 9. Use `git commit -m "Insert a short message of the changes made here"` to store the contents of the index with a descriptive message. | ||
| 10. Push the changes to your repository on GitHub using `git push origin branch-name-here`. | ||
| 11. Submit a pull request to [OpenStickCommunity/GP2040-CE](https://github.com/OpenStickCommunity/GP2040-CE). | ||
| 12. Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so “Added more log outputting to resolve #4352”. | ||
| 13. In the description of the pull request explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It’s OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it! | ||
| 14. Wait for the pull request to be reviewed by a maintainer. | ||
| 15. Make changes to the pull request if the reviewing maintainer recommends them. | ||
| 16. Celebrate your success after your pull request is merged! | ||
|
|
||
| ## Coding Conventions | ||
|
|
||
| ## General Guidelines | ||
|
|
||
| - **Before you contribute**: Please make sure your fork is up to date with the upstream `GP2040-CE` repo. This will help minimize CI failures that may not occur for you when compiling locally. | ||
| - Separate PRs into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature. | ||
| - Check for unnecessary whitespace with `git diff --check` before committing. | ||
| - Make sure your code change actually compiles. | ||
| - Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. | ||
|
|
||
| ## Documentation | ||
|
|
||
| Documentation is one of the easiest ways to get started contributing to GP2040-CE. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren’t sure where or how to jump in please [reach out for help](../getting-help-support.mdx)! | ||
| --- | ||
| title: How to Contribute | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to contribute to the GP2040-CE Project" | ||
| --- | ||
|
|
||
| # How to Contribute | ||
|
|
||
| Thank you for taking the time to read this and contributing to the project! | ||
|
|
||
| Third-party contributions help us grow and improve GP2040-CE. We want to make the pull request and contribution process useful and easy for both contributors and maintainers. | ||
|
|
||
| To this end we’ve put together some guidelines for contributors to help your pull request be accepted without major changes. | ||
|
|
||
| ## Project Overview | ||
|
|
||
| GP2040-CE is largely written in C/C++, with a significant portion of the web configurator written in JavaScript within a React framework. | ||
|
|
||
| ## How do I make a contribution? | ||
|
|
||
| Never made an open source contribution before? Wondering how contributions work in GP2040-CE? Here’s a quick rundown! | ||
|
|
||
| 1. Sign up for a GitHub account. | ||
| 2. Find an issue you are interested in addressing, or a feature you would like to add. | ||
| 3. Fork the repository associated with the issue to your GitHub account. This means that you will have a copy of the repository under `your-GitHub-username/GP2040-CE`. | ||
| 4. Clone the repository to your local machine using `git clone https://github.com/OpenStickCommunity/GP2040-CE` | ||
| 5. If you’re working on a new feature consider opening an issue to talk with us about the work you’re about to undertake. | ||
| 6. Create a new branch for your fix using `git checkout -b branch-name-here`. | ||
| 7. Make the appropriate changes for the issue you are trying to address or the feature that you want to add. | ||
| 8. Use `git add insert-paths-of-changed-files-here` to add the file contents of the changed files to the “snapshot” git uses to manage the state of the project, also known as the index. | ||
| 9. Use `git commit -m "Insert a short message of the changes made here"` to store the contents of the index with a descriptive message. | ||
| 10. Push the changes to your repository on GitHub using `git push origin branch-name-here`. | ||
| 11. Submit a pull request to [OpenStickCommunity/GP2040-CE](https://github.com/OpenStickCommunity/GP2040-CE). | ||
| 12. Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so “Added more log outputting to resolve #4352”. | ||
| 13. In the description of the pull request explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It’s OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it! | ||
| 14. Wait for the pull request to be reviewed by a maintainer. | ||
| 15. Make changes to the pull request if the reviewing maintainer recommends them. | ||
| 16. Celebrate your success after your pull request is merged! | ||
|
|
||
| ## Coding Conventions | ||
|
|
||
| ## General Guidelines | ||
|
|
||
| - **Before you contribute**: Please make sure your fork is up to date with the upstream `GP2040-CE` repo. This will help minimize CI failures that may not occur for you when compiling locally. | ||
| - Separate PRs into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature. | ||
| - Check for unnecessary whitespace with `git diff --check` before committing. | ||
| - Make sure your code change actually compiles. | ||
| - Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. | ||
|
|
||
| ## Documentation | ||
|
|
||
| Documentation is one of the easiest ways to get started contributing to GP2040-CE. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren’t sure where or how to jump in please [reach out for help](/getting-help-support)! |
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
92 changes: 46 additions & 46 deletions
92
...opment/documentation-update-downloads.mdx → ...opment/documentation-update-downloads.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,46 +1,46 @@ | ||
| --- | ||
| title: Update Downloads Page | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to update the Downloads Page to add a new microcontroller board or controller" | ||
| --- | ||
|
|
||
| # Update Downloads Page | ||
|
|
||
| Adding a microcontroller board or device to the [Downloads](../downloads/download-page.mdx) page requires an update to the `docs/src/config/boards.tsx` file. The information required will depend on whether you are adding a microcontroller board or a controller. | ||
|
|
||
| | Key | Value | | ||
| | ------------ | ---------------------------------------------------------------------------------------------------------------- | | ||
| | `name` | The name of the device what will be listed on the Downloads page | | ||
| | `configName` | The name of the device that will be used to generate the .uf2 file and used to generate link to release firmware | | ||
| | `pinout` | Link to the devices pinout diagram | | ||
| | `website` | Link to the website containing device information | | ||
| | `image` | Absolute link to the asset used for device, change only `BoardName` to match file name in `docs/docs/assets/` | | ||
| | `supported` | (Microcontroller Board Only) Whether the device is currently supported by the project | | ||
| | `category` | (Controller Only) The category classification following convention listed below | | ||
| | `desc` | Short description of the device and manufacturer to be displayed on Downloads page | | ||
|
|
||
| ## Microcontroller Board | ||
|
|
||
| The template for microcontroller boards can be found in [Templates - Microcontroller Boards](..//development/templates.mdx#microcontroller-boards). | ||
|
|
||
| To add a microcontroller board to the download list, fill out the template with all of the information and add it to the array `boards['Microcontroller Boards']`. The order that the boards are listed determine the order that they appear on the page so note the following order of boards. | ||
|
|
||
| - Raspberry Pi Pico | ||
| - Raspberry Pi Pico W | ||
| - The rest of the microcontroller boards in alphabetical order | ||
|
|
||
| ## Controllers | ||
|
|
||
| The template for controllers can be found in [Templates - Controllers](..//development/templates.mdx#controllers). | ||
|
|
||
| To add a controller to the download list, fill out the template with all of the information and add it to the array `boards['Controllers']`. The order of the controllers in this array should be alphabetical. | ||
|
|
||
| For categories, the convention is as follows. | ||
|
|
||
| - `official` - Official boards of the project | ||
| - `open` - Open source devices | ||
| - `closed` - Closed source devices | ||
| - `legacy` - Devices that are not or are no longer supported by the project | ||
| --- | ||
| title: Update Downloads Page | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to update the Downloads Page to add a new microcontroller board or controller" | ||
| --- | ||
|
|
||
| # Update Downloads Page | ||
|
|
||
| Adding a microcontroller board or device to the [Downloads](/downloads) page requires an update to the `src/config/boards.tsx` file. The information required will depend on whether you are adding a microcontroller board or a controller. | ||
|
|
||
| | Key | Value | | ||
| | ------------ | ---------------------------------------------------------------------------------------------------------------- | | ||
| | `name` | The name of the device what will be listed on the Downloads page | | ||
| | `configName` | The name of the device that will be used to generate the .uf2 file and used to generate link to release firmware | | ||
| | `pinout` | Link to the devices pinout diagram | | ||
| | `website` | Link to the website containing device information | | ||
| | `image` | Absolute link to the asset used for device, change only `BoardName` to match file name in `static/img/boards/` | | ||
| | `supported` | (Microcontroller Board Only) Whether the device is currently supported by the project | | ||
| | `category` | (Controller Only) The category classification following convention listed below | | ||
| | `desc` | Short description of the device and manufacturer to be displayed on Downloads page | | ||
|
|
||
| ## Microcontroller Board | ||
|
|
||
| The template for microcontroller boards can be found in [Templates - Microcontroller Boards](..//development/templates.mdx#microcontroller-boards). | ||
|
|
||
| To add a microcontroller board to the download list, fill out the template with all of the information and add it to the array `boards['Microcontroller Boards']`. The order that the boards are listed determine the order that they appear on the page so note the following order of boards. | ||
|
|
||
| - Raspberry Pi Pico | ||
| - Raspberry Pi Pico W | ||
| - The rest of the microcontroller boards in alphabetical order | ||
|
|
||
| ## Controllers | ||
|
|
||
| The template for controllers can be found in [Templates - Controllers](..//development/templates.mdx#controllers). | ||
|
|
||
| To add a controller to the download list, fill out the template with all of the information and add it to the array `boards['Controllers']`. The order of the controllers in this array should be alphabetical. | ||
|
|
||
| For categories, the convention is as follows. | ||
|
|
||
| - `official` - Official boards of the project | ||
| - `open` - Open source devices | ||
| - `closed` - Closed source devices | ||
| - `legacy` - Devices that are not or are no longer supported by the project |
134 changes: 67 additions & 67 deletions
134
.../development/documentation-versioning.mdx → development/documentation-versioning.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,67 +1,67 @@ | ||
| --- | ||
| title: Versioning | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to version documents for a new release" | ||
| --- | ||
|
|
||
| # Versioning | ||
|
|
||
| Versioning is used so that the documentation for features currently in development can be updated without affecting user documentation for the current released version, which should remain fairly static and generally only updated with a new release version. | ||
|
|
||
| The result is a default version copy for the current release that is served to the user when visiting https://gp2040-ce.info and another "Next" version that reflects unfinished documentation for the next release. | ||
|
|
||
| ## On New Release | ||
|
|
||
| When a new release is ready, tag the document version with a name that matches the release number (i.e. #.#.#). Once that has been completed, commit the changes and make a pull request to update the site documentation. | ||
|
|
||
| ### Tag New Version | ||
|
|
||
| ```shell | ||
| cd docs/ | ||
| npm run docusaurus docs:version #.#.# | ||
| ``` | ||
|
|
||
| When tagging a new version, the document versioning mechanism will: | ||
|
|
||
| - Copy the full docs/ folder contents into a new versioned_docs/version-\{versionName\}/ folder. | ||
| - Create a versioned sidebars file based from your current sidebar configuration (if it exists) - saved as versioned_sidebars/version-\{versionName\}-sidebars.json. | ||
| - Append the new version to versions.json. | ||
|
|
||
| ### Delete Prior Version | ||
|
|
||
| At the root of the GP2040-CE folder, run the following command to delete the version | ||
|
|
||
| ```shell | ||
| rm -rf versioned_docs/version-#.#.# | ||
| rm -rf versioned_sidebars/version-#.#.#-sidebars.json | ||
| ``` | ||
|
|
||
| Then remove the version from versions.json. | ||
|
|
||
| Example: | ||
|
|
||
| ```diff | ||
| [ | ||
| "0.7.7", | ||
| - "0.7.6" | ||
| ] | ||
| ``` | ||
|
|
||
| ## Updating Documentation | ||
|
|
||
| ### Update Future Release Documentation | ||
|
|
||
| Updates can be made directly in the `docs/` folder or `sidebars.js` as these changes are not reflected in the default versioned documents users will see on the site. Any changes to the `docs/` folder or `sidebars.js` are made to the `Next` version. | ||
|
|
||
|  | ||
|
|
||
| ### Update Current Release Documentation | ||
|
|
||
| This process is different from updating documentation for future releases as changes need to be made with the versioned documents. Changes to the current release version of documentation will need to be made to the files in `/versioned_docs/version-X.X.X` and `/versioned_sidebars/version-X.X.X-sidebars.json`. | ||
|
|
||
| These changes will be reflected in the default user facing documentation that appears when users go to https://gp2040-ce.info and do not specifically select the `Next` version of documentation. | ||
|
|
||
|  | ||
| --- | ||
| title: Versioning | ||
| # tags: | ||
| # - | ||
| pagination_next: null | ||
| pagination_prev: null | ||
| description: "How to version documents for a new release" | ||
| --- | ||
|
|
||
| # Versioning | ||
|
|
||
| Versioning is used so that the documentation for features currently in development can be updated without affecting user documentation for the current released version, which should remain fairly static and generally only updated with a new release version. | ||
|
|
||
| The result is a default version copy for the current release that is served to the user when visiting https://gp2040-ce.info and another "Next" version that reflects unfinished documentation for the next release. | ||
|
|
||
| ## On New Release | ||
|
|
||
| When a new release is ready, tag the document version with a name that matches the release number (i.e. #.#.#). Once that has been completed, commit the changes and make a pull request to update the site documentation. | ||
|
|
||
| ### Tag New Version | ||
|
|
||
| ```shell | ||
| cd docs/ | ||
| npm run docusaurus docs:version #.#.# | ||
| ``` | ||
|
|
||
| When tagging a new version, the document versioning mechanism will: | ||
|
|
||
| - Copy the full docs/ folder contents into a new versioned_docs/version-\{versionName\}/ folder. | ||
| - Create a versioned sidebars file based from your current sidebar configuration (if it exists) - saved as versioned_sidebars/version-\{versionName\}-sidebars.json. | ||
| - Append the new version to versions.json. | ||
|
|
||
| ### Delete Prior Version | ||
|
|
||
| At the root of the GP2040-CE folder, run the following command to delete the version | ||
|
|
||
| ```shell | ||
| rm -rf versioned_docs/version-#.#.# | ||
| rm -rf versioned_sidebars/version-#.#.#-sidebars.json | ||
| ``` | ||
|
|
||
| Then remove the version from versions.json. | ||
|
|
||
| Example: | ||
|
|
||
| ```diff | ||
| [ | ||
| "0.7.7", | ||
| - "0.7.6" | ||
| ] | ||
| ``` | ||
|
|
||
| ## Updating Documentation | ||
|
|
||
| ### Update Future Release Documentation | ||
|
|
||
| Updates can be made directly in the `docs/` folder or `sidebars.js` as these changes are not reflected in the default versioned documents users will see on the site. Any changes to the `docs/` folder or `sidebars.js` are made to the `Next` version. | ||
|
|
||
|  | ||
|
|
||
| ### Update Current Release Documentation | ||
|
|
||
| This process is different from updating documentation for future releases as changes need to be made with the versioned documents. Changes to the current release version of documentation will need to be made to the files in `/versioned_docs/version-X.X.X` and `/versioned_sidebars/version-X.X.X-sidebars.json`. | ||
|
|
||
| These changes will be reflected in the default user facing documentation that appears when users go to https://gp2040-ce.info and do not specifically select the `Next` version of documentation. | ||
|
|
||
|  |
File renamed without changes.
File renamed without changes.
Oops, something went wrong.