Today I learned about why Mastodon don’t have quote toots:
This links to a blog post as well as two GitHub issues:
These links can be carefully studied to analyse, what should go into a design rationale (and how to explain it).
1 Like
I’m wondering, for projects that use C4 such as Ecko, will these projects have the same level of care that goes into the design as a project with BDFL?
I’m not sure I’m following.
I for myself have a reputation of being very detailed oriented. Sometimes so much so that one could think I loosed the target altogether. C4 reads like a spec (I have spotted some vague elements).
Since we are dealing with humans, it could be that the description has to be a bit more fuzzier.
Ah, apologies. There were a lot of buzzwords in my last post. What I meant was, for projects that are more community-run (open governance?), rather than having a BDFL at the helm making design decisions, are those community projects able to make hard decisions such as leaving out quote toots? I feel like it’ll become a very “design by committee” situation where as much functionality as possible is included.
2 Likes
Ah, that’s a good question.
Well, in my view, a community ideally is diverse enough to support different roles.
I’d assume, that those with expertise in a given area are delegated the authority and earned enough trust to make a call in their area.
In Sociocracy this would be called a domain:
Same with Holacracy:
https://blog.holacracy.org/understanding-domains-54af3ba955f4
It’s for the community to decide how they want to be governed.
Specific to C4 methodology… the purpose of the methodology is to make PR’s more easily adopted into the software, which might lead to oversight on the deeper rationale of having a certain feature, which on the surface might make perfect sense.