wiki.dlang.org: How about replacing MediaWiki with a Git repo?
Vladimir Panteleev
thecybershadow.lists at gmail.com
Tue Aug 4 18:20:29 UTC 2026
On Tuesday, 4 August 2026 at 16:40:54 UTC, Mindy Batek (0xEAB)
wrote:
> 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.
Thank you for writing that. Appreciate the enthusiasm :)
> I’m not sure whether it’s fair to consider GitHub as "some
> other platform" in our use case.
You may be right. I recall we did have a community member who
used to submit patches via Bugzilla because they disagreed with
having a GitHub account. I don't know if they're still around.
> (Does GitHub currently discriminate users because of their
> location?)
It does (as I think does any business which is based in the US):
https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls
and some anecdotal horror stories:
https://github.com/orgs/community/discussions/158764
> The current captcha is also reducing the user base that has
> *viewing* access to the current wiki.
This may be true as well. I have been meaning to introduce an
alternative to the CAPTCHA, but postponed that effort until the
first time we encounter this situation in practice, also to
ensure that the alternative is properly effective and works for
the impacted user.
> 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?)
I don't know. However, the barrier to publishing is known to be
correlated with users' motivation to contribute. I'm sure the
German wiki admins are aware of this; that may have been an
informed trade-off they made.
>> 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.
Okay, but we do have to agree that anything that's between
clicking "save" and the contribution becoming world visible
counts as a barrier.
> It could likely be removed if serving the wiki’s webpages were
> cheap computing-wise.
This may be something that's worth revisiting. I recall that
MediaWiki does have built-in support for accelerated serving from
an in-memory cache.
The problem I recall I was seeing was that the scrapers would
hammer the website (never mind that there isn't all that much to
scrape) repeatedly, intensely, and relentlessly for as long as it
was scrapeable.
> 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.
Got it, thanks! I've deployed the changes to the D wiki and soon
to other protected sites.
> - Go: <https://go.googlesource.com/wiki>
Not world editable :(
> - Rust: Haven’t been able to find a “rust-lang wiki”.
:(
> - Nim: <https://github.com/nim-lang/Nim/wiki/>
Looks like someone put in quite a bit of effort here, but it
petered out.
I also found out today that GitHub wikis are not indexed by
search engines, so information added there won't show up in
search results.
> People considered trustworthy enough could be added to a team
> of the GitHub organization and gain direct commit/push access.
I think that misses the goal a little. For core members, we have
dlang.org already; the wiki is specifically for everyone else,
i.e. the community. I'm also wary of the social dynamics and
consequences of there being one group with "direct edit"
superpowers.
> If we establish a policy to merge any contribution that isn’t
> outright bad, there little effort needed.
I am not sure about this, but I think others can offer more
insight here than I can, especially if they do PR review
regularly. I recall that at some point we were already severely
constrained by reviewer time. Personally I probably wouldn't
enjoy being pinged (or having to review every day) a ton of typo
fixes or minor additions about people's pet projects that few
others care about (but that's exactly what a wiki enables people
to host).
> 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.)
Probably official and community content is better kept separate?
Thanks!
More information about the Digitalmars-d
mailing list