After having created an initial spec for mvds, we had decided that we need to specify chat semantics in order to display its utility. Today we decided to abandon the project for multiple reasons:
- Importance lower than other current projects such as Waku
- Badly defined scope
This of course does not mean that we won’t work on something like this in the future.
Dasy is a relic of when we were not focused on organization and properly managing projects yet. So it provides us with at least some lessons learned on how we can improve on this in the future and ensure projects aren’t abandoned.
Broadly defined specs
As mentioned above the specs were broadly defined, this means that to create something even remotely successful one needed to tackle the entire project rather than bite-sized issue. Aka: Dasy required to be an entire group chat with membership semantics etc. whereas it could’ve been a private chat between 2 statically peered parties.
Accountability
Due to the broadly defined spec, we also lacked accountability, I was never working on an issue. I was working on the entire thing making it hard to state exactly where you were and what steps are next.
Next Steps
Going forward I would like to see us define requirements better and break these into smaller issues making the research more organized and providing a faster feedback loop.
Other factors, related to above:
Not timeboxed
Trying out experimental things and failing should be encouraged, but the cost can be limited by keeping a timebox. I.e. it can be a “two week bet” (or even “one day bet/spike”) where after 2 weeks lessons learned are posted and a decision can be made on whether to go forward or not.
This help bound risky projects and keeps morale up.
Didn’t take lessons learned from existing group chat infrastructure
A lot of thought has been put into the existing group chat, and it would’ve been wise to use that as a starting point, figure out what the specific problems are with it and build from there. This is partly documented in Discuss and specs, but could’ve also been clarified by asking previous stakeholders in this design.
(If project was timeboxed to a short time, doing ‘NIH’ style can be acceptable)
Not pulling the plug earlier
De facto it was deprioritized for a longtime, but this wasn’t explicit. This relates to not timeboxing. A more regular ‘review’ process wouldve caught that this was ongoing with no activity for a long time, including making blockers like MDF more explicit.
Not problem-focused enough
We should always ask/remind ourselves the questions “what problem are we solving? does it need solving? how do we solve it?”, just to make sure we keep on track
Meta on PM format
P.M. Could be done in a structured format a la:
- What happened timeline
- Where bad / where good / where lucky
- Steps taken to mitigate / avoid in future
See: