Logseq DB görevleri: Status, Priority, Deadline ve Scheduled

[[Dosya sürümü görevleri]] ayrı model kullanır.

Orada LATER, NOW, DONE veya TODO, DOING, DONE gibi metin işaretleri merkezdeydi.

DB sürümünde model property tabanlı.

Bir task nasıl oluşuyor?

Resmî DB belgesine göre task:

**#Task tag'i taşıyan block.**

Task oluşturmanın birkaç yolu var:

• Status seçmek,
• block sonuna #Task eklemek,
• Task sayfasındaki table'a yeni row eklemek,
• Deadline veya Scheduled eklemek.

Bu işlemler block'u task modeline sokuyor.

Dört temel property

Her task için yerleşik alanlar:

Bu alanlar typed property sisteminin parçası.

Görev özelliği artık metin ayrıştırmasına daha az bağımlı.

Status modeli

Varsayılan yerleşik status değerleri:

• Backlog
• Todo
• Doing
• In Review
• Done
• Canceled

Cmd-Enter ile Todo → Doing → Done döngüsü kullanılabiliyor.

Status seçeneklerinin ad ve icon tarafı özelleştirilebiliyor; yeni choices eklenebiliyor. Yerleşik bazı choices tamamen silinemiyor.

Bu, eski iki workflow seçeneğinden daha açık bir model.

Status history

Resmî belge Status değişiklik geçmişinin tutulduğunu anlatıyor.

Bir task Todo'dan başka duruma geçtiğinde spent time üzerinden geçmiş erişilebilir hale geliyor.

Bu geçmiş advanced queries içinde de sorgulanabiliyor.

Bu özellik task'ı yalnız checklist satırı olmaktan çıkarıyor; süreç verisine dönüştürüyor.

Deadline ile Scheduled ayrımı

İki tarih alanını aynı kullanma.

Scheduled:

**ne zaman üzerinde çalışmayı planlıyorum?**

Deadline:

**en geç ne zamana kadar bitmeli?**

GTD açısından da bu ayrım önemlidir. [[GTD yazısında]] takvim ve next action mantığını ayrı ele alıyoruz.

Bir task aynı anda ikisine de sahip olabilir.

Repeated tasks

Task'ta Deadline veya Scheduled varsa tekrar etkinleştirilebilir.

Done olduğunda resmî belge iki davranış anlatıyor:

1. Status yeniden Todo olur.
2. Deadline veya Scheduled belirlenen interval kadar ileri alınır.

Interval:

• Date için Day → Year,
• DateTime için Minute → Year

aralığında yapılandırılabilir.

Tekrar mekanizması başka node'lara da uygulanabiliyor

DB sürümünün daha ilginç tarafı bu.

Resmî belge aynı repeat mekanizmasının custom properties ile kullanıcı tanımlı node'larda da kurulabileceğini anlatıyor.

Gerekli parçalar:

• Date veya DateTime property,
• choices kullanan başka bir property,
• checkbox state mapping.

Bu, task motorunun daha genel bir recurrence mekanizmasına dönüştüğünü gösteriyor.

Özel task türleri

Tag mirası burada devreye giriyor.

ProjectTask adlı tag oluşturup parent olarak Task verirsen:

• built-in task properties gelir,
• üstüne Project gibi kendi property'ni ekleyebilirsin.

Bu yöntem:

• WorkTask,
• ReadingTask,
• ClientTask

gibi özel türler oluşturmayı mümkün kılar.

Ama önce gerçekten farklı şema ihtiyacı olup olmadığını kontrol et.

İlk kurulum

Başlangıç için yerleşik dört alan yeter.

Bir hafta yalnız:

• Status,
• Priority,
• Deadline,
• Scheduled

kullan.

Sonra baktığında Project veya Context gibi ortak bir alan sürekli gerekiyorsa custom task type düşün.

DB görev modeli güçlü çünkü task artık text token değil, sorgulanabilir bir tagged node.

Gücü property sayısını artırmakta değil; iş durumunu veri olarak tutmakta.