Towards a predictable roadmap for sBTC

[diwakergupta]

Hi everyone,

I wanted to start a discussion around predictability, especially in the context of sBTC. I have one proposal and I'm sure there are much better ideas out there, so the goal really is to just get a conversation going around this.

Note that while there might seem some overlap with #3542, in this discussion I want to specifically focus on predictable roadmaps (vs. development process for Stacks blockchain more generally).

First, some goals for a predictable roadmap:

• Reliable: if dates on a roadmap can't be trusted, it quickly loses utility (and erodes confidence)
• Accessible: it should be easy to quickly see what's happening when, who is working on what, without a lot of prior context (that is, for anyone who is NOT a Stacks blockchain core developer!)
• Useful: specifically 1) it should help the entire stack (APIs, SDKs, wallets, explorers, mining tools, stacking providers) plan and prepare for changes by making the changes and their impact very explicit; and 2) it should help with communications with a wide variety of audiences

With that in mind, here are some ideas for managing execution (some suggestions on other aspects follow):

• Track tasks on a 4 week cadence: each 4 week interval should have a very clear deliverable (some new functionality for instance), that is easy to explain (why should I care?).
  • first week should be dedicated to planning. Make sure anything that needs to be implemented is fully specified before implementation. Design docs where applicable. Everything is broken into appropriately scoped tasks. Each task has an owner and designated reviewers for each component / module.
  • weeks 2 and 3 are focused on implementation. Well scoped PRs, tight review turnaround.
  • week 4 is for testing and quality (tech debt, bugs, any changes to specs as a result of testing etc). We could have a dedicated "sBTC testnet" that we upgrade (or reset, as the case may be) each month with the release from that month.
• We can leverage the new project board & roadmap functionality -- looks like Trust Machines is already using this on one of their boards
• Establish norms around design docs (what necessitates a design doc / review) and a single place to collect all design docs. Right now there's the SIP on one end and ad-hoc efforts like this doc on the other. We need a consistent process for creating, reviewing and collecting design docs.

Other suggestions

• Over-communicate, on all mediums: I believe right now folks are working towards an "alpha testnet" milestone. I try to attend most blockchain meetings, and have access to most docs. But even I can't confidently articulate exactly what's in scope of this alpha testnet, exactly when would it become available, what do I need to know if I'm a developer or casual observer, what's coming after that etc. I know folks like @andrerserrano and others are aware of and working towards this, so I mention this mostly to underscore the importance.
• IMO it would also help to have a higher-level design doc that outlines how the different pieces come together. This can help uncover dependencies early, among other things. This doesn't preclude separate docs for individual components where appropriate (e.g. StackerDB).
• I would recommend early outreach and engagement with downstream consumers. Key stakeholders of APIs, wallets, SDKs, miners, stacking pools, exchanges, explorers. Ideally there would be some sort of spec / abstract / interface (even if not implemented) that say an API can assume and start to build against. For instance, changes to event observer that might impact the API -- if there's a contract that the implementation will adhere to, the API can mock against that and start development sooner rather than later. (yes I know some of these conversations are starting to happen)
• Stacking needs special attention, because the entire stacking flow + experience will change drastically. IMO there really should be a team dedicated to this problem, with a strong product lens. Solo stacking experience will be very different -- what would an amazing product experience look like? Ditto for stacking pools and other stacking integrators.

Please add your ideas, comments or feedback below!

[diwakergupta]

Feedback from all is welcome, tagging a few folks I'd love to hear from: @igorsyl @jcnelson @kantai @saralab @zone117x

[igorsyl]

Thanks for writing this up!

Reliable: if dates on a roadmap can't be trusted, it quickly loses utility (and erodes confidence)

I'm taking a bottoms-up approach to planning which involves engs defining projects into units of up to 4 days of work and providing estimates and execution risks.

Accessible: it should be easy to quickly see what's happening when, who is working on what, without a lot of prior context (that is, for anyone who is NOT a Stacks blockchain core developer!)

Andre Serrano started the Bitcoin Writes newsletter, which includes GTM, and Eng weekly updates.
We also maintain the sBTC Eng GitHub Project updated.
The sBTC Eng Wiki provides visibility into the eng meetings and notes.

Useful: specifically 1) it should help the entire stack (APIs, SDKs, wallets, explorers, mining tools, stacking providers) plan and prepare for changes by making the changes and their impact very explicit; and 2) it should help with communications with a wide variety of audiences

Even though the Trust Machines Core Eng Team will not be leading contributions to the Hiro products impacted by sBTC, I plan to track these dependencies in our project board, so we remain aware of our stakeholders! I need your support to maintain discipline in keeping up with the project board.

Over-communicate, on all mediums

All meetings are recorded, and video files are automatically inserted into Google Sheets, documented and linked in meeting notes.

Stacking needs special attention

I plan to dogfood all the products to feel the maximum pain from any bad UX. This includes stacking too.
I have also proposed several Stacks Foundation Request for Proposal Bounties to scope product opportunties.

IMO it would also help to have a higher-level design doc that outlines how the different pieces come together.

Thank you for identifying this. I also need to prepare a system-wide high-level doc to onboard new engs in my team. The issue is that the design keeps evolving as we learn from implementing components but I suspect we are nearing the end of design iteration (hopefully).

I would recommend early outreach and engagement with downstream consumers.

I join calls with Sabby and Salara about Hiro products.
I collaborate with the Degens team on their Decentralized Mining Pool project.
I work with Will at Stacks Foundation to define RFP bounties and later review progress.

[diwakergupta]

Thanks @igorsyl -- I really enjoy the sBTC meetings and appreciate everything you're doing around planning, communication and coordination. Thank you!!

[igorsyl]

Useful: specifically 1) it should help the entire stack (APIs, SDKs, wallets, explorers, mining tools, stacking providers) plan and prepare for changes by making the changes and their impact very explicit; and 2) it should help with communications with a wide variety of audiences

@diwakergupta @saralab I created issues to track the above. What partners are we missing?

• stacks-blockchain-api
• stacks.js
• Clarinet
• Explorer
• subnets
• LNSwap
• Wallet
• micro-stacks