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..913851c
--- /dev/null
+++ b/Accepted-RFCs/RFC-013-new-initiative-process.md
@@ -0,0 +1,136 @@
+# RFC-013: New initiative & working group 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 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.
+
+
+
+## Motivation
+
+As we grow, our risk of project scope creep and sprawl grows. As a group, we should grow *with intent*. 
+
+
+## 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. 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.)
+
+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.
+
+### 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:
+
+> 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
+
+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
+
+* Project & product management-type humans should weigh in heavily
+* Working group leads and those who have thoughts on new initiative should review
+
+## 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: +1
+
+
+Community members who voted (non-binding):
+
+- {Your name}: {Your vote}
\ No newline at end of file