In T286859#7223008, @bd808 wrote:

In T286859#7220127, @Leaderboard wrote:

In T286859#7219964, @bd808 wrote:

I actually haven't found a local override for MediaWiki:Badaccess-groups yet to borrow ideas from yet. There is no override for that message on meta, mediawiki.org, or enwiki.

This just means that anonymous editors are not allowed, and I would change it to reflect that. Something like "to edit Wikitech, please log in".

In this very particular case you are correct that any authenticated user satisfies the missing group-user right. The thing that might not be obvious is that any message override we create will be used for all badaccess-groups responses and these could be parameterized with other needed rights which are not satisfied by merely authenticating. I am not sure that there are any other group based restrictions on page edits configured for Wikitech today--there very well may not be any--but there is no guarantee that there will not be others in the future. Overriding the system message to document one specific error cause and resolution without support for other messages that the system may be trying to present will actually make confusion worse rather than better.

I know I am an insider in my use of both Wikitech and MediaWiki, but the current message: "The action you have requested is limited to users in the group: Users." actually provides factual information and if you click through to the page on meta that it links to seems to clearly state that the fix is authenticating to the wiki.

In T286859#7219964, @bd808 wrote:

I actually haven't found a local override for MediaWiki:Badaccess-groups yet to borrow ideas from yet. There is no override for that message on meta, mediawiki.org, or enwiki.

In T286859#7219632, @Aklapper wrote:

in line with other Wikimedia projects

What do other Wikimedia projects do? Please include expected behavior in tickets - thanks!

@Zabe It seems that you have assigned the removal of flood from self to WIkisource, not Wikibooks. Also with that change you can safely remove add/remove flood from 'crats.

In T285130#7163499, @Billinghurst wrote:

I would thought that it would be reasonably obvious why that is not a great idea to grant it to all autoconfirmed users

In T285130#7163461, @Billinghurst wrote:

Do you know what you are talking about? That is not the proposal nor the consensus of the community. The purpose *is* to create a limited scope for the right.

You were welcome to have joined the conversation. You are welcome to read it to enhance your understanding.

How about giving this to autoconfirmed users instead of creating an entirely new group with such limited scope?

My response above was to MarcoAurelio, but will supply a response to JEumerus' question below.

In T284241#7132994, @MarcoAurelio wrote:

I think rMW maintenance/reassignEdits.php can be used to do this, but I've never seen this being used on Wikimedia.

In T237890#5930305, @TerraCodes wrote:

Couldn't you just temporally add yourself to the bot usergroup?

You should also include WSL (by dual-booting the iMac/Macbook Air). That's a killer Windows 10 feature that I think is being underreported.

In T282624#7101559, @Alfa80 wrote:

I am also thinking of this approach (to further reduce concerns about 2FA status by using 2LA, see below ):

Is it possible to mark the changes made by an IA with some "Requires review" flag so that all other users keep seeing/using/loading the latest approved version before that change. When someone with adequate permission approves the change, it will become active and visible worldwide. Hence we achieve a two-layer approval (2LA)

In T281600#7099050, @Acagastya wrote:

@Leaderboard we can't have the mailserver there. So we can really drop that part of the request.

In T281600#7095826, @Bstorm wrote:

Just wanted to make sure you still wanted/needed it.

In T281600#7094315, @Bstorm wrote:

Ok, I think we can create the project so you can create some VMs. What was the verdict on the floating IP? I'm a bit lost on that.

In T281600#7086223, @Bstorm wrote:

In T281600#7086207, @bd808 wrote:

No. Using Cloud VPS as a proxy to access geo-blocked content is not an acceptable use.

+1 This is not a grey area. It is simply not an acceptable use.

In T281600#7085517, @Bstorm wrote:

By "infrastructure" I mean a blank virtual computer, per @Leaderboard 's comments. You have to build a database, web server, etc. and keep them safe.

In T281600#7084372, @Acagastya wrote:

Re guarantees, are you referring to loss of data, or backups, or storage failures?

In T282624#7083246, @jrbs wrote:

Hi all. Thanks for your input. I apologise for the hasty implementation here.

Taking into account the feedback provided here, T&S will put together a more comprehensive communications plan around this change.

In T282624#7081664, @Leaderboard wrote:

Also, I am not happy with the practice of WMF delegating everything it wants to stewards - why can't the WMF do it themselves if it's really that important? Remember that stewards are often overworked (T162297).

I would like to clarify that this change was not made alone. We have been discussing this with the Stewards for months. This is not a case of a random decision by a rogue staffer, it's just a staffer who made some communications mistakes.

In any case - please allow us some time to come up with a better way to communicate how this change will happen, what it will look like from a practical perspective, etc. I would like to ask @Quiddity to remove or potentially reword the Tech News item about this task too please. :)

In T282624#7083009, @Tks4Fish wrote:

In T282624#7082771, @Leaderboard wrote:

How would bureaucrats removing 2FA from the request of the user (or abuse unrelated to 2FA) be an issue? I don't think 'crats need to check for 2FA when removing access; the only reason for stewards to remove should be for the lack of 2FA and nothing else according to the proposal.

<small>Bureaucrats would remove IA, not 2FA, think you mixed up the names.</small>'Crats won't check 2FA when removing access. What I'm referring to is a regular audit for 2FA status of IAs. If they don't have it enabled, the access is removed after a warning and a period to reenable it. The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

In T282624#7082771, @Leaderboard wrote:

Also, if you don't explain why "you should make the function not work if 2FA isn't enabled", us users can't understand why that's not an option (I'm not sure what BEANS has to do with that either, unless I am missing something).

Discussing why is saying "hey, do this and that and you can go over our security", that's why WP:BEANS was invoked.

In T282624#7082657, @Tks4Fish wrote:

As for the whole "you should make the function not work if 2FA isn't enabled" there's a huge BEANS complication here, so not going to go deeper.

The check only works in the moment, yes, but there's work on the pipelines for regular audits of 2FA status for users that should have it enabled.

Due to that, 'crats can't also remove the flag, as stewards doing the audit would be overstepping the boundary when removing it due to lack of 2FA, and 'crats can't check it due to the above.

I'm also reopening this task as this comes from the office and thus doesn't need consensus.

Going bold, anyone can feel free to revert if people think my action is inappropriate. I can't, in good faith, allow a proposal that has not been discussed beforehand and raises so many questions.

Why is such a drastic change not widely announced? I've never heard of this plan before today. At the very least you have got to be informing every community with an active bureaucrat. I would support allowing bureaucrats to verify 2FA - that should be a no-brainer. Such a ridiculous proposal with no notice...

For the record, it works properly when trying to rename the same user globally (returns an error saying that "you cannot rename yourself"). The problem is only local.

In T281600#7063113, @Ladsgroup wrote:

sysadmins don't like creating it on prod so will give this a try and see if it works; fought hard but they are persistent

What type of phrasing is this?

I outlined my reasoning in the declined ticket. I see no need to "fight" (iterate again) here. The requested material are not private in sense of NDA-protected private information and certainly WMCS is much more secure than some random third party vendor.

In T281600#7062941, @bd808 wrote:

In T281600#7062873, @Acagastya wrote:

Frankly, the seriousness of it should be treated no less than CU, or OC wiki, though it won’t require near the same amount of maintenance. As I mentioned, we need a simple wiki to have revision control, and option to upload files.

This is the part that make me wary of Cloud VPS as the hosting environment your data requires. The Cloud VPS project is setup to make it easier for Wikimedians to collaborate on technical projects and share information with each other. It is not a core goal of the project to enable collection, storage, and long term security of sensitive information. That is not to say that we force everyone's data to public, there are certainly "secrets" in many Cloud VPS hosted projects, but typically these "secrets" are in the form of passwords and API access tokens which can be revoked if leaked. Holding data that could cause a human to have legal, financial, or physical safety issues if disclosed is a completely different sort of secret.

In T281600#7062429, @bd808 wrote:

Per discussion at T281520: Create Wikinewsie's Portal wiki, it looks like one of the needs of this wiki is storage of confidential/private information. Is that a correct statement @Leaderboard? If so, can you help us understand the nature of confidentiality (is this "personally identifiable information" about humans? what bad things will happen when this data leaks?).

In T281600#7054193, @bd808 wrote:

A floating IP address will be required (for the website).

Are you aware that Cloud VPS provides HTTPS reverse proxies? A project specific public IP address should really only currently be needed for:

• Hosting under a domain other than *.wmcloud.org
• Hosting non-HTTP based public services

In T281600#7054184, @bd808 wrote:

In T281600#7054120, @Leaderboard wrote:

• Occasional use as a proxy - there are some cases where the Wikinewsie cannot access essential sites (when reviewing for instance), such as one instance where I was told that the said reviewer had to resort to Pornhub's VPN as some US government sites could not be accessed from the reviewer's country, and hence the Cloud VPN instance may be used as a proxy (Wireguard) for such purposes. I would expect this use to be uncommon at most.

This use case is very explicitly disallowed by the Cloud Services Terms of Use:

Using Wikimedia Cloud Services as a network proxy: Do not use Wikimedia Cloud Services servers or projects to proxy or relay traffic for other servers. Examples of such activities include running Tor nodes, peer-to-peer network services, or VPNs to other networks. In other words, all network connections must originate from or terminate at Wikimedia Cloud Services. An explicit exception for Github Actions has been granted, with conditions. See T260746 for details.

Some notes (as requested at #wikimedia-cloud)

Not UBN level, especially when it's just a logo.

Plus, how did https://sysop-it.wikipedia.org/w/index.php?title=Pagina_principale get approved in that case (in 2020) (https://phabricator.wikimedia.org/T256545)? I would argue that no WMF-based NDA information occurs there, and it does feel like differential treatment when compared to this request.

In T281520#7049364, @Ladsgroup wrote:

Storing NDA-protected information in such places can be constituted as violation of your NDA. You know that? If it is NDA-level, then adding admins there is also breach of your NDA (because admins don't sign NDA with WMF)

I'm confident this wiki is not storing NDA-level information and in that case, As I said WMCS is a good option and it's free for such projects.

In T281520#7049240, @Ladsgroup wrote:

In T281520#7047701, @Urbanecm wrote:

@Ladsgroup I remember you had some reservations about chapter/user-group wikis. While this doesn't look like such a wiki, it looks similar enough to me. Do the same reservations apply here, in your opinion?

I would be okay if the wiki was on the level of enwiki-arbcom or cu-wiki but since it doesn't look like it contains NDA information (if so, then why it was hosted in a third party system?) I'm against creating this wiki. If all wikinews admins (in all languages) want to share a wiki, that makes it bigger than just a enwikinews and can bring more merit to the request but I don't see much point in an admin-wiki for all wikinews wikis either.

In T281520#7048286, @Green_Giant wrote:

Ideally this proposed wiki would also have a VRT queue but this is something that could be arranged once the wiki is up and running.

In T281520#7047701, @Urbanecm wrote:

It looks like this is supposed to be a private wiki used by an estabilished project, not a chapter/user-group used wiki, is that right?

The username of the first account on the private wiki should be Acagastya, with email agastya@wn-reporters.org.

Some context: Wikinews requires a significant amount of off public wiki discussion for things like reviewing (they have a rigorous process before an article gets published; an actual workflow involves sharing private audio details with other reviewers during an interview). In the past they used to run an independent private wiki http://www.wikinewsie.org/wiki, which was operated by an admin whose heart has stopped for over 6 months. Now, when discussing on IRC, they've expressed a desire to host a private wiki on WMF servers. I've hence filed a request on their behalf, and @Acagastya can confirm if needed.

In T281333#7041117, @Zabe wrote:

In T281333#7041102, @Urbanecm wrote:

I'm not sure what's the requested change. You should be able to import from all beta projects, and that appears the case – there are only two wikibooks in beta (English, and Spanish). It doesn't make much sense to import from self (ie. from enwikibooks to enwikibooks), so having only eswikibooks there makes sense to me.

I think what is meant is that importing from production isn't possible.

I don't see a problem personally; this user is clearly trusted.

@Aklapper Sorry, saw this only now. I've merged them.

Loginwiki is also a source - some stewards reported ~20000 IP checks just on that wiki per year, which if you ask me (as a non-steward) is ridiculously high.

In T278683#6953262, @Base wrote:

Does not really sound as a good idea to me. I would rather the wiki changed the interwiki import sources if some big imports are emerging, or just had a few importers but have them go through SRP. I am not sure even about giving this permission management to crats is a good idea, certainly not to all sysops. Is there a precedent?

In T276851#6913430, @matmarex wrote:

In T276851#6910627, @Leaderboard wrote:

@ppelberg As the user who filed the request, we would prefer the Reply and New Discussion Tool to be available by default to all users (so opt-out, like at Meta).

enable DiscussionsTools by default (like at Meta)

The proposed patch by @Zabe would currently make the Reply Tool enabled by default, but the New Discussion Tool only available as a beta feature. Also, at Meta, both of them are only available as a beta feature (not opt-out as you wrote). So I think you need to clarify the details :)

As one of the developers, I'd actually suggest using the configuration proposed by @Zabe – it's how it's configured on several other wikis, and we'd prefer having fewer variants to test.

Also, the New Discussion Tool still has some known issues (in particular cases where the interface reverts back to the old version: T276495, T270323; and other blocker tasks of T271964), and we don't want users who didn't sign up to be beta testers to run into them.

Setting the same as in the (duplicated) task: https://phabricator.wikimedia.org/T103290

In T276851#6910172, @ppelberg wrote:

In T276851#6894016, @ppelberg wrote:

In T276851#6893989, @Urbanecm wrote:

Hello, since DiscussionTools are product actively maintained by Editing-team, I'm not comfortable with deploying this without Editing team signoff. Apologizes for the slight delay.

@ppelberg Hi Peter, can you please have a look at this? Thank you!

We typically like for deployment discussions [i] to be open for a week before taking any action.

As such, I've set a reminder to check back in on the discussion [i] on Friday, 12-March.

Moving forward with offering the Reply Tool, the New Discussion Tool and the VisualEditor at en.wikibooks is okay with us.

Before doing so, @Urbanecm / @Zabe: can you please confirm how you are planning to make the Reply and New Discussion Tools available at en.wikibooks? E.g. as opt-in Beta Feautres? As features that are available by default for all users? Something else?

Per MarcoAurelio.

In T273864#6803242, @Peachey88 wrote:

@Leaderboard Please provide a link to community consensus for the change

(Setting priority as high as indeed the lack of it is causing significant issues). Also see https://en.wikibooks.org/wiki/User_talk:QuiteUnusual#Blocking_using_abusefilter

But then support for upgrading to intermediate, unsupported, versions must be provided? If I recall correctly, the current guidance is to "ignore" support requests that involve upgrading to an unsupported version. Would a patch be issued if a bug exists in an old version that prevents upgrading to a newer one?

BTW: I should note that the usergroup for reviewer is actually "editor", not sure if that impacts @Urbanecm's patch. https://en.wikibooks.org/w/index.php?title=Special:ListUsers&group=editor

How about change the minimum from -2 LTS to -3 LTS? Considering that existing documentation encourages users with really old versions to upgrade, but it is indeed kind of ridiculous to expect a perfect upgrade from a version as old as 1.2. I think -3 LTS is a reasonable balance of giving users running old versions a one-path method to upgrade while keeping the scripts reasonable.

How is this anywhere close to unbreak-now level?

The issue no longer occurs to me. Waiting for a response from original poster (@Wang_Qiliang) before closing.

It's happened twice for me in the last hour when trying to import just the latest revision (when trying to import everything, it times out as usual).