Maiyannah BishopI continue to be amused by people who want to discuss changes to a social network on anything but that social network.
Really starting to appreciate my old boss at IBM's motto of "dogfood your shit or gtfo" If you aren't going to use your own stuff, how can you expect anyone else to?
Hallå Kitteh@maiyannah Dogfooding is great, but what if the use case of collaboratively creating software is different than the use case for a social network?
Paul Free (14 Ⓐ, ♥, europe)@maiyannah @clacke
then you choose a federated software suiting this case.
'Dogfooding' doesn't need to mean choosing a mircoblog, when a forum might be better suited.
And it's exisiting. #hubzilla.
There are still some federation issues, but at least it's build to federate. means more ppl using impovmet comes.
#discourse was never build for that usecase.
being #fediverse is 'dogfooding'
then you choose a federated software suiting this case.
'Dogfooding' doesn't need to mean choosing a mircoblog, when a forum might be better suited.
And it's exisiting. #hubzilla.
There are still some federation issues, but at least it's build to federate. means more ppl using impovmet comes.
#discourse was never build for that usecase.
being #fediverse is 'dogfooding'
All of the people who would be affected by any proposed change to the social networking standards are _right here_ talking on this thing _right now_. Any alternative is just going to be a subset of those people at best. If you want to discuss changes I'm going to consider at all, discuss them here, or don't bother.
sungo@maiyannah But they might get involved in the conversation before there's a common front by the admins/devs! They might have an opinion before the admins/devs are ready to hand down an edict! *eye rolling so hard they stick*
@maiyannah I remember when a decision to create an admin-only instance and to use Discourse heavily happened a couple months ago. It was entirely about controlling the narrative. There was a distinct desire for a lack of transparency about the ongoing operations of instances.
Well, and making sure the messages didn't propagate to the GS side of the fediverse because god help us if the OLD TIMERS had thoughts.
Well, and making sure the messages didn't propagate to the GS side of the fediverse because god help us if the OLD TIMERS had thoughts.
@sungo By splitting the community like that they empower a few at the cost of the many. It's literally the oppression dynamic. I reject it.
@maiyannah Total agreement. That's when I decided to change software and opt out of their bullshit using the most obvious means I could.
@sungo A responsibility falls on any ethical project manager to reject attempts to try to empower small segments of the community in such a way. They need to be the safeguard against a few people imposing their will on the many.
@maiyannah I think that was the entire point. Huge instances didn't know what to do with gauging the needs of 100k users. So they cut them out of the discussion.
At this point, I firmly believe that admins of any type of instance, Mastodon or PA or GS or Hubzilla or wtf, need to cap their user count to something fairly low. Or lock down registration and manually vet every entrant (mostly because that's fucking annoying and won't scale). It's cool to say "I run a thing that has 100k users" but it is something else entirely to manage it, even with help.
At this point, I firmly believe that admins of any type of instance, Mastodon or PA or GS or Hubzilla or wtf, need to cap their user count to something fairly low. Or lock down registration and manually vet every entrant (mostly because that's fucking annoying and won't scale). It's cool to say "I run a thing that has 100k users" but it is something else entirely to manage it, even with help.
@sungo You either need to know how to deal with this - it's not an unsolvable problem after all - or yeah, you need to stay smaller.
But cutting people out of the development process of the software, whether it be by a hard blocking means or a soft blocking means, is how you end up with oppressive software in the truest sense. It's the tyranny of the minority.
But cutting people out of the development process of the software, whether it be by a hard blocking means or a soft blocking means, is how you end up with oppressive software in the truest sense. It's the tyranny of the minority.
@maiyannah Fast moving specialist software projects always become a steamroller of developer bias. God knows I've run a few. And when you've got a ticket queue that's 700 deep going back 6 months, who the fuck knows what's going on.
@sungo Sometimes I think the REASON Mastodon moves fast is because it slows down it would actually have to stop and address many longstanding bugbears like usergroups.
@maiyannah I've seen this a lot in quite a few projects. Momentum lies in cool new stuff or super easy bugs. Longstanding complicated issues and boring bugs get sidelined because they're not sexy. I had to completely rewrite a project at the last job because of it. Got so deep in the shiny that I coded us into an inflexible box. And yeah, "I", which you can totes take to mean that there was not enough communication with the other devs or customers.
@sungo There's a lot any software project's users are going to want out of it and you can't do everything - priorities have to be made. This is why it's even more important to include as many people as you can in those discussion - that way, a reasonable consensus can be made about what items are priorities and which are not.
Nolan Lawson@maiyannah @sungo Just for context, I'm the one who spearheaded the admin-only instance (which is basically dead now BTW). My original goals were:
- move meta-talk off of the timeline; it was consuming all discussion
- try to get admins to at least talk to each other
- originally it was admin-only, but I relaxed this and even added a non-admin as an admin (insert Bertrand Russell reference) to avoid any appearance of elitist cabal
@maiyannah @sungo Yep that was a failure. My idea of a U.N. for admins was too ambitious.
@sungo @maiyannah Discourse forum came after, and I wasn't involved with that. I suspect it was a reaction to Matrix chat (@chr's project) and admins.town (my and @hugo's project). Same goals, but when it became clear Discourse had more momentum I stepped back from admins.town.
@nolan @maiyannah while I get that meta-talk was insane back then, consuming all discussion was actually important because folks were defining the culture of the system. Folks could always mute you all as I did from time to time. When the admins disappeared, the users lost their voice and their say in the culture you all were creating.
@sungo @nolan Yeah, this is the side-effect of having an inclusive development process. The "solution" to it made the development process more exclusive. I'm not a fan.
This is why I make a point of having postActiv discussions largely right here, and if there is discussion on the tracker, being sure to mention it here to try to solicit maximal feedback. I want everyone to have a say. That is of supreme importance to me.
This is why I make a point of having postActiv discussions largely right here, and if there is discussion on the tracker, being sure to mention it here to try to solicit maximal feedback. I want everyone to have a say. That is of supreme importance to me.
@sungo @maiyannah Discourse forum is open; do you see this as a better alternative w.r.t inclusiveness? I agree my idea of "admins only" instance was too secret cabal-y.
@maiyannah @sungo I dunno, I kinda feel like it's too ephemeral here, and lack of searchability makes it hard to keep a paper trail (dunno if postActiv's UI is more amenable to this). I doubt Twitter's devs use Twitter to discuss dev stuff, so to me it seems fine to use some other communication software for dev/community talk. Already a lot of it is on GitHub.
@sungo @maiyannah My point was that if you're building a communication platform you don't have to use that platform for every kind of communication. E.g. I'm pretty sure Mozilla Thunderbird devs use IRC to chat and don't feel like they need to use email for everything. But your points elsewhere about dogfooding are well-taken. :)
@nolan @maiyannah But Thunderbird isn't an application for real-time chat. If you're a thunderbird dev and you're not using thunderbird to send email, you're doing it wrong. If you're an IRC dev and you're not using IRC, you're doing it wrong. you are asking your users to find all your problems for you and, then, because you're not using it that way, you end up with responses like "that's not an issue I have. Ticket closed" which has happened. FFS, the "make columns wider" conversation went exactly like that. "I like the column size. Issue closed".
@sungo @maiyannah Kinda feels like we're talking about a few different things here, but I think the project devs use Mastodon plenty and that's not so much the issue. I happen to agree with Eugen about the column size thing but for the general issue you raise I think the situation could maybe be improved by a foundation/governance model which is a topic I've broached: https://discourse.joinmastodon.org/t/mastodon-project-governance/215
@maiyannah @sungo Same reason Discourse devs don't use Discourse for chat, Matrix devs don't use Matrix for email… I mean I get your points about dogfooding but I just really think a platform can be optimized for non-programmers to talk about non-programmer things (e.g. memes! 😁) and programmers don't need to use it to discuss their programming.
gled => Moved@nolan @maiyannah @sungo
I still don't get why github cannot be used to discuss dev subjects...
You can use the web interface, you can reply by email to issues, what else is needed ?
@nolan @maiyannah You know how you handle something like column sizing? You make it configurable and make the default something the devs think is ok. Then, if I as the user or admin want something terrible, I can have it but by default the system is how you think it should be. It's all about choice and user/admin freedom.
@sungo @maiyannah Sure but every additional feature makes it harder to maintain the project. I've run into this in literally every OSS project I've been involved in that reached a certain level of popularity. Every user has their pet/idiosyncratic feature request, and if you say yes to every one, then the project quickly looks like Homer's car with 100 bells and whistles and configuration options. Also folks are always free to fork and modify.
@maiyannah @sungo If I understand what you two are saying, it sounds like there are two issues here: 1) folks feel uncomfortable with Eugen making unilateral decisions, and 2) Mastodon has a hugely outsized influence on the fediverse because it's so popular. #1 feels to me like it's solvable with governance, #2 seems solvable with standards and compat effort (similar to browsers, e.g. when one browser has huge market share and thus influence on web ecosystem).
@maiyannah @sungo Hm yeah this is a problem I know well from the browser space (try convincing Chrome they need to change their impl when they have 60% market share, or IE6 back when it had 90% 😉).
It seems to me that having a common test suite and making it as part of the CI testing for all OStatus projects would be a big step forward. Browsers are doing this now but should have done it decades ago.
@sungo @maiyannah If I've misrepresented please let me know; I am earnestly trying to understand. :)
@nolan @maiyannah #2 is simply not true. Ya'll would like to think you have an outsized influence on the fediverse but you don't. There's not a big effort to make GS/pA support all of Mastodon's non-standard stuff. We have standards. They're not the best standards on earth but there are standards that are followed by the rest of the fediverse. Mastodon specifically breaks or doesn't implement a lot of them.
@sungo @maiyannah Didn't mean any offense, but based on https://radar.amberstone.digital/chart/fediverse I figured Mastodon's influence is very large.
@nolan @maiyannah I totally understand that issue which is why, typically, one creates a plugin system for something like Mastodon. Then admins can add features or whatever without modifying the core code. You give the plugins enough hooks to do all sorts of craziness.
As far as forking and modifying is concerned, back in the thread someplace is a ticket that expresses that using one mastodon instance should be the same as using all the others. That making changes to the core experience is unsupported and frowned upon.
It's also kinda bullshit on a codebase like Mastodon because it moves so fast. I used to maintain a patchset to add features but the core breaking-changed every fucking day and every release required a complete rewrite.
As far as forking and modifying is concerned, back in the thread someplace is a ticket that expresses that using one mastodon instance should be the same as using all the others. That making changes to the core experience is unsupported and frowned upon.
It's also kinda bullshit on a codebase like Mastodon because it moves so fast. I used to maintain a patchset to add features but the core breaking-changed every fucking day and every release required a complete rewrite.
@maiyannah @sungo Yeah Mastodon changes very very fast and I agree backwards compat is not always taken into account. custom.scss was pretty painful the last few releases.
@nolan @maiyannah There is a large difference between governance and development. You can have as many rules as you want but someone can still commit code that disagrees. I've seen time and again how you can bury changes like that in a large break-fix patch. Mastodon is full of PRs and commits that fix 20 issues all at once in one big diff. With how fast Mastodon development moves, no governance can fully control it.
@maiyannah @sungo Good to know, thanks!
@nolan @maiyannah And talking about the system on the system will show you the flaws. Eat your own dogfood. You'll start to see that not supporting groups is ridiculous, for instance. Lack of searchability is a problem. etc etc. "This system is not good for talking to lots of people with multiple threads" should tell you that there is a problem with your system designed to talk to lots of people across multiple threads.
@nolan @maiyannah @sungo I kind of second Maiyannah there, implementing groups and using that would be much more efficient imho. We are admin on mastodon, and as an example, I'm allergic to discourse so i'll probably not be active there... Regarding dev questions, there's already GH...
covfefe@sungo @gled @nolan @maiyannah This one I really don't understand: https://github.com/tootsuite/mastodon/issues/1446#issuecomment-293142234