I’m concerned about bikeshedding (it would make orders of magnitude more difference to see commits that actually implement designs), but if engaging on this is part of encouraging engagement rather than costing time that could have gone toward implementation, so be it. But there’s also perfect-enemy-of-good…
Anyway, FWIW, I’ve found the squares to be extra visual noise, but I didn’t feel it was worth bringing up.
I’d suggest this might be where time-lines might help. Also A/B or outside feedback. The details at this point are getting to where it’s trivial to change our minds later, even after implementation and going live with some good-enough version.
I don’t want to discourage the exchange if it’s overall positive, but I do worry that the energy could be better spent elsewhere.
You da boss, but for what it’s worth, I downloaded the image, opened in gimp, used the paint bucket to white out the squares and the same trick to give the Xs the color the squares used to have. No time at all
Implementing… Anything, on the other hand, has proven to be much harder, and I’m not sure if people are as likely to suggest after-the-fact changes.
But I do engage in perfectionism, and tend to care too much about being misunderstood, so you’re right, energy could be spent elsewhere. Not sure it would be, though. Motivation is a fickle thing, and it’s more common to respond to something than to be proactive
Not really, but I otherwise appreciate the rest of your reply.
I think such iteration is super likely, and I want to encourage it. I think if we get stuff implemented, it will be easier for people to show up and tweak it. I think the more perfect something seems at first, the less people will even consider whether it could be any other way. I think we should err toward putting out stuff sooner and iterating in general. The only qualifications to that are when iteration is costly for development or when we actually think the less-ideal initial version could be harmful.
While I understand the concern, and definitely thought similarly of @Adroit creating a new mock-up regarding time spent, I’m glad to hear (as I’d hoped) it was a pretty rush job.
Regarding the larger commentary, I think that any positive engagement with the project helps me in terms of motivation to do things on other parts of the project.
In this case, I saw a request for commentary on a feature that had been requested in a direct conversation. There was a fairly clear direction, but not full consensus on a decision. The design struck enough on a particular nerve that I wanted to mention it, especially to mirror the immediate felt response argument rather than A/B testing or some other UX metric.
Note: Footnotes make up a sort of parallel topic; reading them all together at the end works well.[1]
When I first joined the project, shortly after @david stepped away to contribute money instead of time, it was Aaron’s project, where he had the final say in everything except code. In operation, he usually wouldn’t give that final say until we had consensus, so our governance was some combination of benevolent dictatorship and consensus.[2]
Over time, we’ve moved away from both of those things.[3] Instead, we’ve moved towards Sociocracy/Holacracy style decision-making. Different roles have authority over relevant domains, and the people filling those roles are the arbiters of those domains, although they still take other people’s input into consideration.
Transitioning away from a benevolent dictatorship can be hard while the former dictator remains with the project. For a while, it was hard for Aaron to make suggestions and have them be taken as just that (rather than directions).
Today, I think we’ve made the transition pretty successfully[4]. Say @wolftune and @mray or @msiep really fundamentally disagreed on a design decision. I don’t think we’re quite at the point where Aaron would be overruled, but I don’t think he’d be able to insist on his way, either. Not without completely breaking the project apart and setting out on his own, anyway. Fortunately, we’re all pretty aligned and haven’t needed to put this to the test[5]
So, why mostly true? Because there are still some gaps where we don’t have roles well mapped out — for example, governance functions like onboarding — and in those places, Aaron still fills the gaps.[6] Those are shrinking, though, and they’re small enough at this point that I think the project would lose momentum, not cease to exist, if Aaron left.
Or as you go. I did make them footnotes, after all. ↩︎
This lead to a lot of very-well-thought-out decisions, and also perfectionism that slowed our progress. ↩︎
In line with Aaron’s explicit desire for this project not to be his alone, and our need to actually get launched instead of deliberating for years. ↩︎
On both criteria; while we’re still moving slower than we’d like today, it’s more a result of manpower shortage. Decisions are no longer the bottleneck — you can see this by taking a look at the number of open issues in the design repo compared to the code repo. ↩︎
I suspect the end result would be the designer moving away from the project. But this is exactly how {Socio,Hola}cracy is supposed to work, where the lead [link] doesn’t have the ability to micromanage, only replace a role-filler if they’re fundamentally misaligned. ↩︎
But again, this is also how {Socio,Hola}cracy is supposed to work, although it’s the long-term goal for the lead [link] to create new roles so they can delegate instead of holding the line themselves. ↩︎
To be clear, in the past there was never a benevolent-dictator explicit in any way. Any tensions were all around how to make decisions and the pain that came from not having an adequate process. I never pulled some benevolent-dictator “sorry, I’m deciding” overruling of anyone. Instead, we sunk a lot of time into debating disagreements and failing to come to decision points.
Anyway, I really meant my question directly not rhetorically. I was inviting @Adroit to consider whether this engagement is adding to overall positive direction (as @Salt suggests, and I don’t deny is possible) or if he could maybe get back to more implementation (which is the real bottleneck right now). I don’t want anyone to feel discouraged or to worry about push-back for engaging in not-top-priority ways. I do think erring toward open engagement is the right way to go.
Indeed, there was never a formal organizational structure. I would describe it as you being a benevolent dictator, but being uncomfortable doing the overruling thing, so you wouldn’t make the decision until we had consensus. “Benevolent dictatorship delegated to consensus”, if you will.
At the start of the holacracy phase, I’d say it was still “benevolent dictatorship delegated to holacracy” with a lot of “…but check with Aaron first” feeling. My point was that over time we’ve moved away from that — in part thanks to your encouragement — to where people actually feel comfortable driving the process themselves (or at least that’s how it seems to me).
edit:
I know, I just felt like it would be interesting to provide some context
And to get even more “meta”, last night I was enjoying some wine[1], so I wouldn’t have done anything but.[2]
Bikeshedding says the time would have been better spent elsewhere, assuming that “elsewhere” is just as doable. That assumption wasn’t true in this particular case (especially given that “real contributions” involve dealing with GitLab, etc) so the opportunity cost doesn’t apply.
Yup, and what you’re referring to is exactly what I meant. I would be participating even if it was run BDFL-style, so that was no slight against anyone; I’m actually very impressed with the speed and efforts made to relinquish authority and make it a co-op. Not sure I’d be quite as virtuous haha
Even more meta: The problem with that approach is you didn’t re-state the context in each footnote, so you have to scroll back up and down and up and down to see what they’re talking about anyway.
In fact I replied thinking this thread was a PM, not a public topic, and was surprised when others chimed in! ↩︎
Speaking of rush job, you can tell, because if you look closely, I left some red antialiasing-artifacts… oops! I actually did try to do it with a css tweak at first, but couldn’t find the page on the static site. ↩︎
The footnotes thing is meta on this meta topic! Ideally made it’s own topic, but whatever.
FWIW, on the bdfl idea, at the VERY first Snowdrift presentation ever (my first ever tech presentation) to the local LUG in Ann Arbor, MI in early 2013, I already made it explicit that the whole point was to create a platform for democratic empowerment and that I understood conflict-of-interest and “easier-to-avoid-temptation-than-to-resist-it” and was purposely designing things so that I couldn’t have some dictatorial power. Audio was recorded for posterity: https://wiki.snowdrift.coop/about/presentations#aarons-first-public-presentation
So, anyway, to have a 3rd meta tangent in this one post: I guess it’s not as bad for meta topics to themselves stretch to include more-meta than most other topics?
