Replies: 2 comments 1 reply
-
Personally I am believer in pushing things often and in small batches. I think what we currently have lacks a few more things that would make MVP ready. Open-source thrives from imperfections. Imperfections motivate people to get involved and contribute if those imperfections provide enough value. We must be aware that work here will never be perfect or complete. Like Bitcoin itself, things change every day and we need to get our work out there in order to see the reactions and get feedback. When should we be ready for the launch and what activities should follow the launch? I think end of Q1 that @danielnordh brought up is reasonable time frame. By then we should have the basics of on-boarding and payment guide out there and polish up the rest. What would a successful lanuch look like and what should we expect from it? A big celebratory moment for everyone who worked on the guide. It should be followed by blog post, twitter announcement and bring more attention to the project. We'd need to figure out CTA for people (perhaps inviting projects to join us?) |
Beta Was this translation helpful? Give feedback.
-
Agreed. I also think Q1 is doable and that this would be more "ceremonial" launch in that we push content live bit by bit, but then pick a point (the launch date) where we agree that this is a solid version 1. Then we can swarm out and try to validate it with projects through discussions, reviews and collaboration and let those interactions inform the next steps. My expectations for a V1 would be that we cover most of what we laid out in our initial table to contents. Doesn't have to be structured exactly like that and it doesn't have to be covered to the smallest detail, but I find that outline still generally holds up. The content should be deep enough to be useful and informative, and should be of good quality. I'd prefer less content of better quality than having to go back and redo certain areas from scratch. We should also have sorted out the structural things we are currently discussing (like whether we centralize use cases and values/principles) and clear info on how to contribute. As far as CTA, that's where I think it will be helpful to define the larger best practices for open-source design collaboration, as that makes it easier to show the role the guide can play. For example, if we can identify different project/design stages, then we can recommend certain design activities and guide pages to help with those particular issue. So many thoughts on this topic. Really exciting though, can't wait to see what the next few months will bring. |
Beta Was this translation helpful? Give feedback.
-
In a community call #9 one of the topic that came up while we discussed 2021 goals was determining the launch moment when the work on the guide becomes more public-facing.
There have been several suggestions (some of which included quite different time-frames), so I'd like to open a focused topic to discuss this a bit more in-depth.
Beta Was this translation helpful? Give feedback.
All reactions