From c22fc2505786e66bd7c4530a45419d33e8085ea7 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 24 Aug 2022 22:53:15 +0000 Subject: [PATCH 1/4] initial submission of RFC 013 --- .../RFC-013-new-initiative-process.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 Accepted-RFCs/RFC-013-new-initiative-process.md diff --git a/Accepted-RFCs/RFC-013-new-initiative-process.md b/Accepted-RFCs/RFC-013-new-initiative-process.md new file mode 100644 index 0000000..ea6e545 --- /dev/null +++ b/Accepted-RFCs/RFC-013-new-initiative-process.md @@ -0,0 +1,120 @@ +# RFC-013: New initiative process + + +## Proposed by + +Ryan Macklin ([@macklin](https://thegooddocs.slack.com/team/U01DYRWG43X)) + +Initially submitted on 24 Aug 2022 + +## Current status + +- [x] Draft +- [ ] Under discussion +- [ ] Final comment and voting (until YYYY-MM-DD) {{Add date after selecting this status.}} +- [ ] Accepted +- [ ] Rejected +- [ ] Implemented +- [ ] Deferred +- [ ] Withdrawn + + +## Proposal overview + +The Good Docs Project has an issue of delivery: we haven't delivered a 1.0 of our templates since the inception. And as a volunteer org, we need to keep focus on our mission and goal. It's easy to dilute ourselves if we don't keep ourselves accountable to focus and intentional communal growth. + +In other words, we as a project need to make sure we can at least do our core mission well. All new initiatives should + +(As a personal note, the drafter of this RFC has ADHD, so "new project energy" is a real thing, a true risk of distraction and effort dilution.) + + +## Motivation + +As we grow, our risk of project scope creep and sprawl grows. As a group, we should grow *with intentionality*. + + +## Proposal + +When someone wants to start a new working group or sub-project in the Good Docs Project, it should coherently address at least one of: +* We have an internal need, to make working on the project better—whether that's smoothing out processes, spinning up groups to keep work from being on one person, documenting information for worldwide efforts, etc +* We identify some utility we can offer our userbase that either directly or reasonably indirectly builds off of our core mission: to delivery high-quality template resources to people who need help making their own documentation. + +Along with that, each new initiative needs someone to lead it. That person needs to be confident in leading (or co-leading) that initiative for at least a year. This is to prevent initiatives from being spun up and left to dwindle. (Unless said initiative isn't intended to last that long, of course. But we can expect some initiatives that intend to be short to take longer than initially planned.) + +Finally, each initiative needs to articulate the deliverables it intends to produce in its first year. This can of course mutate over time, but an initial understanding is key to helping the rest of the project understand the new initiative. + +With all of that, the initiative should be drafted as a RFC so the project steering committee can both ask insightful questions/provide comments, as flag their possible interest in helping with that initiative. + +### Not every doc initiative is a Good Docs Project initiative + +As passionate documentarians, we often want to find ways of helping the wider world. That's why we're here! But not every doc project is the right fit to take up project leadership bandwidth and meeting time. So when we look at a new initiative, we should as a group ask: + +> Does this initiative naturally fit with our core project? Or is it a "sister" initiative? + +For those that might be "sister" initiatives, we want to support those! And part of that support is being honest about if that initiative might be poorly supported as part of our project. + +### The timing might not always be right for a given initiative + +Keeping to the idea of focusing our efforts and providing deliverables to our userbase, sometimes we'll have a great idea that fits with the Good Docs Project mission that we aren't actually ready for. That could be because we need to process an intensive effort for a release, or we don't have the resources to sustain addressing a cause. Thus, part of this process is about being genuine and honest about what an initiative needs, and if we can provide for that initiative what it needs. + +For example, the "Blog/Video" group has dropped videos from their working group for the time being, because the bandwidth to create videos doesn't exist. We may pick that up in 2023 or 2024, or decide the cost of supporting that is better spent on other initiatives. + +## Consequences + +This could appear to make the project feel "bureaucratic" or "stuffy." While I feel that isn't the case, I understand some ways of implementing this idea could be alienating to passionate people. That's a conversation worth having. + +## Links and prior art + +{This section is optional if you want to [link](https://example.com) to other resources.} + + +## Open questions + +{This section is optional and is where you can list questions that won't be resolved by this RFC, including those raised in comments from community members.} + + +## Decisions deferred + +{This section is option and is where you can list decisions that won't be resolved by this RFC, but which should be raised at a later time.} + + +## Feedback + +{If you accept feedback from a community member, you will incorporate it into your RFC before it is accepted. +If you reject feedback, note that rejected feedback here before resolving the conversation.} + + +## Implementation checklist + +If this proposal is accepted, the following tasks must be completed: + +- [ ] Actually write the process flow up +- [ ] Publish the flow somewhere (like in the KB referenced in RFC-012) +- [ ] Once that's all done, consider if any existing initiatives should be de-prioritized or otherwise re-evaluated + + +## Votes + +Votes as per our [decision process](https://thegooddocsproject.dev/decisions/): + +Project steering committee (listed alphabetically by first name): + +- Aaron Peters: +- Alyssa Rock: +- Ankita Tripathi: +- Bryan Klein: +- Cameron Shorter: +- Carrie Crowe: +- Erin McKean: +- Deanna Thompson: +- Felicity Brand: +- Gayathri Krishnaswamy: +- Morgan Craft: +- Nelson Guya: +- Ryan Macklin: +- Tina Lüdtke: + + +Community members who voted (non-binding): + +- {Your name}: {Your vote} \ No newline at end of file From e741d863a8c6055c7651fe41ca49a70b9ee3f5fc Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Thu, 25 Aug 2022 00:46:23 +0000 Subject: [PATCH 2/4] Added org dependencies --- Accepted-RFCs/RFC-013-new-initiative-process.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Accepted-RFCs/RFC-013-new-initiative-process.md b/Accepted-RFCs/RFC-013-new-initiative-process.md index ea6e545..b1006c8 100644 --- a/Accepted-RFCs/RFC-013-new-initiative-process.md +++ b/Accepted-RFCs/RFC-013-new-initiative-process.md @@ -83,6 +83,10 @@ This could appear to make the project feel "bureaucratic" or "stuffy." While I f {If you accept feedback from a community member, you will incorporate it into your RFC before it is accepted. If you reject feedback, note that rejected feedback here before resolving the conversation.} +## Organizational dependencies + +* Project & product management-type humans should weigh in heavily +* Working group leads and those who have thoughts on new initiative should review ## Implementation checklist From 847d8e963a7876578584e51bb12e639b3e697c05 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 21 Sep 2022 22:54:08 +0000 Subject: [PATCH 3/4] Some notations made --- Accepted-RFCs/RFC-013-new-initiative-process.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/Accepted-RFCs/RFC-013-new-initiative-process.md b/Accepted-RFCs/RFC-013-new-initiative-process.md index b1006c8..cf78dae 100644 --- a/Accepted-RFCs/RFC-013-new-initiative-process.md +++ b/Accepted-RFCs/RFC-013-new-initiative-process.md @@ -1,4 +1,4 @@ -# RFC-013: New initiative process +# RFC-013: New initiative & working group process ## Proposed by @@ -23,7 +23,7 @@ Initially submitted on 24 Aug 2022 The Good Docs Project has an issue of delivery: we haven't delivered a 1.0 of our templates since the inception. And as a volunteer org, we need to keep focus on our mission and goal. It's easy to dilute ourselves if we don't keep ourselves accountable to focus and intentional communal growth. -In other words, we as a project need to make sure we can at least do our core mission well. All new initiatives should +In other words, we as a project need to make sure we can at least do our core mission well. All new initiatives & associated working groups should (As a personal note, the drafter of this RFC has ADHD, so "new project energy" is a real thing, a true risk of distraction and effort dilution.) @@ -36,8 +36,14 @@ As we grow, our risk of project scope creep and sprawl grows. As a group, we sho ## Proposal When someone wants to start a new working group or sub-project in the Good Docs Project, it should coherently address at least one of: -* We have an internal need, to make working on the project better—whether that's smoothing out processes, spinning up groups to keep work from being on one person, documenting information for worldwide efforts, etc -* We identify some utility we can offer our userbase that either directly or reasonably indirectly builds off of our core mission: to delivery high-quality template resources to people who need help making their own documentation. +* We have an internal need to make working on the project better. For example: + - smoothing out processes + - spinning up groups to keep work from being on one person + - documenting information for worldwide efforts +and other initiatives in this vein. +* We identify some utility to offer our userbase that either directly or reasonably indirectly builds off of our core mission: to deliver high-quality template resources to people who need help creating their own documentation. + +Related comment from Tina: "It would be nice to have the criteria in check-list form. That could make a nice "cover sheet" for new repos until they write a proper README." Along with that, each new initiative needs someone to lead it. That person needs to be confident in leading (or co-leading) that initiative for at least a year. This is to prevent initiatives from being spun up and left to dwindle. (Unless said initiative isn't intended to last that long, of course. But we can expect some initiatives that intend to be short to take longer than initially planned.) @@ -116,7 +122,7 @@ Project steering committee (listed alphabetically by first name): - Morgan Craft: - Nelson Guya: - Ryan Macklin: -- Tina Lüdtke: +- Tina Lüdtke: +1 Community members who voted (non-binding): From 51ddfc4934195381ddf41dcb1dc7e701efa43d24 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 21 Sep 2022 23:05:41 +0000 Subject: [PATCH 4/4] Processed comments --- .../RFC-013-new-initiative-process.md | 20 ++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/Accepted-RFCs/RFC-013-new-initiative-process.md b/Accepted-RFCs/RFC-013-new-initiative-process.md index cf78dae..913851c 100644 --- a/Accepted-RFCs/RFC-013-new-initiative-process.md +++ b/Accepted-RFCs/RFC-013-new-initiative-process.md @@ -21,16 +21,13 @@ Initially submitted on 24 Aug 2022 ## Proposal overview -The Good Docs Project has an issue of delivery: we haven't delivered a 1.0 of our templates since the inception. And as a volunteer org, we need to keep focus on our mission and goal. It's easy to dilute ourselves if we don't keep ourselves accountable to focus and intentional communal growth. +The Good Docs Project has a lot of passionate people, and that passion sometimes needs some focus lest we spread ourselves too thin. We're doing great work, and want to make sure we don't derail that unintentionally! To that end, here's a proposed framework for adding focus and intentionality when someone wants to add a new initiative and working group to our project. -In other words, we as a project need to make sure we can at least do our core mission well. All new initiatives & associated working groups should - -(As a personal note, the drafter of this RFC has ADHD, so "new project energy" is a real thing, a true risk of distraction and effort dilution.) ## Motivation -As we grow, our risk of project scope creep and sprawl grows. As a group, we should grow *with intentionality*. +As we grow, our risk of project scope creep and sprawl grows. As a group, we should grow *with intent*. ## Proposal @@ -51,6 +48,10 @@ Finally, each initiative needs to articulate the deliverables it intends to prod With all of that, the initiative should be drafted as a RFC so the project steering committee can both ask insightful questions/provide comments, as flag their possible interest in helping with that initiative. +### Out of scope for this: new epics for existing working groups + +This proposal is for creating new groups for new initiatives, not for handling the natural state of existing groups growing into tackling new epics. (Though I'm sure some of those will be their own RFCs anyway, but that's beside the point.) + ### Not every doc initiative is a Good Docs Project initiative As passionate documentarians, we often want to find ways of helping the wider world. That's why we're here! But not every doc project is the right fit to take up project leadership bandwidth and meeting time. So when we look at a new initiative, we should as a group ask: @@ -86,8 +87,13 @@ This could appear to make the project feel "bureaucratic" or "stuffy." While I f ## Feedback -{If you accept feedback from a community member, you will incorporate it into your RFC before it is accepted. -If you reject feedback, note that rejected feedback here before resolving the conversation.} +Comments from Cameron to preserve and process, as we execute on implementation: + +> How are we going to do the early brainstorming for ideas? +> * How can someone say "I reckon this is a good idea, another one else want to join me?" +> * Would it be worth introducing some sort of light prioritized "backlog" of ideas, so we can say to someone "Cool, you want to work on a GeeWiz template. You should talk to Jo who was also interested in that." +> * Maybe also use the backlog to record a suggestion which was rejected and why, so we can reference it when the suggestion comes through again. +> * I note that a backlog can become long and unwieldy, and so probably should be implemented with a way to easily ignore old suggestions. Maybe use an archived email list. ## Organizational dependencies