:INFO [align:center]
A note on inheriting thicket
This library parses and re-emits iCalendar files and has done since 2013. The person who wrote it stopped answering in early 2024. In October I asked for the commit bit on a project I had contributed to exactly twice. This is the note I wanted to read before I said yes.

|
:INFO
How This Happened
There was no handover. There was an issue titled "is this project still maintained?" with fourteen thumbs up and no reply, and underneath it a comment from somebody offering to help that was also unanswered. I emailed the address in the gemspec and got nothing. Six weeks later I emailed again saying I intended to ask the registry about adopting it, and that one got a two line reply: yes, go ahead, sorry, I have not had the energy for a long time.

|
:TIMELINE
The handover
2013-06-01 | First release. Written by one person for one consulting project that needed to read Outlook invitations.
2019-11-01 | Peak. Six contributors in a year. Almost every Ruby calendar integration ends up here eventually.
2023-08-01 | Last substantive commit from the original author. Nothing dramatic in it. It just stops.
2024-02-01 | "Is this project still maintained?" opened. Fourteen thumbs up. No reply for eight months.
2024-10-01 | Two line email. Yes, go ahead, sorry. Commit bit transferred four days later.
2024-11-01 | First release in fifteen months. Contained nothing new. Only the four security advisories.
|
:INFO
What I Found Underneath
Better than I expected and worse than it looked. The parser is genuinely good, carefully written, and clearly the work of someone who had read the RFC properly rather than guessed. Around it were 340 open issues, a test suite that had not run on a supported Ruby in two years, and four dependency advisories that were all trivially fixable and had simply been sitting there because nobody had the keys.

|
:STATS
|
:INFO
About The Person Who Wrote It
They gave eleven years to something they were not paid for, and then they stopped, which is allowed. The reason there was no handover is that there is no mechanism for one. Nobody asks a volunteer to write a succession plan, and by the time it is needed the person who would have written it has already run out of the energy required to write it. This page exists partly so that the next transfer of this library is less improvised than mine was.

|
:QUOTE [quotetype:plain, subtitle:from the reply that transferred the project]
Sorry, I have not had the energy for a long time. I kept meaning to write something and then it was easier to not open the tab.

|
:CHECKLIST
What I have actually fixed
[ ] Four dependency advisories, in the first release after taking over
[ ] CI running again, on every supported Ruby rather than the one from 2022
[ ] The timezone handling for all-day events, which caused about 40 of the 340 issues
[ ] Triage on every issue older than a year. Most were closed. Some were just answered
[ ] A CONTRIBUTING file that says what I will and will not merge
|
:CHECKLIST
What I have not fixed and probably will not
[ ] The recurrence rule engine. It is correct for common cases and wrong for exotic ones
[ ] Streaming for very large files. Requested since 2018. It needs a rewrite I do not have time for
[ ] Windows path handling in the file loader. I have no Windows machine and will not guess
[ ] Anything requiring me to break the API. That decision is not mine to make alone
[ ] The 180 issues still open. Realistically most will stay open
|
:INFO
What I Will Not Do
I will not pretend this is a thriving project. I will not add features to make it look active. I will not accept a pull request I do not understand well enough to fix at midnight when it breaks, no matter how good it looks, because merging code you cannot maintain is how a project gets abandoned twice. Everything I have merged in eighteen months, I could rewrite from scratch.

|
:INFO
If I Stop
Somebody should be able to take this over without the eight months of silence I sat through. So: the gem is owned by two accounts rather than one, the second belonging to a person who has agreed to hand it on rather than to maintain it. The CONTRIBUTING file names them. It is not a succession plan. It is a phone number, which is one more than I had.

|
:CHECKLIST
If you are considering taking on an abandoned project
[ ] Read the last two years of issues before the code. That is the real workload
[ ] Check whether the original author is unreachable or just tired. Ask twice, kindly
[ ] Fix security and CI first. It buys goodwill and it is finite work you can finish
[ ] Write down what you will not do, publicly, in the first month
[ ] Find one other person for the registry account before you need them
|
:LINK
https://rubygems.org/gems/thicket
thicket on RubyGems
|
:LINK
https://github.com/thicket-rb/thicket/blob/main/CONTRIBUTING.md
What I will and will not merge