Thanks for the input. I feel your pain about the "project drawer" problem. Have too many pet-projects myself that don't ever see the light of day because they are too (s)crappy and I'm too ashamed. This time around, I had set the day as a hard deadline to ship (also as a bday gift to self) -- regardless how scrappy . I then told some buds about it to add some peer-pressure to the mix (thanks to my accountability buds). This helped and I'm happy for all the feedback I'm getting. Could have hacked another few weeks on this before getting input, but I've been following startups for long enough to believe that there is much value in the early feedback. I also need to learn to be less ashamed of my shit code and embrace that I'm not a great programmer and I no longer have to gatekeep the quality of my stuff out there for the world to see. No matter how hard the feedback may hit, I want to learn to absorb those punches.
On Reddit (r/orgmode and r/emacs) and on the SystemCrafters discord (Emacs communities mostly ) folks were kinda interested but ATM I'm touching upon something niche here that may perhaps be too small warrant a time investment beyond a pet-project. Could also been that this thing didn't really reach a wide enough audience (a total of about 300 pageviews according to Plausible is peanuts, really ) to say something meaningful about it yet, so the jury isn't completely out yet.
Since it's an own itch, I'll continue with the collaboration bit. Also as a learning exercise since I've been wanting to build something with collaborative editing features to cut my hands a bit more on CRDT-based tech... we all need study projects, anyways.
Yes to the calendar view! That would be one of the next ones up because I also long for such a perspective on a doc that has deadlines or timestamps. We're flirting with the idea of a few other perspectives as well -- like a diff perspective e.g.: show me what happened in the Prose/Kanban/Calendar perspectives between a week ago and today) git may be useful. This could be convenient when someone returns from vacation and wants a quick glance overview of what happened meanwhile.
Git as a database would allow folks (devs, in particular) to interact with the data without us having to roll an API, editor extensions or utils. Nearly all devs that would be part of our audience are git-users and understand how to make and merge changes. It also removes the burden of domiciling someone's data. As a dev-tool, it may be fair to expect that devs know best where they want this data to live.
For tracking entries, git is definitely not the best option because the docs are quite fluid/malleable and tasks can be split, changed or reordered between commits without us being able to trivially map previous tasks to current ones. I already had a bud suggest that reeling in CouchDB for some stuff may be helpful here, so we're going to have to experiment here to see what sticks. On the other hand, perhaps the modern task/proj-mgmt paradigm is too rigid in this regard anyways. Perhaps there is a place for sculpting collections of tasks that can morph into something unexpected altogether without much effort. Tracking a task's full-lifecycle may therefore not be as important as facilitating for the flux and fluidy that we are aiming for ATM where we can't map every event to a single ledger entry with a unambiguous lifecycle and identity. I believe that the incumbent paradigm has enough tools available already, so playing into the more fluid org camp would be a more useful contribution to the tooling landscape, I'm guessing.