İşler ve projeler

Bir iş, Multica'da bağımsız bir çalışma birimidir — bir hata, yeni bir özellik, yapılması gereken bir şey. Her işin bir başlığı, bir açıklaması (Markdown desteklenir), bir durumu, bir önceliği, bir atananı vardır ve isteğe bağlı olarak bir projeye aittir. Linear veya Jira kullandıysanız, bu aynı yapı.

Multica'yı tanımlayan özellik, bir işin atananının bir kişi veya bir agent olabilmesidir — buradan başlayacağız.

Bir işi bir agent'a atama

Bir işi bir agent'a atamak o işi ona devreder. Agent otomatik olarak başlar — saniyeler içinde çalışmaya başlar, yorumlarda ilerlemeyi raporlar ve bitirdiğinde durumu bitti olarak değiştirir. Bir takım arkadaşına iş vermekten tek farkı, bir agent'ın çevrimdışı olmaması, hatırlatmaya ihtiyaç duymaması ve 7/24 kullanılabilir olmasıdır.

Özel agent'lar yalnızca çalışma alanı sahipleri ve yöneticileri tarafından işlere atanabilir. Rol izinleri için bkz. Üyeler ve roller.

Durum

Her çalışma alanı yedi yerleşik durumla başlar. Bunlar aynı zamanda yedi kategoridir — Multica'nın bildiği sabit davranış kümesi — bu yüzden her yerleşik durum kendi kategorisinin adını taşır.

Multica'da yedi durum vardır. Herhangi bir durum doğrudan başka herhangi bir duruma geçebilir — Multica bir iş akışı dayatmaz ve backlog'dan doğrudan done'a atlamanızı engellemez.

Agent'lar, işlerini değiştirdikçe işin bulunduğu durumu yazar: işin kendisinin istediği şey üzerinde çalışmaya başlamak — hangi biçimde olursa olsun, araştırma, tasarım veya işin kendisinin talep ettiği bir inceleme dahil — işi hemen in_progress'e taşır, böylece pano çalışma sürerken bunu gösterir; teslim etmek işi in_review'e taşır; görev sınırının ötesinde devam eden çalışma işi in_progress'te tutar; işin kendi teslimatından hiçbirini üretmeyen bir görev — soruları yanıtlamak, başka birine ait bir iş üzerine görüş bildirmek gibi — durumu baştan sona dokunulmadan bırakır. Bu güncellemeler, görev sırasında agent tarafından Multica CLI üzerinden açıkça yazılır — sunucu, bir görev başladığında veya tamamlandığında iş durumunu kendiliğinden değiştirmez (aşağıdaki iki sistem istisnası dışında). done genellikle bir insan onayıdır, veya kapatma niyetiyle birleşen bir PR gibi bir entegrasyondur.

Özel durumlar

Bir çalışma alanı sahibi veya yöneticisi, Ayarlar → İş Durumları altında kendi durumlarını ekleyebilir — Code Review, QA, Rework. Her yeni durum, yedi kategoriden birini seçer ve o kategorinin davranışını tamamen devralır:

Yani in_review kategorisindeki bir Code Review durumu, bir Otopilot çalışmasını tam olarak in_review'in yaptığı gibi sonlandırır; backlog'dan todo kategorisindeki bir Rework durumuna geçmek de, tam olarak todo'ya geçmenin yaptığı gibi atanan agent'ı başlatır.

İsim, ekibinizin okuduğu şeydir; kategori ise platformun hareket ettiği şeydir. Bu dokümantasyonun geri kalanı bir durumun bir şeyi tetiklediğini söylediği her yerde, bu kural kategoriye aittir — dolayısıyla o kategorinin içindeki özel bir durum da kapsanır. Bu tersine işlemez: platform durumu kendisi belirlediğinde — yukarıdaki todo'ya geri dönüş veya birleşen bir PR'daki done gibi — her zaman yerleşik durumu yazar, o kategoriden özel bir durumu asla.

Bu modelden dört şey çıkar:

• Bir durumun kategorisi, durum var olduktan sonra sabittir. Daha sonra değiştirmek, platformun o durumda bulunan her iş için yaptığı şeyi sessizce yeniden yazardı, bu yüzden düzenleyici bunu salt okunur tutar. Önce davranışı seçin, sonra adlandırın.
• Pano sütunları durumlar değil, kategorilerdir. Bir durum eklemek asla bir sütun eklemez — her kategori için bir sütun vardır. Özel bir durum kendi kategorisinin sütununda yer alır ve kartları durum adını taşıyan küçük bir rozetle görünür, böylece Code Review ile QA İncelemede sütunu içinde ayırt edilebilir kalır.
• Yerleşik durumlar kilitlidir. Adları, renkleri ve kategorileri değiştirilemez ve arşivlenemezler — bu sayfayı hiç açmayan bir çalışma alanı, sahip olduğu panoyu aynen korur.
• Arşivleme bir durumu emekliye ayırır, silmez. Zaten o durumda olan işler durumu korur, adını ve rengini korur ve aynı şekilde davranmaya devam eder. Yalnızca bir sonraki sefer birisi durum ayarladığında sunulmaktan çıkar.

Yerleşik durumlar arayüz diline çevrilir; özel bir durum her zaman yazdığınız adı gösterir. API ve CLI ona anahtarıyla erişir: multica issue status MUL-42 code_review. Ayarlar sayfası bu anahtarı isimden türetir; API ise açık bir anahtar kabul eder ve yalnızca türetmeye geri döner. Her iki durumda da anahtar oluşturulduğunda sabitlenir — durumu daha sonra yeniden adlandırmak anahtarı değiştirmez.

Öncelik

Öncelik, varsayılan iş listesini sıralamak için kullanılan beş seviyeye sahiptir:

İş numaraları

Her işin <önek>-<rakamlar> biçiminde çalışma alanına özgü benzersiz bir numarası vardır — örneğin MUL-123. Numara, oluşturulma anında sistem tarafından atanır ve asla değişmez. Bkz. Çalışma alanları → İş numaraları.

Yorumlar

Bir işin altındaki yorum konusu, iş birliğinin gerçekleştiği yerdir — bir yoruma yanıt verin, bir kişiden veya agent'tan @ ile bahsedin, bir tepki ekleyin.

Bir yorumda bir agent'tan @ ile bahsetmek onu otomatik olarak tetikler — bu, "ata"nın yanında bir agent'ı başlatmanın ikinci yoludur. Bkz. Yorumlar ve bahsetmeler ve Yorumlarda agent'lardan bahsetme.

Bir işi silme

Projeler

Bir proje, birden fazla işi bir arada gruplandıran bir kaptır. Bir iş en fazla bir projeye aittir, veya hiçbir projeye ait değildir.

Projelerin kendi sorumlusu vardır — tıpkı bir işin atananı gibi, bir sorumlu da bir kişi veya bir agent olabilir.

Bir projeyi silmek içindeki işleri silmez: bu işler projeden ayrılır ve çalışma alanında kalmaya devam eder.

Sırada

• Yorumlar ve bahsetmeler — bir iş altında iş birliği yapma
• Agent'lar — "bir agent'a atama"nın gerçekte nasıl çalıştığını anlayın