David Sterry @weex@c4.social

Polls options are now displayed in random order on c4.social for scientific validity purposes however this effectively ruins the low-effort joke option.

I guess the question is what's more important, jokes or scientific rigor? Should there be a randomize-options checkbox?

Next visualization of #Fediverse source code: GoToSocial!

#foss #dev #golang #gotosocial

https://peertube.co.uk/videos/watch/d14d45c5-33ce-4aa5-937e-1891e48ebe87

Next in a series of visualizations of #fediverse source code. Here's #diaspora!

#foss #dev

https://peertube.co.uk/videos/watch/50cf87f2-0e58-4e5c-a947-c43e53d782af

I've noticed in using Mastodon that I'd rather start with a toots-only view (i.e. no boosts) and then want to check the boosts feed. For that matter, I wish a link to Boosts were visible on the timeline screens. Anyone else use it this way, where they only want to see boosts some of the time?

Do not track? Yes. Very good.

Now give me Do not app!

/I don't want the app.
//I knew you had one
///seriously, you won't even set a cookie?

First of a series of visualizations of #fediverse source code. Here's #mastodon!

https://peertube.co.uk/videos/watch/38934036-017a-4ab4-93cb-8cfceb81b2f0

Isn't it funny how often things that should be simple can get flipped and become anything but?

Here we have a simple faucet with hot and cold water, but in the common case that it takes a while for hot water to appear, one wonders which way for cold?

Is it up because the handle should go in the direction of the blue dot or down so that the blue dot is brought into some position relative to the base?

streaming a hintjens talk, coding more on web of trust, but mostly hanging out

https://www.twitch.tv/aptact

When compared with centralized services, federated social networking has brought you _______ conversations which are of _______ quality.

#fediverse #social

Had a really nice hangout this morning with folks from @ohn and it was really fun! It's great to meet new people and realize that maybe I'm making new friends.

It also got me thinking about richness of social interaction and humanity where at one extreme we operate in text and emojis while at the other end we can spend time together in the same physical space with no tech required.

In this light, Open Hospitality Network (https://openhospitality.network/) is taking on perhaps the hardest kind of technology project where people use this tech intentionally to connect with real people.

What if the social platforms we use, instead of suggesting we follow celebrities to increase engagement, saw that we're spending an unhealthy amount of time in a low-quality medium and suggested we pick up the phone or arrange a video chat or meetup?

In the interest of furthering standards discussion and development on the Fediverse, I'm proposing a change to SocialHub.

https://socialhub.activitypub.rocks/t/move-fep-under-a-new-standards-category/2039

Two books for the C4Social library!

5yo intermittent testing problem

https://github.com/c4social/diaspora/issues/39

I lik this post from @agateblue@mastodon.technology in the ActivityPub library titled "Getting our hands dirty", which is about project governance, the problem that sent me off on the search that found C4 and spawned C4Social.
https://library.activitypub.dev/shelves/web-2.html

C4Social was created to solve two problems (not enough developers on the fediverse and slow development pace) with the hypothesis that the Collaborative Code Construction Contract (C4) offered a compelling solution.

Core to the C4 is that code is merged not on its content but on the problem it addresses. So from the first moments, feeding the process meant finding code which addresses valid problems. Upstream is therefore the first place you look… and there we found and merged 35 PRs between the two forks.

As people joined, some concerns were raised with this practice:

* First, that such PRs might be work-in-progress and that by merging code before upstream maintainers, we would be taking on additional risk on a patch which may still receive comments and changes.
* Second, if more changes are made and then the code is then merged upstream, we may have conflicts to resolve which might make merging not worth the extra maintenance.
* Third, the author of the patch may be surprised that their code is used on a fork.

Today, there are another dozen or so PRs to look at so this is a good time throw a question out there. Are there other concerns that should be raised about this practice? If you make PRs, would you want to be pinged by a fork?