Looking at @aycabta (aycabta .) 's GitHub activity, he's been inactive on the Internet for 6~7 months, which means that IRB hasn't had the maintainer during that period of time. While I managed to sneak in some IRB changes when he was active, I personally have some more IRB changes that I want to make, but I'm not sure if we're gonna make it to Ruby 3.2 since we can't predict when he'll be back and there's nobody taking the ownership of the IRB design now.
However, I don't think the 2nd most active contributor (@nobu (Nobuyoshi Nakada)) is particularly interested in IRB, and the 3rd most active contributor (myself) currently doesn't have capacity to maintain anything new. So having a temporary maintainer from existing committers could also be hard.
I propose to make Stan Lo (@st0012 (Stan Lo)) a new committer and a co-maintainer of IRB.
He's best known for being almost as active as @ko1 (Koichi Sasada) in recent debug.gem development and I think he deserves maintainership in the Ruby's debug tooling area in general. While he has fewer contributions to IRB, some modules of IRB (which I authored, so I should have a say) are used by debug.gem, so I believe IRB being maintained by him will also be useful for the success of debug.gem and Ruby 3 tooling.
We have no active IRB maintainer who is responsible for making technical decisions and maintaining IRB and Reline for a long term.
My primary interest in this ticket was to address (1), hopefully solving (2) as well. However, given the highly complicated nature of IRB around Reline, having a co-maintainer of IRB in the absence of the current maintainer could result in design decisions that conflict with @aycabta (aycabta .) 's vision, which might make the long-term maintenance hard. So we discussed an idea to address only (1) for now, waiting for @aycabta (aycabta .) about (2) in the meantime.
@naruse (Yui NARUSE) raised the following idea of partial maintainership and @matz (Yukihiro Matsumoto) approved it. (I got asked to post this summary myself first, which he may leave a confirmation comment on later.)
We also discussed the idea of handling IRB command inputs that are not valid as a Ruby expression, and the meeting attendees agreed to make this change.
We discussed this again in the DevMeeting-2022-12-15. We agreed to make the following changes after the Ruby 3.2 release. Now that Ruby 3.2 is released, I'm publishing this update and making permission changes on the IRB repository.
Updated by 
Updated by 
Updated by