4
|
1
|
* roadmap |
9
|
2
|
:PROPERTIES: |
|
3
|
:ID: 01634e21-2d66-4e47-a060-c774b354b17d |
|
4
|
:END: |
1
|
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. |
|
10
|
|
|
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. |
|
14
|
|
|
15
|
#+begin_src org |
|
16
|
,* |
|
17
|
#+end_src |
|
18
|
|
|
19
|
* Inbox Architecture |
9
|
20
|
:PROPERTIES: |
|
21
|
:ID: 5da80539-43a4-4977-a4a2-f51b142d74e3 |
|
22
|
:END: |
1
|
23
|
|
|
24
|
* Inbox Metadata |
9
|
25
|
:PROPERTIES: |
|
26
|
:ID: 70c8688f-9941-4c3c-a486-60cf0333a263 |
|
27
|
:END: |
1
|
28
|
** Tags |
9
|
29
|
:PROPERTIES: |
|
30
|
:ID: febf20bf-7626-4730-9ecb-5b2086e05ba4 |
|
31
|
:END: |
1
|
32
|
Pandora's box. I guess we should make use of decorators/capitalization |
|
33
|
for significant tags, and the rest are user-defined. |
|
34
|
** IDs |
9
|
35
|
:PROPERTIES: |
|
36
|
:ID: 16265000-164a-41cb-8aa0-dcc61bf16b9c |
|
37
|
:END: |
1
|
38
|
Not entirely commited to uuid, but maybe it makes the most sense to |
|
39
|
use the timestamp one. |
|
40
|
** Status |
9
|
41
|
:PROPERTIES: |
|
42
|
:ID: 0e24d4ec-294d-4cca-b640-119c7fd1175e |
|
43
|
:END: |
1
|
44
|
A Status should be applied to tasks only. |
|
45
|
|
|
46
|
We need a significant number of 'in progress' types, but each |
|
47
|
completed task will start as TODO and end up at DONE. |
|
48
|
** Dates |
9
|
49
|
:PROPERTIES: |
|
50
|
:ID: f134a4b4-64b5-4492-a5e0-18673f7b0c52 |
|
51
|
:END: |
1
|
52
|
Deadline,Scheduled,DATE property,LOGBOOK |
|
53
|
** Log |
9
|
54
|
:PROPERTIES: |
|
55
|
:ID: f3a4440c-a186-40e1-80be-b311100ffe63 |
|
56
|
:END: |
1
|
57
|
The logbook should be used to record progress throughout the lifetime |
|
58
|
of an item. |
|
59
|
** Description |
9
|
60
|
:PROPERTIES: |
|
61
|
:ID: 82b15096-474a-4913-93ab-eeb28ff998d9 |
|
62
|
:END: |
1
|
63
|
Descriptions can be blank, but tasks in need of review require a |
|
64
|
description. |
|
65
|
** Properties |
9
|
66
|
:PROPERTIES: |
|
67
|
:ID: c2f6ac27-4f7b-4839-b6be-c3f96adf0b6a |
|
68
|
:END: |
1
|
69
|
- Effort |
|
70
|
- Category |
|
71
|
** Links |
9
|
72
|
:PROPERTIES: |
|
73
|
:ID: 1c39c531-d4ba-407e-a54a-5ee4ad22ea42 |
|
74
|
:END: |
1
|
75
|
I don't think we need org-roam for this? TBD. The thing is that I want |
|
76
|
link data to end up in a set of rocksdb instances instead of sqlite. |
|
77
|
|
|
78
|
For the time being we should limit the scope to a set of properties: |
|
79
|
- PREVIOUS |
|
80
|
- REQUIRES |
|
81
|
- RELATED |
|
82
|
- PARENT |
|
83
|
|
|
84
|
Note there's no forward references. |
|
85
|
|
|
86
|
* Notifications |
9
|
87
|
:PROPERTIES: |
|
88
|
:ID: 8c101baa-e3ee-4982-986b-b6b9854eb25e |
|
89
|
:END: |
1
|
90
|
discord bot? |
|
91
|
prob use rust, parse json or something |
|
92
|
|