Retrospective and Risk Assessment
Last Friday, the steering group held its first retrospective and risk assessment. The goal of this meeting was to analyze what's gone right and what's gone wrong so far throughout this lead-in period, and to try and forecast the major risks to avoid as Luke starts full-time development.
The discussion proceeded with each person identifying a potential risk, and brief discussion of each item.
Near Term Risks
- Luke is the only person full-time on Arachne: will the steering group have time to be sufficiently prepared for meaningful input?
- Is everyone clear on their roles in the project, and what's expected of them?
- The only expectation from the steering group is that they spend a couple hours every few weeks thinking about the project, and identify any screw-ups or mis-steps they can see. Additional levels of involvement are welcome but not necessary.
- Not only do we need to make sure existing roles are clear, but we need to make sure these stay clear as we ramp up community involvement, and let community members participate meaningfully without derailing forward progress or becoming chaotic.
- We could be either too ambitious, or not ambitious enough. We need to make sure we thread a fairly narrow corridor, and try to stay in the sweet spot that produces something genuinely new and useful, while not getting mired down in attempting to solve every problem in the world.
- We need to make sure that there is enough of a feedback loop to help Luke find that sweet spot. That feedback loop should be more rapid than just these bi-weekly sync-up meetings. What are some ways people who are interested can get involved in a more active way?
- There is a risk that we could go off on technical tangents instead
of solving the real/core problems that people have.
- Having a real client from day 1 (Apex) is a mitigation here.
- So far, we've been weighted a bit heavily towards up-front design
rather than iterating on an MVP.
- That's true, we will try to move more towards an iterative model once we're working full-time and the core modules are done. We definitely want to prefer an iterative, agile model of development.
- Luke might try to take on too much instead of delegating or seeking help.
- Steering group can try to help more, as they have time. Ideas for things that they could do to help Luke focus on core tasks: website/docs admin, shipping Kickstarter rewards. Anything else?
- We need to be careful not to get lost aiming too high and trying too much to "change the world" - we can do as much as we have time for, but need to remember that we're actually on the hook to deliver a web framework first.
- We need to get the foundations in place so we and others can use Arachne as a platform, from which to build the really cool/big stuff.
- As a counterpoint, let's be careful to actually aim high enough to do something meaningful; let's not be so focused on not flying into the sun that we stay stuck in the mud.
- What exactly are we afraid of being too ambitious about?
- Aiming too far ahead and designing for too much generality could slow development down. If we always choose the technical approach that is "50% more work, but better for the future…" that could put our schedule at risk.
- We might try to be more than a web framework before we even become a web framework. This increases risk in many ways, both from a schedule point of view and running the risk that we're not solving a real problem (or not solving it in the right way). We need to focus on building and iterating on a web framework first, and going from there.
- Luke's output is about to increase 15x as he goes full-time. Are we
ready for this?
- Questions will shrink in scope as time goes on; but these early questions are vitally important.
- Ever design decision will have an ADR for review.
- Code reviews from steering group are desirable but optional.
- Will soon be a public repo, can "crowdsource" code review.
Long Term Risks
- Open source project, especially those that aspire to have community involvement, risk an explosion of configurations, which can lead to lots of complexity.
- Backwards compatibility can be hard to maintain - how long do we
want to support a bad decision made early on?
- We can either make the choice to preserve or break backwards compatibility, but we should make these choices explicitly rather than letting them linger ambiguously.
- If we don't hit some critical mass for adoption, Luke will have to write everything, which will limit the amount/quality/utility of what Arachne (and it's modules) can offer.
- There will be other challenges we can't foresee. We need to make sure we deal with enough of the known problems that we have time for unknown and unforeseen issues.
- We risk having bad or out-of-date documentation. We need to remain vigilant and set up processes such that the docs closely match the code. It can be very frustrating to the community if the documentation is inadequate or out-of-sync.
- We need to make sure we stay organized, and will probably need a more powerful backlog and issue-management system than Trello in the long term.
- Even if we technically succeed, if we haven't succeeded socially, we will have failed. Arachne's community needs to be more than just an arrogant group of white dudes looking down their technical noses: we need to be welcoming, beginner-friendly and diverse.