From 06aaf8ad53dab8832cf1826891c0de4334f7ec56 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 10 Sep 2019 12:36:35 +0200 Subject: [PATCH 1/8] Initial commit of focus projects RFC, intended for discussion in the meeting --- rfcs/0000-focus-projects.md | 124 ++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 rfcs/0000-focus-projects.md diff --git a/rfcs/0000-focus-projects.md b/rfcs/0000-focus-projects.md new file mode 100644 index 00000000..86272469 --- /dev/null +++ b/rfcs/0000-focus-projects.md @@ -0,0 +1,124 @@ +- Feature Name: focus-projects +- Start Date: 2019-09-10 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +In order to keep progress moving in the Embedded WG, this RFC proposes a method to track potential and in-progress "focus projects" worked on by members of the Embedded WG. + +These focus projects are intended to be larger scale works, with a fixed "end goal", that can be achieved by a group of people, and are not blocked by outside factors, such as changes to the Rust or LLVM projects, unless the project scope includes these changes. + +# Motivation +[motivation]: #motivation + +In 2018, the Embedded WG came together to get embedded development in Rust to a stable level. Following the success of this venture progress has continued, but due to a lack of concrete items to focus on, and a lack of free time to work on specific items, 2019 has had less focus. + +This RFC proposes a structure for proposing, selecting, and tracking progress on larger scale improvements to the Embedded Rust ecosystem. + +# Detailed design +[design]: #detailed-design + +This RFC covers four main stages of how we tackle large scale work, referred to as "focus projects": **Proposal**, **Selection**, and **Tracking**, and **Completion**. + +## Proposal + +Anyone may propose a large scale project to be worked on. Projects are proposed by opening an issue that is tagged with the `focus-project` tag on the [Issue Tracker]. + +[Issue Tracker]: https://github.com/rust-embedded/wg/issues + +All proposals should contain the following information: + +1. What is the current problem/shortcoming? +2. What is the relevance to the Rust Embedded Ecosystem? +3. What is the desired outcome to address this problem/shortcoming? +4. What is necessary to achieve this outcome? + +After opening this issue, the proposer of this project should solicit feedback from Working Group members to refine the proposal, and the steps necessary to address this. Once the proposal has been refined, the proposer should find a member of the working group to **sponsor** the issue. + +Once a potential sponsor has been found, the project may be selected. + +## Selection + +In order to move an issue from "proposed" to "selected", the proposer and sponsor should open a PR to add the project to the `focus-projects/` folder in this repo. Items in this folder should be named `0000-project-name.md`, and should contain the following information: + +1. All contents from the proposal + * Original problem + * Relevance + * Desired Outcome + * What will be done? +2. Who is the WG sponsor for this issue? +3. Who else is working on this issue? +4. If relevant, a link to the repository where work on this project is being done + +A project does not require full WG approval to be selected, only the sponsorship of one or more WG members. This member will be expected to provide status updates at the weekly Matrix meeting on the status of this focus project. If the WG member is unable to attend, they can delegate this responsibility as necessary. + +A project moves to the tracking state once the PR adding the project to the `focus-projects/` folder has been approved by the sponsoring WG member. + +It is recommended (but not a hard rule) that a WG member sponsors no more than one project at a time, to limit the number of in-flight projects at once. + +## Tracking + +Each week, the sponsor of each in-progress focus project should be prepared to give a short update in the Matrix meeting on the status of their project, and solicit help if additional assistance is needed. + +Priority in each meeting will be given to discuss focus projects, if there are no critical issues to discuss (upcoming breakages, etc). + +Updates will be expected until a focus project moves into a completion state. + +If any major changes are made to the goals of the focus project, or if the WG sponsor changes, the status should be updated in the markdown file in `focus-projects/`. This file does not need to be updated for regular status items, and should instead be tracked in an external repository linked in this file. + +## Completion + +There are three main ways a project can be completed: **Finished**, **On-Hold**, or **Rejected**. + +Once a project has been completed, the WG sponsor is no longer required to provide regular status updates. + +### Finished + +If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/completed/`. This move only requires the approval of the sponsoring WG member. + +It is recommended to add a section to the project file summarizing the outcome of the project, and what was achieved. + +### On-Hold + +If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/on-hold/`. This move only requires the approval of the sponsoring WG member. + +If a project is not expected to make progress, or hasn't made progress, for one month or more it is recommended that it be moved to the on-hold state. + +When moving a project to the on-hold state, a section should be added to the project file describing what this project needs to resume work (e.g. a new sponsor, people to work on it). + +An on-hold project can be moved back into in-progress with a PR and approval from a WG sponsor. At this point, status updates are expected to resume. + +### Rejected + +If a project no longer makes sense, or has been in the on-hold state for a significant time period, a project can be moved the Rejected state by moving the project file to `focus-projects/rejected`. This move can be signified with a PR, and only requires the approval of the sponsoring WG member. + +Rejected projects can still be moved back into in-progress if necessary, though the rejected state signifies that progress is unlikely to change unless a significant event happens (a technical shortcoming is overcome, or new people are available to work on this project). + +It is recommended to add a section to the project file summarizing why a project was rejected, and what items would need to be addressed to re-open this project in the future. + + +# How We Teach This +[how-we-teach-this]: #how-we-teach-this + +## Vocabulary + +**Project file** - This is a markdown document that contains core information about each focus project. It lives within the `focus-project/` folder, and may move into subfolders to signify the project state. + +**Working Group Sponsor** - This is a member of the working group who is responsible for providing status updates, making sure a project is continuing, and providing mentorship to people working on the project. Work is generally **NOT** performed only by the sponsor, and the expectation is that multiple people will work on any given project. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions +[unresolved]: #unresolved-questions + +What parts of the design are still TBD? From 6192b99214781947ac83aad5b82d50ebbe2a98e9 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 10 Sep 2019 14:02:49 +0200 Subject: [PATCH 2/8] Update rfcs/0000-focus-projects.md --- rfcs/0000-focus-projects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-focus-projects.md b/rfcs/0000-focus-projects.md index 86272469..ab2d95c3 100644 --- a/rfcs/0000-focus-projects.md +++ b/rfcs/0000-focus-projects.md @@ -82,7 +82,7 @@ It is recommended to add a section to the project file summarizing the outcome o ### On-Hold -If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/on-hold/`. This move only requires the approval of the sponsoring WG member. +If the work needs to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/on-hold/`. This move only requires the approval of the sponsoring WG member. If a project is not expected to make progress, or hasn't made progress, for one month or more it is recommended that it be moved to the on-hold state. From ed59f593da699c9876db1cdfaf962abccdd6eb89 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 10 Sep 2019 14:05:08 +0200 Subject: [PATCH 3/8] Update rfcs/0000-focus-projects.md --- rfcs/0000-focus-projects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-focus-projects.md b/rfcs/0000-focus-projects.md index ab2d95c3..1a0f49a8 100644 --- a/rfcs/0000-focus-projects.md +++ b/rfcs/0000-focus-projects.md @@ -20,7 +20,7 @@ This RFC proposes a structure for proposing, selecting, and tracking progress on # Detailed design [design]: #detailed-design -This RFC covers four main stages of how we tackle large scale work, referred to as "focus projects": **Proposal**, **Selection**, and **Tracking**, and **Completion**. +This RFC covers four main stages of how we tackle large scale work, referred to as "focus projects": **Proposal**, **Selection**, **Tracking**, and **Completion**. ## Proposal From 0a2017acb99fd35eb5487ba01f68ef111ad6157f Mon Sep 17 00:00:00 2001 From: James Munns Date: Fri, 13 Sep 2019 00:07:26 +0200 Subject: [PATCH 4/8] Rename RFC --- rfcs/{0000-focus-projects.md => 0000-shepherding.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/{0000-focus-projects.md => 0000-shepherding.md} (100%) diff --git a/rfcs/0000-focus-projects.md b/rfcs/0000-shepherding.md similarity index 100% rename from rfcs/0000-focus-projects.md rename to rfcs/0000-shepherding.md From bc9ce49e2273deb0d3aaea23ba8b6070287f2360 Mon Sep 17 00:00:00 2001 From: James Munns Date: Fri, 13 Sep 2019 02:26:08 +0200 Subject: [PATCH 5/8] More work on shepherding --- rfcs/0000-shepherding.md | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/rfcs/0000-shepherding.md b/rfcs/0000-shepherding.md index 86272469..5dabd0a5 100644 --- a/rfcs/0000-shepherding.md +++ b/rfcs/0000-shepherding.md @@ -1,4 +1,4 @@ -- Feature Name: focus-projects +- Feature Name: shepherding - Start Date: 2019-09-10 - RFC PR: (leave this empty) - Rust Issue: (leave this empty) @@ -6,17 +6,24 @@ # Summary [summary]: #summary -In order to keep progress moving in the Embedded WG, this RFC proposes a method to track potential and in-progress "focus projects" worked on by members of the Embedded WG. +In order to keep progress moving in the Embedded WG, this RFC proposes adopting the "Shepherding" method for tracking potential and in-progress project worked on by members of the Rust Embedded community. -These focus projects are intended to be larger scale works, with a fixed "end goal", that can be achieved by a group of people, and are not blocked by outside factors, such as changes to the Rust or LLVM projects, unless the project scope includes these changes. +Projects tracked by the Shepherding process are intended to be larger scale works, with a fixed "end goal", that can be achieved by a group of people, and are not blocked by outside factors, such as changes to the upstream Rust or LLVM projects, unless the project scope includes these changes. # Motivation [motivation]: #motivation In 2018, the Embedded WG came together to get embedded development in Rust to a stable level. Following the success of this venture progress has continued, but due to a lack of concrete items to focus on, and a lack of free time to work on specific items, 2019 has had less focus. +Additionally, we hope to provide more direct routes for individuals in the community to contribute to improving the Embedded Rust ecosystem, as well as provide necessary mentoring and support. + This RFC proposes a structure for proposing, selecting, and tracking progress on larger scale improvements to the Embedded Rust ecosystem. +For a general background on the concept of Shepherding, refer to the blog posts by [James Munns] and [Niko Matsakis]. + +[James Munns]: # +[Niko Matsakis]: http://smallcultfollowing.com/babysteps/blog/2019/09/11/aic-shepherds-3-0/ + # Detailed design [design]: #detailed-design @@ -24,7 +31,7 @@ This RFC covers four main stages of how we tackle large scale work, referred to ## Proposal -Anyone may propose a large scale project to be worked on. Projects are proposed by opening an issue that is tagged with the `focus-project` tag on the [Issue Tracker]. +Anyone may propose a large scale project to be worked on. Projects are proposed by opening an issue that is tagged with the `project` tag on the [Issue Tracker]. [Issue Tracker]: https://github.com/rust-embedded/wg/issues @@ -41,7 +48,7 @@ Once a potential sponsor has been found, the project may be selected. ## Selection -In order to move an issue from "proposed" to "selected", the proposer and sponsor should open a PR to add the project to the `focus-projects/` folder in this repo. Items in this folder should be named `0000-project-name.md`, and should contain the following information: +In order to move an issue from "proposed" to "selected", the proposer and sponsor should open a PR to add the project to the `projects/` folder in this repo. Items in this folder should be named `0000-project-name.md`, and should contain the following information: 1. All contents from the proposal * Original problem @@ -52,21 +59,21 @@ In order to move an issue from "proposed" to "selected", the proposer and sponso 3. Who else is working on this issue? 4. If relevant, a link to the repository where work on this project is being done -A project does not require full WG approval to be selected, only the sponsorship of one or more WG members. This member will be expected to provide status updates at the weekly Matrix meeting on the status of this focus project. If the WG member is unable to attend, they can delegate this responsibility as necessary. +A project does not require full WG approval to be selected, only the sponsorship of one or more WG members. This member will be expected to provide status updates at the weekly Matrix meeting on the status of this project. If the WG member is unable to attend, they can delegate this responsibility as necessary. -A project moves to the tracking state once the PR adding the project to the `focus-projects/` folder has been approved by the sponsoring WG member. +A project moves to the tracking state once the PR adding the project to the `projects/` folder has been approved by the sponsoring WG member. It is recommended (but not a hard rule) that a WG member sponsors no more than one project at a time, to limit the number of in-flight projects at once. ## Tracking -Each week, the sponsor of each in-progress focus project should be prepared to give a short update in the Matrix meeting on the status of their project, and solicit help if additional assistance is needed. +Each week, the sponsor of each in-progress project should be prepared to give a short update in the Matrix meeting on the status of their project, and solicit help if additional assistance is needed. -Priority in each meeting will be given to discuss focus projects, if there are no critical issues to discuss (upcoming breakages, etc). +Priority in each meeting will be given to discuss projects, if there are no critical issues to discuss (upcoming breakages, etc). -Updates will be expected until a focus project moves into a completion state. +Updates will be expected until a project moves into a completion state. -If any major changes are made to the goals of the focus project, or if the WG sponsor changes, the status should be updated in the markdown file in `focus-projects/`. This file does not need to be updated for regular status items, and should instead be tracked in an external repository linked in this file. +If any major changes are made to the goals of the project, or if the WG sponsor changes, the status should be updated in the markdown file in `projects/`. This file does not need to be updated for regular status items, and should instead be tracked in an external repository linked in this file. ## Completion @@ -76,13 +83,13 @@ Once a project has been completed, the WG sponsor is no longer required to provi ### Finished -If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/completed/`. This move only requires the approval of the sponsoring WG member. +If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `projects/` to `projects/completed/`. This move only requires the approval of the sponsoring WG member. It is recommended to add a section to the project file summarizing the outcome of the project, and what was achieved. ### On-Hold -If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `focus-projects/` to `focus-projects/on-hold/`. This move only requires the approval of the sponsoring WG member. +If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `projects/` to `projects/on-hold/`. This move only requires the approval of the sponsoring WG member. If a project is not expected to make progress, or hasn't made progress, for one month or more it is recommended that it be moved to the on-hold state. @@ -92,7 +99,7 @@ An on-hold project can be moved back into in-progress with a PR and approval fro ### Rejected -If a project no longer makes sense, or has been in the on-hold state for a significant time period, a project can be moved the Rejected state by moving the project file to `focus-projects/rejected`. This move can be signified with a PR, and only requires the approval of the sponsoring WG member. +If a project no longer makes sense, or has been in the on-hold state for a significant time period, a project can be moved the Rejected state by moving the project file to `projects/rejected`. This move can be signified with a PR, and only requires the approval of the sponsoring WG member. Rejected projects can still be moved back into in-progress if necessary, though the rejected state signifies that progress is unlikely to change unless a significant event happens (a technical shortcoming is overcome, or new people are available to work on this project). @@ -104,7 +111,7 @@ It is recommended to add a section to the project file summarizing why a project ## Vocabulary -**Project file** - This is a markdown document that contains core information about each focus project. It lives within the `focus-project/` folder, and may move into subfolders to signify the project state. +**Project file** - This is a markdown document that contains core information about each project. It lives within the `project/` folder, and may move into subfolders to signify the project state. **Working Group Sponsor** - This is a member of the working group who is responsible for providing status updates, making sure a project is continuing, and providing mentorship to people working on the project. Work is generally **NOT** performed only by the sponsor, and the expectation is that multiple people will work on any given project. From 01de7cdeefce4dbfe90339515d11a52352064363 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 17 Sep 2019 20:05:11 +0200 Subject: [PATCH 6/8] Almost done! --- 0000-project-template.md | 17 +++++++++++++++++ rfcs/0000-shepherding.md | 25 ++++++------------------- 2 files changed, 23 insertions(+), 19 deletions(-) create mode 100644 0000-project-template.md diff --git a/0000-project-template.md b/0000-project-template.md new file mode 100644 index 00000000..8e99ef23 --- /dev/null +++ b/0000-project-template.md @@ -0,0 +1,17 @@ +# Metadata + +These items should be filled in on accepting of this task: + +* (task shepherd) +* (who are contributors to this task?) +* (link to the external repository/fork/branch where work on this task is occuring) + +# Background + +* What is the current problem or shortcoming motivating this task? +* What is the relevance to this project? + +# Suggested Task + +* What is the desired outcome to address this problem/shortcoming? +* What is necessary to achieve this outcome? diff --git a/rfcs/0000-shepherding.md b/rfcs/0000-shepherding.md index 5dabd0a5..9702a591 100644 --- a/rfcs/0000-shepherding.md +++ b/rfcs/0000-shepherding.md @@ -21,7 +21,7 @@ This RFC proposes a structure for proposing, selecting, and tracking progress on For a general background on the concept of Shepherding, refer to the blog posts by [James Munns] and [Niko Matsakis]. -[James Munns]: # +[James Munns]: https://jamesmunns.com/blog/shepherding-3-1/ [Niko Matsakis]: http://smallcultfollowing.com/babysteps/blog/2019/09/11/aic-shepherds-3-0/ # Detailed design @@ -31,11 +31,9 @@ This RFC covers four main stages of how we tackle large scale work, referred to ## Proposal -Anyone may propose a large scale project to be worked on. Projects are proposed by opening an issue that is tagged with the `project` tag on the [Issue Tracker]. +Anyone may propose a large scale project to be worked on. Projects are proposed by opening an PR that copies the project template from `0000-project-template.md` to `projects/in-progress/0000-your-project-name.md`. -[Issue Tracker]: https://github.com/rust-embedded/wg/issues - -All proposals should contain the following information: +All proposals should contain the following information in the template file: 1. What is the current problem/shortcoming? 2. What is the relevance to the Rust Embedded Ecosystem? @@ -48,17 +46,6 @@ Once a potential sponsor has been found, the project may be selected. ## Selection -In order to move an issue from "proposed" to "selected", the proposer and sponsor should open a PR to add the project to the `projects/` folder in this repo. Items in this folder should be named `0000-project-name.md`, and should contain the following information: - -1. All contents from the proposal - * Original problem - * Relevance - * Desired Outcome - * What will be done? -2. Who is the WG sponsor for this issue? -3. Who else is working on this issue? -4. If relevant, a link to the repository where work on this project is being done - A project does not require full WG approval to be selected, only the sponsorship of one or more WG members. This member will be expected to provide status updates at the weekly Matrix meeting on the status of this project. If the WG member is unable to attend, they can delegate this responsibility as necessary. A project moves to the tracking state once the PR adding the project to the `projects/` folder has been approved by the sponsoring WG member. @@ -83,13 +70,13 @@ Once a project has been completed, the WG sponsor is no longer required to provi ### Finished -If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `projects/` to `projects/completed/`. This move only requires the approval of the sponsoring WG member. +If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/completed/`. This move only requires the approval of the sponsoring WG member. It is recommended to add a section to the project file summarizing the outcome of the project, and what was achieved. ### On-Hold -If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `projects/` to `projects/on-hold/`. This move only requires the approval of the sponsoring WG member. +If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/on-hold/`. This move only requires the approval of the sponsoring WG member. If a project is not expected to make progress, or hasn't made progress, for one month or more it is recommended that it be moved to the on-hold state. @@ -128,4 +115,4 @@ What other designs have been considered? What is the impact of not doing this? # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD? +None known at this time From cca84c4d1f8fb082d81a708e198eedb3d48d5071 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 17 Sep 2019 20:13:47 +0200 Subject: [PATCH 7/8] s/sponsor/shepherd --- rfcs/0000-shepherding.md | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/rfcs/0000-shepherding.md b/rfcs/0000-shepherding.md index 9702a591..368f3bef 100644 --- a/rfcs/0000-shepherding.md +++ b/rfcs/0000-shepherding.md @@ -40,53 +40,53 @@ All proposals should contain the following information in the template file: 3. What is the desired outcome to address this problem/shortcoming? 4. What is necessary to achieve this outcome? -After opening this issue, the proposer of this project should solicit feedback from Working Group members to refine the proposal, and the steps necessary to address this. Once the proposal has been refined, the proposer should find a member of the working group to **sponsor** the issue. +After opening this issue, the proposer of this project should solicit feedback from Working Group members to refine the proposal, and the steps necessary to address this. Once the proposal has been refined, the proposer should find a member of the working group to **shepherd** the issue. -Once a potential sponsor has been found, the project may be selected. +Once a potential shepherd has been found, the project may be selected. ## Selection A project does not require full WG approval to be selected, only the sponsorship of one or more WG members. This member will be expected to provide status updates at the weekly Matrix meeting on the status of this project. If the WG member is unable to attend, they can delegate this responsibility as necessary. -A project moves to the tracking state once the PR adding the project to the `projects/` folder has been approved by the sponsoring WG member. +A project moves to the tracking state once the PR adding the project to the `projects/` folder has been approved by the shepherding WG member. -It is recommended (but not a hard rule) that a WG member sponsors no more than one project at a time, to limit the number of in-flight projects at once. +It is recommended (but not a hard rule) that a WG member shepherds no more than one project at a time, to limit the number of in-flight projects at once. ## Tracking -Each week, the sponsor of each in-progress project should be prepared to give a short update in the Matrix meeting on the status of their project, and solicit help if additional assistance is needed. +Each week, the shepherd of each in-progress project should be prepared to give a short update in the Matrix meeting on the status of their project, and solicit help if additional assistance is needed. Priority in each meeting will be given to discuss projects, if there are no critical issues to discuss (upcoming breakages, etc). Updates will be expected until a project moves into a completion state. -If any major changes are made to the goals of the project, or if the WG sponsor changes, the status should be updated in the markdown file in `projects/`. This file does not need to be updated for regular status items, and should instead be tracked in an external repository linked in this file. +If any major changes are made to the goals of the project, or if the WG shepherd changes, the status should be updated in the markdown file in `projects/`. This file does not need to be updated for regular status items, and should instead be tracked in an external repository linked in this file. ## Completion There are three main ways a project can be completed: **Finished**, **On-Hold**, or **Rejected**. -Once a project has been completed, the WG sponsor is no longer required to provide regular status updates. +Once a project has been completed, the WG shepherd is no longer required to provide regular status updates. ### Finished -If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/completed/`. This move only requires the approval of the sponsoring WG member. +If the work has completed successfully by meeting the current or revised goals, and does not require ongoing focus, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/completed/`. This move only requires the approval of the shepherding WG member. It is recommended to add a section to the project file summarizing the outcome of the project, and what was achieved. ### On-Hold -If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/on-hold/`. This move only requires the approval of the sponsoring WG member. +If the work need to be put on hold due to availability or technical reasons, this can be signified by submitting a PR to move the project file from `projects/in-progress/` to `projects/on-hold/`. This move only requires the approval of the shepherding WG member. If a project is not expected to make progress, or hasn't made progress, for one month or more it is recommended that it be moved to the on-hold state. -When moving a project to the on-hold state, a section should be added to the project file describing what this project needs to resume work (e.g. a new sponsor, people to work on it). +When moving a project to the on-hold state, a section should be added to the project file describing what this project needs to resume work (e.g. a new shepherd, people to work on it). -An on-hold project can be moved back into in-progress with a PR and approval from a WG sponsor. At this point, status updates are expected to resume. +An on-hold project can be moved back into in-progress with a PR and approval from a WG shepherd. At this point, status updates are expected to resume. ### Rejected -If a project no longer makes sense, or has been in the on-hold state for a significant time period, a project can be moved the Rejected state by moving the project file to `projects/rejected`. This move can be signified with a PR, and only requires the approval of the sponsoring WG member. +If a project no longer makes sense, or has been in the on-hold state for a significant time period, a project can be moved the Rejected state by moving the project file to `projects/rejected`. This move can be signified with a PR, and only requires the approval of the shepherding WG member. Rejected projects can still be moved back into in-progress if necessary, though the rejected state signifies that progress is unlikely to change unless a significant event happens (a technical shortcoming is overcome, or new people are available to work on this project). @@ -100,17 +100,18 @@ It is recommended to add a section to the project file summarizing why a project **Project file** - This is a markdown document that contains core information about each project. It lives within the `project/` folder, and may move into subfolders to signify the project state. -**Working Group Sponsor** - This is a member of the working group who is responsible for providing status updates, making sure a project is continuing, and providing mentorship to people working on the project. Work is generally **NOT** performed only by the sponsor, and the expectation is that multiple people will work on any given project. +**Working Group Shepherd** - This is a member of the working group who is responsible for providing status updates, making sure a project is continuing, and providing mentorship to people working on the project. Work is generally **NOT** performed only by the shepherd, and the expectation is that multiple people will work on any given project. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +This requires some administration overhead, and is a new concept to track in addition to the RFC process. # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? +* Periodic goal meetings +* Top down decisions and assignment of tasks # Unresolved questions [unresolved]: #unresolved-questions From 4dc0a8d5c29f2eca6be90a5291c6d786a86b0461 Mon Sep 17 00:00:00 2001 From: James Munns Date: Tue, 17 Sep 2019 20:29:27 +0200 Subject: [PATCH 8/8] Rename with correct number to avoid invalidating reviews later --- rfcs/{0000-shepherding.md => 0378-shepherding.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename rfcs/{0000-shepherding.md => 0378-shepherding.md} (99%) diff --git a/rfcs/0000-shepherding.md b/rfcs/0378-shepherding.md similarity index 99% rename from rfcs/0000-shepherding.md rename to rfcs/0378-shepherding.md index 368f3bef..b4e779be 100644 --- a/rfcs/0000-shepherding.md +++ b/rfcs/0378-shepherding.md @@ -1,6 +1,6 @@ - Feature Name: shepherding - Start Date: 2019-09-10 -- RFC PR: (leave this empty) +- RFC PR: https://github.com/rust-embedded/wg/pull/378 - Rust Issue: (leave this empty) # Summary