RFC-014: Product Vision for "templates 1.0" #31
Conversation
ryanmacklin
requested review from
camerons,
flicstar,
acpkendo,
carriecrowe1138,
barbaricyawps and
itsdeannat
| - Whatever other templates happen to be done, that feel cohesive rather than oddly placed | ||
| - Those that feel out of place can continue to exist in a dev channel, until they feel like they're part of a whole (if any such templates fall under this category) | ||
| - Basic supplemental material on how to use the templates | ||
| - Basic Chronologue execution of templates |
There was a problem hiding this comment.
Thought (non-blocking): If we don't have chronologue examples ready by our deadline, I'd be still comfortable with releasing 1.0 without the examples. (Due to the momentum in chronologue, it seems they will be ready in time.)
There was a problem hiding this comment.
I agree with Cameron. We seem to have a reliable flock of people at the moment, but I don't want to be holding up a release.
|
|
||
| Given our tethering to the Write the Docs calendar, here's a proposal: | ||
|
|
||
| - We have a "0.9 release candidate" ready and out 2 weeks prior to WTD Portland |
There was a problem hiding this comment.
Thought: From working on prior open source releases, I'm mindful that our community will be working very hard to make this milestone, there will be people burning out, there will be requests for extensions. We should expect to slip by one week and factor that into our schedule, even if we don't publish this. (The deadline being two weeks before WtD conference will facilitate this.)
|
|
||
| That said, if we can't hit this timeline, but the rest of this RFC looks legit to the steering committee, this element is deemed as flexible. (Similar to deciding what is/isn't 1.0.) However, the author strongly wants to assert a timeframe, as it's more beneficial to work toward a timeframe and fall short than it is to work without a timeframe. | ||
|
|
||
| ### "Wait, a 0.9 release candidate?" |
There was a problem hiding this comment.
Praise: Love this 0.9 release idea, for all the reasons you mention.
|
|
||
| Part of what would help us forge a path toward a 1.0 is having someone keeping an eye of what as a group we're working on, and how those efforts can intersect with the product vision… or force the vision to adapt to reality. That would be a **product leader**. | ||
|
|
||
| Ryan is proposing (in third person) of taking on that role, at least until we get to a 1.0 release. He doesn't have an attachment to any given template working group, so he's hoping that having a less biased viewpoint could help in offering product direction. (If anyone else wants to be a part of this role, that's welcomed! Though we'd like the tempalte leads to stick to production, and not split their focus.) |
There was a problem hiding this comment.
Praise: Yes, this leader role is definitely needed for a successful project. It requires someone who will prod, chase, mentor, but also be able to firmly but nicely say "no, you are not ready yet". I'm confident that Ryan would be very good at this.
| - Alyssa Rock: | ||
| - Ankita Tripathi: | ||
| - Bryan Klein: | ||
| - Cameron Shorter: |
|
|
||
| As an organization, we've been talking about having template releases for years. We've been actively recruiting people to help participate in the process, but we've lacked a critical element: an overarching plan for what's a "1.0" release of our templates. | ||
|
|
||
| On a logisitcs level, it feels hard to pitch our project to people, as we've spent multiple WTD Portlands talking about goals and aspirations, but not providing someone concrete that proves The Good Docs Project isn't just vaporware. As an organization, we could use the credibility of achieving a concrete 1.0 launch. |
There was a problem hiding this comment.
| On a logisitcs level, it feels hard to pitch our project to people, as we've spent multiple WTD Portlands talking about goals and aspirations, but not providing someone concrete that proves The Good Docs Project isn't just vaporware. As an organization, we could use the credibility of achieving a concrete 1.0 launch. | |
| On a logistics level, it feels hard to pitch our project to people, as we've spent multiple WTD Portlands talking about goals and aspirations, but not providing someone concrete that proves The Good Docs Project isn't just vaporware. As an organization, we could use the credibility of achieving a concrete 1.0 launch. |
|
|
||
| And if we're aiming to support devs who are overwhelmed or scared to make docs, they could use that 1.0 launch too. | ||
|
|
||
| Another very important benefit of having a product plan/roadmap is that it'll help us better identify what template work needs to be done (thus filling in our backlog and issue list). We have a perpetual problem of new community members who join our project and are excited to create templates, but very few of them have their own independent ideas for what templates they could work on. Many templateers would prefer for us to say what work needs to be done and what our priorities are. Much of the time, we just make this up and talk it out on an ad-hoc basis, but it would be great to have a clear plan that clearly indicates what work needs to be done. |
| - Whatever other templates happen to be done, that feel cohesive rather than oddly placed | ||
| - Those that feel out of place can continue to exist in a dev channel, until they feel like they're part of a whole (if any such templates fall under this category) | ||
| - Basic supplemental material on how to use the templates | ||
| - Basic Chronologue execution of templates |
There was a problem hiding this comment.
I agree with Cameron. We seem to have a reliable flock of people at the moment, but I don't want to be holding up a release.
| - Detailed best practices | ||
| - Templates with a smaller use case, that happens to be someone's passion | ||
| - Material related to docs but don't directly serve the "open source dev scared of writing docs," like how to sell the value of docs in one's organization | ||
| - In-depth Chronologue execution |
|
|
||
| ### What makes up the template product 1.0 | ||
|
|
||
| - Whatever templates we deem as "core" (which is a follow-up conversation) |
There was a problem hiding this comment.
Food for thought for the follow-up conversation:
@barbaricyawps Did a great job with sketching out "template packs". I think they are a wonderful grouping of templates. We could use that as a reference as to which of the pack(s) to include in 1.0.
|
|
||
| This product vision needs to understand that we'll have some failure points, and that we'll have to make compromises and shifts in the overall plan as we that happens. Part of the product management role will be to try to keep an eye on those various tasks or initiatives, to see if any failure points can be mitigated early on. And when they can't be, then we adapt and do the best we can. That might mean pushing some timelines back, or reducing the overall list of deliverables, or seeing if others can shift their own energies and help with a sudden hole in production. | ||
|
|
||
| This is all to say: just because we draft a vision for 1.0, that doesn't give us an excuse to be inflexible with respect to the needs of our community members. One of the things I mentioned in the post-mortem as a success: *That we all still like each other.* That should remain even if we're trying to hold to a product vision. |
| - 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. Thanks Ryan for articulating it. |
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