Extension:Moderation/tr

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?:
 * 1) Yeni bir kullanıcı tarafından yapılan her düzenleme (veya resim yüklemesi) bir denetim kuyruğuna gönderilir.
 * 2) 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.
 * 3) Kullanıcı kendi düzenlemesini görebilir ve sayfanın kendi sürümünü düzenlemeye devam edebilir.


 * Hizmetliler nasıl denetlenir?:
 * 1) 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.
 * 2) Reddedilen düzenlemeler reddedilen arşive gider.
 * 3) Onaylanan düzenlemeler normal şekilde uygulanır.
 * 4) "Neyi onaylayan" günlükleri tutulur. Bunları yalnızca moderatörler görebilir.
 * 5) 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?:
 * 1) Sinir bozucu, telefon numarası doğrulamaları vb. yeni kullanıcıların cesaretini kırmaz. MediaWiki'de moderasyon olmadan yaptıkları gibi normal şekilde düzenlerler.
 * 2) 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).
 * 3) "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.
 * 4) "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.
 * 5) Web sitesi, TOR veya I2P gibi anonim ağlarda çalışabilir.

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:


 * 1) 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.
 * 1) 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, Lurkmore.to, Ramzan Kadırov ve Molotof kokteyli ile ilgili sayfaların yazarları hakkında bilgi ifşa etme talepleriyle Rus "aşırılık karşıtı özel kuvvet" 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  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:


 * 1) MediaWiki'nin en yeni sürümü
 * 2) MediaWiki 1.31 (LTS)
 * 3) MediaWiki 1.27 (eski LTS)

Bilinen tüm sorunlar için lütfen KNOWN_LIMITATIONS, TODO ve WONT_DO dosyalarını okuyun. Herhangi bir sorunuz varsa yazarla iletişime geçebilirsiniz.

FlaggedRevs veya Approved Revs'den farkı nedir?
ve 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, hizmetliler vandalizmi hızla geri döndürmek zorundadır.

Ö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.

Kurulum
For modern versions of MediaWiki (1.31+), use the following instruction:

Installation for older versions of MediaWiki
For MediaWiki 1.27-1.30, replace the above-mentioned "git clone" command with the following:

For MediaWiki 1.23-1.26, replace the above-mentioned "git clone" command with the following:

These versions may still receive security fixes (if any), but not new features.

LocalSettings.php 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. ), 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, ), 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ı $email 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).

Ek vandalizm karşıtı ipuçları
Vandalizmi önlemek için aşağıdaki ek önlemler uygulanmalıdır:


 * 1) 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).
 * 2) 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:

Önerilen kullanım / iyi uygulamalar
Aşağıdaki iyi uygulamalar tavsiye edilir:


 * 1) Yalnızca vandalizm reddedilmelidir. İyi niyetle yapılan pek iyi olmayan düzenlemeler (örneğin filmle ilgili Vikipedi maddesine aşırı olay örgüsü ayrıntıları eklemek) daha iyi onaylandı ve ardından her zamanki gibi geri döndürüldü. Bu şekilde yazar rahatsız olmaz ve metin herkes tarafından görüntülenebilen sayfa geçmişine kaydedilir.
 * 2) Meşru kabul edilen (N iyi düzenleme yapan) herhangi bir kullanıcı   grubuna eklenmelidir.
 * 3) Vandalları çok küçük düzenlemeler yapmaya (örneğin vikiarası eklemek) motive ettiğinden, kullanıcıları  üzerinden   grubuna eklemek ÖNERİLMEZ. Tek bir iyi düzenleme için bunları manüel olarak   yükseltin ve sayım için yapılan 30 gereksiz düzenlemeye yükseltmeyin.
 * 4)  kullanmaktan kaçının. Belki önemli şablonlar dışında, "her ihtimale karşı".
 * 5) 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.

Ö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:


 * 1) Endüstrinin katı kalite standartlarını karşılayana kadar hiçbir düzenlemeyi onaylamayın.
 * 2) Yazarın gerektiği kadar düzenlemeye devam edebilmesi için henüz yeterince iyi olmayan düzenlemeleri reddetmeyin.

Pros of this approach:


 * 1) New page appears as a fully reviewed, correctly formatted document with no typos, etc.
 * 2) No one except the author and moderators would see the imperfect revisions.

Cons:


 * 1) Other users can't improve the article until it is Approved. In fact, they won't even know that it exists.
 * 2) Pending changes don't have an "edit history". Moderation stores only 1 pending change for each Page/User pair. That's inconvenient if you are preparing your page for publication for weeks. User can even accidentally delete the necessary text in their pending revision, and it won't be recoverable.

Configuration options ONLY for pre-publish review
The following parameters are only needed when using Moderation for review. They are not recommended for 95% of wikis (when following the Best Practices, they are totally not needed).

''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.''
 * $wgModerationPreviewLink: If true, Preview link is shown on Special:Moderation. Default: false.

''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.''
 * $wgModerationEnableEditChange: If true, moderators can modify the text of pending changes before Approving. Default: false.

Compatibility with other extensions

 * 1) Extension:Moderation should be enabled last in LocalSettings.php, because it aborts at least  hook.
 * 2) Extension:Moderation fully supports Extension:CheckUser, meaning that if CheckUser extension is enabled, then any approved edit will have correct IP, user-agent and XFF saved in the checkuser tables.
 * 3) Extension:Moderation is fully compatible with  and . Theoretically it should also work with other API-based editors.
 * 4) Extension:StructuredDiscussions (also known as Flow) will work, but edits in Flow forums will bypass moderation.
 * Moderation of Flow forums should be implemented in Extension:StructuredDiscussions itself. These forums use a non-text "content model", which is not supported by Moderation.
 * 1) Extensions that modify several slots of Multi-Content Revisions (not just the main slot, as MediaWiki itself does) are not yet supported. (currently very few extensions do)