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.