[Terretta]

> this is definitely one of those things which will require changes across most packages of the project code

While iterative development is the best way, there's something to be said for staring at a whiteboard full of the most common calendaring use cases, and being sure before starting the basics that the data model and code factoring "plan" support foreseeable uses, particularly "must have" ones.

This gets lost sight of in most Agile™ teams, maybe even more so than with solo-dev.

One way to do this in a reasonably light and OSS-friendly way is to pre-write the essential features README for the tool (event recurrence is an essential calendaring feature), then go through and mark them as TODO or blank checkboxes or etc., letting people contribute.

If you've architected the code structure a bit towards those things, the contributions / PRs are easier too, as the third party contributor isn't trying to refactor out from under everyone.