From 10164fa150d11cedf11464d8e8da6511554b82da Mon Sep 17 00:00:00 2001 From: Angus Gratton Date: Tue, 5 Sep 2023 16:07:11 +1000 Subject: [PATCH] some cleanup of previous edits --- ContributorGuidelines.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/ContributorGuidelines.md b/ContributorGuidelines.md index efd3625..cf76789 100644 --- a/ContributorGuidelines.md +++ b/ContributorGuidelines.md @@ -53,12 +53,14 @@ Some guidelines if adding a new Python library feature (like a new function or a ### Adding Python syntax features -If you want to change the Python language features exposed by MicroPython, it's a good idea to discuss this with the maintainers first. +If you want to change the Python language features supported by MicroPython, then it's a good idea to discuss this with the maintainers first. ### Adding hardware features -* If implementing an existing [machine](https://docs.micropython.org/en/latest/library/machine.html) API on a new port (for example, to add `machine.I2S` to a port which has I2S hardware but no MicroPython driver yet), then the API must match the existing `machine` API whenever possible. Additions that substantially change an existing `machine` API for a single port only, or have too many "special case" notes, may be better suited as port-specific APIs (see below). -* Contributing a new [machine](https://docs.micropython.org/en/latest/library/machine.html) API that adds brand new functionality (for example, adding a `machine.TenGbpsEthernet` class for 10Gbps Ethernet controllers) must be very carefully implemented and designed. These APIs must be as generic to work on multiple ports, while still being efficient and small in code size. If you're planning to contribute such a driver, please discuss with the maintainers and the community first. You could start with a [Discussion](https://github.com/micropython/micropython/discussions) or make a Pull Request that only adds the docs for your proposed API. +New hardware driver support or functionality is always welcome: + +* If implementing an existing [machine](https://docs.micropython.org/en/latest/library/machine.html) API for a new port (for example, adding `machine.I2S` to a port which has I2S hardware but no MicroPython driver yet), then the API must match the existing `machine` API whenever possible. Additions that substantially change an existing `machine` API for a single port only, or have non-trivial "special case" notes, may be better suited as port-specific APIs (see below). +* Contributing a new [machine](https://docs.micropython.org/en/latest/library/machine.html) API that adds brand new functionality (for example, adding a `machine.TenGbpsEthernet` class for 10Gbps Ethernet controllers) must be very carefully implemented and designed. These APIs must be generic to work on multiple ports, while still being efficient and small in code size. If you're planning to contribute such a driver, please discuss with the maintainers and the community first. You could start with a [Discussion](https://github.com/micropython/micropython/discussions) or make a Pull Request that only adds the docs for your proposed API. * If a new driver has port- or hardware-specific features that aren't suitable for a [machine](https://docs.micropython.org/en/latest/library/machine.html) API then consider adding them to a [port-specific library](https://docs.micropython.org/en/latest/library/index.html#port-specific-libraries). (Except `pyb`, this is legacy and new code should go into `stm` instead). This allows more freedom to expose the hardware's exact capabilities. ## Ports @@ -83,4 +85,4 @@ All PRs will trigger GitHub Actions to run the continuous integration (CI). This ## Updating PRs -When updating a PR, either due to review feedback or to fix CI issues, you should update your branch locally and then force push it to your GitHub branch that the PR was created from. When updating your branch, this typically involves either editing the commits directly via rebase, or adding new commits then "fix"-ing them into the existing commits during a rebase. Please fetch the upstream and rebase your branch on `master` before pushing. \ No newline at end of file +When updating a PR, either due to review feedback or to fix CI issues, you should update your branch locally and then force push it to your GitHub branch that the PR was created from. When updating your branch, this typically involves either editing the commits directly via rebase, or adding new commits then "fix"-ing them into the existing commits during a rebase. Please fetch the upstream and rebase your branch on `master` before pushing.