1. roadmap

I think roadmap should be product/management oriented. Agile terminology applies and things are grouped into sprints/trains/PIs/etc. There's really no need for that currently at least not until there's at least 10 or so contributors. The inbox.org workflow is much more 'agile' in fact, e.g. hackable.

I would like to make use of the core/inbox.el and ORGAN, perhaps move inbox.el to a new repository, where it will live as a package, which we can contribute to MELPA. 

*

2. Inbox Architecture

3. Inbox Metadata

3.1. Tags

Pandora's box. I guess we should make use of decorators/capitalization for significant tags, and the rest are user-defined.

3.2. IDs

Not entirely commited to uuid, but maybe it makes the most sense to use the timestamp one.

3.3. Status

A Status should be applied to tasks only.

We need a significant number of 'in progress' types, but each completed task will start as TODO and end up at DONE.

3.4. Dates

Deadline,Scheduled,DATE property,LOGBOOK

3.5. Log

The logbook should be used to record progress throughout the lifetime of an item.

3.6. Description

Descriptions can be blank, but tasks in need of review require a description.

3.7. Properties

  • Effort
  • Category

3.8. Links

I don't think we need org-roam for this? TBD. The thing is that I want link data to end up in a set of rocksdb instances instead of sqlite.

For the time being we should limit the scope to a set of properties:

  • PREVIOUS
  • REQUIRES
  • RELATED
  • PARENT

Note there's no forward references.

4. Notifications

discord bot? prob use rust, parse json or something