1 #+title: notes on a shared inbox workflow
2 #+author: Richard Westhaver <ellis@rwest.io>
3 #+date: [2024-05-05 Sun]
5 I think roadmap should be product/management oriented. Agile
6 terminology applies and things are grouped into
7 sprints/trains/PIs/etc. There's really no need for that currently at
8 least not until there's at least 10 or so contributors. The
9 =inbox.org= workflow is much more 'agile' in fact, e.g. hackable.
11 I would like to make use of the core/inbox.el and ORGAN, perhaps move
12 inbox.el to a new repository, where it will live as a package, which
13 we can contribute to MELPA.
23 Pandora's box. I guess we should make use of decorators/capitalization
24 for significant tags, and the rest are user-defined.
26 Not entirely commited to uuid, but maybe it makes the most sense to
27 use the timestamp one.
29 A Status should be applied to tasks only.
31 We need a significant number of 'in progress' types, but each
32 completed task will start as TODO and end up at DONE.
34 Deadline,Scheduled,DATE property,LOGBOOK
36 The logbook should be used to record progress throughout the lifetime
39 Descriptions can be blank, but tasks in need of review require a
45 I don't think we need org-roam for this? TBD. The thing is that I want
46 link data to end up in a set of rocksdb instances instead of sqlite.
48 For the time being we should limit the scope to a set of properties:
54 Note there's no forward references.
58 prob use rust, parse json or something
