Mastodawn

There's a new piece explaining "The Slow Collapse of #MkDocs": "How personality clashes, an absent founder, and a controversial redesign fractured one of Python's most popular projects."

https://fpgmaas.com/blog/collapse-of-mkdocs/

Well, that says a lot. But what's really interesting is that MkDocs 2.x is being developed as part of the "encode" organization. That's great, right? The people who gave us such great libraries as #httpx?

Well, turns out no, not at all. It looks like encode has already crumbled and became immensely toxic.

httpx is not allowing bug reports anymore, apparently because of "absurdly skewed gender representation", whatever that means.

https://web.archive.org/web/20260228113715/https://github.com/encode/httpx/discussions/3784

That also explained why starlette moved out of the organization a while back:

https://web.archive.org/web/20260323042730/https://github.com/Kludex/starlette/issues/3180

There's a great rot in #OpenSource.

#FreeSoftware #Python

The Slow Collapse of MkDocs

How personality clashes, an absent founder, and a controversial redesign fractured one of Python's most popular projects.

Show thread

i’m Mi 22h ago

@mgorny The “absurdly skewed gender representation” sounds reasonable. That must have aggravated there with the exodus of the community from GitHub. Nobody can comment there without an account. This is similar to calling GitHub Issues & Discussions to be full of spam, which they are. Whether bug tracking discussion should happen in the open is an open point in general I think. What should however happen is accepting bug reports *somehow* and publishing details of known bugs *somehow*. And uh wasn’t MkDocs supposed to be a SSG

I wish we could somehow transition into a distributed model, perhaps dropping Git, of just shuffling patches and patch series around on individuals’ websites and devising some ways of maintaining that at scale (perhaps darcs/pijul remedy some of the same pain points, but they still keep the repository as a whole and not as subdirectories iirc), and also perhaps considering bug report tickets to be preserved documentation kept as files in a distributed manner.

Show thread

Έλλεν Εμίλια Ά.ζ.21h ago

@mi @mgorny Actually, one could just continue to use git and distribute patches via other ways supported by git.

In a sense, git actually is more flexible (e.g. in the supported transport mechanisms and patch communication workflows) than e.g. pijul in regards to that.

On the other hand, with smaller-scale git forges becoming more common, there isn't really a need to return to much older ways, "just" forge federation might be sufficient (and many work on that rn).

Show thread

i’m Mi 21h ago

@fogti @mgorny this is good thinking, but Git 1) makes it problematic to work on a single directory when your project gets merged/turned into a monorepo by a current authoritative owner and 2) every non-authoritative patches application is going to result in rewrites — we only can have a hell of revert commits and cherry-pick commits. Git also does allow some things but its philosophy makes us reluctant to do them all the time

Show thread

Έλλεν Εμίλια Ά.ζ.21h ago

@mi (1) is something I overlooked. I accept it's a problem, in particular because I also know that managed dozens of small single-purpose repos isn't that nice to work with, either.

(2) is something one has to work with anyways, pull requests run into that problem regularly, as soon as they lay around long enough.

Something which I'd like to add is that basically no version-control system I've seen yet tries to make it easier to rebase "mechanical commits/patches".

Show thread

Έλλεν Εμίλια Ά.ζ.

@mi Whereby "mechanical commits" are those that are basically just one or two command line invocations of `sed`, `awk` or such nested in `find` to iterate over the entire repository for systematic search-and-replace during refactoring. One might think of them as "migrations" for code instead of data (to summarize refactorings).