dehub/docs/ROADMAP.md

# Roadmap

This document describes currently planned features and events related to the
dehub project. It's intention is to help prioritize work. There are no dates
set, only a sequence of milestones and the requirements to hit them.

## Milestone: IPFS support

* Big ol' question mark on this one.

## Milestone: Versions

* Tag commits
* Add dehub version to payloads, make binary aware of it
* Figure out a release system?

## Milestone: Prime commits

(Cloning/remote management is probably a pre-requisite of this, so it's a good
thing it comes after IPFS support)

* Ability to specify which commit is prime.
    * The prime commit is essentially the identifier of the entire project; even
      if two project instances share a commit tree, if they are using a
      different prime commit then they are not the same project.

## Milestone: Minimal plugin support

* SPEC and implement. Things which should be pluggable, initially:
    * Conditions
    * Signifiers
    * Filters
    * Payloads???

## Milestone: Minimal notifications support

* Some way to store notification settings locally, and run a command which shows
  a sequence of events since the last time you ran it.
    * The command should keep a history of all of its outputs, and allow the
      user to see that history (in case they run the command, then clear the
      output by accident).
    * The user should be able to specifically get notifications on threads
      they're a part of, threads by branch name pattern, files by path pattern,
      and keywords in commit messages.

# Misc Polish

These tasks aren't necessarily scheduled for any particular milestone, but they
are things that could use doing anyway.

* Config validation. Every interface used by the config should have a
  `Validate() error` method, and Config itself should as well.

* Maybe coalesce the `accessctl`, `fs`, and `sigcred` packages back into the
  root "dehub" package.

* Polish commands
    * New flag system, some kind of interactivity support (e.g. user doesn't
      specify required argument, give them a prompt on the CLI to input it
      rather than an error). This is partially done, in that a new flag system
      has been started. Needs further work.

    * Review flags:
        * probably make some of them into positional arguments
        * add flag shortcuts
        * document everything better.

    * POSIX compatible-ish flags?

    * Possibly save state locally in order to speed things along, such as
      "account id" which probably isn't going to change often for a user.