On 10/03/2017 09:38 AM, Bryan Richter wrote:
> Hi all,

Howdy! Going to write some reactions in-line:

> [This will be my last "regular" update for a while, since my personal
> schedule is becoming correspondingly less regular.]
Incidentally, I'm getting a bit more regular myself and hope to figure
out a more regular flow for myself and the project soon.

> Well, September didn't go as well as planned. :/ I had it all blocked
> out to work on Snowdrift, and I got pretty much nowhere. There were a
> few contributing factors, but I'm not sure how much I will talk about
> them in this email. More pressing are the following news items.

Yay for pithiness! (not sarcastic)

> First, at 10am this morning (UTC+2) I ran the first crowdmatch
> event[1].  So far there is no outward evidence of this fact, because
> crowdmatch history isn't shown on the website! But I can fix that
> quickly. We'll manually send out some email notices later today, I
> hope, depending on team availability.

Yes, I will do it.

> Second, after much wringing of hands and wracking of brains, I find
> that I have to reset the code repo back to a deployable state. I
> regret to relate that that is a rather long time ago in the code
> history. To be more blunt, I'm going to take out Sass and pretty much
> everything else that isn't already on the live website.

I agree 100% with the goal of getting back to truly deployable,
iterative state. This has been one of the biggest sources of tension.
But it wasn't just the code side causing it. It was caused by the design
side doing a waterfall-style dump of design overhauls. We need to avoid
that type of working either forever or until we have the resources to
handle it.

That said, the imperfect, deployable, iterative situation ought not
require just losing all the work. We should accept that pre-alpha
iterative progress will look publicly messy. That means we do crap like
putting up a "intro video coming soon" notice where a video will go or
whatever else is the *fastest* possible acceptable-enough temporary state.

Putting up a temporary state that isn't easy to iterate and deploy
constantly is awful. A temporary state we can fix and deploy over in
minutes/hours is fine, even if it sometimes is up for some days.

I am fine enough with taking current master, forking it to a new branch
(so it isn't just lost in the git history) (or at least a label) and
returning to the last-deployed version so that we can start deploying
from there and iterate going forward. But I'm also fine with deploying
an imperfect master that may have issues that we then iterate on fixing.

Perhaps when we go back to cherry-picking the updates or whatever, you
can clearly express what is or isn't okay about various things like the
Sass situation.

> Practically, this means a forced update to master will be coming soon.
> In human terms, it means I'm a terrible person. :( Ok, so that's
> hyperbole, but I definitely want to say that a different programmer --
> a better one, for instance -- would be able to work with the current
> version of master. But the version of Snowdrift that *I* can work
> on has to be one that can be deployed on the daily, and it has to
> be implemented more incrementally than what I allowed to happen in
> the last few months.  So, I definitely feel bad about this, but I need
> to do it.

Sometimes regret is good. Let's be forward looking from here. I'm about
to give a talk about SeaGL doing a whirlwind run-through of a
post-delayum (let me know if you know a better or more authentic Latin
term). I'm going to describe the lessons-learned or
lessons-being-discovered-still not as a pitch for Snowdrift but as
perspective for others about challenges and mistakes in a project like this.

We can't work with a situation where only the greatest coder could make
sense of it. We need a situation that is good for someone at least of
your caliber. Don't feel bad about that.

But in the spirit of non-perfectionism, please focus on blocking
development that adds tension going forward more than on removing all
the existing tension. That said, I can now deal with the stress and
tension of replying to you and thinking about this situation because I
got my own tasks and situation in order.

We NEED a codebase in a state that motivates YOU to work on it and bring
in other volunteers. It doesn't need perfection, but it's worth
investing in the level of cleaning that lets you be in a good state for
working and better progress.
> Once the reset is done, I can add the crowdmatch history as I
> mentioned above, and then hopefully the project team can agree on
> smaller, incremental changes that move us forward.

We should do all the smaller, incremental changes first through written
specs/requirements that both design and coding folks can agree on.

Aside from that, all manner of typo-fixes, cosmetic tweaks, bug-fixes
etc. are always welcome.

> The final thing I've realized from this month's slog is that Yesod has
> got to go. This, again, is as much a personal decision as a technical
> one: I clearly am not within Yesod's target market. But it's me or
> Yesod, so do-ocratically speaking, Yesod is on its way out.

Okay, this is huge. As much as I respect Yesod's goals, it's always been
a pain point, and I can't work with it myself as a novice. But I fear
that this is perfectionism again. Removing Yesod is not getting us to
iteration, it's a massive waterfall change. But if you are concluded
that it's the right thing to do, I don't care to discuss it further.

Should we move to Snap? What do you have in mind? Can you start a new
thread about choosing the right framework for us?

I'd personally rather see us just move forward with Yesod if it were
truly workable, but I don't want to fall into sunk-cost fallacy. Just
beware the grass-is-greener-other-side-of-fence issue.

> But that won't happen just yet! I am going to simply abandon the path I
> was attempting (namely, abstracting over Web.Stripe.stripe as a field
> in the App datatype) and move forward with necessary functionality on
> the website. Fast and loose. Less perfection[2], in order
> to hit a feature milestone.
> That's all for now. Thanks for reading. Feedback appreciated.

In summary on my feedback: Let's not try to get to a "clean state" that
is optimal to build from (not now anyway), that's perfectionism. But
let's INDEED get to a state where you feel capable of making sense of
each iterative patch so that everything we do going *forward* is making
sense and feeling good.

I'd like to see all the work that's been done on master get put back in
/ cherry-picked, with the idea of deploying continually through that
cherry-picking process. Consider a "deploy" branch that works its way
toward catching up with master? Or otherwise consider reaching out to
the contributors to master and ask them to pick out their work and send
new PRs (squashing in a human way rather than git and skipping
intermediate issues)?

Finally, do you have opinions about the best place to publish
requirements/specs docs? And maybe you can start some things by
publishing the first of those based on what you think each module/page
needs? I think those will be KEY to everything going forward.


Attachment: signature.asc
Description: OpenPGP digital signature

Dev mailing list

Reply via email to