freddieridell / hypertask Goto Github PK

to stop distant tasks creeping up the board when they shouldn't

different views of the data can produce different prefixes, because they don't have all the same information

What could these other sources be? JIRA? Contact's Birthdays? Calenders? How would they be sourced? how would updates be synced? What would we do with extra data that hypertask can't handle?

make a cli similar to hypertask, that stores a simple list of links, probably with tags, and a read status: unread, archived, read

that looks at the current task "pressure" (a metric I'll have to calculate) and sets it into the future based on that.

Add a new snooze prop, and a shortcut command to hypertask-cli.

This will act just like wait, and allow you to hide a task for a short ammount of time because it is impossible to do right now

This probably resolves #38

Years ago, the core idea of this project was to replicate commands as a CRDT add only set. I've since abandoned that idea, as I was finding it to difficult to efficiently rebuild the current most up-to-date state when new commands arrived from external sources.

The reified nature of Commands still makes them a good candidate for this style of replication, so later on down the line I could pick up this idea again.

However, I want to ship version 1.0 before I pick this back up, as it's more important in the mid-term to have a mobile client than to have a cool replication model

I should just update my usage, rather than locking at a version

It keeps crashing for some reason, I have no idea why, let's start logging the output to a file so we can keep propper tabs on it

just have each shortcut present the interface ({ filter, modifications }) => Promise, and let them decide how to implement themsevles

old system of due: should work

make clients store their hostname in the telemetry store, and display it from the share command

so I can remove pins from the backlog while also keeping hold of them

Break hypertask-cli's arg parsing out into a seperate module, and implement it into hyperpin-cli

by default we can just show only the tasks we've edited

based on the number of tasks over a ceartain score today, and how many there will be tomorow.

can be used for calculating things like #5 and for telling the user how many tasks they aught to complete each day.

Don't try to include recuring tasks, just take it as it is

this is most obvious in pin, but also seems to be visible in task, I thinks it's because some feeds still have the data, and the conflict resolver is still bringing them through. Perhaps I should move this logic to the reducer? can I remember why it's currently not?

hyperswarm isn't working, use https://github.com/karissa/hyperdiscovery instead

add an optional filter param to objAll generator, so we can filter at a more base level, rather than having to re-implement each time

scans through the tasks and finds the next $x that has no tasks due that $x

• due:free.h
• due:free.d
• due:free.w
• due:free.m

I'm pretty sure that "2018-11-02" doens't work...

task and pin (and friend, org, cal in the future) should all have the same interface that is handled by a specific package.

• delete any un-used main, or index files
• remove any packages that aren't in use
• remove any duplicate files
• break out any duplicated code

so that we can add and remove things from a set

to allow one process to stay up, seeding permenantly, with an ephemeral client connecting in to query it.