From 23a56cafc78e1e8337917d72b2043bd3eff5353d Mon Sep 17 00:00:00 2001 From: xeruf <27jf@pm.me> Date: Wed, 7 Dec 2022 20:48:48 +0100 Subject: [PATCH] Add Intro and Fediverse thoughts --- README.md | 47 +++++++---- bonfire.org | 223 ++++++++++++++++++++++++++++++++++++++++++++++++++++ nodal.org | 9 ++- 3 files changed, 260 insertions(+), 19 deletions(-) create mode 100644 bonfire.org diff --git a/README.md b/README.md index bbb293b..550155e 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,25 @@ -Months ago, I started my quest to refine task management. I was using Todoist at the time and wasn't satisfied. -I barely trusted it anymore - it was lacking capabilities I wanted, such as a wait date as well as a difference between scheduled and due. Since it is a proprietary service, extending it would have been very challenging. +# How-Todo? + +This write-up and the accompanying markdown-files +are from 2020, +outlining my original thoughts and vision +amidst my studies as a Software Engineer. + +I have since added Org-Files in 2022, +which outline a more grand picture +but also more refined details. + +## Introduction + +Months ago, I started my quest to refine task management. +I was using Todoist at the time and wasn't satisfied. +I barely trusted it anymore - it was lacking capabilities I wanted, such as a wait date as well as a difference between scheduled and due. +Since it is a proprietary service, extending it would have been very challenging. I was also growing more accustomed and comfortable with the terminal and the UNIX philosophy. So I started exploring the CLI task managers and found [taskwarrior] - it seemed the perfect tool at first glance, with great customizability and control. But it too turned out to have some fundamental flaws. -# The concept of trust +## The Concept of Trust I believe I first heard CGP Grey using this term, but I have not found it anywhere on the Internet with this meaning. @@ -22,7 +37,7 @@ My problem is that I don't trust any of the systems I am currently using: - CLIs: too verbose to use, didn't get me the information I needed in time - web: too many clicks, too slow, not available offline, often unflexible -# Design +## Design The most important rule: Everything is a task. There is nothing else. @@ -37,7 +52,7 @@ More fundamentals: - UNIX philosophy: use plain text is possible, separate into independent modules - Complete control: Inbuilt reports and attributes should use available configuration, so that the user can change fundamental parts of the system -## Task types +### Task types There are essentially 4 types of things we do: - tasks: things to be done once e.g. hand in an assignment, fix a bug - activities: can't be completed e.g. browse the internet, gaming, spend time with family @@ -54,24 +69,24 @@ These basic types also incorporate other types: Since "task" is one of these types, entities of any of these types can be called "items" within the implementation to avoid confusion. -## User Stories +### User Stories - areas - housework projects - GTD - Agile -### Reports I need +#### Reports I need - Review active projects - Find out tasks to batch when going out - Find things I can do when I am (outside watching the babies e.g. cut nails | focused, wanting to do some (writing|programming) in the morning | unfocused in the afternoon e.g. check mails | taking a break from work on the computer e.g. do laundry | eating/snacking something e.g. watch a video/read a paper | listening to an audiobook e.g. digging, hang out the laundry) -# Inspirations +## Inspirations -## Taskwarrior +### Taskwarrior I have been using [taskwarrior] for a few weeks now, but I am already starting to lose trust again. I don't work on most of the tasks I've entered, and if I do, I rarely remember checking them off. -### Issues +#### Issues - A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook. This also makes entering tasks more verbose as I have to specify multiple tags repeatedly which could otherwise simply be inherited. - Recurrence is a longstanding issue, but can somewhat be solved by plugins: https://github.com/tbabej/task.shift-recurrence and https://github.com/JensErat/task-relative-recur @@ -80,17 +95,17 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t - Keeping all reports aligned with custom attributes is a hassle, since you can't base reports off each other - ids change whenever a task is completed, so you constantly have double-check or might complete a wrong task -### What it does well +#### What it does well - Great customizability with reports, UDAs, DOM etc - Great extendability with hooks - Integrates with many tools (e.g. vimwiki, powerlevel10k, timewarrior) -# Links +## Links [taskwarrior]: https://taskwarrior.org/ -## Discussions +### Discussions - https://kolaente.dev/vikunja/api/issues/1198: Thoughts on Vikunja, my new hope. - https://github.com/lyz-code/pydo/issues/73: @@ -98,10 +113,10 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t - https://www.wired.com/2016/03/best-to-do-list-app/: Maybe Technology won't help, after all... -## Projects +### Projects - https://codeberg.org/equilibrium/equilibrium: - A Haskell project I started to link task managers, - unfortunately abandoned by now. + A Haskell project I started to connect task managers, + unfortunately abandoned now. - https://tasklite.org/related.html: List of CLI-oriented productivity systems Should have a look at: diff --git a/bonfire.org b/bonfire.org new file mode 100644 index 0000000..d24d97f --- /dev/null +++ b/bonfire.org @@ -0,0 +1,223 @@ +#+title: Bonfire +* [2022-12-07] Federating Everything +** Groups +In response to my original write-up below, +I have been pointed towards a more appropriate distinction +of groups and tags: + +A group is bound to an instance +and has a Fediverse handle. +This allows it (and thus its members) to be mentioned +and ensures communication stays private +within a private group +as it never leaves the instance. + +(Hash)Tags on the other hand +are instance-independent +and cannot have members, +only subscribers. +** [[id:bonfire][Bonfire]] as a Task Manager +[[id:fediverse][ActivityPub]] is perfect for interactive task management +close to reality. +Let me explain. + +When a message is posted, +one might select its type: +note, task, poll, offer, request and so on. +Each of these types is provided by an extension, +but underneath is a common schema which allows for graceful fallbacks +if no matching extension is available. + +One option are textual keywords, +combined with metadata. +For example, +a task called "Finish the presentation" +with a deadline at the 8. December +might be represented as: +#+begin_quote +Task: Finish the presentation +Due: 2022-12-08 +#+end_quote +But with an appropriate extension it might be displayed as: +#+begin_quote +⃞ Finish the presentation 📅 Due Tomorrow +#+end_quote + +Ticking that checkbox would send an automatic message, +optionally prompting for a comment which might then be sent as: +#+begin_quote +Complete: 2022-12-07T19:48 + +Generated through reveal.js from Emacs Org-Mode, uploaded files to Nextcloud at LINK. +#+end_quote +The timestamp might be superfluous, +as it should match the send time of the message. +Detecting such a comment under the task, +the original message would display differently: +#+begin_quote +✅ Finish the presentation 📅 Completed Today +#+end_quote + +An offer or request could be handled very similarly, +except that it usually involves multiple parties +and should use different icons. + +By including a mention, +the task may be assigned to somebody +who can then also complete it. +Optionally the extension could allow anybody +or a certain group of users +to complete any task. + +Posts on the Fediverse cannot be modified +and thus neither edited nor reassigned directly. +This limitation is actually a great feature, +as it always preserves an accurate history of what happened. + +Descriptions, clarifications, findings and discussions +can easily be added as comments, +providing tight feedback loops. +Tasks may also be reassigned or rescheduled if permitted, +simply by sending a message with the appropriate syntax, +for example: +#+begin_quote +Assign: Somebody +Due: 2022-12-12 +#+end_quote +This will mark the initial task as ⊟ obsolete +(one could even include a completion date, +thus the original task is marked completed - +for example if one department is done and pushes it to another). +This task then copies all non-changed properties +and transforms the message into a new task: +#+begin_quote +⃞ Finish the presentation 📅 Due Monday 👤 Somebody +#+end_quote +It might be sensible to add an indicator here +that this is an update of the parent task, +but that is not of primary concern. + +With this, +tasks and communication can naturally intertwine, +as one often acompasses the other. +Notifications on new messages +and a task dashboard +ensure that nothing gets lost. + +In the end, +the Fediverse is also just a hierarchical graph database :) + +** Hooking Mails into the Fediverse +When we have this universal toolbox, +we want to be as inclusive as possible. +E-Mail persists as the most ubiquoutus federated protocol for decades, +with tools and workflows available for any platform imaginable. + +So similar as in Zulip, +communicating with an instance +entirely by E-Mail +would be a great enabler. + +This would entail +either running an own SMTP server +or polling an inbox, +with the latter likely being preferrable due to less complexity. +Either way, this does not have to be a locked-in decision +as it should also be handled by an extension. + +Then a domain or subdomain +should be entirely reserved as gateway, +handled by the instance of with a star-redirect to its inbox. +It could thus both send and receive with E-Mail-Adresses +that equal the handle in the Fediverse. +It can accept private and group messages +if a match is found, +otherwise converting the username to a tag. + +There should be filtering measures, +choosing between an Allowlist and Blacklist +which can match individual adresses +as well as whole domains. +It could be sensible to base this +on the moderation tools of the ActivityPub instance +to block spam from both protocols simultaneously. + +Once an E-Mail is known to the instance, +it will receive responses on its own posts +and on mentions of its handle, +which might correspond to a fediverse handle as well. +There should also be the option +(in the mail footer, just like with a proper mailing list) +to adjust these notifications +and subscribe to every new message +or a particular group or hashtag, +just like a registered user. + +This makes the Fediverse truly accessible to every generation. +* [2022-04-07] Making Team Chat Simple, Social and Scalable +** Analogies :noexport: +Ideally combines [[id:fediverse][Fediverse]] and [[id:messengers][Messengers]] + +- Zulip :: structured communication, discussion, internal announcements +- Fedi :: resource sharing, inspiration, connection + +Zulip is to jour fixe what Fedi is to huddle +** Current Issues +Unforunately, Zulip does not work too well with our startup: +1. the separation into channels is often not clear and can seem artificial due to our integrated nature +2. people often fail to determine the appropriate topic +3. participants feel compelled to read everything +4. the mobile experience takes too many clicks for a quick chat compared to a messenger +5. many externals that struggle to use it well, and guest accounts on many platforms worsen that experience +** Enter Real [[id:fedisocial][Social Networks]] +In ActivityPub, every post is a top-level-post, so no responses are lost in threads. +Nonetheless, one can reply to a post, +continuing a conversation to arbitrary depth without the need for a fixed structure +(fixes 2, as topics arise from reply chains - +bottom-up rather than top-down/on-demand rather than at the outset - +sparing cognitive load). + +People can be pinged, posts can seemlessly switch from public to private or internal +(or even split up for topics with both public relevance and private information), +enabling integration of outwards social-media representation in the normal flow of communication. +With public posts, external collaborators can join in with an account from another server (fixes issue 5), +and if both server support hashtag permission management, even on sensitive topics. + +*** Hashtags +But most important of all will be the handling of hashtags for classification and authorization: +Every post requires at least one hashtag, which will function similar to a Zulip Stream/Slack Channel/Mailing List/... +(fixes issue 1, as there can be multiple categorizing hashtags) +And they will also make groups superfluous. + +Many hashtags will probably come and go, as is typical in social networks. +But any hashtag can be subscribed to, at which point it also functions as a shared channel - +without anyone who does not join having to be afraid of missing anything, +as they can still see the content in relevant replies, mentions, subscriptions of other people and the global timeline. + +The icing on the cake is permission management: +Posts with a specific hashtag could be restricted to subscribers, which are of course invite-only, +so even sensitive topics can be discussed. +And last but not least, subscribed hashtags need an unread count - but only these (solves 3)! + +The unread count on muted channels in Zulip induces FOMO and makes people use them the other way around: +Muting streams they need so they don't mindlessly check the messages there... + +*** Conclusion +With ValueFlows from Bonfire, these posts can encompass tasks and more, +creating a single tool where ideas, discussions, tasks and updates (internal and external) +can be posted and collaborated on hassle-free, +while being available in an open format for further processing! + +Thankfully, there is already a plethora of intuitive apps available at least for [[id:mastodon][Mastodon]]-compatible APIs, +enabling a personalized mobile experience (fixes issue 4). +** Alternatives +I am considering [[id:xmpp][XMPP]] via Movim, too, as it provides a familiar messenger experience, but it has one big issue: \\ +Posts are confined to groups. +This means that new participants actively need to seek out the groups they want to be part of, +always have to decide where to post and thus sometimes crosspost. +Groups come and go, thus relevant content is easily missed, +as is typical in Slack and other Messaging solutions. + +The biggest abomination of this are Telegram groups, +which are used like a bad social network +with constant annoying unstructured crossposts. diff --git a/nodal.org b/nodal.org index f36336e..6ec3447 100644 --- a/nodal.org +++ b/nodal.org @@ -165,19 +165,22 @@ in our business use of Zulip, which requires you to decide the receipients of a message by posting it into a stream. ** Ideas -# Plantuml wireframes +Plantuml wireframes + +Application Lifecycle Management (ALM) Labels as Properties -> dynamic interface -https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747 Kanban config options: - group by: assignee, property (label group, status, ...), date, parent task - display levels: 1-X (range), only leaves - display text levels: 1(self)-X - ordering direction/sorting -# Application Lifecycle Management (ALM) +See also +https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747 + *** Copied Write-Ups I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion. Either way, there should be a way to add more task status options through which a task can be moved with one click as outlined above.