Something a little more concrete

[Trevor Schrock]

Last week a small number of the design crew met up encountered the probability field of "what do we have, what goes where, what are the constraints, etc etc."  In an effort to collapse the wave, we took Wendy's stab at a wall matrix, made a few changes, slapped some features into it and called it a first plan.  It may be ambitious, but it's also the first glimpse of a design incorporating the featureset we've come up with so far.

So I broke out my trusty MS Paint skills (I don't have better tools) and transcribed it thus.  It illustrates what we've got in mind.  Each feature could stand more explanation on the vision, which is a next step.

So what needs doing next:

1. Finalize this bsns.  Call out any changes / suggestions to this sketch.  This may include scaling it back, though I'm not suggesting it. This all needs to happen this week, for real.

2. Use the final sketch to gauge parts and materials, and figure out where we can scale back if we must.

3. Engineer a method to keep the walls standing up.  This may be a design constraint that changes this design, but we had to start somewhere.  I want to see a concrete idea, not hypothetical or "we'll figure it out when we get there."  Cuz we're there.

4. Decide what else goes.  It's been suggested the the tower might stand to be sacrificed in the name of time and cost.  It's a thought.  That decision needs to be made this week as well, and will inform structural stability.

Then, how I recommend we go forward:

1.  Each feature needs a subteam.  Someone takes point on the design and implementation of that thing, and gathers helpers.  Soon as the sketch is done this must be done immediately.

2. Each feature team gauges design and cost of implementation and time to completion, now that the size and boundary constraints are figured out.

3.  Each feature team makes an honest assessment of whether that feature is feasible to complete by ship.  This needs to be planned, and cannot take much time.

4.  Each feature team then gets going on build.  They can work relatively independently, and if we have a lot of people we can parallelize the shit out of the effort.

I'm open to other methods of operation, but this seems to get us on the path.

trev

--
Trevor Schrock
spac...@gmail.com