I feel like automatically-modified state doesn't belong in configuration files.
Storing tasks in config.yml creates unnecessary git noise for us, as well as requires caution so that changes done on staging won't be propagated to production configuration.

I would love if task information could be stored in a separate file, that can be ignored.

I understand this is small priority compared to other issues, but would love to at least get opinion on this.

@Prof-Bloodstone @vitaly-rudenko As of commit 309d3e1 tasks are now loaded separately from the configuration file.

I fully agree with you. I borrowed the idea of storing the tasks in the config file from the classic WorldBorder plugin (which Chunky is heavily inspired by), which has been doing it that way forever. It was also obviously an easy shortcut to implement this way instead of two separate files. In hindsight it's a bit silly.

I plan on addressing this eventually, but it's been lower priority. Right now, everything for the most part still works just fine, aside from the fact that it isn't possible to reload the configuration while tasks are running (easily worked around by pausing, then reloading). The issue you mentioned about wanting to copy files from a staging environment is new to me, but it makes sense, and it would be nice to accommodate that workflow as well.

I may coincide this change with auto-save, which is something I have been considering. I have avoided it since I don't want to be automatically editing the config file unless the user takes an action (e.g. pausing / resuming), again to avoid the possibility of changes being overwritten.