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

[FR] Quarterly file support #90

Open
1 task done
zalegrala opened this issue Feb 9, 2022 · 3 comments
Open
1 task done

[FR] Quarterly file support #90

zalegrala opened this issue Feb 9, 2022 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@zalegrala
Copy link

Please confirm

  • I am running the latest version of this plugin

Is your feature request related to a problem? Please describe.

Some organizations use a goal-setting process called OKRs, where once a quarter you set some goals. It is now that time where I fill out mine and submit them up the chain, but in thinking about and using telekasten for the last few weeks, it occurs to me that much of this could be wrapped into this plugin if quartelry support were added.

Describe the solution you'd like
In the same way that we have a weekly template, and a weekly file, I think having a quarterly file and template would be pretty great. Template variables like {{thisquarter}} or {{lastquarter}} or some such could also be handy. A weekly template could have a link to this quarters goals to make it easier to refer back, etc.

Describe alternatives you've considered
Right now I'm using a tag to go back to a file that I know has what I want, which is just a weekly note.

Additional context
Quarters are not always aligned to the year, so having a way to tell when the quarter starts would be handy, but perhaps tricky to implement.

@zalegrala zalegrala added the enhancement New feature or request label Feb 9, 2022
@zalegrala
Copy link
Author

In thinking about this a little more, I think it would be sufficient to have a template variable that would be able to contain the quarter. Perhaps there could be a config variable to say when to anchor the quarter beginning.

@lambtho12
Copy link
Member

lambtho12 commented Feb 16, 2022

it would be sufficient to have a template variable that would be able to contain the quarter

Agree. I do not think it is necessary to have a specific file for each possible subdivision. People will want semesters, bi-annual, bi-weekly, whatever else and we will never see the end of it.

What we could do instead is creating a goto_specialDate() that would always start by prompting the user pick a template (monthly, quarterly, whateverly) and save them in journal/special/ with a custom filename like S2022-<your_input>.md. The custom filename with a fixed part would help telekasten determine if it is a regular note or a Special Date note. In addition to that, some simple templates for quarters, months, etc could be added.

For changing the Q1 reference date, I do not exactly know how we could do it. Ideally that would happen within the template itself. So if you make quarterly notes for multiple companies, you can align each note on the appropriate calendar. Maybe adding a {{quarterstart=DD-MM}} somewhere in the template would be the easiest solution.

I also feel that if we go that route, we should refactor a bit and put the templates variables and the calculation of dates in a separate file so it becomes easier to maintain (actually, the code could benefit from a good refactoring where we would split the main blocks in different files (pickers, date calculations, templates, helpers,...)

@lambtho12 lambtho12 mentioned this issue Mar 6, 2022
1 task
@zalegrala
Copy link
Author

The more I use this plugin, the less I think this is specifically required. I like the discussion on the Custom Date Format. What I've done is just put the specific quarter I'm referencing as a link in the template, and then once a quarter I will change one number. That seems reasonable enough to me. We can leave this open if you wish, but the other conversationin #101 with a more general approach to flexibility seems like a better approach to me. Consider this a mostly non-issue for me at the moment. Thanks for the discussion.

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

No branches or pull requests

3 participants