

Topluluk Araştırması, topluluk yönetimine ilişkin iki kapasite belirledi:
- Politika oluşturma ve yeniden değerlendirme
- Yönetim rolleri
Yönetim rolleri ve politikaları arasındaki sıkı bağ göz önüne alınarak bu iki kapasiteye dair zorluklar ve yaklaşımlar birlikte özetlenmiştir. Bununla birlikte, sadece politika veya yalnızca roller ile ilgili zorluklar ve yaklaşımlar ayrı ayrı da özetlenmiştir.
"Politika" kapasitesinin kapsamı
Politika oluşturma ve yeniden değerlendirme kapasitesi, wiki üzerinde yeni veya mevcut toplum temelli politikaların tanımlanması, değerlendirilmesi ve revizyonu ile ilgili tüm faaliyetleri kapsar. Bu, politika tartışmalarını, tartışma ve karar verme için kuralları/normları içerir; ancak ayrı bir kapasite olarak değerlendirilen çatışma yönetimini içermez (çatışma yönetimi ve çözünürlüğü kesinlikle wiki politikalarını içerirmesine rağmen).
Bu kapasiteyi ele alan zorluklar ve yaklaşımlar, editör topluluğunun ve genel okur kitlelerinin ilgisini çekecek politikalar yaratmak ve revize etme "süreci" ve "yeteneği" üzerine odaklanacaktır. Herhangi bir politikaya veya belirli politikaların özüne odaklanmayacaktır.
Wikimedia Vakfı politikaların ihtiyaca uygun olup olmamasının ve ne kadar 'iyi oluşturulup incelendiğinin, topluluğun sağlığının bir ölçüsü olduğunu iddia etmektedir.
"Yönetim rolleri" kapasitesinin kapsamı
Yönetim rolleri kapasitesi, topluluk politikalarının ve wiki kurallarının oluşturulması veya uygulanmasını sağlamak üzere, topluluk üyelerinin sahip olabileceği resmi veya gayriresmi rollere odaklanır.
Yönetim rolleri
- Yetkilerin kaldırılması (Örneğin hizmetlilerin, bürokratların, denetçilerin): Bazı durumlar, yetkilerin kaldırılmasına neden olsa da (pasiflik, istismar, bir Tahkim Kurulunun kararı) yetki kaldırmanın sıklığı, ve neenleri topluluktan topluluğa farklılık gösterebilir. Bazı topluluklarda, yetki kaldırma çeşitli nedenlerden dolayı çok zor olabilir; örneğin açık veya etkili politikaların olmaması, süreçlerin zaman alıcı olması gibi. İzinleri kaldırma konusunda sağlam politikaların veya süreçlerin olmaması, bir topluluğun böyle davranışlar gerçekleştiğinde uygunsuz davranışlarla başa çıkma yeteneğini etkiler, ör. Taciz; Tükenmeye bağlı rahatsızlıklar veya yeni başlayanlar; Bölgesellik ve otoriterlik ("Kurucu sendromu").
- Tahkim Komitelerinin olmaması veya etkisiz olması: Bir çok dil sürümünde Tahkim Komitesi yoktur. Bir Tahkim Komitesi tüm diller için zorunlu veya etkin olmasa da Tahkim Komitesi olan veya geçmişte bunu deneyimlemiş olan bazı topluluklar komitelerin etkisiz kaldığını ya da yeterince etkin olmadığını bildirmiştir.
Eksik politika
Bazı projelerin belli başlı proje politikaları, örneğin açık bir kaydadeğerlik politikası veya açık bir görevli politikasının (örneğin, hizmetlir, bürokrat, denetçi) atanma politikası yoktur. Politikaların eksik olmasının bazı dezavantajları şunlardır:
- Karar verme sürecinde kişisel yargılar etkin olduğu durumlarda açık politikaların yokluğunda yönetim. Bu, editörler arasında hayal kırıklığı yaratabilir, ayrımcılık yapıldığı şeklinde eleştiriye ve "klik" ya da "hizip" algısına neden olabilir.
- Örtük kurallar, biri onları ihlal edilinceye kadar görülmez; örneğin kurallar, emektar editörlerin kişisel yargısına dayanarak "post factum" (olay sonrası) açıklanırsa. Birçok yeni editörün sansüre uğrama tehlikesinden rahatsız olduğu göz önüne alındığında, açık, tartışılmış politikaların aksine, eksik politikalar; yeni editörlerin çalışmalarını kontrol etme ya da gerçekleştirme imkanlarını sınırlar.
Bu nedenle eksik politikaları ele almak, düzenleme yapmayı veya topluluk ilişkilerini önemli ölçüde kolaylaştırabilir ya da daha az sorunlu hale getirebilir.
Bununla birlikte, eksik politikaları ele almak için "politika boşluğunu tanımak" bir ön-şarttır.
Uygun olmayan politika
Bazen mevcut politikalar projenin durumu veya o projenin üstünde çalışan topluluğa "uygun" değildir (veya "artık uygun değildir"). Uygun olmayan politikaların çeşitli farklı türleri olsa da bu politikalar genelde verimliliği düşürür, hayalkırıklığı ve potansiyel çatışmalar doğurur ve uzun vadede motivasyonu bozar, tükenme sıklığını arttırır.
Bir politikanın uygun olmadığını veya politikanın projede hayal kırıklığı veya sıkıntının kaynağı olduğunu belirlemek bazen zordur. Belirlense bile, bazen politikanın uygun olmadığı genel olarak kabul gördüğünde bile bir "politika değişikliği"ni uygulamak oldukça zor olabilir.
Politikaların uygun olmayabileceği dört ayrı durum şunlardır:
Ölü-metin politika
Genellikle "göz ardı edilen" bir politika; iptal edilmemesine rağmen, gerçekte bir şekilde geçersizdir, uygulanamaz veya artık uygulanmamaktadır.
Örneğin bir wikinin başka dillerden çeviri yapan katılımcıların maddenin kaynakçasındaki her bir kaynağı okuyup doğruladıktan sonra çevrilmiş versiyona eklemesini gerektiren bir politikası olabilir. Fakat bu wiki'deki madde çevirmenlerinin çoğu bu politikaya uymayı sessizce bırakır.
Ölü metin politikanın bazı dezavantajları şunlardır:
- Mevcut politika uygulanmazken, bir yönetim politikası temel olarak yoktur. Ve daha uygun bir politika ihtiyacı, ölü-metin politikanın varlığı yüzünden gözden kaçar.
- Uygulanmayan politika veya iyi niyetli editörlerin rutin olarak çiğnediği politika, diğer politikalara da gölge düşürür. Bu toplulukta seçici uygulamaların yolunu açar.
Tartışmalı politika
Aktif editörlerin yeterince geniş bir çoğunluğu tarafından kabul görmemiş politikadır. Bu, aktif anlaşmazlıklar kadar pasif fakat belirli bir politikanın özü veya yorumlanması üzerine ara sıra alevlenen uyuşmazlıklar ile topluluğu bölen anlaşmazlıkları da içerir. Tartışmalı politikanın bazı dezavantajları şunlardır:
- Politika aleyhindeki ihlallerden (ya da uygulamaya tepki olarak) dolayı sık sık çıkan çatışmaların içerik katkısı veya daha yararlı tartışmalardan zaman çalması.
- Politika veya poltiikanın uygulanmasıyla ilgili çelişkili tavsiyeler veya görüşler nedeniyle doğan karışıklıkların da etkisiyle yeni katılımcıların entegrasyonunda güçlük çekilmesi
Belirsiz veya Karışı politika
A policy that is too difficult to understand or follow, because it either lacks specificity, or on the other hand, is highly specialized and overly detailed or technical. Some specific disadvantages of ambiguous or arcane policy are:
- Difficulty in integrating new contributors. Ambiguous policies are hard to adhere to without some “wiki instincts”; complicated policies are hard to comprehend all at once, and are often overwhelming as they are introduced as monolithic policies.
- "Rules-lawyering": This is a term for certain kinds of misbehavior by a minority of contributors who spend the time to master the rules in ways most contributors would not, and who then act in ways likely to demotivate and frustrate non-"wikilawyers". Some examples are: following the letter of the rules while violating their intent, needlessly using legalistic terminology or overly formal procedures for discussion, justifying inappropriate behavior through "loopholes" or technicalities.[1]
- Extensive time needed to interpret ambiguous policies or determine the precise application of complicated policies. This can sometimes lead to disagreements being resolved by exhaustion rather than by agreement.
Diğer uygun olmayan politika türleri
Policy can be broadly supported, reasonably clear, and generally adhered to, and still be the cause of frustration, conflict, or waste of time in a project, because it may be unsuitable to the state of the project.
To take an extreme example, for clarity of illustration: if a very small community (with a handful of editors and fewer than 1000 articles) were to adopt the Featured Article process from the English Wikipedia, those few contributors would quickly be overwhelmed and demoralized by the high bar set by the process, and they would either give up and stop contributing, or the policy would become dead-letter.
While less extreme cases are less obvious, they still burden a project with policies that it is either not yet ready for, or has already outgrown. Such policies can hold back a project from achieving growth, improving quality, appointing functionaries, and generally achieving good governance.
Analiz ve Değerlendirme
- Policy survey: To begin with, a community needs to identify one or more policies that need attention. This is sometimes readily apparent and widely-acknowledged among active contributors, but if it isn't, a preliminary stage would be a survey of existing policies (as well as policies that may be missing, looking at policies in comparable projects) to assess whether each policy is clear, uncontroversial, enforced, and suitable to the project.
- Comparative Policy Review: Where a missing or unsuitable policy is identified, a comparative policy review from comparable projects can surface potential solutions. This comparative review should summarize not just the substance of the policy, but ideally also perceived pros and cons of that policy in the eyes of some active editors from that community.
- Policy metrics: It is possible to assess some policies with metrics and data collection. For example, statistics about deletion decisions (e.g. How many votes were cast? What was the proportion between 'keep' and 'delete'? What was the average size of the deletion discussion page?) following deletion discussions can shed light on notability policies.
- Group review of sample cases: Convening a broad group of experienced contributors to review a sample of recent cases with a view to desired/ideal results/decisions, compared to what current policy would determine. For example, reviewing a sample of recently deleted/kept articles to assess how well the current notability policy is reflecting active contributors' expectations; reviewing a sample of recent Featured Article candidates to assess whether the criteria are resulting in decisions that match community expectations.
- Off-wiki brainstorming: Decisions about policy should always happen on the wiki. But at times, particularly if past attempts to revise policy or reach consensus have failed, it may be beneficial to gather as many active contributors as possible for a face-to-face meeting to brainstorm and seek group agreement on one or more proposals, to then bring back to the wiki for consideration by the entire community.
- Design an experiment: Experiment with potential solutions for a proposed policy creation/change, including a transition plan, measures of success, a fallback procedure, etc.
Politika değişikliği:olası bir süreç
Communities change policy in any number of ways. But aggregate experience with community conversations suggests the following steps work well:
- Frame the need for change: To create or revise policy, it is essential to have a clear and concise description of the current policy gap or the way current policy is not well-suited to current project needs. It should be easy to see how proposed changes (at least potentially) address the needs.
- Present data, alternatives, or a specific proposal: It's always easier to respond to concrete data, alternatives, or a detailed proposal, rather than to open-ended questions such as "what should our paid editing policy be?".
- Facilitate community discussion: Let the community discuss the needs, the alternatives, the proposal. Afford enough time for different contributors to provide input (e.g. include both weekdays and weekends). Encourage input from: people who were not involved with the analysis or earlier discussion stages, editors with different interests, roles, and tenure on the projects. Ideally, provide some "nutshelling" (i.e. brief summaries) of longer contributions, to assist everyone in keeping track of what can often be a long and complex conversation.
- Arrive at significant agreement for deliberate action or inaction: Discussion should eventually arrive at either significant agreement on changing (or introducing) policy, or significant agreement to not take action and prefer the “status quo”. The latter is sometimes the right decision, if no compelling alternatives have been found, or if persuasive objections have been raised to what seemed a good proposal earlier.
- Document the decision: Whether or not change is agreed upon, it is important to end the process by documenting the decision arrived at (particularly when the decision is to not change policy). If policy is introduced or revised, it is important to achieve clarity, in writing, about what changes and what remains the same, about timelines and effective dates, and about any transitional or interim steps.
- Zorluk
- Zamanı geçmiş kaydadeğerlik politikasında değişikliğin zorluğu
- Hedef
- Kaydadeğerlik politikasını değiştirip değiştirmemek konusunda geniş destekli topluluk kararı almak. Eğer değişikliğe karar verilirse yeni bir politika taslağı hazırlamak ve uygulamak.
- Ana adımlar
- Mevcut politikadaki sorunları ifade etmek
- Olası bir politika değişikliği hakkında görüşmek için geniş destek sağlamak
- Aşağıdakilerden destek/bilgi alarak politika değişikliği hakkında topluluk müzakereleri gerçekleştirmek
- benzer projelerdeki kaydadeğerlik politikalarının karşılaştırılması incelemesi
- Aktif editörlerin topluluk tartışmalarında üzerinde görüşülmesi için bir taslak öneri hazırlamak üzere birebir görüşmeleri (seyahat fonlaması)
- Topluluk müzakeresini bir karar ve belge ile sonlandırmak
- Zaman
- 6 ay
- Araçlar ve kaynaklar
- Karşılaştırmalı politika incelemesini oluşturmada Wikimedia Vakfı desteği; birebir toplantı için seyahatin Wikimedia Vakfı tarafından fonlanması
- Değerlendirme
- Kaydadeğerlik politikasının kullanışlılığını ve kaydadeğerlik ile ilgili anlaşmazlıkların sıklığı ve seviyesini değerlendirmek üzere proje öncesi ve sonrasında topluluk anketi
- Resmî kaydadeğerlik ve silme tartışmalarının politika değişikliği (varsa) öncesi ve sonrasındaki sıklığını (bir araçla?) ölçümü.
Aşağıda sınırlı bir kaynak listesi bulunmaktadır. Lütfen faydalı bulduğunuz kaynakları ekleyiniz ya da listeyi zenginleştirmeye yardımcı olunuz!
Vaka çalışmaları


- The Wikimedia Foundation is interested in assisting interested communities in considering and achieving policy change, for instance through research, external conversation facilitation, and funding for face-to-face meetings.
- Sign up below if you are interested in implementing this in your local community: