Offering to co-maintain Recurring Dates Field

Thanks @joelpittet for accepting my offer, happy to work with you on the project, and appreciate any time and experience you have to offer.

Pasting a general guide/intro of how I maintain this project, and others, for ongoing collab.

• Major versions, only new if breaking changes in the project itself. Not changed for core compat.
• Minor versions, increase depending on the current state of PHP x Drupal core.
• Currently maintained versions are posted to the project page. Info for old versions is posted to a wiki page.
• Features usually only go into the very latest branch (one branch), but sometimes they will get backported.
• I will often re-roll and either commit or push changes to a MR, instead of waiting for this kind of feedback from contributors.
• I generally lack the experience for multilingual. As an Australian we rarely deal with non-English. So any help here is always welcome.
• I really prefer tests, and will often delay a issue just on tests. However for Views integration in particular, I'm happy if things are well-tested by hand. I understand Drupal testing for Views drives insanity.
• Pipelines need to be green before any new work is merged, and I intend to keep the latest branch green. I'm not concerned about older branch testing, even though they are officially maintained. PHPCS and PHPStan also need to be passing in full.
• I usually push PHPStan fixes and PHPCS updates myself to MRs and merge-on-green. I decline any MRs with CS changes.
• Notably, the project uses a high PHPStan level. And PHPCS uses a custom ruleset which is less picky than the default coder rules. In general, all CS rules should be autofixable (phpcbf).
• I don't have any big picture plans for the project, so if you want to drive something I'm open to it.
• I'd welcome it if you are open to also maintaining Date Recur Modular → .
• There is a widget from the old branches of DR at https://www.drupal.org/project/date_recur_interactive → , but this is unmaintained.
• At most, my primary use of this project in the context of sites I maintain is in partnership with https://www.drupal.org/project/oh → , which is largely a non UI use of DR. So you can see why I would rarely need to interact with this project.

I thought this would be a good starting point, and to clear where I stand going forward.

Updated maintainer config.

Thanks!

Thanks for setting such clear expectations—really appreciate the thought you’ve put into it.

Just to reassure you: I don’t plan to make any big changes without checking in first. For smaller fixes or features with tests, I’ll likely commit directly. With Views-specific changes, I’ll make a best effort to include tests, but if it starts getting too sanity-draining, I may commit without them (with discretion, of course).

I’ve worked with multilingual at a surface level—some in contrib, some in core dev—but only a few actual projects. One was even just US vs. Canadian English, so… not exactly a stress test 😅 Still, happy to help there where I can.

Tests (especially for Views) are something I struggle with too, but I’m actively working to improve on that. I’ll do my best to keep the 3.8.x branch green—mainly because I need it for a D7 to D10 migration (blocking D11 until dependencies are sorted). Eventually I’ll relax that, like you mentioned.

As for big picture stuff, I’ll try to surface it openly in issues, though I may check in over Slack first if something needs a quick sanity check before wider discussion.

Lastly, I just want to say I’ve noticed and appreciated the attention you’ve given to timezones in the past (recalling from previous issues), and the architectural choices—especially the split between the date field and occurrences table in the DB. I think it's a nice setup and inverse of D7’s date_repeat and D8+'s smart_date database structure.

especially the split between the date field and occurrences table in the DB

I will not try to take credit for this, this was from my predecessor. Though the way it is put together changed significantly; made non-pluggable, as it was formerly known as "pluggable occurrence backends", as referenced in credits on project page.

Might add extra project management notes in this issue as we go along.

Git commit messages, standard Drupal, except I add an emoji according to https://gitmoji.dev/. E.g, new features ✨, bug fixes 🐛, linting/cs 🚨.