Dash Core Group Q1 Quarterly Call - 22.04.2021

bob

New Member
May 31, 2018
14
60
13
51
Comparing

Q3-2020 Call Roadmap


with Q1-2021 Call Roadmap



Just makes me feel very sad.. it seems stuff is just shifting quarter over quarter..
I would love to discuss the changes to the roadmap between the 2020 Q3 version and 2021 Q1 version. We publish our roadmap quarterly in order to provide transparency into our plans and I accept the responsibility of explaining changes. The biggest change actually occurred between the Q3 and the Q4 version. Although we thought we identified a path to mainnet in Q1, it had a lot of risk to it. It was flagged with an asterisk and carried many dependencies. By the next quarterly call, we had a real view of the remaining work and didn’t even project a mainnet target. I have tried to keep the focus on our quarterly call to discuss the plan moving forward, so I don’t usually take the time to explain the reasoning behind changes in scope or timing. This is something I can improve on in the future. However, let me explain the reasoning behind the longer delivery roadmap to mainnet.

Effort to release to testnet - The effort to release Dash Platform to testnet represented a significant body of work which was underestimated in the 2020 Q3 roadmap. The majority of the development work planned for Q4 was pushed forward as the development team prepared environments, tested and hardened code, and migrated the final release of the year onto testnet. We prioritized this deliverable because we believed that it would increase confidence in the quality of code and reality of our progress, despite the cost.

Changes to Dash Platform MVP scope - We increased the scope of what will be included in the MVP release of Dash Platform as we continue to scrutinize items in our backlog and receive feedback from the community. For example, we announced a shorter path to MVP with a release requiring running a full-node. As we contemplated the value of that release, we increased the scope to eliminate that requirement. We have also re-prioritized other post-MVP items for greater resiliency and reliability such as feature flags, strict data contract validation, local network setup, protocol upgrade process, and platform state sync. These should have been identified as increases in scope, but with a value to the network. It is possible that we may yet identify more scope to be included in MVP, but as a team we are prioritizing time to market over breadth of scope whenever possible.

Accuracy in estimating level of effort - We have been utilizing standard scrum processes for a couple years on the Dash Platform team. As I look back over the past couple quarters, there have been several cases where specific sets of development tasks have taken much longer to implement than estimated. We have bi-weekly sprint processes which include planning, grooming, reporting and retrospectives to help us improve in this area.

Dependency on Dash Core releases - In the 2020 Q3 roadmap, we were targeting to have Core v17 on mainnet in Q1 with all features necessary to support Dash Platform MVP. The Dash Core mainnet migration is now occurring in Q2, which represents a slip. However, not all of the features required for Dash Platform MVP made it into v17, so a v18 is necessary. It is fair to ask why we didn’t include all the features needed for Platform, especially since it was on testnet for 4 months. The answer is that design is not complete for asset locking and the resources required are fully engaged on other development efforts.

Dependency on Dash Core migrations - In our 2021 Q1 roadmap, we have included the timing necessary for the actual migration and activation of both v17 and v18 on mainnet. Activation by mining pools has historically taken about 6 weeks to complete. This is one-half of a quarter, and we need to do this twice prior to Dash Platform MVP being activated on mainnet. The 2020 Q3 development roadmap highlighted that 2021 Q1 was the target for a mainnet release. However, the roadmap never communicated the length of the activation and when Platform MVP would have realistically been activated. A Q1 mainnet release would have been a signal of readiness, but not accurately reflect its usability. This is an area for improvement that I see in our current communication which I will look to clarify.

In summary, if you are looking for an accounting of a three quarter change in the delivery date of Dash Platform, here it is. It is not based on Dash Core, although those efforts need to be aligned. We lost time moving to testnet, with scope increases to provide a more resilient, secure and usable product, and due to some under-estimation. We do have a dependency on Dash Core readiness and will need v0.18 activated on mainnet, which can not occur much sooner than Q4 of this year. We definitely missed an opportunity to have v0.17 be the dependency which was due to resource bottlenecks and constraints. This is one of the challenges managing the coordination of product delivery across teams, with a small set of resources - 50% of our 2018 headcount.

Thanks for the question. I hope you appreciate the transparency. I appreciate the opportunity to reflect and continue to mature and improve the organization.
 

GrandMasterDash

Grizzled Member
Masternode Owner/Operator
Jul 12, 2015
3,018
1,173
1,183
@bob I'm guessing the promised proposal for an independent security audit is out of the question then.
 

bob

New Member
May 31, 2018
14
60
13
51
Sporks allow features to be deployed to the network with risk mitigation as the goal. I personally believe the feature is brilliant, although - with great power comes great responsibility. It has to be the responsibility of some individuals to hold keys with which to enable and disable sporks. And in turn, with great responsibility, comes great power. That power has to be thoroughly understood by the holders of the keys and we can't put them in the hands of individuals who don't understand the technical and economic details of their actions. So, are keys within DCG a vulnerability for Dash? Absolutely not. Should there be great decentralization of spork activation? Of course, that is always a goal. With desires for anonymity, the need for thorough technical understanding, a vote of confidence by the network for the stewards, and other risk mitigating criteria, I believe the keys have been entrusted properly to this point. The track record of DCG's avoidance of risk is the evidence I need.
 
  • Like
Reactions: Spaniard

Geert

Member
Aug 26, 2015
259
82
88
Bob. I hope you understand that there are masternode owners here who greatly appreciate your efforts and what you've been able to accomplish. IMHO you saved this project. Not everyone here has the ability to understand that, but there are some who do. Thank you.