dehub/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: Publicize project

Must be able to feel good about showing the project publicly, as well as be able
to accept help from people asking to help.

* Fast-forward perms on branches (so they can be deleted)
* Figure out commit range syntax, use that everywhere.
* Create a branch which is just a public "welcome thread", which can be part of
  the tutorials.
* Tutorials
* Update SPEC; it's sloppy, out-of-date, and incomplete.
* Maybe move external host?

## Milestone: IPFS support

* Big ol' question mark on this one.

## Milestone: Versions

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

## Milestone: Checkpoints

* Ability to set change commits as being a "checkpoint", so that they mark a new
  root commit. A couple of considerations:
    - Only a checkpoint on the main branch should be considered when determining
      the project "root".
    - Must be a flag on change commits, to allow hard-forks of projects where
      the config file is completely replaced.
    - Not sure if it should be subject to ACL or not.

## Milestone: Minimal plugin support

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

## 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 all error messages. A good error message has the following qualities:
    * If wrapping an error which was returned from a sub-call:
        * Uses `fmt.Errorf` with the `%w` format directive at the end.
        * Phrased as if the sentence starts with the word "while", e.g. "opening
          file: %w".
    * Only includes information the caller of that function/method couldn't
      already know.

* 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.

* More/better tests
    * Commits need much better test coverage.