Closed:

en_labswikimedia
de_labswikimedia

liquidthreads_labswikimedia

Already closed:
flaggedrevs_labswikimedia
readerfeedback_labswikimedia

Thehelpfulonewiki wrote:

Hi Reedy,

Although I can't edit, I can still login to the wiki, per https://meta.wikimedia.org/wiki/Requests_for_comment/Rights_and_closed_wikis - I thought it should be "it can be only edited by stewards, system administrators and staff users; nobody else."

Also, at https://en.labs.wikimedia.org/w/index.php?title=Special%3ALog&type=rights&user=Thehelpfulone&page=&year=&month=-1&hide_review_log=1 - I can edit my own user rights and give myself review and uber reviewer.

I believe this is because of https://en.labs.wikimedia.org/wiki/Special:ListGroupRights - all users can Add groups to own account: Reviewers and Uber-Reviewers and remove them -- can you disable this?

Thanks!

kontakt-bugzilla-wikimedia-org-22.07.2011 wrote:

https://liquidthreads.labs.wikimedia.org/wiki/MediaWiki:Sitenotice

automatically redirects to

https://incubator.wikimedia.org/wiki/W/liquidthreads/MediaWiki:Sitenotice

where you can reed an error message. Should be fixed ...

I think we could move all these projects to beta.wmflabs.org? eventually redirect. SUL there is using (or should be) different pw than on prod so it's secure for all users even on non https

(In reply to comment #2)

Hi Reedy,

Although I can't edit, I can still login to the wiki, per
https://meta.wikimedia.org/wiki/Requests_for_comment/Rights_and_closed_wikis -
I thought it should be "it can be only edited by stewards, system
administrators and staff users; nobody else."

Also, at
https://en.labs.wikimedia.org/w/index.php?title=Special%3ALog&type=rights&user=Thehelpfulone&page=&year=&month=-1&hide_review_log=1

• I can edit my own user rights and give myself review and uber reviewer.

I believe this is because of
https://en.labs.wikimedia.org/wiki/Special:ListGroupRights - all users can Add
groups to own account: Reviewers and Uber-Reviewers and remove them -- can you
disable this?

Thanks!

I've now killed the settings for FlaggedRevs to all labs wikis

(In reply to comment #3)

https://liquidthreads.labs.wikimedia.org/wiki/MediaWiki:Sitenotice
automatically redirects to
https://incubator.wikimedia.org/wiki/W/liquidthreads/MediaWiki:Sitenotice
where you can reed an error message. Should be fixed ...

Same issue for other wikis, see bug 33809 for that.

Nothing else to do on this, bug 33809 "handles" the weird redirects

Note that we've been using en.labs.wikimedia.org for testing the ArticleFeedbackV5 extension. It's a useful test wiki because it's running on the production cluster and has some example content, so it's a good place to do pre-deployment testing.

Unfortunately we have some naming confusion between this and the new wmflabs.org cluster, and it's also the case that these test wikis haven't been well maintained. But we may have to at least temporarily reactivate en.labs.wikimedia.org for purposes of AFTv5 testing.

Hi Erik, the deployment beta is perfect for you, it contains example pages as well and the tools are available there too.

Hi Peter,

I'm well aware of the good work you, Mark and others have been doing on the deployment beta sites, and they should definitely be part of the staging process. However, they are and always will be only an approximation of actually running code on the production cluster. There may still be small differences which result in bugs -- some oddness about the configuration of the bits cluster, or memcached, or Lucene, ...

Because of these unavoidable differences, mature engineering organizations have multiple staging/testing steps. We do, although we're not quite routinely utilizing them. Software should first be deployed into an ever-improving beta site (for which purpose we can hopefully soon get rid of prototype.wikimedia.org* completely). Provided all code is reviewed and passes initial QA, it should then be deployed into a testing mode on the production cluster. That can be done in different ways -- dark launches (where a URL parameter is used to call up some code that's not yet officially released), opt-in launches, or test wikis running on the production cluster. For AFTv5 specifically, it's useful to have the latter option prior to production deployment.