Does this still need community consensus as it is tagged?

No, I don't think so, it's a beta wiki. It's for testing stuff

@Reedy , while I agree with the first clause of your statement, I must correct the latter one: Beta Wikiversity is not a beta wiki for testing stuff like testwikipedia or testwikidata are. It is a full fledged content Wikimedia project being that to separate Wikiversities what Wikimedia Incubator is to separate Wikipedias, Wikivoyages, Wiktionaries, and Wikinewses.

In T209208#4737009, @Base wrote:

@Reedy , while I agree with the first clause of your statement, I must correct the latter one: Beta Wikiversity is not a beta wiki for testing stuff like testwikipedia or testwikidata are. It is a full fledged content Wikimedia project being that to separate Wikiversities what Wikimedia Incubator is to separate Wikipedias, Wikivoyages, Wiktionaries, and Wikinewses.

Ugh. Yeah. This is why we shouldn't reuse names like we do. See also naming things is h ard

Maybe the only way to address what @Reedy concerns above, is to rename the root url of this wiki to https://mul.wikiversity.org/ (like T64717), but that's a separated question.

Dear Beta Wikiversity admins: what's the status of local discussion? Looks like no further comments after my posting?!

I a

In T209208#4857219, @Liuxinyu970226 wrote:

Dear Beta Wikiversity admins: what's the status of local discussion? Looks like no further comments after my posting?!

I am an admin, but I do not think this requires community consensus. At least I cannot remember that there has been community consensus on every single wiki where arbitrary access has been rolled out.

We're going to move forward with this. Next steps:

• update and improve task description
• get details about how we can enable arbitrary access without coupling it with enabling sitelinks

In T209208#5495213, @Lea_Lacroix_WMDE wrote:

We're going to move forward with this. Next steps:

• update and improve task description
• get details about how we can enable arbitrary access without coupling it with enabling sitelinks

Regarding the second point:

In T204706#4707035, @Ladsgroup wrote:

I spent one hour digging the code and apparently sitelinks stuff and client are different things. The way that sitelinks in repo works is (according to SiteLinkTargetProvider) and then get valid groups + special wikis and then discards everything else. Meaning as long as we are not adding 'sources' to $wgWBClientSettings['specialSiteLinkGroups'] and $wgWBRepoSettings['specialSiteLinkGroups'], we are fine. It's interesting to see 'oldwikisource' is not a 'wikisource' but a 'sources' wiki but if anyone fixes it, it will accidentally enable sitelinks for oldwikisource.

If we want to enable client on sourceswiki, we need to add it to the client dblist and pull it on mwmaint1002, make the tables and then just sync the dblist everywhere. I can do it later.

wikiversity is not configured to work with sitelinks, so you won't be able to add them unless we explicitly add it.