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. Moderation extension belongs to this category.

Is this extension stable?
This extension is stable. It has been deployed in production on Russian Uncyclopedia (absurdopedia.net) since November 2014.

The extension has an automated testsuite with significant coverage (phpunit and Selenium). Every change to Moderation is automatically tested on:


 * 1) newest version of MediaWiki
 * 2) MediaWiki 1.31 (LTS)
 * 3) MediaWiki 1.27 (legacy LTS)

Please read the files KNOWN_LIMITATIONS, TODO and WONT_DO for all known issues. Feel free to contact the author if you have any questions.

What's the difference from FlaggedRevs or Approved Revs?
and hide the bad revisions only from readers. The vandal edits will still exist in history and RecentChanges, and all editors will stumble upon them when they try to edit the page which was vandalized. Therefore administrators have to revert vandalism quickly.

On the other hand, Moderation completely eliminates vandal edits: non-approved revisions are simply not created in page history, etc. This ensures that not only readers, but also other editors won't see the vandal edits in any of the pages.

In short, (1) FlaggedRevs is for quality control but doesn't help against persistent vandalism. (2) Moderation is specifically against vandalism and renders it completely ineffective.

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

Parameters for LocalSettings.php

 * $wgModerationEnable: If set to false, then new edits are applied as usual (not sent to moderation). Default: true.
 * $wgModerationTimeToOverrideRejection: Time (in seconds) after which rejected edit could no longer be approved. Default: 2 weeks. Note: old rejected edits are NOT deleted (moderators can always look at them in Rejected folder even if this time has elapsed).
 * $wgModerationOnlyInNamespaces: If set to an array of namespace numbers (e.g. ), moderation is only enabled in these namespaces (edits in other namespaces will bypass moderation). Default (empty array): moderation is enabled everywhere.
 * $wgModerationIgnoredInNamespaces: If set to an array of namespace numbers (e.g. ), non-automoderated users can bypass moderation in these namespaces. Default (empty array): moderation can't be bypassed anywhere.
 * $wgModerationNotificationEnable: If true, notification email will be sent to $wgModerationEmail each time an edit is queued for moderation. Default: false.
 * $wgModerationNotificationNewOnly: If true, only notify about new pages (but not about edits in existing pages). Default: false.

See also: #Configuration options ONLY for pre-publish review (options not recommended for 95% of wikis).

Additional anti-vandalism tips
In order to prevent vandalism, the following additional measures should be applied:


 * 1) Please restrict the renaming of pages to a trusted group (not just "automoderated"), because it can be used for difficult-to-revert vandalism.
 * 2) Registering new accounts with offensive names is still a way for a vandal to show itself in the RecentChanges. A simple solution is to remove newusers log from RecentChanges:

Recommended use / good practices
The following good-practices are advised:


 * 1) Only vandalism should be Rejected. Not-so-good edits with good intentions (e.g. adding excessive plot details into the Wikipedia article about film) are better made Approved and then reverted as usual. This way the author is not offended and the text is saved in page history, viewable by anyone.
 * 2) Any user that is deemed legitimate (does N good edits) should be added into   group.
 * 3) Adding users to   group via  is NOT recommended, as it motivates the vandals to do many very-minor edits (e.g. adding interwiki). Better promote them to   manually for one good edit and not promote for 30 useless-edits-made-for-count.
 * 4) Abstain from using . Don't  "just in case", except maybe for important templates.
 * 5) Allow the full rehabilitation of users with a bad history of editing. Their useful edits to the articles should be allowed, no matter how many times they were blocked. At the same time, trolling on talk pages should be rejected, so are the purposely-low-quality edits.

Non-recommended use: Moderation as pre-publish review extension
Moderation is an anti-vandalism tool first, but some wikis use it for quality control. For example, a wiki of scientific works might choose to:


 * 1) Not Approve any edits until they meet the strict quality standards of the industry.
 * 2) Not Reject any edits that are not yet good enough, so that the author could continue editing it as long as necessary.

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)