wiki.dlang.org: How about replacing MediaWiki with a Git repo?

[Mindy Batek (0xEAB)]

On Tuesday, 4 August 2026 at 11:28:52 UTC, Vladimir Panteleev 
wrote:
> Before I address the specific points, I would like to mention 
> that a lot of personal time and effort has been invested into 
> keeping the current wiki running and mostly clean, and I 
> continue to do my best to maintain it to the best of my 
> ability. I thus feel like the tone of your message could have 
> been a bit more considerate; that said, I am going to assume 
> good faith going forward.

Hi Vladimir,

You’ve got a very good point here.

I’m sometimes quite bad at phrasing my thoughts appropriately. 
Shifting the blame or not, it can be hard at times to think 
clearly when there’s something bugging you (maybe even after an 
exhausting day at work). Writing things has proven useful to get 
them off your mind but comes with the downside of the lack of 
filtering.

As unfortunate that may be, I can assure you I’m acting in good 
faith only.
After all, If I weren’t interested in D’s success, I wouldn’t be 
here. And I wouldn’t bother people about the things I consider 
candidates for improvement.

I’m sorry.

> The main thing to understand is that if we move the content to 
> Git + static site generator, it will no longer be a wiki. The 
> defining property of a wiki is that *anyone* can edit it - even 
> if they don't have an account on some other platform, and even 
> if they live in a country where creating a GitHub account is 
> not possible.

I’m not sure whether it’s fair to consider GitHub as "some other 
platform" in our use case.
(Does GitHub currently discriminate users because of their 
location?)

The current captcha is also reducing the user base that has 
*viewing* access to the current wiki.

> This also defines the moderation model: if a bad actor engages; 
> we restore the desired state by rolling back bad edits after 
> the fact, rather than gate-keeping every edit before it lands.

Funfact: You might want to look up the German Wikipedia’s sifting 
feature („Sichtung“). The German Wikipedia does actually 
gate-keep contributions from new users. (Does that make it no 
longer a true wiki?)

> We already have a static website backed by a Git repository: 
> dlang.org. The wiki exists specifically to be the complementary 
> thing: a place for community contributions which anyone can 
> edit.

There’s a difference between the official website — a digital 
store window, if you will — and a knowledge base.

To clarify:
I’m not trying to raise the bar for knowledge-base contributions.


> Thanks for flagging that page. For context, this was one extant 
> case out of many hundreds: shortly after installing the new 
> CAPTCHA, we did a mass cleanup (with help from other users from 
> the community Discord, IIRC). That one, we missed.

I found it through a quick glimpse at 
<https://wiki.dlang.org/Special:AllPages>. There was something to 
it that really caught my eye… Hence I was quite surprised how 
that could have gone unnoticed. But to be fair, shit happens ^^

> I should note that, all things considered, our wiki is doing 
> much better in this regard than most other wikis out there 
> following recent developments and increases in spam attacks; 
> over the past few years, many projects' community wikis have 
> been either locked down much more drastically (such as 
> requiring accounts to be approved by a moderator after 
> displaying some proof of intent, humanity, or identity), or 
> have much bigger spam problems. I'm quite happy that we have 
> figured out a solution that did not require such drastic 
> compromises.

Credit where credit is due. Well done.

> Sorry for the trouble. It is indeed custom, and here is why 
> it's necessary: over the past year, the wiki has suffered 
> massive DDoS-scale traffic from scraper bots (plus the usual 
> spam bots), causing repeated downtime. The standard MediaWiki 
> CAPTCHAs didn't work. Cloudflare bot protection didn't work. 
> Standard Anubis didn't work. The current solution is a quick 
> and imperfect compromise, made necessary as LLM-powered bots 
> recently became mainstream. I'm hoping that with time, better 
> solutions will emerge, and we will be able to follow other 
> projects' lead.

As far as I was concerned, the history that lead to the captcha 
was quite obvious to me.

> So, no, it cannot simply be removed; but, I'm happy to discuss 
> specific improvements.

It could likely be removed if serving the wiki’s webpages were 
cheap computing-wise.

> Regarding the technical issues you describe: I tested the 
> custom challenge on mobile devices before launching it, and 
> testing it again now, it seems to work fine here, including 
> zoom. I would suggest trying another device / OS / browser; if 
> it works there, that would help identify what the problem is 
> with the original one. I'm happy to continue the discussion and 
> fix any real specific issues we identify.

I’ve sent you an email with a fullscreen screenshot and the model 
name of the affected device.
Should it bounce feel free to shoot me an email from an address 
where you accept replies to.

> I think that any serious proposal to move the wiki's content to 
> something else needs to:
>
> - come with a comparison of what other similar projects are 
> doing;

- Go: <https://go.googlesource.com/wiki>
- Rust: Haven’t been able to find a “rust-lang wiki”.
- Nim: <https://github.com/nim-lang/Nim/wiki/>
- D Idioms: <https://github.com/p0nce/d-idioms>

> - have a plan for how to preserve authorship;

We could replay the whole history from MediaWiki in Git, if we 
really need that.
I suppose the FDL-1.3 imposes certain requirements we have to 
consider.

> - have a plan for how it will be maintained;
> - have a plan for how it will be moderated;

If it’s a Git repo hosted on GitHub, we have our army of 
maintainers.
People considered trustworthy enough could be added to a team of 
the GitHub organization and gain direct commit/push access.

If we establish a policy to merge any contribution that isn’t 
outright bad, there little effort needed.

> - have a plan for how to redirect all existing URLs;

Keeping existing “slugs” intact, a redirector should be easy to 
set up with any webserver.


> - be done in a way that's respectful of the effort all 
> contributors have invested into the content.

I’d be interested to learn what would be considered disrespectful.
I’ve seen people take shortcuts during content migrations, I’d 
obviously like to avoid that and ensure that no content is lost.

We could even merge it into a subfolder under the main domain, 
dlang.org. That would express our dearest respect for those 
contributions. Might even come with an SEO benefit. (I’m no 
expert at all, rather clueless actually, but at work we had a 
client whose SEO guy asked us to deploy their web app as a 
sub-URL of the main website for better ranking compared to a 
subdomain.)

> I'm not against it, especially if there is the DFL is in favor, 
> but we should consider it carefully. We would lose sovereignty 
> over our content, and platform functionality can be taken away 
> (deprecated and then removed) at any time. The above 
> considerations should be taken into account as well.

This only applies if we were to use the built-in wiki of GitHub — 
which I’d rather not —, doesn’t it?

> Hope this helps,

Sure thing; thank you very much! :)