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. Thanks, Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
