From 0f6824a4411f5511e8e7403f09a7e31d7fb728a1 Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Sun, 29 Jul 2018 22:49:35 -0500 Subject: [PATCH 1/4] [RFC] rust-embedded teams and maintenance of the embedded ecosystem closes #46 --- rfcs/0000-teams.md | 241 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 rfcs/0000-teams.md diff --git a/rfcs/0000-teams.md b/rfcs/0000-teams.md new file mode 100644 index 00000000..244a2150 --- /dev/null +++ b/rfcs/0000-teams.md @@ -0,0 +1,241 @@ +# Summary + +This RFC proposes that we: + +- Move crates that are widely used in the embedded ecosystem into the [rust-embedded] organization + +- Significantly expand the membership of the rust-embedded org and organize the members into teams + focused in different areas. + +- Create guidelines for developing and maintaining the crates in the rust-embedded org. + +- Settle on a policy for the inclusion of new crates and creation of new teams. + +[rust-embedded]: https://github.com/rust-embedded + +# Detailed design + +## Teams + +### Role + +- The role of a team is to oversee the development of the crates under their purview. With input + from stakeholders they set the development roadmap of each crate assigned to them. + +- The members of a team are the main reviewers of the crates assigned to the team. Teams are + free to add collaborators (reviewers) to the repositories they oversee, and to increase / modify + their membership as they see fit. + +- The team is in charge of publishing new versions of the crates they oversee to crates.io, and of + maintaining the CHANGELOG of the project. + +### Membership + +- For visibility, the membership of each team, along with the set of crates they oversee, will be + listed in the README of the rust-embedded/wg (previously known as rust-lang-nursery/embedded-wg) + repository. + +- To expand the membership of a team the candidate will send a PR to the rust-embedded/wg repository + modifying the README to add themselves as a new member. The current members of the team will + review the PR. If all the members approve the PR will be merged and the membership change will be + made effective. + +### The triage team + +A special team named `triage` will be also be created. This team has the *very* important task of +keeping the PR queues moving and making sure no PR gets stuck in the review limbo. + +- This team will consist of volunteers that will triage open PRs to rust-embedded repos on a weekly + basis. + +- The `triage` team can't review PRs; they can only change the labels of the PR and comment on the + PRs. + +- The `triage` team will follow the triage process used in [the rust-lang/rust repo]: + - Open PRs will get assigned one of these status label: `S-waiting-on-author` or + `S-waiting-on-reviewer`. + - If the PR has no assigned reviewer assign a reviewer and set the `S-waiting-on-reviewer` label. + - If around a week has passed since a reviewer was assigned ping the reviewer to remind them about + the PR. + - If the reviewer requested changes to the PR apply the `S-waiting-on-author` label. + - If around a week has passed since changes were requested ping the author to remind them that + changes are needed. + - If the author made the requested changes change the label to `S-waiting-on-reviewer`. + - If the author hasn't responded to pings for over two weeks, close the PR. + +[the rust-lang/rust repo]: https://github.com/rust-lang/rust/pulls + +## Crate inclusion policy + +Only crates that are widely used and / or that have a wide scope will be maintained by the +embedded-rust org. Additionally, the crate must compile on stable Rust 1.31. In principle, this +excludes HAL implementations crate like the [`stm32f103xx-hal`] but exception can be made for crates +with narrow scope, like the [`f3`] crate, that are used by widely used resources like the +[`discovery`] book. + +[`stm32f103xx-hal`]: https://github.com/japaric/stm32f103xx-hal + +The procedure to add a crate is similar to the one used to add a new member to a team. The author +of the crate will make a PR modifying the README of the rust-embedded/wg repo. The team that +will adopt the crate will review the PR. If everyone accepts, the PR will be merged, the author will +transfer ownership of the repo to the org, and the author will become a collaborator. + +## Reviewing guidelines + +- The `master` branches will be protected and can't be directly pushed to. + +- All changes will go through a PR, which must pass review and [bors] before landing. A team member + / collaborator can't review / approve their own PR. + +[bors]: https://bors.tech + +- Breaking and major changes must be consulted with other team members, reviewers and stakeholders + before the PR is reviewed. A mini [RFC] must be written listing the rationale of the change and + the alternatives. + +[RFC]: https://github.com/rust-lang/rfcs#table-of-contents + +- Mandatory: Read the [Rust API guidelines] before you start reviewing PRs that add new API. + +[Rust API guidelines]: https://rust-lang-nursery.github.io/api-guidelines/about.html + +## Publishing guidelines + +- Publish patch releases (bug fixes) often. + +- Publish minor releases as soon as all the new features have been properly documented. + +- Try to avoid *frequent* major (breaking) releases. Collect several breaking changes into a single + major release. + +- Before publishing a breaking release, read [semver-trick] and apply it to minimize breakage. + +[semver-trick]: https://github.com/dtolnay/semver-trick + +## Repository guidelines + +- The README of all repositories will indicate which team is in charge of the repository and it will + link to the teams sections of the README of the rust-embedded/wg repo. + +- All the repositories that are crates will maintain a CHANGELOG.md file that adheres to the [keep a + changelog] format. + +[keep a changelog]: https://keepachangelog.com/en/1.0.0/ + +- The repository will include a copy of Rust [Code of Conduct]. Each team will enforce the code of + conduct in the repositories they govern. + +[Code of Conduct]: https://github.com/rust-lang/rust/blob/master/CODE_OF_CONDUCT.md + +- Where appropriate the repositories will adopt the 2018 milestones used in the rust-embedded/wg + repository. + +## Initial organization + +Based on current ownership, collaborator-ship and recent activity. + +> @japaric: this is off the top of my head. If I forgot about you, sorry! Also, the proposed teams +> are too small. I expect teams will be much larger once we get this RFC in motion. + +- `embedded-linux` team + - Crates: [`spidev`], [`sysfs-gpio`], [`rust-sysfs-pwm`], [`i2cdev`], [`linux-embedded-hal`][] + (+@japaric) + - Members: @nastevens, @posborne + +[`spidev`]:https://github.com/rust-embedded/rust-spidev +[`sysfs-gpio`]: https://github.com/rust-embedded/rust-sysfs-gpio +[`rust-sysfs-pwm`]: https://github.com/rust-embedded/rust-sysfs-pwm +[`i2cdev`]: https://github.com/rust-embedded/rust-i2cdev +[`linux-embedded-hal`]: https://github.com/japaric/linux-embedded-hal + +- `hal` team + - Crates: [`embedded-hal`], [`linux-embedded-hal`], [`stm32f30x-hal`] + - Members: @therealprof, @hannobraun, @japaric + +[`embedded-hal`]: https://github.com/japaric/embedded-hal +[`stm32f30x-hal`]: https://github.com/japaric/stm32f30x-hal + +- `tools` team + - Crates: [`svd2rust`][] (+@Emilgardis, +@ryankurte), [`cargo-binutils`], [`itm`] + - Members: @therealprof, @japaric + +[`svd2rust`]: https://github.com/japaric/svd2rust +[`cargo-binutils`]: https://github.com/japaric/cargo-binutils +[`itm`]: https://github.com/japaric/itm + +- `resources` team + - Repos: [`discovery`], [`book`], [`embedonomicon`], [`awesome-embedded-rust`], [`f3`], + [`newsletters`]. + - Members: @andre-richter, @jamesmunns, @therealprof, @japaric + +[`discovery`]: https://github.com/japaric/discovery +[`book`]: https://book.rust-embedded.org/ +[`embedonomicon`]: https://embedonomicon.rust-embedded.org/ +[`awesome-embedded-rust`]: https://github.com/rust-embedded/awesome-embedded-rust +[`f3`]: https://github.com/japaric/f3 +[`newsletters`]: https://github.com/rust-lang-nursery/embedded-wg/tree/master/newsletters + +- `cortex-m` team + - Crates: [`cortex-m`], [`cortex-m-rt`], [`cortex-m-quickstart`], [`cortex-m-semihosting`], + [`alloc-cortex-m`], [`itm`], [`panic-semihosting`], [`panic-itm`] + - Members: @hannobraun, @thejpster, @japaric + +[`cortex-m`]: https://github.com/japaric/cortex-m +[`cortex-m-rt`]: https://github.com/japaric/cortex-m-rt +[`cortex-m-quickstart`]: https://github.com/japaric/cortex-m-quickstart +[`cortex-m-semihosting`]: https://github.com/japaric/cortex-m-semihosting +[`alloc-cortex-m`]: https://github.com/japaric/alloc-cortex-m +[`panic-semihosting`]: https://github.com/japaric/panic-semihosting +[`panic-itm`]: https://github.com/japaric/panic-itm + +- `riscv` team + - Crates: [`riscv`], [`riscv-rt`], [`riscv-quickstart`] + - Members: @dvc94ch + +[`riscv`]: https://github.com/riscv-rust/riscv +[`riscv-rt`]: https://github.com/riscv-rust/riscv-rt +[`riscv-quickstart`]: https://github.com/riscv-rust/riscv-rust-quickstart + +- `msp430` team + - Crates: [`msp430`], [`msp430-rt`], [`msp430-quickstart`] + - Members: @pftbest, @cr1901 + +[`msp430`]: https://github.com/pftbest/msp430 +[`msp430-rt`]: https://github.com/pftbest/msp430-rt +[`msp430-quickstart`]: https://github.com/japaric/msp430-quickstart + +- `triage` team + - Crates: read/write access to all repositories. + - Members: TBD + +Note that this is the *proposed* organization. Invitations will be sent to the people listed here +but they are free to decline the invitation. + +Name and other changes: + +- `rust-lang-nursery/embedded-wg` -> `rust-embedded/wg` +- The embedded Rust book and the embedonomicon which currently live in `rust-embedded/wg` will be + moved into their own repositories. +- The newletters in `rust-embedded/wg` will also be moved into their own repository. +- The logo of the rust-embedded logo will change to the embedded WG logo. +- All members of the rust-embedded org will be able to manage issues and PRs in the rust-embedded/wg + repository. + +# Alternatives + +An alternative to this proposal is to have the architectures teams be their own independent orgs. + +# Unresolved questions + +> Where is the AVR team? + +Only architectures with built-in support, or that will soon have built-in support, in `rustc` have +been considered in this proposal. We can spin up more teams in the future. + +- Should we require that would-be team members do some time as collaborators before they apply? + +- The procedure for having a team member retire is still TBD. + +- The procedure for removing (deprecating?) a crate from the rust-embedded org is still TBD. + +- The procedure for creating a brand new team is still TBD. From 889260de9762d4c825da42a787c626e382c776ce Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Mon, 30 Jul 2018 12:22:21 -0500 Subject: [PATCH 2/4] remove initial organization section the initial composition of the teams will be discussed as a separate process --- rfcs/0000-teams.md | 83 +--------------------------------------------- 1 file changed, 1 insertion(+), 82 deletions(-) diff --git a/rfcs/0000-teams.md b/rfcs/0000-teams.md index 244a2150..20f7e93a 100644 --- a/rfcs/0000-teams.md +++ b/rfcs/0000-teams.md @@ -130,88 +130,7 @@ transfer ownership of the repo to the org, and the author will become a collabor - Where appropriate the repositories will adopt the 2018 milestones used in the rust-embedded/wg repository. -## Initial organization - -Based on current ownership, collaborator-ship and recent activity. - -> @japaric: this is off the top of my head. If I forgot about you, sorry! Also, the proposed teams -> are too small. I expect teams will be much larger once we get this RFC in motion. - -- `embedded-linux` team - - Crates: [`spidev`], [`sysfs-gpio`], [`rust-sysfs-pwm`], [`i2cdev`], [`linux-embedded-hal`][] - (+@japaric) - - Members: @nastevens, @posborne - -[`spidev`]:https://github.com/rust-embedded/rust-spidev -[`sysfs-gpio`]: https://github.com/rust-embedded/rust-sysfs-gpio -[`rust-sysfs-pwm`]: https://github.com/rust-embedded/rust-sysfs-pwm -[`i2cdev`]: https://github.com/rust-embedded/rust-i2cdev -[`linux-embedded-hal`]: https://github.com/japaric/linux-embedded-hal - -- `hal` team - - Crates: [`embedded-hal`], [`linux-embedded-hal`], [`stm32f30x-hal`] - - Members: @therealprof, @hannobraun, @japaric - -[`embedded-hal`]: https://github.com/japaric/embedded-hal -[`stm32f30x-hal`]: https://github.com/japaric/stm32f30x-hal - -- `tools` team - - Crates: [`svd2rust`][] (+@Emilgardis, +@ryankurte), [`cargo-binutils`], [`itm`] - - Members: @therealprof, @japaric - -[`svd2rust`]: https://github.com/japaric/svd2rust -[`cargo-binutils`]: https://github.com/japaric/cargo-binutils -[`itm`]: https://github.com/japaric/itm - -- `resources` team - - Repos: [`discovery`], [`book`], [`embedonomicon`], [`awesome-embedded-rust`], [`f3`], - [`newsletters`]. - - Members: @andre-richter, @jamesmunns, @therealprof, @japaric - -[`discovery`]: https://github.com/japaric/discovery -[`book`]: https://book.rust-embedded.org/ -[`embedonomicon`]: https://embedonomicon.rust-embedded.org/ -[`awesome-embedded-rust`]: https://github.com/rust-embedded/awesome-embedded-rust -[`f3`]: https://github.com/japaric/f3 -[`newsletters`]: https://github.com/rust-lang-nursery/embedded-wg/tree/master/newsletters - -- `cortex-m` team - - Crates: [`cortex-m`], [`cortex-m-rt`], [`cortex-m-quickstart`], [`cortex-m-semihosting`], - [`alloc-cortex-m`], [`itm`], [`panic-semihosting`], [`panic-itm`] - - Members: @hannobraun, @thejpster, @japaric - -[`cortex-m`]: https://github.com/japaric/cortex-m -[`cortex-m-rt`]: https://github.com/japaric/cortex-m-rt -[`cortex-m-quickstart`]: https://github.com/japaric/cortex-m-quickstart -[`cortex-m-semihosting`]: https://github.com/japaric/cortex-m-semihosting -[`alloc-cortex-m`]: https://github.com/japaric/alloc-cortex-m -[`panic-semihosting`]: https://github.com/japaric/panic-semihosting -[`panic-itm`]: https://github.com/japaric/panic-itm - -- `riscv` team - - Crates: [`riscv`], [`riscv-rt`], [`riscv-quickstart`] - - Members: @dvc94ch - -[`riscv`]: https://github.com/riscv-rust/riscv -[`riscv-rt`]: https://github.com/riscv-rust/riscv-rt -[`riscv-quickstart`]: https://github.com/riscv-rust/riscv-rust-quickstart - -- `msp430` team - - Crates: [`msp430`], [`msp430-rt`], [`msp430-quickstart`] - - Members: @pftbest, @cr1901 - -[`msp430`]: https://github.com/pftbest/msp430 -[`msp430-rt`]: https://github.com/pftbest/msp430-rt -[`msp430-quickstart`]: https://github.com/japaric/msp430-quickstart - -- `triage` team - - Crates: read/write access to all repositories. - - Members: TBD - -Note that this is the *proposed* organization. Invitations will be sent to the people listed here -but they are free to decline the invitation. - -Name and other changes: +## Other changes - `rust-lang-nursery/embedded-wg` -> `rust-embedded/wg` - The embedded Rust book and the embedonomicon which currently live in `rust-embedded/wg` will be From 23e8d9302971573453c2f31f187e29d4a8907db6 Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Mon, 30 Jul 2018 16:27:29 -0500 Subject: [PATCH 3/4] update with input from the WG meeting --- rfcs/0000-teams.md | 175 ++++++++++++++++++++++++++++----------------- 1 file changed, 110 insertions(+), 65 deletions(-) diff --git a/rfcs/0000-teams.md b/rfcs/0000-teams.md index 20f7e93a..7e7eb02c 100644 --- a/rfcs/0000-teams.md +++ b/rfcs/0000-teams.md @@ -17,81 +17,136 @@ This RFC proposes that we: ## Teams +This section describes the role of the teams and mechanisms for changing their memberships. + ### Role -- The role of a team is to oversee the development of the crates under their purview. With input - from stakeholders they set the development roadmap of each crate assigned to them. +The role of a team is to oversee the development of the crates under their purview. With input from +stakeholders they set the development roadmap of each crate assigned to them. -- The members of a team are the main reviewers of the crates assigned to the team. Teams are - free to add collaborators (reviewers) to the repositories they oversee, and to increase / modify - their membership as they see fit. +The members of a team are the main reviewers of the crates assigned to the team. Teams are free to +add collaborators (reviewers) to the repositories they oversee, and to increase / modify their +membership as they see fit. -- The team is in charge of publishing new versions of the crates they oversee to crates.io, and of - maintaining the CHANGELOG of the project. +The team is in charge of publishing new versions of the crates they oversee to crates.io, and of +maintaining the CHANGELOG of the project. ### Membership -- For visibility, the membership of each team, along with the set of crates they oversee, will be - listed in the README of the rust-embedded/wg (previously known as rust-lang-nursery/embedded-wg) - repository. +For visibility, the membership of each team, along with the set of crates they oversee, will be +listed in the README of the rust-embedded/wg (previously known as rust-lang-nursery/embedded-wg) +repository. + +#### Adding new members + +A person that wants to join a team (the "candidate") will first consult with (part of) the team. The +team may decide that the candidate participates as a collaborator to one of the repositories +maintained by the team before they apply for membership. After receiving a soft OK from (part of) +the team the candidate will send a PR to the rust-embedded/wg repository modifying the README file +to list themselves as a new member. + +The complete team will review the PR and perform one of these 3 actions: approve the PR, abstain +from reviewing, or raise a concern. When the PR achieves the *majority* of votes (defined below) it +will be merged and the membership changes will be made effective. + +#### Voting majority + +Voting majority is defined as having more approvals than abstentions and zero unresolved concerns. +In the case where there are equal numbers of approvals and abstentions (i.e. the team has an even +number of members) the WG lead will give the casting vote. + +#### Removing members + +When (part of) a team wishes to remove one of its member they will make a PR to the +rust-embedded/wg repository updating the README with the modified membership. The team minus the +member being removed will vote on the proposal. After voting majority (defined in the previous +section) has been achieved the PR will be merged and the membership changes will be made effective. -- To expand the membership of a team the candidate will send a PR to the rust-embedded/wg repository - modifying the README to add themselves as a new member. The current members of the team will - review the PR. If all the members approve the PR will be merged and the membership change will be - made effective. +In the case where the member wishes to retire the procedure is similar. The retiring member will +make a PR notifying the team (e.g. "cc rust-embedded/$team"). In this case no voting is necessary. +The PR will be merged and the changes will be made effective. ### The triage team A special team named `triage` will be also be created. This team has the *very* important task of keeping the PR queues moving and making sure no PR gets stuck in the review limbo. -- This team will consist of volunteers that will triage open PRs to rust-embedded repos on a weekly - basis. +This team will consist of volunteers that will triage open PRs to rust-embedded repos on a weekly +basis. When triaging the members of the `triage` team will assign or change reviewers, add or change +the labels of the PR, and/or comment on the PRs; they will not review PRs while triaging. -- The `triage` team can't review PRs; they can only change the labels of the PR and comment on the - PRs. +#### The triaging process -- The `triage` team will follow the triage process used in [the rust-lang/rust repo]: - - Open PRs will get assigned one of these status label: `S-waiting-on-author` or +The proposed triaging process is based on [the one used in the rust-lang/rust repo][rust-triage]. + +[rust-triage]: https://github.com/rust-lang/rust/pulls + +- Open PRs will get assigned one of these status label: `S-waiting-on-author` or `S-waiting-on-reviewer`. - - If the PR has no assigned reviewer assign a reviewer and set the `S-waiting-on-reviewer` label. - - If around a week has passed since a reviewer was assigned ping the reviewer to remind them about - the PR. - - If the reviewer requested changes to the PR apply the `S-waiting-on-author` label. - - If around a week has passed since changes were requested ping the author to remind them that - changes are needed. - - If the author made the requested changes change the label to `S-waiting-on-reviewer`. - - If the author hasn't responded to pings for over two weeks, close the PR. -[the rust-lang/rust repo]: https://github.com/rust-lang/rust/pulls +- If the PR has no assigned reviewer assign a reviewer and set the `S-waiting-on-reviewer` label. + +- If around a week has passed since a reviewer was assigned ping the reviewer to remind them about + the PR. + +- If the reviewer requested changes to the PR apply the `S-waiting-on-author` label. + +- If around a week has passed since changes were requested ping the author to remind them that + changes are needed. + +- If the author made the requested changes change the label to `S-waiting-on-reviewer`. + +- If the author hasn't responded to pings for over two weeks, close the PR. + +## Projects -## Crate inclusion policy +The section describes the guideline for incorporating projects into the rust-embedded organization +and the mechanism for adopting projects. -Only crates that are widely used and / or that have a wide scope will be maintained by the -embedded-rust org. Additionally, the crate must compile on stable Rust 1.31. In principle, this -excludes HAL implementations crate like the [`stm32f103xx-hal`] but exception can be made for crates -with narrow scope, like the [`f3`] crate, that are used by widely used resources like the -[`discovery`] book. +### Inclusion guideline + +Only projects (crates or documentation) that are widely used and / or that have a wide scope will be +maintained by the embedded-rust org. Additionally, if the project is a crate it must compile on the +stable channel by Rust 1.31 (2018-12-06); if the project is documentation all the included code and +patterns must be usable on the stable channel. + +In principle, this guideline excludes HAL implementation crates like the [`stm32f103xx-hal`] and +board support crates because of their narrow scope but exceptions could be made for crates, like the +[`f3`] crate, that are dependencies of widely used resources like the [`discovery`] book. [`stm32f103xx-hal`]: https://github.com/japaric/stm32f103xx-hal +[`f3`]: https://github.com/japaric/f3 +[`discovery`]: https://github.com/japaric/discovery + +### Adopting projects + +An author that wishes to have their project adopted by the rust-embedded org should first approach +the team that would oversee their crate if it were to be adopted. If the author is unsure which team +should take ownership of their project they will first open an issue in the rust-embedded/wg +repository requesting input. + +After getting a soft OK from (part of) the team the author will send a PR to rust-embedded/wg adding +their repository to the list of crates the team maintains. After voting majority (see definition in +the membership section) the PR will be merged, ownership will be transferred and the author will +become a collaborator of the transferred repository. -The procedure to add a crate is similar to the one used to add a new member to a team. The author -of the crate will make a PR modifying the README of the rust-embedded/wg repo. The team that -will adopt the crate will review the PR. If everyone accepts, the PR will be merged, the author will -transfer ownership of the repo to the org, and the author will become a collaborator. +## Guidelines -## Reviewing guidelines +This section contains a set of guidelines that aim to standardize the management of projects +within the rust-embedded org. + +### Reviewing - The `master` branches will be protected and can't be directly pushed to. -- All changes will go through a PR, which must pass review and [bors] before landing. A team member - / collaborator can't review / approve their own PR. +- All changes will go through a PR that must pass review and [bors] before landing. Team members + and collaborators can't approve their own PRs. [bors]: https://bors.tech - Breaking and major changes must be consulted with other team members, reviewers and stakeholders - before the PR is reviewed. A mini [RFC] must be written listing the rationale of the change and - the alternatives. + before the PR is reviewed. The team will decide whether a mini [RFC], listing the rationale of the + change and the alternatives, needs to be written. [RFC]: https://github.com/rust-lang/rfcs#table-of-contents @@ -99,7 +154,7 @@ transfer ownership of the repo to the org, and the author will become a collabor [Rust API guidelines]: https://rust-lang-nursery.github.io/api-guidelines/about.html -## Publishing guidelines +### Publishing - Publish patch releases (bug fixes) often. @@ -112,17 +167,17 @@ transfer ownership of the repo to the org, and the author will become a collabor [semver-trick]: https://github.com/dtolnay/semver-trick -## Repository guidelines +### Repository contents - The README of all repositories will indicate which team is in charge of the repository and it will - link to the teams sections of the README of the rust-embedded/wg repo. + link to the teams section of the README in the rust-embedded/wg repo. - All the repositories that are crates will maintain a CHANGELOG.md file that adheres to the [keep a changelog] format. [keep a changelog]: https://keepachangelog.com/en/1.0.0/ -- The repository will include a copy of Rust [Code of Conduct]. Each team will enforce the code of +- The repository will include a copy of Rust's [Code of Conduct]. Each team will enforce the code of conduct in the repositories they govern. [Code of Conduct]: https://github.com/rust-lang/rust/blob/master/CODE_OF_CONDUCT.md @@ -132,29 +187,19 @@ transfer ownership of the repo to the org, and the author will become a collabor ## Other changes -- `rust-lang-nursery/embedded-wg` -> `rust-embedded/wg` +- Transfer the `rust-lang-nursery/embedded-wg` to the rust-embedded org and rename it to + `rust-embedded/wg`. + - The embedded Rust book and the embedonomicon which currently live in `rust-embedded/wg` will be moved into their own repositories. + - The newletters in `rust-embedded/wg` will also be moved into their own repository. -- The logo of the rust-embedded logo will change to the embedded WG logo. + +- The logo of the rust-embedded org will change to the embedded WG logo. + - All members of the rust-embedded org will be able to manage issues and PRs in the rust-embedded/wg repository. # Alternatives An alternative to this proposal is to have the architectures teams be their own independent orgs. - -# Unresolved questions - -> Where is the AVR team? - -Only architectures with built-in support, or that will soon have built-in support, in `rustc` have -been considered in this proposal. We can spin up more teams in the future. - -- Should we require that would-be team members do some time as collaborators before they apply? - -- The procedure for having a team member retire is still TBD. - -- The procedure for removing (deprecating?) a crate from the rust-embedded org is still TBD. - -- The procedure for creating a brand new team is still TBD. From ed9bfbcac4b0eeb7c4550f36853520d5285b8259 Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Thu, 2 Aug 2018 00:33:18 -0500 Subject: [PATCH 4/4] use triage procedure documented in the forge --- rfcs/0000-teams.md | 30 +++++++----------------------- 1 file changed, 7 insertions(+), 23 deletions(-) diff --git a/rfcs/0000-teams.md b/rfcs/0000-teams.md index 7e7eb02c..3b1e378c 100644 --- a/rfcs/0000-teams.md +++ b/rfcs/0000-teams.md @@ -71,32 +71,16 @@ The PR will be merged and the changes will be made effective. A special team named `triage` will be also be created. This team has the *very* important task of keeping the PR queues moving and making sure no PR gets stuck in the review limbo. -This team will consist of volunteers that will triage open PRs to rust-embedded repos on a weekly -basis. When triaging the members of the `triage` team will assign or change reviewers, add or change -the labels of the PR, and/or comment on the PRs; they will not review PRs while triaging. +This team will consist of volunteers that will periodically triage open PRs to rust-embedded repos. +When triaging the members of the `triage` team will assign or change reviewers, add or change the +labels of the PR, and/or comment on the PRs; they will not review PRs while triaging. -#### The triaging process +#### The triage procedure -The proposed triaging process is based on [the one used in the rust-lang/rust repo][rust-triage]. +The proposed triage procedure is [the one used to triage PRs in the rust-lang/rust +repo][rust-triage]. -[rust-triage]: https://github.com/rust-lang/rust/pulls - -- Open PRs will get assigned one of these status label: `S-waiting-on-author` or - `S-waiting-on-reviewer`. - -- If the PR has no assigned reviewer assign a reviewer and set the `S-waiting-on-reviewer` label. - -- If around a week has passed since a reviewer was assigned ping the reviewer to remind them about - the PR. - -- If the reviewer requested changes to the PR apply the `S-waiting-on-author` label. - -- If around a week has passed since changes were requested ping the author to remind them that - changes are needed. - -- If the author made the requested changes change the label to `S-waiting-on-reviewer`. - -- If the author hasn't responded to pings for over two weeks, close the PR. +[rust-triage]: https://forge.rust-lang.org/triage-procedure.html ## Projects