Extension:Moderation
Moderation uzantısı, küçük ve orta büyüklükteki vikiler için vandalizme karşı koruma sağlar.
Bu, en etkili vandal koruma yöntemlerinden biridir ve yasal kullanıcılar üzerinde çok az etkisi vardır.
Giriş
- Nasıl çalışır?
- Yeni bir kullanıcı tarafından yapılan her düzenleme (veya resim yüklemesi) bir denetim kuyruğuna gönderilir.
- Moderatör bu düzenlemeyi onaylayana kadar sayfa değiştirilmez. Bekleyen düzenlemeler ne sayfa geçmişinde ne de RecentChanges'da yer almaz.
- Kullanıcı kendi düzenlemesini görebilir ve sayfanın kendi sürümünü düzenlemeye devam edebilir.
- Hizmetliler nasıl denetler?
- Yeni bir özel sayfa sağlanır (Special:Moderation). Son Değişiklikler'e çok benzer, ancak "Onayla", "Reddet", "Tümünü onayla" ve "Tümünü reddet" düğmelerine sahiptir.
- Reddedilen düzenlemeler reddedilen arşive gider.
- Onaylanan düzenlemeler normal şekilde uygulanır.
- "Neyi onaylayan" günlükleri tutulur. Bunları yalnızca moderatörler görebilir.
- Düzenleme çakışması tespit edilirse ve otomatik olarak çözülemezse, moderatörün düzenlemeyi manüel olarak uygulamak için bir birleştirme düğmesi vardır.
- Bu neden iyi?
- Sinir bozucu captcha'lar , telefon numarası doğrulamaları vb. yeni kullanıcıların cesaretini kırmaz. MediaWiki'de moderasyon olmadan yaptıkları gibi normal şekilde düzenlerler.
- Engel neredeyse eski hale gelir. Ve engellemeler iyi değildir (aralık engellemesiyle meşru bir kullanıcıya ulaşma şansını veya bazen bir veya iki sayfayı tahrip etme dürtüsü olan çok yetersiz bir kullanıcının iyi düzenlemelerine izin verememesini düşünün).
- "Fark edilmek istemekten" kaynaklanan vandalizm caydırılır. Kimse, tüm bu eylemlerin bir sorun olmadığı biliniyorsa, hizmetliye kızdıracak yeni ve yeni proxy'ler aramak için 5 saat oturmaz.
- "Tek tıklamayla geri döndürme önlemek için bir sayfayı iki hesaptan tahrip etme" gibi vandalizm yöntemleri artık etkili değil.
- Web sitesi, TOR veya I2P gibi anonim ağlarda çalışabilir.
- Users can hide their mistakes from appearing in the revision history and even from moderators by fixing them in time.
- Since any edit is only permanently recorded upon approval, users can correct botched edit summaries.
Alternatifler
MediaWiki'nin vandalizme karşı başka yöntemleri var mı? Kısaca - gerçekten değil.
MediaWiki, Vikipedi için geliştirilmiştir. Herhangi bir zamanda, Vikipedi'de gerçek zamanlı olarak vandalizmi geri döndürmek isteyen yüzlerce gönüllü var. Vikipedi dışında neredeyse tüm diğer vikilerin bu tür bir avantajı yok. MediaWiki'nin yerleşik karşı-vandalizm fikri, vandalizmin onu geri döndürmekten daha fazla zaman almasıdır. Normalde bu doğrudur, ancak bu, vandalizmin cesaretini kırmada yetersiz bir iş çıkarır ve hizmetliler, geri döndürme zamanlarının çoğunu almasa bile, vandalizmi sık sık kontrol etmek zorundadır.
Vandalizmle savaşmanın bilinen üç yöntemi vardır:
- Tüm düzenlemeleri zorlaştırın. Örneğin, Lurkmore.to, yeni kullanıcıların tüm düzenlemelerine güçlü bir captcha uygular ve sonunda captcha olmadan düzenleme yapabilmek için çok sayıda düzenleme gerekir. Bu nedenle vandal, bir avuç düzenleme yapmak için çok zaman harcamak zorundadır.
- Bariz bir eksi, tüm meşru kullanıcıların da captcha'yı atlaması gerektiğidir, bu da yazım düzeltmeleri gibi küçük düzenlemeleri caydırabilir.
- Kullanıcı kimliğini zorunlu kılın - örneğin, Facebook üzerinden oturum açın. Sosyal ağ, tüm kullanıcılarının geçerli bir cep telefonu numarasına sahip olduğunu doğrularsa, her vandalizm girişimi, vandalın mağazaya gidip yeni bir SIM kart almasını gerektirir. Bu yöntem son derece etkilidir, ancak anonim düzenlemeyi ortadan kaldırır ve desteklenen herhangi bir sosyal ağda hesabı olmayan kullanıcıları uzaklaştırır.
- Bu yöntemin güçlü bir eksi, kullanıcıların gizliliği üzerindeki etkisidir. Demokratik olmayan ülkelerde siyasetle ilgili bir sayfanın düzenlenmesi, hükümetin kullanıcıyı belirlemeye ve zulmetmeye çalışmasına neden olabilir. Örneğin Rus "aşırılık karşıtı özel kuvveti", Ramazan Kadirov ve Molotof kokteyli konulu sayfaların yazarları hakkında bilgilerin elde edilmesi talebiyle Lurkmore.to ile temasa geçti.[1]
- Vandalizmin sonuçlarını hafifletin. Örneğin, bir kullanıcı rahatsız edici başlıklara sahip 100 sayfa oluşturabilir, ancak hepsi Extension:Nuke içinde iki tıklama ile silinebilir. Moderasyon uzantısı bu kategoriye aittir.
Bu uzantı kararlı mı?
Bu uzantı kararlı. Kasım 2014'ten beri Rusça Yansiklopedi'de (absurdopedia.net) üretimde kullanılmaktadır.
Uzantı, önemli kapsama alanına sahip bir otomatik testsuite sahiptir (phpunit ve Selenium). Moderasyonda yapılan her değişiklik aşağıdakiler üzerinde otomatik olarak test edilir:
- MediaWiki'nin en yeni sürümü
- Latest LTS versions of MediaWiki (such as 1.43 or 1.39) that haven't been declared obsolete
Bilinen tüm sorunlar için lütfen $limitations, [$todo TODO] ve $wont dosyalarını okuyun. Herhangi bir sorunuz varsa yazarla iletişime geçebilirsiniz.
FlaggedRevs veya Approved Revs'den farkı nedir?
Extension:FlaggedRevs ve Extension:Approved Revs yanlış revizyonları yalnızca okuyuculardan gizler. Vandal düzenlemeler geçmişte ve Son Değişiklikler'de hala var olacak ve tüm editörler, tahrip edilmiş sayfayı düzenlemeye çalıştıklarında bunlarla karşılaşacaklar. Bu nedenle editörler vandalizmi hızla geri almak zorunda kalacaklardı.
Öte yandan, Moderation, vandal düzenlemeleri tamamen ortadan kaldırır: onaylanmamış revizyonlar, yalnızca sayfa geçmişinde oluşturulmaz, vb. Bu, yalnızca okuyucuların değil, diğer editörlerin de herhangi bir sayfadaki vandal düzenlemeleri görmemesini sağlar.
Kısacası, (1) FlaggedRevs kalite kontrol içindir, ancak kalıcı vandalizme karşı yardımcı olmaz. (2) Moderation, özellikle vandalizme karşıdır ve onu tamamen etkisiz kılar.
Moderasyon | FlaggedRevs/ApprovedRevs | |
---|---|---|
Okuyucular vandalizm görüyor mu? | Hayır | Hayır |
Editörler vandalizm görüyor mu? | Hayır | Evet |
Vandalizm sayfa geçmişinde kalıyor mu? | Hayır | Evet |
Kullanıcı tarafından yapılan tüm düzenlemeleri hızla reddedebilir mi? | Evet | Hayır |
Diğer editörler onaylanmamış düzenlemeleri iyileştirebilir mi? (vandalizm değil) | Hayır | Evet |
Kurulum
MediaWiki'nin (1.39+) modern sürümleri için aşağıdaki talimatı kullanın:
- Dosyaları
git clone https://github.com/edwardspec/mediawiki-moderation.git
ile kaynakları kontrol edin veextensions/
klasörünüzdekiModeration
adlı dizine yerleştirin. - LocalSettings.php dosyanızın altına aşağıdaki kodu ekleyin:
wfLoadExtension( 'Moderation' );
- Bu uzantının ihtiyaç duyduğu gerekli veritabanı tablolarını otomatik olarak oluşturacak betik güncelleme komutunu çalıştırın.
- Yapıldı – Uzantının başarıyla yüklendiğini doğrulamak için vikinizde Special:Version seçeneğine gidin.
MediaWiki'nin eski sürümleri için kurulum
For MediaWiki 1.35-1.38, replace the above-mentioned "git clone" command with the following:
git clone -b REL1_35 https://github.com/edwardspec/mediawiki-moderation.git
MediaWiki 1.31-1.34 için yukarıda belirtilen "git clone" komutunu aşağıdaki ile değiştirin:
git clone -b REL1_31 https://github.com/edwardspec/mediawiki-moderation.git
MediaWiki 1.27-1.30 için yukarıda belirtilen "git clone" komutunu aşağıdaki ile değiştirin:
git clone -b REL1_27 https://github.com/edwardspec/mediawiki-moderation.git
MediaWiki 1.23-1.26 için yukarıda belirtilen "git clone" komutunu aşağıdaki ile değiştirin:
git clone -b REL1_23 https://github.com/edwardspec/mediawiki-moderation.git
Bu sürümler yine de güvenlik düzeltmeleri alabilir (varsa), ancak yeni özellikler alamaz.
Yapılandırma
<span id="Parameters_for_LocalSettings.php ">
$LS için parametreler
- $wgModerationEnable
- false olarak ayarlanırsa, her zamanki gibi yeni düzenlemeler uygulanır (denetime gönderilmez). Varsayılan:
true
. - $wgModerationTimeToOverrideRejection
- Reddedilen düzenlemenin ardından geçen süre (saniye cinsinden) artık onaylanamazdı. Varsayılan: 2 weeks. Not: reddedilen eski düzenlemeler SİLİNMEZ (moderatörler, bu süre geçse bile bu düzenlemelere her zaman Reddedilenler klasöründe bakabilirler).
- $wgModerationOnlyInNamespaces
- Bir ad alanı numarası dizisine ayarlanırsa (ör.
$wgModerationOnlyInNamespaces = [ NS_MAIN, NS_FILE ];
), moderasyon yalnızca bu ad alanlarında etkinleştirilir (diğer ad alanlarında yapılan düzenlemeler denetlemeyi atlayacaktır). Varsayılan (boş dizi): moderasyon her yerde etkindir. - $wgModerationIgnoredInNamespaces
- Bir ad alanı numarası dizisine ayarlanırsa (örneğin,
$wgModerationIgnoredInNamespaces = [ NS_MAIN, NS_FILE ];
), otomatik denetlenmeyen kullanıcılar bu ad alanlarında denetlemeyi atlayabilir. Varsayılan (boş dizi): denetim hiçbir yerde atlanamaz. - $wgModerationNotificationEnable
- True ise, denetim için her düzenleme kuyruğa alındığında bildirim e-postası $wgModerationEmail (ör.
$wgModerationEmail = 'send.to.this.address@example.com';
) ile gönderilir. Varsayılan:false
. - $wgModerationNotificationNewOnly
- True ise, yalnızca yeni sayfalar hakkında bildirimde bulunun (mevcut sayfalardaki düzenlemeler hakkında değil). Varsayılan:
false
.
Ayrıca bakınız: #YALNIZCA yayın öncesi inceleme için yapılandırma seçenekleri (vikilerin %95'i için önerilmeyen seçenekler).
Editing notices
When a user who is not in a trusted group edits a page, a message is added to the top of the page informing the user about moderation. You can edit this message by editing the MediaWiki:Moderation-edit-queued page.
Kullanıcı hakları
This extension adds two groups (automoderated
and moderator
), which have the following rights:
Yetki | Kullanıcı ne yapabilir? | Bu hakkı kimde? (varsayılan olarak) |
---|---|---|
skip-moderation
|
Düzenlemeler her zamanki gibi uygulanır (denetime gönderilmez). | automoderated, sysop, bot |
skip-move-moderation
|
Sayfa taşıma her zamanki gibi uygulanır (denetlemeye gönderilmez). | automoderated, sysop, bot |
moderation
|
Special:Moderation sayfasına erişebilir | moderator, sysop |
moderation-checkuser
|
Special:Moderation sayfasında kayıtlı kullanıcıların IP'lerini görebilir. | checkuser |
Ek vandalizm karşıtı ipuçları
Vandalizmi önlemek için aşağıdaki ek önlemler uygulanmalıdır:
- Geri döndürülmesi zor vandalizm için kullanılabileceğinden, lütfen sayfaların yeniden adlandırılmasını güvenilir bir grupla sınırlayın (yalnızca "automoderated" değil).
$wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
$wgGroupPermissions['sysop']['skip-move-moderation'] = true;
- Rahatsız edici adlarla yeni hesaplar kaydetmek, bir vandalın kendisini Son Değişiklikler'de göstermesinin bir yoludur. Basit bir çözüm, yeni kullanıcı günlüğünü Son Değişiklikler'den kaldırmaktır:
$wgLogRestrictions["newusers"] = 'moderation';
Önerilen kullanım / iyi uygulamalar
Aşağıdaki iyi uygulamalar tavsiye edilir:
- Yalnızca vandalizm reddedilmelidir. İyi niyetle yapılan pek iyi olmayan düzenlemeler (örneğin, vikinin bir film hakkındaki maddesinde aşırı olay örgüsü ayrıntıları eklemek) daha iyi Onaylanır ve ardından her zamanki gibi ve düzenleme özetinde bir nedenle geri alınır. Bu şekilde yazar rahatsız olmaz ve metin sayfa geçmişine kaydedilir, şeffaflık ve düzenleyici sorumluluğu için herkes tarafından görülebilir.
- Meşru kabul edilen (N iyi düzenleme yapan) herhangi bir kullanıcı
automoderated
grubuna eklenmelidir. - Vandalları çok küçük düzenlemeler yapmaya (örneğin vikiarası eklemek) motive ettiğinden, kullanıcıları
$wgAutopromote
üzerindenautomoderated
grubuna eklemek ÖNERİLMEZ. Tek bir iyi düzenleme için bunları manüel olarakautomoderated
yükseltin ve sayım için yapılan 30 gereksiz düzenlemeye yükseltmeyin. - Engelleri kullanmaktan kaçının. Belki önemli şablonlar dışında, "her ihtimale karşı" sayfaları korumayın .
- Kötü bir düzenleme geçmişine sahip kullanıcıların tam olarak iyileştirilmesine izin verin. Kaç kez engellenirlerse engelesin, maddelerdeki yararlı düzenlemelerine izin verilmelidir. Aynı zamanda, tartışma sayfalarındaki trolleme, özellikle düşük kaliteli düzenlemeler de reddedilmelidir.
- Please note that an editor who appears to be resubmitting a rejected edit does not necessarily imply an intent to edit-war, but the editor might have made changes to their pending edit without noticing that it was rejected in the meantime.
Önerilmeyen kullanım: Yayım öncesi inceleme uzantısı olarak moderasyon
Moderasyon ilk önce bir anti-vandalizm aracıdır, ancak bazı vikiler bunu kalite kontrol için kullanır. Örneğin, bilimsel çalışmalardan oluşan bir viki şunları seçebilir:
- Endüstrinin katı kalite standartlarını karşılayana kadar hiçbir düzenlemeyi onaylamayın.
- Yazarın gerektiği kadar düzenlemeye devam edebilmesi için henüz yeterince iyi olmayan düzenlemeleri reddetmeyin.
Bu yaklaşımın avantajları:
- Yeni sayfa, tamamen incelendi, yazım hatası içermeyen doğru biçimlendirilmiş bir belge olarak görünür.
- Yazar ve moderatörler dışında hiç kimse kusurlu revizyonları görmez.
Eksileri:
- Diğer kullanıcılar, onaylanana kadar maddeyi geliştiremez. Aslında, var olduğunu bile bilmeyecekler.
- Bekleyen değişikliklerin "düzenleme geçmişi" yoktur. Moderasyon, her sayfa/kullanıcı çifti için yalnızca 1 bekleyen değişikliği saklar. Sayfanızı haftalarca yayına hazırlıyorsanız bu sakıncalıdır. Kullanıcı, bekleyen revizyonundaki gerekli metni yanlışlıkla silebilir ve bu kurtarılamaz.
YALNIZCA yayım öncesi inceleme için yapılandırma seçenekleri
Aşağıdaki parametreler yalnızca gözden geçirme için Moderasyon kullanılırken gereklidir. Vikilerin %95'i için tavsiye edilmezler (En İyi Uygulamaları takip ederken, tamamen gerekli değildir).
- $wgModerationPreviewLink
- true ise, Önizleme bağlantısı Special:Moderation sayfasında gösterilir. Varsayılan: false.
Neden tavsiye edilmiyor? Cevap: En İyi Uygulamaları takip ederken, kötü biçimlendirildiği için iyi bir değişikliği asla reddetmezsiniz. Bu düzenleme iyi olsun ya da olmasın, "fark" bağlantısından biliyorsunuz. "Önizleme" bağlantısı, kararınızı etkilememesi gereken "bu sayfanın nasıl biçimlendirildiğini" söyler.
Why not recommended? Answer: when following Best Practices, you would never Reject a good change just because it is formatted poorly. Whether this edit is good or not, you know from "diff" link. "Preview" link tells you "how is this page formatted", which shouldn't affect your decision.
- $wgModerationEnableEditChange
- true ise, moderatörler onaylamadan önce bekleyen değişikliklerin metnini değiştirebilir. Varsayılan: false.
Neden tavsiye edilmiyor? Cevap: karıştırması kolay. Moderatör, bekleyen düzenleme metnini yanlışlıkla silebilir (ve kurtarılamaz). Dahası, bu değişiklikler moderatöre atfedilmez (onaylandıktan sonra, orijinal yazar düzenlemeyi bu şekilde yapmış gibi görünür) ki bu ürkütücüdür.
Why not recommended? Answer: easy to mess up. Moderator can accidentally delete the text of pending edit (and it won't be recoverable). Furthermore, these changes are not attributed to moderator (after approval, it looks as if the original author made the edit this way), which is creepy.
Allowing moderators to mark users as automoderated
By default, any sysop
can add users to automoderated
and moderator
groups.
If you want to allow moderators to mark users as automoderated
, you can use the following configuration:
$wgAddGroups['moderator'][] = 'automoderated';
$wgRemoveGroups['moderator'][] = 'automoderated';
Diğer uzantılarla uyumluluk
- Extension:Moderation,
LocalSettings.php
'de last etkinleştirilmelidir, çünkü en az MultiContentSave kancayı iptal eder. - Extension:Moderation, Extension:CheckUser ile tam olarak destekler, yani CheckUser uzantısı etkinleştirilirse, onaylanan herhangi bir düzenlemede doğru IP, kullanıcı aracısı ve XFF denetleyici tablolarında kaydedilmiş olacaktır.
- Extension:Moderation, Extension:VisualEditor ve Extension:MobileFrontend ile tamamen uyumludur. Teorik olarak diğer API tabanlı editörlerle de çalışmalıdır.
- Extension:StructuredDiscussions (Flow olarak da bilinir) ve Extension:CommentStreams çalışacaktır, ancak Flow/CommentStreams forumlarındaki düzenlemeler denetlemeyi atlayacaktır.
- Flow forumlarının yönetimi Extension:StructuredDiscussions'ın kendisinde uygulanmalıdır. Bu forumlar, Moderation tarafından desteklenmeyen metin olmayan bir "içerik modeli" kullanıyor.
- CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
- Çoklu İçerik Revizyonların birkaç yuvasını değiştiren uzantılar (MediaWiki'nin yaptığı gibi yalnızca ana yuvayı değil) henüz desteklenmemektedir. (şu anda çok az uzantı var)
Ayrıca bakınız
- Extension:ConfirmEdit - genel CAPTCHA uzantısı.
- Extension:AbuseFilter - spam botlara karşı genel uzantı ve boşluk gibi tipik vandalizm.
- Content approval extensions
This extension is included in the following wiki farms/hosts and/or packages: This is not an authoritative list. Some wiki farms/hosts and/or packages may contain this extension even if they are not listed here. Always check with your wiki farms/hosts or bundle to confirm. |
- Stable extensions/tr
- Special page extensions/tr
- GPL licensed extensions/tr
- Extensions in GitHub version control/tr
- Extensions which add rights/tr
- AlternateEdit extensions/tr
- ApiBeforeMain extensions/tr
- ApiCheckCanExecute extensions/tr
- BeforePageDisplay extensions/tr
- CheckUserInsertForRecentChange extensions/tr
- EchoCanAbortNewMessagesAlert extensions/tr
- EditFilter extensions/tr
- EditFormInitialText extensions/tr
- EditFormPreloadText extensions/tr
- EditPage::showEditForm:fields extensions/tr
- FileUpload extensions/tr
- GetNewMessagesAlert extensions/tr
- GetUserPermissionsErrors extensions/tr
- ListDefinedTags extensions/tr
- LoadExtensionSchemaUpdates extensions/tr
- LocalUserCreated extensions/tr
- MultiContentSave extensions/tr
- PageForms::EditFormInitialText extensions/tr
- PageForms::EditFormPreloadText extensions/tr
- PageMoveCompleting extensions/tr
- PageSaveComplete extensions/tr
- RecentChange save extensions/tr
- RevisionFromEditComplete extensions/tr
- SpecialPageBeforeExecute extensions/tr
- TitleMove extensions/tr
- UploadVerifyUpload extensions/tr
- WgQueryPages extensions/tr
- All extensions/tr
- Extensions included in Miraheze/tr
- Extensions included in MyWikis/tr
- Extensions included in ProWiki/tr
- Extensions included in WikiForge/tr
- Spam management extensions/tr
- Revision management extensions/tr