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