Fill in retro details in the table below. Type /date to quickly add the date and @mention participants to help them find the page.
Background
Our purpose is to reflect on our work over the past few months (what's working and what's not) and think proactively about changes and how we want to work together going forward.
Retrospective
What went well?
- Back in Nov we did a good job of reflecting and making positive change.
- We started testnet and collecting data from it. (What is our next iteration of this for our next 3 months?)
- Courage to say RSpace and Rholang are broken and work to address
- The last dev retreat paid off (ex the Vault solution)
- It's good we have a contract like REV Vault for users to work with. It helps reveal aspects of the platform to fix and/or optimize.
- Stand ups and what-I'm-doing is working
- We've heightened the "bus factor" by broadening the knowledge and depth of the team.
- We gained focus with the challenge of delivering the wallet and cost-accounting
- It also created a lot of pressure
- There wasn't enough work in those two areas for the team
If we could do it again, what would we do differently?
- Coordinate and ideally proactively plan for shifts of focus and responsibility
- More research "reconnaissance" in the codebase to identify what needs to change (ex reduce surprises of where the code is not able to support new features)
- Focus more on what the enduser needs to do and how he will do it
- Show-blocks and ListenAtName don't meet needs
- Develop Rholang more before trying to deliver Rholang contracts
- Look for opportunities to improve Rholang based on our current contracts and/or contracts we know are needed.
- Wish we would have focused more on networking and persistence ("only the plumbing") to deliver an earlier testnet
- We could better define MVP
- Before we automate, run manually several times to better understand what needs to be automated "We can't make platform API's right unless we are able to experience them as end users."
- Share learning between SRE team and other devs
- Build broader and deeper understanding for how Ethereum works to better understand what end users expect and/or are used to
- "If you haven't been scammed on Ehthereum, you haven't used it enough to understand what RChain users might experience."
- Spend more time gleaning from other projects
- Use ETH features and functionality as a framework for considering our features and functionalities
- Improve our estimation to more effectively communicate what we're doing and when it will be done.
- Separate architecture and development activities
- Requires more wholistic understanding of the platform
Ideas
- Kanban approach - where people could pick up work when they're ready to shift
- Focus on improving Rholang to improve usability
- Create personas to define "end users"'
- Implement "event bus" or block explorer
| Start doing | Stop doing | Keep doing |
|---|
- We should all use the platform as an end-user would do.
- Deepen Rholang knowledge on the team. "We should all know how to read and write Rholang."
- We should focus our decision-making for what to do and how to do it with user needs in mind.
- Use an understanding for how Ethereum works as a framework for
- Identify our "architect" team and improve our process for making architecture decisions.
- Hold one another accountable to estimates.
- Consider adopting a Kanban approach that would support people picking up tasks relevant to priority and interest. Consider how to do this so that we don't slow down and to ensure we stay on track to deliver and complete work.
- Do more reconnaissance in the codebase when starting new feature work to proactively look for issues.
- Adopt a focus "on the plumbing" to prioritize delivery of a minimum viable product before to adding improvements or additional complexity.
| - e.g., Scheduling meetings without a clear agenda
| - Continue to reflect every few months because we benefit from this.
|
Action items