Hi @Mateja3m,
Thanks for taking the time to write back.
Speaking as a Spark committee member, this outcome is not a judgment on your effort, your sincerity, or your future place in the ecosystem. You engaged the review honestly, restructured under pressure when asked to, and closed the project with grace. Those things are real and worth acknowledging.
The decision came down to the question every onboarding doc must ultimately answer: can an unfamiliar developer, sitting at a different machine, get through the guide on their own? That standard is the one you yourself laid out in Section 8 of the proposal, and on that single bar the committee had to close the project. It is an estimation about delivery against the baseline within the proposal, not about you.
We genuinely hope you stay involved with the ecosystem. The onboarding-experience problem you tried to solve is real, and we would welcome a future attempt at it.
Best,
3 Likes
In my opinion, onboarding documentation is one of the hardest kinds of writing to do well. The audience is regularly the people you cannot ask, and the success condition is invisible until someone you have never met succeeds without your help.
The cleanest practitioner reference I know on this craft is Docs for Developers: An Engineer’s Field Guide to Technical Writing, co-authored by documentation engineers from Google, Stripe, Monzo, and elsewhere.
Four things from that book are worth carrying into any future attempt:
-
A guide that gets one stranger through the first 30 minutes is worth more than a 12-module survey the author has personally verified. A tutorial is defined by a learner’s journey, not a topic outline.
-
Recruit at least one developer with no prior relevant exposure to follow the guide cold, on their own machine, while you watch silently. Where they stop is the guide’s real edge.
-
Publish a thin slice, run it past two or three real readers, revise, then expand. A finished-looking doc that no outside reader has run is the fragile shape.
-
Pairing with one or two builders who recently walked the path themselves makes the guide much harder to get wrong. The reason is that the longer you have known something, the harder it becomes to model what it feels like not to know it.
None of this is Spark committee preference. And we are looking forward to more and more guides that finally let a stranger reach their first CKB success on their own machine.
7 Likes
Hi @zz_tovarishch,
Thank you for the thoughtful reply and for the kind words. I appreciate the clarification, and I understand the committee’s position.
I will definitely stay involved with the ecosystem and will continue looking for ways to contribute to new projects and community efforts. I also appreciate the book recommendation. I will take it seriously and use it as a reference for improving how I approach developer-facing documentation in the future.
Although this project did not succeed within the Spark grant process, I still believe the repository can become useful over time. I plan to continue improving it gradually, so that it can hopefully become a practical resource for the community. Any feedback, suggestions, issues, reviews, or contributions from the community would be very welcome and helpful during that process.
Thanks again for the review, the feedback, and the encouragement.
Best,
Milan
7 Likes
