@Urbanecm can you comment on whether it is feasible to make a wiki semi-private. Per discussion the wiki may be viewable by a relative large number of users (perhaps all extended confirmed users), so it seems not suitable to have a manual account management like traditional private wikis.

Also I propose the "member" user group can be automatically added by a (to be created) adminbot in that wiki.

In T299590#7634571, @Bugreporter wrote:

@Urbanecm can you comment on whether it is feasible to make a wiki semi-private. Per discussion the wiki may be viewable by a relative large number of users (perhaps all extended confirmed users), so it seems not suitable to have a manual account management like traditional private wikis.

My answer would depend on what "semi-private" would mean. Connecting a private wiki to SUL or otherwise making use of the already-existing extended confirmed group will definitely be an issue though.

Also I propose the "member" user group can be automatically added by a (to be created) adminbot in that wiki.

That's one of the options to handle the wide area of users issue you mention. Alternatively, you can create Toolforge tool that would create an account for you if you meet the criteria and press a button. The advantage would be the Toolforge tool can request access to user's email address and as such, create the acc in an easier way.

Is it possible to revoke user's access to this semi-private wiki? Like if one user is blocked for various reason and the community believe should not have access to this wiki which contains somehow sensitive information.

A traditional private wiki (account creation restricted, non-SUL): blocking a user will revoke access (as $wgBlockDisablesLogin is true)

A Miraheze-style private wiki, which is proposed in this task (SUL enabled and access restricted to a "member" group): removing users from the group will revoke access

Note in a Miraheze-style private wiki users in global group with "read" right (currently there are two: founder and VRT permission) can see contents. This is not a concern here, as contents in the proposed wiki is not confidential and the access restriction is only used to prevent vandals from accessing LTA pages.

I suggest the URL should be lta.zh.wikipedia.org, cause zh-lta is not a valid language code.

In T299590#7635133, @Emojiwiki wrote:

I suggest the URL should be lta.zh.wikipedia.org, cause zh-lta is not a valid language code.

We don't support two level subdomains due to how our certificates work iirc.

My personal recommendation is to use zho.wikipedia.ORG , Because zho is a valid language code, this can be used as the new domain name.

In T299590#7635473, @IN wrote:

My personal recommendation is to use zho.wikipedia.ORG , Because zho is a valid language code, this can be used as the new domain name.

Let's not use a valid language code for something that is not a wiki in that language. We already have wikis (such as sysop_itwiki) that don't use a valid language code + project suffix as their database name and that's ok.

In T299590#7634618, @Stang wrote:

Is it possible to revoke user's access to this semi-private wiki? Like if one user is blocked for various reason and the community believe should not have access to this wiki which contains somehow sensitive information.

Yes, but nothing prevents that user from copying all of its content off-wiki before their access is revoked.

In T299590#7634599, @Urbanecm wrote:

In T299590#7634571, @Bugreporter wrote:

@Urbanecm can you comment on whether it is feasible to make a wiki semi-private. Per discussion the wiki may be viewable by a relative large number of users (perhaps all extended confirmed users), so it seems not suitable to have a manual account management like traditional private wikis.

My answer would depend on what "semi-private" would mean. Connecting a private wiki to SUL or otherwise making use of the already-existing extended confirmed group will definitely be an issue though.

CentralAuth is currently not designed to support private wikis in a otherwise public wiki farm (see for example T298361), and as a maintainer of that extension I'm not currently interested in spending my volunteer time in changing that.

In T299590#7635513, @Majavah wrote:

CentralAuth is currently not designed to support private wikis in a otherwise public wiki farm (see for example T298361), and as a maintainer of that extension I'm not currently interested in spending my volunteer time in changing that.

Although I have no access on that restricted task, but I want to point out 1. Miraheze handles private wikis that way (using SUL+a member group) and 2. the content of LTA wiki is not really private, the access restriction is mostly for BEANS purposes and currently all LTA pages are hosted in Wikipedia, which is public.

In T299590#7635513, @Majavah wrote:

In T299590#7635473, @IN wrote:

My personal recommendation is to use zho.wikipedia.ORG , Because zho is a valid language code, this can be used as the new domain name.

Let's not use a valid language code for something that is not a wiki in that language. We already have wikis (such as sysop_itwiki) that don't use a valid language code + project suffix as their database name and that's ok.

So we think we should set the database name for this wiki to lta_zhwiki.

Also what is the domain name of sysop_itwiki?

I suggest going with zh-lta.wikimedia.org instead. That is more aligned with how we set DNS for misc projects.

General notes:

• This can be a fishbowl wiki but if people really want to.
  • Or this can pull a foundationwiki, connected to SUL but edit rights being limited.
  • Anything else is not possible at the moment and possibly require developer time.
• This needs an extra approval or consultation with T&S on how it should look like.

I prefer Miraheze-style private wiki. There should be lots of users who have the right to have access to the wiki, and this approach is easier for managing accounts.

As for the traditional-wiki/Toolforge-tool method, we still need bots to revoke a user's access, right?

In T299590#7636101, @Ladsgroup wrote:

General notes:

• This can be a fishbowl wiki but if people really want to.
  • Or this can pull a foundationwiki, connected to SUL but edit rights being limited.
  • Anything else is not possible at the moment and possibly require developer time.
• This needs an extra approval or consultation with T&S on how it should look like.

One important point is the right to view (not just edit) must be restricted to a (large) group of trusted users, since the problem of current LTA pages (hosted in zhwiki) is they allow LTAs to bypass detection and encourages copycat vandals.

Wouldn't a Toolforge tool protected by an OAuth authentication layer be more suitable for this, rather than a full wiki?

Also what is the domain name of sysop_itwiki?

https://sysop-it.wikipedia.org/

在T299590#7641723中，@Stang写道：

Discussion about this task has started on VP/P: link.

Discussion about this task has re-started on VP in zhwiki, here is link.
Hopefully this time we can reach a consensus rather than silencing it, hopefully.

在T299590#7636101中，@Ladsgroup写道：

General notes:

• This can be a fishbowl wiki but if people really want to.
  • Or this can pull a foundationwiki, connected to SUL but edit rights being limited.
  • Anything else is not possible at the moment and possibly require developer time.
• This needs an extra approval or consultation with T&S on how it should look like.

For this wiki, can we use "Project" be our project namespace and "Project Talk"be our project talk namespace etc.?

In T299590#8355098, @LClightcat wrote:

For this wiki, can we use "Project" be our project namespace and "Project Talk"be our project talk namespace etc.?

Of course yes, this is the default setting of NS4.