Bir üniversite sitesinde içerik neredeyse her yerden gelir. Fakülteler, bölümler, enstitüler, araştırma merkezleri, öğrenci işleri ve kurumsal iletişim birimi sayfa yayımlar. Bunu yapan onlarca kişinin çoğu için web asıl iş değildir. Tanımlı bir yol olmadığında ortaya yazım hataları, kurum kimliğine uymayan sayfalar, kaldırılması unutulmuş duyurular ve zaman zaman yetkili biri okumadan yayına giren hassas içerik çıkar. İçerik onay iş akışı tam bu noktada devreye girer.
Bu akış her sayfaya aynı yolu verir. Sayfa taslak olarak başlar, belirlenmiş bir inceleyeni bekler ve o kişi onayladığında yayına girer. Drupal bunu iki çekirdek modülle, ücretli bir eklentiye ihtiyaç duymadan yönetir. Bu yazıda modüllerin nasıl birleştiğini, sürecin kuruma göre nasıl ölçeklendiğini, çift dilli sitelerde neyin değiştiğini ve onay sürecinin gerçekten işleyip işlemediğini belirleyen yapılandırma detaylarını ele alıyoruz.
Üniversitelerde inceleme adımı neden gerekir?
Üniversite büyük ve merkezî olmayan bir yayıncıdır. Editöryal denetimi zorlaştıran şey de tam olarak bu birleşimdir. Her fakülte ve birimde web deneyimi birbirinden çok farklı katkıcılar çalışır. Buna karşılık doğruluk, kurum kimliği, erişilebilirlik ve başvuru ya da yönetmelik sayfalarında hukuki ve itibar riski merkezî iletişim ile bilgi işlemin sorumluluğunda kalır.
Türkiye'de bu tabloya bir de KVKK boyutu eklenir. Sınav sonuç listeleri, burs duyuruları, akademik personel profilleri ve başvuru formları kişisel veri içerir. Bir sayfanın yayına girmeden önce yetkili biri tarafından okunması, bu verinin gereğinden fazla açılmasını yakalayacak en pratik noktadır.
Yükseköğretimde en büyük Drupal ekosistemlerini yöneten kurumlar tam olarak bu sorunun üzerine kurulu. Harvard, Yale, Stanford ve Duke'un her biri, bölümlerin ve araştırma gruplarının içerik yayımladığı adlandırılmış bir kurumsal Drupal platformu işletiyor. Harvard kendi platform dokümantasyonunda içerik yayımlama ile kullanıcı yönetimini yan yana temel özellik olarak sayıyor. Yüzlerce birim aynı platformu paylaşmaya başladığında kimin yayımlayabileceği sorusu ayrıntı olmaktan çıkar ve platformun merkezî yönetişim sorusu hâline gelir.
Amaç katkıcıları yavaşlatmak değildir. İlk kez sayfa hazırlayan bir akademisyenin serbestçe çalışabilmesini, eğitimli birinin ise sayfa kurum dışına açılmadan önce standartları karşıladığını doğrulamasını sağlamaktır.
Workflows ve Content Moderation nasıl birlikte çalışır?
Drupal'da bir sayfa varsayılan olarak iki durumda bulunabilir. Ya yayımlanmıştır ya da yayımlanmamıştır. Bu, bir inceleme sürecini tarif etmeye yetmez. İki çekirdek modül bu tabloyu genişletir.
Workflows, içeriğin bulunabileceği durumları ve aralarındaki geçişleri tanımlar. Sürecinizin soyut biçimini çizer, o kadar. Tek başına hiçbir şey yapmaz ve yalnız kurulduğunda size kullanılabilir bir iş akışı tipi olmadığını söyleyen bir ekran gösterir.
Content Moderation o iş akışı tipini sağlar. İş akışını gerçek içeriğe, örneğin belirli içerik tiplerine bağlar ve her geçişi kendi iznine bağlayarak yalnızca amaçlanan rollerin sayfayı ileri taşımasını sağlar.
İkisi de çekirdek modüldür ve kararlılık geçmişlerini bilmekte fayda var, çünkü bu konu kaynaklarda çoğu zaman toptan aktarılıyor. Content Moderation çekirdeğe deneysel modül olarak Drupal 8.2'de, Workflows ise 8.3'te girdi. Workflows 8.4'te kararlı işaretlendiğinde Content Moderation hâlâ beta aşamasındaydı ve kararlı sürümüne Drupal 8.5.0 ile ulaştı. Content Moderation, Drupal 8.4 veya üstünü gerektirir. Drupal 10 ve 11'de ikisi de doğrudan çekirdeğin parçasıdır ve Extend sayfasından etkinleştirilir. Kurulumun adımlarını resmi Content Moderation dokümantasyonu anlatıyor.
Durumlar, geçişler ve bunları uygulayan izinler
Her Drupal iş akışının altında üç kavram yatar. Durumlar, içeriğin bulunabileceği koşullardır. Geçişler, durumlar arasındaki izin verilen hareketlerdir ve yönlüdür, yani siz izin vermedikçe bir sayfa taslaktan doğrudan arşive atlayamaz. Revizyonlar, tüm bunların altındaki sürümlenmiş geçmiştir. Drupal bekleyen revizyonları destekler ve bu sayede bir editör hâlihazırda yayında olan bir sayfanın yeni sürümünü hazırlarken, o çalışma onaylanana kadar hiçbiri herkese açık görünmez.
Bu şemayı gerçek bir denetime çeviren şey izinlerdir. Drupal her geçiş için ayrı bir izin oluşturur. Örneğin Yayımla geçişini kullanma yetkisi inceleyenlere verilip katkıcılardan esirgenebilir. Onay zincirini kuran mekanizma tek başına budur.
Content Moderation etkinleştirildiğinde Taslak, Yayımlanmış ve Arşivlenmiş durumlarını içeren varsayılan bir Editorial iş akışı oluşur. Burada gözden kaçan bir ayrıntı var. Bu varsayılan iş akışı yalnızca site standart kurulum profiliyle kurulduysa otomatik olarak oluşturulur. Minimal ya da özel bir profilde onu kendiniz kurarsınız.
Üniversitede işe yarayan durum kümesi genellikle varsayılanı biraz genişletir.
| Durum | Ne anlama gelir | Bu duruma kim taşıyabilir |
|---|---|---|
| Taslak | Yazılıyor ya da düzenleniyor, herkese açık değil | Her katkıcı |
| İnceleme bekliyor | Gönderildi, bir inceleyeni bekliyor | Her katkıcı |
| Düzeltme gerekiyor | Geri bildirimle yazarına döndü | İnceleyenler |
| Yayımlanmış | Sitede canlı | İnceleyenler ve yöneticiler |
| Arşivlenmiş | Siteden kaldırıldı ama saklanıyor | Yöneticiler |
Varsayılan iş akışının çoğu yeni editörü şaşırtan bir sonucu var. Yayından kaldırma düğmesi yoktur. Canlı bir sayfayı indirmek için yayımlanmış revizyonu Arşivlenmiş durumuna alırsınız.
İş akışını üniversitenin ölçeğine göre kurmak
Pratikte bir üniversite bunu geniş değil, küçük bir roller kümesine eşler.
| Rol | Neler yapabilir | Genellikle kimde |
|---|---|---|
| Katkıcı | Taslak oluşturur ve düzenler, içeriği incelemeye gönderir. Yayımlama geçişi yoktur. | Fakülte ve bölüm personeli |
| İnceleyen | İçeriği inceler, düzenler, yayımlar ya da geri gönderir. Yayımlanmamış ve en son sürümü görme izni gerekir. | Eğitimli fakülte editörleri ya da merkezî web ekibi |
| Yönetici | İnceleyenin yapabildiği her şey, ayrıca rol atama ve iş akışı yapılandırma. | Bilgi işlem ya da kurumsal iletişim |
Yol gösterici ilke en az yetkidir. Ders sayfalarını güncelleyen birinin site yapılandırmasına ya da kullanıcı yönetimine ihtiyacı yoktur ve o rolü dar tutmak tüm platformu korur.
Drupal tek sitede birden fazla iş akışına izin verir ve her birini farklı içerik tiplerine uygularsınız. Modeli üniversite ölçeğinde gerçekten kullanışlı kılan da budur. Sıradan bölüm sayfaları kısa yoldan gider. Başvuru yönetmelikleri, basın bültenleri ve hukuki duyurular ise sıradan sayfaların atladığı ek bir onay durumundan geçer. Böylece her içerik türüne gerçekten gerektiği kadar denetim uygularsınız ve hepsini aynı süreçten geçmeye zorlamazsınız.
Bu, mimari yönetişimin editöryal karşılığıdır. Onlarca alt siteyi tek kurulumdan yöneten büyük üniversite platformlarında ikisi el ele çalışır. Mimari taraf hangi sitelerin ortak altyapıda durduğunu belirler, editöryal taraf ise o sitelerde kimin neyi onayladığını.
Çok dilli sitelerde her çeviri ayrı incelenir
Drupal 8.5, çevirilerin birbirinden bağımsız olarak modere edilmesine destek getirdi. Türkçe ve İngilizce yürüyen bir üniversite sitesinde bu, sürecin biçimini doğrudan değiştirir.
Her çeviri kendi moderasyon durumunu taşır. Bir sayfanın Türkçe sürümü yayında olabilirken İngilizce çevirisi incelemede bekleyebilir ya da tam tersi olabilir. Bu ayrım önemlidir, çünkü tek bir inceleyenin her dili onaylayacak yetkinlikte olması beklenemez. Tam olarak okuyamadığı bir metni onaylayan kişi denetim değil, biçimsel bir imza üretir.
Yapılandırmaya başlamadan önce dil sahipliğini netleştirin. Hangi dili kimin inceleyeceğine karar verin ve bir çeviri onaylanmışken diğeri onaylanmamışsa ziyaretçinin ne göreceğine karar verin. Bağımsız moderasyon, bir sayfanın bir dilde yayında olup diğerinde olmaması anlamına gelir. Uluslararası öğrenciye açılan bir üniversite sitesinde bu durum sık yaşanır, o yüzden bir çeviri hazır değilken ziyaretçiye hangi dilin gösterileceğini kontrol edin.
Onay sürecini sessizce durduran yapılandırma detayları
Onay iş akışlarının çoğu tasarımından dolayı değil, inceleme kuyruğunu görünmez ya da kullanılmaz hâle getiren küçük yapılandırma detayları yüzünden durur.
- İnceleyenler inceleyecekleri içeriği göremez. Geçiş izinleri tek başına yetmez. İnceleyenlerin ayrıca en son sürümü görme ve yayımlanmamış içeriği görme iznine ihtiyacı vardır. Bunlar verilmediğinde inceleme kuyruğu boş görünür.
- Taslaklar üst üste birikir ve birlikte yayımlanır. Taslak revizyonları kümülatiftir, yani her biri bir öncekinin üzerine eklenir. Aynı sayfada birkaç kişi inceleme öncesinde taslak kaydettiyse, yayımlama işlemi bu değişikliklerden birini değil hepsini birden canlıya alır. Birden fazla yazarı olan sayfalarda bunu kaçırmak kolaydır.
- İçerik doğrudan incelemeye geçemez. Geçişler yönlüdür. Yayımlanmış durumdan inceleme durumuna giden bir geçiş açıkça tanımlanmadığında, canlı bir sayfayı güncelleyen katkıcı önce taslak olarak kaydetmek, sonra göndermek zorunda kalır. İş akışı mevcut sayfaların düzenlenmesi değil de yeni sayfalar düşünülerek tasarlandığında bu geçişi atlamak kolaydır.
- Kimse sırasının geldiğini bilmez. Elle kontrole bırakıldığında içerik incelemede bekler, çünkü kimse geldiğini fark etmez. Content Moderation Notifications, içerik durumlar arasında hareket ettiğinde seçtiğiniz bir role ya da içeriğin yazarına e-posta gönderir ve /admin/config/workflow/notifications adresinden yapılandırılır. Süreçte bekleyen her şeyi listeleyen bir pano gerisini tamamlar.
- İnceleyenlerin yine de giriş yapması gerekir. Drupal, yayımlanmamış revizyonları yalnızca doğru izinlere sahip ve oturum açmış kullanıcılara gösterir. Yoğun bir dekanın sayfaya şöyle bir göz atmasına dayanan bir iş akışı tasarlandığı gibi çalışmaz.
Onay iş akışının gerekmediği durumlar
Moderasyon, içeriği üretenlerle onaylayanları birbirinden ayırmak için vardır. Bu ikisi aynı kişilerse süreç denetim getirmez, yalnızca işi zorlaştırır.
Hepsi yayımlama yetkisine sahip bir iki güvenilir editörle yürüyen bir sitenin buna ihtiyacı yoktur, çünkü kendi işinizi kendi kuyruğunuzdan geçirmek hiçbir kazanç sağlamadan yayını yavaşlatır. Zincir kurumun personel kapasitesinden uzunsa iş akışı bir yüke de dönüşür. Bir sayfanın meşgul birkaç onaylayanı geçmesi gerekiyorsa kuyruk darboğaza döner, katkıcılar etrafından dolaşmanın yollarını aramaya başlar ve kurum eskisinden daha az denetime sahip olur.
Büyük kurumlarda geçerliliğini koruyan tavsiye, moderasyonu riskin gerektirdiği kadar basit tutmaktır. Gerçekten ihtiyaç duyduğunuz durumlarla başlayın ve yeni bir durumu ancak gerçek bir editöryal ihtiyaç belirdiğinde ekleyin, süreç uğruna süreç kurmayın. İnsanların etrafından dolaştığı bir iş akışı, hiç iş akışı olmamasından kötüdür.
Karar vermeden önce bilinmesi gereken iki sınır var. Moderasyon yalnızca revizyon destekleyen varlıklara uygulanır ve bu da node'ları, özel blok tiplerini ve sınıflandırma terimlerini kapsar, ancak sitedeki her şeyi kapsamaz. Platform kararı ise bunların hepsinin altında durur. O konu hâlâ açıksa neden Drupal sayfamız kararın dayandığı kriterleri bir arada ele alıyor.
Bu disiplinle yapılandırıldığında içerik onayı, platformun üzerine eklenen bir katman olmaktan çıkar ve platformun çalışma biçiminin parçası hâline gelir. Fakülteler ve bölümler geniş biçimde katkı verir, kurum dışına açılan her şeyin önünde güvenilir bir kontrol durur. Drupart bünyesindeki Drupal4edu ekibinin Sabancı Üniversitesi, ODTÜ, Yıldız Teknik Üniversitesi, Yeditepe Üniversitesi, Işık Üniversitesi ve İstinye Üniversitesi gibi kurumlar için geliştirdiği Drupal platformlarında editöryal onay, burada anlatılan aynı çekirdek temelin üzerinde durur. Bu temelin yükseköğretime neden uyduğunu eğitimde Drupal genel bakışımızda daha ayrıntılı ele alıyoruz.
Drupal içerik moderasyonu hakkında sıkça sorulan sorular
İçerik moderasyonu Drupal çekirdeğinin parçası mı?
Evet. Workflows ve Content Moderation'ın ikisi de çekirdek modüldür, Extend sayfasından etkinleştirilir ve satın alınacak ya da indirilecek bir şey yoktur. Workflows Drupal 8.4'te, Content Moderation ise 8.5.0'da kararlı işaretlendi. Content Moderation, Drupal 8.4 veya üstünü gerektirir. E-posta bildirimi ve moderasyon panosu gibi isteğe bağlı eklentiler contrib modüllerden gelir, ancak onay mekanizmasının kendisi Drupal'ın içinde hazır durur.
Durum ile geçiş arasındaki fark nedir?
Durum, içeriğin bulunabileceği bir koşuldur. Taslak, İnceleme bekliyor, Yayımlanmış ve Arşivlenmiş birer durumdur. Geçiş ise bir durumdan diğerine izin verilen harekettir ve Yayımla ile Arşivle birer geçiştir. Ayrım önemlidir, çünkü izinler durumlara değil geçişlere bağlanır. Bir sayfayı kimin ilerletebileceğini, her geçişi vererek ya da esirgeyerek belirlersiniz. Durumlar içeriğin nerede olduğunu, geçişler ise bir sonraki adıma nasıl ve kim tarafından ulaştığını tanımlar.
Farklı içerik tipleri farklı iş akışı kullanabilir mi?
Evet ve bu, bir üniversite sitesinde yapılandırabileceğiniz en kullanışlı şeylerden biridir. Birden fazla iş akışı oluşturup her birini farklı içerik tiplerine uygulayabilirsiniz. Bir bölüm duyurusu basit bir taslaktan yayına akışını kullanırken, bir başvuru yönetmeliği ek bir onay durumundan geçebilir. Böylece her içerik türü yalnızca gerçekten ihtiyaç duyduğu kadar denetim taşır.
Moderasyon açıkken bir sayfayı yayından nasıl kaldırırım?
Varsayılan Editorial iş akışında ayrı bir yayından kaldırma eylemi bulunmaz. Bunun yerine yayımlanmış revizyonu Arşivlenmiş durumuna alırsınız. Bu işlem sayfayı herkese açık siteden kaldırırken revizyon geçmişini olduğu gibi korur. Basit bir yayımlandı düğmesine alışkın editörlerin bunu bir kez öğrenmesi yeterli olur, sonrası rutine döner.
İnceleyenler bir içeriğin kendilerini beklediğini nasıl öğrenir?
Content Moderation Notifications adlı contrib modül aracılığıyla. Bu modül, içerik durumlar arasında hareket ettiğinde e-posta gönderir. Bir inceleyen rolündeki herkese ya da içeriğin yazarına bildirim gidebilir, yapılandırması /admin/config/workflow/notifications adresindedir ve çekirdek Content Moderation ile birlikte çalışır. Süreçte bekleyen her şeyi gösteren bir panoyla birleştiğinde, içeriğin fark edilmeden incelemede kalmasını önler.