RFC-013: new initiative process #30
Conversation
There was a problem hiding this comment.
Again, nice work on this RFC, Ryan. As a general statement of principles, I 100% agree with the sentiments expressed here. I also have a few questions and concerns to raise.
Question 1: Release planning
Since we've been spending the last few months developing our new release planning mechanism for the first time, I wonder how initiatives will interact with the release planning process. In your proposal, you suggest any new initiative that is large enough in scope to require a new working group would need an RFC. What I wonder is how the RFC process will interact with the release planning process. Is the release planning process a separate/additional channel for proposing project-level epics/initiatives? If so, how does it relate to the RFC process? If not, what's the distinction? I'd maybe like to hear @acpkendo's thoughts on this interaction. Like would we store up proposals for initiatives and just review them in the release planning window?
Question 2: Sister initiatives
Your RFC leaves open the possibility of providing support to sister initiatives. If a sister initiative came about (like there's another org that wants to partner with members of our community on project), how much support should we be willing to give it? Should we take it on a case by case basis?
Praise
Thanks again for your efforts getting this conversation started, Ryan. You've done some great work here!
| 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. | ||
|
|
There was a problem hiding this comment.
This is not directly related to the overall content of the RFC, so please treat this is a non-blocking side comment. I wanted to say that I don't agree with the narrative/framing here and so I want to push back a little. This paragraph makes it sound like we haven't accomplished anything noteworthy in our community and I find myself bristling a bit at that statement. While it is true that we haven't delivered a 1.0 release, we are quite close to achieving it.
I also want to state that we have many significant accomplishments that shouldn't be lightly overlooked. Since the project began in 2019, we've been laying important groundwork to attract high quality community members to TGDP because we've been building a healthy, vibrant, fun community that delivers very real tangible benefits to people who participate over the long term in both intrinsic and extrinsic terms. Because of our strong mentorship program, we're training the next generation of tech workers and have at least 5+ success stories of people who have gotten jobs or entered the field of tech because of their direct involvement in the project. We're also promoting thought leadership within the documentation field in general. I'm proud of the community we've built and I think that is still a significant achievement. Healthy and happy open source communities are hard to build and maintain, but that's exactly what we've done here.
To me, TGDP feels like the equivalent of a startup that has taken time to set up the business infrastructure and attract a high quality workforce. We've moved past the bootstrapping phase where we operate out of someone's garage into a fairly serious project. The difference is just that time passes more slowly in open source than it does in the business world and we have to module our expectations for how fast things get done with a volunteer community.
I also think we have been productive, it's just not immediately visible what has been achieved. For the past two years, we've been laying the groundwork for how we will work, building out our tech stack, procedures, and communication channels so that we can ensure easier onboarding, good community support and feedback, and high quality products. I think we are only just now beginning to see the benefits of that foundational groundwork we've been building. If I may be so bold, I think we're 75% on target to having what would meet my definition of a 1.0 release and that is no small accomplishment.
At the end of the day, we've done great things and soon we will have something tangible to show for it. We're so, so close. Let's both celebrate what we've accomplished in the past while also setting our sights on the next milestone.
There was a problem hiding this comment.
*stealing this for a future blog post about the project ninja
There was a problem hiding this comment.
That's all pretty fair! I'll reframe the RFC with those thoughts in mind, and make sure we are being celebratory.
There was a problem hiding this comment.
And while I still agree with my "issue of delivery" sentiment, I also recognize (and should be explicitly saying) that we are working to deliver. We aren't just sitting around talking about a thing we'd like to do—we're doing the work. Just gotta make sure we keep doing the right work at the right time.
Timing is
.
.
.
.
.
everything
There was a problem hiding this comment.
Adding to @barbaricyawps 's list of achievements. We actually have a number of templates which are at 1.0 quality, or about to be released at 1.0 quality. (We just don't have a full set yet.)
There was a problem hiding this comment.
Revised this section!
I'll wait for Aaron's thoughts on this. I have a possible answer, but want to make sure it's shaped by his input.
I'd call that case-by-case, namely that if individuals want to offer support, rad! I wouldn't put any suggestion on what to do as an org for supporting a sister initiative, since the point of it being a sister initiative is that the org's energies aren't best suited there. Does that distinction make sense? |
|
|
||
| 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 |
There was a problem hiding this comment.
| 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 should |
should what?! Aargh, don't keep me in suspense!
There was a problem hiding this comment.
All new initiatives should finish their sentences! (Issue noted, I'll see if I can remember precisely my train of thought. Is what I got for drafting 4 RFCs at once)
There was a problem hiding this comment.
I believe it's "All new initiatives should support the organization's core goal/mission."
At least until we're at a point where our mission's execution isn't in its infancy anymore.
|
Thanks for raising this @ryanmacklin
|
|
Thanks for rasing this! Great work, Ryan! I'll provide more feedback soon. |
That sounds like a great idea! Though I think I'd defer that to after this is agreed upon, so we aren't constantly redrafting an image. Unless you think it's key to the discussion now. Which I guess means I could just make a Google Drawing for it. Which is trivial work. So I'll do that as part of the RFC, and make it a static image when the RFC is closed (since I don't want the RFC to link out to linkrot at some future point).
I like this idea. I'm surprised it's not in the RFC already, as I feel like that's been in my head. We could consider that an advisory rather than as a mandate. Like "and if you don't have a second sponsor when you draft the initiative, that's okay for now, but we'd really like to see you get one early in its implementation." Plus, the new initiative proposal is a way of soliciting for a second sponsor from the community as a whole, rather than from the initial sponsor's smaller network within the community. (We might even say we encourage others to sponsor, rather than the same usual suspects, but also not a mandate cuz we can't mandate that to a volunteer org.) |
| 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. | ||
|
|
There was a problem hiding this comment.
Assuming the definition of "initiative" here is precisely "creating a new WG," this all looks logical. Just want to make sure there's a distinction between what's covered by this RFC and an "epic" (in release planning terms), which may be an ongoing goal that we never fully "complete," spans several releases, and is comprised on multiple tasks/issues.
I mention this because epics are a natural outcome of the backlog refinement process, and I don't think need an RFC or dedicated working group/leader.
There was a problem hiding this comment.
+1 to @flicstar 's decision tree.
suggestion: (non-blocking): Riffing further off that, 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.
There was a problem hiding this comment.
Revised this to be about new initiatives that require working groups.
|
|
||
| ## Motivation | ||
|
|
||
| As we grow, our risk of project scope creep and sprawl grows. As a group, we should grow *with intentionality*. |
There was a problem hiding this comment.
| 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 intention*. |
There was a problem hiding this comment.
Small nitpick up here. As a non-native speaker, I don't know if there is a difference between intention and intentionality.
There was a problem hiding this comment.
"Intentionality" is a wordier way of saying "intent," which isn't exactly the same as "intention" (but there's nuance, they're 99% the same and could be used this way as well, which is also the case with "intentionality"). I'll change the instances to "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—whether that's smoothing out processes, spinning up groups to keep work from being on one person, documenting information for worldwide efforts, etc |
There was a problem hiding this comment.
| * 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 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. |
Suggestion to make it easier on the eyes.
|
|
||
| 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. |
There was a problem hiding this comment.
| * 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 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. |
|
|
||
| ## 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: |
There was a problem hiding this comment.
After reading the initial set of criteria I had this thought:
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.
There was a problem hiding this comment.
Noted in proposal
|
|
||
| ## 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. |
There was a problem hiding this comment.
We're growing as a project, and therefore we need some guidelines to bundle our efforts instead of dispersing into chaos.
I've seen that happening a few times :D
I greatly appreciate the RFC!
| - Morgan Craft: | ||
| - Nelson Guya: | ||
| - Ryan Macklin: | ||
| - Tina Lüdtke: |
There was a problem hiding this comment.
| - Tina Lüdtke: | |
| - Tina Lüdtke: +1 |
|
I'm +1 on this. |
Note to RFC reviewers
This pull request description is not the actual RFC. To view the actual RFC, click Files changed in the top menu for this pull request.
NOTE: We recommend reading the files in their rendered format rather than their raw format.
Current RFC status