Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document data format #40

Open
chmac opened this issue Aug 5, 2021 · 3 comments
Open

Document data format #40

chmac opened this issue Aug 5, 2021 · 3 comments

Comments

@chmac
Copy link
Owner

chmac commented Aug 5, 2021

@lquenti asked about the documentation for the data format. Good point, it's not clearly laid out.

First step, there is an example repo which shows the format, and hopefully it's relatively self explanatory, but ideally it would be clearly documented also. Here's the example file:

https://raw.githubusercontent.com/chmac/do-test/master/do.md

@lquenti
Copy link

lquenti commented Aug 6, 2021

Great! The main question would probably be one of scope:

  • Is there a single type of document or are there multiple ones (Let's say, if the first line starts with # Kanban it is a Kanban document)
  • Which type of views are intended? (Think: Notion, which allows to view data through multiple type of layouts)
  • Which type of interoperability is wanted (If we want some Calendar integration it needs dates, deadlines are great, maybe even some time tracking?)

@chmac
Copy link
Owner Author

chmac commented Aug 6, 2021

I really like frontmatter for this type of thing. But I also wanted the "inbox" to be the start of the document so that I could easily insert tasks, but actually I think that's backwards, having it last is probably smart.

I found that my support of headings and text and then sub headings is all a bit over the top. Maybe there's a simpler way with multiple files, where each file has an intro, and then only one single list or tasks, with nested child tasks. Then hierarchy could be based on folders.

Another question is does the data live in its own git repo, or could it be part of say a code repo. I liked the idea that the do.md file at the repo root is the task list. So my PR could include a change to the file to close that task.

I'll jot down any other thoughts that come up here, and then we can discuss in more detail next week and share our findings back here afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@chmac @lquenti and others