It’s rather bold of many of the commenters in this thread to assume they know the needs of Mozilla and their developers rather than those people themselves. GitHub makes complete sense, even if it doesn’t live up to some people’s desires for free software purity.
bamboo
It’s the most widely used platform that the most people are familiar with that they get to use likely for free. Newer projects of theirs are also hosted there. Why would you say it makes no sense?
Messaging apps are useless if the people you want to message don’t have the same one.
I’m not looking for guaranteed amplifiers. I’m looking for an outcome where anyone can find an amplifier if that’s what they want. No party should be required to amplify anyone else. It’s possible in this situation that someone could fail to find an amplifier, but I’d like to minimize that by just having many platforms with different incentives such that it is unlikely that they would all align against any one persons message.
The fediverse is built on this concept. Every instance can moderate their own users and communities, and choose which other instances to federate with. It’s unlikely that a specific user would be unable to find an instance that accommodates them, even if larger instances won’t. This contrasts with traditional social media where there is a sole for-profit entity that controls the entire network, able to completely remove people and ideas they don’t want.
I’m not necessarily in favor of “guaranteed amplification”, as you put it. Anyone is free to yell whatever ideas they have on a street corner. Barring some specific exceptions, that is free speech. I understand why a for-profit company might not want to amplify any means everything someone decides to spew out. We’ve designed an un-free capitalist system though where some people do have guaranteed amplifiers, and others do not. That’s the problem I’m more interested in solving. It’s not forcing any one company to be forced to amplify any specific idea, but rather to make sure that centralized authorities, be they governments, social media companies, etc can’t in unison stamp out those ideas. I think decentralized platforms like this are somewhat key to that goal, even with individual instances having full moderation and federation control.
Centralized for-profit companies policing speech doesn’t really solve free speech concerns. It doesn’t violate the US first amendment, but corporate-approved speech isn’t really free speech either. No person or organization is really suitable to be the arbiter of truth, but at the same time unmoderated misinformation presents its own problems.
Like the other guy said, it is indicator of new account age. I think there is a setting to turn it off if you dislike it.
We did that in the 90s. We gave ISPs billions to deploy fiber everywhere. It was mostly squandered and 25 years later most Americans still don’t have fiber access.
If congress passes a bill to improve internet infrastructure, it will be a 10s of billions hand out to ISPs that in turn will do little to nothing to actually improve their infrastructure. Just like when they did it in the 90s to get fiber to most Americans.
I have Verizon 5g with the ultra wideband service. Tower is on a light post on the street corner, speeds max out around 700/70 for me. 400/400 sounds like Fios which is a fiber service.
If I understand correctly it’s not intrinsic to the DOCSIS standards, it’s just how more or less every cable company chooses to allocate channels. Think like a cable company has 100 channels they may be able to use on a given line, and they choose to put 90 of them on download and 10 on upload (numbers are made up to convey idea). Now they have only a small amount of available upload bandwidth and lots of download, but they could have set it up to be 50/50 to have it be equal.
GitHub has an option when merging a PR to “squash and merge”. This option squashes all of the commits on the PR branch into a single commit and cherry-picks it on top of the base branch. We use this by default in our open source projects at work. Most people are not gonna go through the effort of making a well defined patch series the way it would be required for a Linux kernel contribution. Most changes aren’t that big though and so it doesn’t really matter. Send as many commits as you want in the PR, I’ll just review the diff as a whole and squash it when I’m done. Workflows should adapt to user preference, not the other way, and this is a good example of that.