Contributing to Rails? Start with the Gems You Already Use


Summarized using AI

Contributing to Rails? Start with the Gems You Already Use

Yasuo Honda • July 09, 2025 • Philadelphia, PA • Talk

Contributing to Rails? Start with the Gems You Already Use

Introduction

This session, presented by Yasuo Honda at RailsConf 2025, addresses the challenges new developers face when getting started with open-source contributions to Ruby on Rails. The central theme is the practical approach of beginning open-source involvement by improving and maintaining the Ruby gems that one's own Rails application depends on, with a focus on compatibility and CI (Continuous Integration).

Key Points

  • Initial Barriers to Contribution

    • Contributing to Rails can seem intimidating due to its large codebase and rapid closure of 'good first issues.'
    • Yasuo suggests starting with gems that you already use, as these are familiar and easier to understand and test.
  • Suggested Goals for Gem Contribution

    • Ensuring compatibility with the latest Ruby and Rails versions (e.g., Ruby 3.4 and upcoming releases).
    • Keeping CI (Continuous Integration) pipelines healthy ("green") to ensure stability and facilitate further contributions.
  • How to Choose a Gem to Contribute to

    • Review your application's Gemfile.lock to identify gems not yet updated for recent Ruby versions.
    • Focus on third-party gems, as Rails' own dependencies are usually kept up to date by core contributors.
  • Common Compatibility Issues to Address

    • Transition to frozen string literals ("chilled strings") in Ruby.
    • Changes in Ruby's URI parser and the obsolescence of certain methods.
    • Standard library gems ("bundled gems") requiring explicit inclusion in your Gemfile or gemspec.
    • Modifications in how Hash objects are inspected and displayed.
    • Updates in error message formatting (such as quotes and inclusion of class names).
  • Practical Examples and Real Pull Requests

    • The talk includes references to real-world pull requests and examples, such as fixes applied to httpclient and pending changes in capybara.
    • Tips on how to update tests when Ruby changes output formats or error message styles.
  • Importance of Maintaining CI

    • CI ensures your gem works across Ruby versions, catching compatibility issues early.
    • Two main CI types:
      • CI for released Ruby versions (always required for all pull requests).
      • CI for Ruby development versions (helps prepare for upcoming changes but should be scheduled and not strictly required for all contributions).
    • Examples using GitHub Actions to run tests across multiple Ruby versions and with warnings enabled.
    • Recommendations for handling test failures specific to future or development versions of Ruby.
  • Contributing Workflow and Community Interaction

    • Communicate with maintainers, especially when introducing CI for development versions.
    • Be patient with response times for pull requests.
    • Provide feedback or bug reports upstream to Ruby or relevant projects, when necessary.

Conclusion and Takeaways

  • Start your open-source journey by improving the gems you already use, focusing on compatibility fixes and keeping CI green.
  • Addressing these practical, well-defined issues is an effective way to learn, contribute value, and smooth the upgrade path for your Rails applications and the broader community.
  • The talk provides a clear, actionable roadmap for newcomers to begin making meaningful contributions to the Rails ecosystem.

A QR code with slides and contact information is provided for follow-up.

Contributing to Rails? Start with the Gems You Already Use
Yasuo Honda • Philadelphia, PA • Talk

Date: July 09, 2025
Published: July 23, 2025
Announced: unknown

Contributing to Ruby on Rails might seem difficult, especially if you're new to open source. But the first step is ensuring that the gems your application depends on are compatible with new Ruby and Rails versions. Many gems power your Rails app, and improving them is a great way to get comfortable with open-source development.

This session is designed for developers who are interested in open source but don't know where to begin. We'll explore why contributing to gems is an ideal first step—it helps ensure compatibility, improves your understanding of Rails, and makes a meaningful impact. You'll learn how to find issues, interact with maintainers, and submit your first pull request with confidence.

We'll also discuss best practices for running CI across different Rails and Ruby versions and how to address compatibility issues. By the end of this talk, you'll have a clear roadmap to start contributing and making an impact in the Rails ecosystem.

RailsConf 2025

00:00:16.720 So good morning. Um welcome to my talk
00:00:20.000 and I'm very happy to be you know the
00:00:22.160 many people is coming to attend it. Uh
00:00:25.039 it is my eight times raise conf since
00:00:29.359 2012 but this is my first talk session
00:00:33.360 in racecon so a little bit nervous but I
00:00:36.480 will try my best.
00:00:41.600 So today I'd like to share a simple idea
00:00:45.440 for getting started with rails
00:00:47.440 contributions.
00:00:49.520 Uh I will explain a simple and practical
00:00:52.960 way to begin.
00:00:54.960 So this talk includes many real examples
00:00:58.399 like actual pull request links and
00:01:01.840 pages. You can scan this QR code to get
00:01:06.000 the all the slides. Yeah.
00:01:13.200 Yep.
00:01:14.799 So let me introduce myself. I'm a LA
00:01:17.920 commiter since 2022 and I maintain the
00:01:22.320 active record Oracle enhance adapter
00:01:26.000 in LA. I mainly work on the database
00:01:29.439 connection adapters and fixing flaky CI
00:01:33.360 issues.
00:01:36.159 My journey into contributing
00:01:39.600 didn't start itself.
00:01:42.799 I started by contributing to a third
00:01:45.840 party gem for the Oracle database
00:01:48.479 adapter because I used to be a Oracle
00:01:50.399 DBA
00:01:53.280 and you can find me on these social
00:01:56.240 network platforms. My handle name is
00:01:58.880 usually like a YA Honda. It's a my first
00:02:02.399 name and last name.
00:02:08.319 and also I'm a member of Asakusa Arby a
00:02:12.959 one of the biggest luby community in
00:02:14.879 Tokyo. Uh we meet uh every Tuesday. Uh
00:02:19.840 usually recently that we meet online and
00:02:23.200 once a month we met in person.
00:02:26.879 So if you have a chance to come to visit
00:02:29.040 the Tokyo or Asakusa, please let me
00:02:31.360 know. uh we always welcomes the foreign
00:02:34.800 or anywhere the lubist.
00:02:40.560 Okay. So let's go to the the my point.
00:02:45.280 So like contribution
00:02:48.720 looks hard, very difficult.
00:02:52.239 Uh for those who guys are interested in
00:02:55.680 contributions but adding new features or
00:02:59.519 even uh improving the documents,
00:03:03.120 you guys need to understand how the gem
00:03:05.920 works
00:03:07.920 and also in late the unfortunately the
00:03:11.760 good first issues are you know very
00:03:14.560 taken fast. So when I uh checked in
00:03:18.480 early dry all of the good first issues
00:03:22.400 were closed. So there's no good first
00:03:24.879 issue right now.
00:03:27.519 And also the layers has a huge code
00:03:31.599 bases and a lot of the modules. So it
00:03:34.799 may be hard to get know where to begin.
00:03:43.200 So my proposal is like this. So
00:03:48.959 considering starting with gems that you
00:03:52.239 already use and focus on these two
00:03:54.959 things, two goals
00:03:59.360 uh fix Ruby compatibility issues like a
00:04:02.560 warnings uh on the newer version of Ruby
00:04:05.760 like a 3.4 or something.
00:04:08.799 And second, let's keep CI green.
00:04:13.439 I think many people want to contribute
00:04:16.000 but do not know where to begin.
00:04:19.440 These two goals give you a very cleaner
00:04:22.000 and helpful starting point. I believe
00:04:32.000 so. Why does this approach work? the for
00:04:35.360 the compatibility you actually use these
00:04:37.919 old gems. So I think it's easier to
00:04:41.040 understand what gem is doing and easy to
00:04:44.560 should be easier to test
00:04:49.440 and also you can follow the existing
00:04:52.080 progress like I will show the real ones
00:04:55.040 in my talk let's say you know rails
00:04:57.759 address this kind of ruby3.4 for u
00:05:00.720 incompatibility something like that you
00:05:02.560 can refer them as a references
00:05:06.960 the for the CI
00:05:09.120 some gems have no or some gems has kind
00:05:12.320 of broken CI
00:05:15.680 just make uh CI green you can show that
00:05:19.039 your changes are working and uh it will
00:05:22.800 help others contribution
00:05:30.639 So let's say how do I find the right gem
00:05:34.240 to start. So at first uh I would suggest
00:05:38.479 to check your application gem file lock
00:05:42.720 the raise one. Uh I'm not sure if link
00:05:46.720 is working.
00:05:52.720 Oops.
00:05:56.080 Oh, forget about it. Looks like network
00:05:58.479 is not working.
00:06:05.039 So then focus on the gems that are not
00:06:08.800 on the latest gem file lock
00:06:11.840 because the this gem file which is
00:06:15.440 listed in the late gem file lock already
00:06:20.240 3.4 four or maybe the Louis 3.5
00:06:22.800 development compatible because of you
00:06:25.199 know the active contributors including
00:06:27.199 me
00:06:29.199 but uh your gems or maybe I would say
00:06:33.280 the third party one might not like this
00:06:35.840 the so fixing them uh your gems would
00:06:39.280 help you upgrade to use the newer
00:06:43.039 version of Ruby like let's say Ruby 34
00:06:45.120 something like that
00:06:52.720 I got found timer is not working. So I
00:06:55.199 don't know how many time how much time
00:06:56.560 remains but anyway
00:06:59.280 uh
00:07:05.520 so
00:07:07.280 here is a list of the lub 3.4 for
00:07:09.840 compatibility fixes. You can do it right
00:07:12.560 now.
00:07:17.759 One second.
00:07:25.840 Oh, looks good. So, Lub 34 was released
00:07:29.520 in December last year, but it's still
00:07:32.000 quite new.
00:07:34.479 Let's look at some common compatibility
00:07:36.720 changes you can already fix today.
00:07:40.400 I will talk about the chilled strings,
00:07:43.680 URI passer changes,
00:07:46.400 bundled gems warnings
00:07:49.199 and change to hash inspect and changes
00:07:53.440 the error message quotes.
00:07:56.720 I think every each one is a very small
00:08:00.720 and practical. So this will keep your
00:08:03.759 code and gems ready for the latest Ruby.
00:08:12.160 So let's start with the chewed strings.
00:08:14.639 Chew strings might not be familiar uh
00:08:17.039 might be familiar with you but this is a
00:08:19.199 translation phase toward possibility
00:08:22.560 making all string lit the frozen by
00:08:26.080 default in Dub. frozen means uh
00:08:28.720 immutable in Ruby world.
00:08:32.159 So when you run luby with the w dash
00:08:35.360 option, you will get a warning if you
00:08:38.000 try to modify a string material.
00:08:41.839 So this is a kind of common for example
00:08:45.360 uh let's create an empty string then
00:08:47.920 appending the another one to string it.
00:08:51.600 So with the W uh warning is enabled it
00:08:55.600 will get you a warning. This says the
00:08:57.680 literal storings will be frozen in the
00:09:00.800 future.
00:09:02.959 To fix it uh you just use the dot dup on
00:09:07.360 the strings if you need to modify it in
00:09:09.519 other ones.
00:09:12.000 The actually has made this decision yet.
00:09:15.040 I mean I don't know the actually the
00:09:17.519 frozen sta string lit will be default or
00:09:20.399 not but I think uh pre uh it's good
00:09:26.320 opportunity to prepare in advance even
00:09:29.120 though the final decision hasn't been
00:09:31.120 made.
00:09:34.160 So you can see the actual example of
00:09:36.720 these gems like a lubby and HTTP client.
00:09:46.880 The another one is the URI default
00:09:49.760 password changes.
00:09:51.920 So in Ruby 3.4 for the default passer
00:09:55.440 changes from URL RFC 2396 passer to RFC
00:10:02.320 3986.
00:10:05.760 So then introducing this new default
00:10:08.959 passer some method on RSC39
00:10:14.000 like escape and extract like these five
00:10:17.120 methods are obsolete not d dep d dep d
00:10:20.000 dep d dep d dep d dep d dep d dep d dep
00:10:20.000 d dep duplicated but obsolete not
00:10:21.600 recommended.
00:10:23.600 So if you need to use this method,
00:10:26.720 you'll be lubby will show a warning like
00:10:29.120 this. Luby RFC 3968
00:10:33.519 3986 passer escape is obsolete use blah
00:10:36.640 blah blah.
00:10:41.760 So here is a how to fix the warning. So
00:10:44.320 if you want the existing I mean the
00:10:46.640 before the 3.3 behavior is fine use the
00:10:50.079 previous default uh RC29
00:10:54.160 2396 passer directory. So it will just
00:10:57.920 silence the warning.
00:11:01.040 So you can take a look at got this uh
00:11:03.600 example in the lace and the capy bar
00:11:06.959 actually
00:11:09.200 unfortunately or I don't know but capy
00:11:13.760 uh the p request to the cap bar has not
00:11:16.000 been merged yet. So if you use ddb3
00:11:20.079 you get this kind of warning yet.
00:11:26.640 So next one is the bundle gem warning.
00:11:30.480 So, Luby has a term like a bundle gem
00:11:33.680 standard library or blah blah blah. So,
00:11:36.480 the some the standard
00:11:43.279 standard library is like openact and we
00:11:47.040 can bundle them starting in I think lub
00:11:50.240 3.5 in this se December but maybe later.
00:11:55.360 So, this means they won't be loaded by
00:11:58.320 port anymore. So
00:12:01.360 uh and then you not familiar with bundle
00:12:06.240 gem or this kind of term please visit
00:12:09.360 sdddge gems.org. So it explains what the
00:12:12.959 bundle gems are and what is the the list
00:12:15.839 of the standard gem is very helpful.
00:12:21.600 So to fix these warnings added the
00:12:26.079 affected gem to your gem spec or what
00:12:28.800 gem file. So for example if you use all
00:12:33.440 adding the tech should stop the warning
00:12:37.920 but for the open stract please consider
00:12:40.800 to replace the open struct with
00:12:43.360 something else like a stract
00:12:46.000 because openstruct is much slower than
00:12:48.880 stract and uh could cause the security
00:12:51.920 problem. So it's already you know not
00:12:54.079 recommended or not duplic uh it's dep d
00:12:56.639 dep d dep d dep d dep d dep d dep d dep
00:12:56.639 d dep d dep d deprecated in lub3.0 So
00:13:00.320 here are some differences you can refer
00:13:02.720 if you want to fix this kind of waring.
00:13:09.040 So the next one is the hash inspect
00:13:11.760 format changes.
00:13:15.040 This slide shows the uh output
00:13:18.079 differences between the 3.3 and 3.4 or
00:13:21.440 later.
00:13:23.519 So in the Ruby 3.3 or earlier version of
00:13:27.120 Ruby this output used in the hash rocket
00:13:31.200 old style like
00:13:33.920 this the on the above
00:13:36.560 in the lub 34 it switches to the column
00:13:40.320 based format like a column one like
00:13:43.519 introduced in the Ruby one n I think it
00:13:47.519 shouldn't affect the actual application
00:13:50.160 but if your test cases depend on the
00:13:53.440 extract inspect messages they might
00:13:56.240 fail.
00:13:58.160 So you can refer the layers to how the
00:14:02.160 layers handle this one. So it actually
00:14:04.399 instead of writing the test output
00:14:06.720 literally it depends on the hash inspect
00:14:09.519 output.
00:14:15.040 So should be the last one. So the uh uh
00:14:18.399 behavior changes. So let's look at the
00:14:20.880 changes in error messages.
00:14:24.560 Here is a simple example. Uh this tries
00:14:27.519 to add the number one and add string
00:14:30.880 one. So which you know raises a type
00:14:34.079 error as expected
00:14:37.279 in luby 3.3 the error messages shows the
00:14:40.639 method name inside the starting with the
00:14:43.519 backward backic
00:14:46.399 because it's
00:14:49.040 the uh markdown format is becomes very
00:14:52.720 popular this format is not I also I'm
00:14:56.480 not fan of this one so in lub 34 the
00:14:59.839 same message it uses is the just a
00:15:02.639 single quote and also it includes the
00:15:06.079 class name before the method like now it
00:15:09.279 says not just plus but also integer
00:15:12.399 plus.
00:15:14.959 So these changes makes the message for
00:15:17.120 more informative and easier to
00:15:19.120 understand.
00:15:24.399 So if your test compare with the full
00:15:26.800 error message strings so this change can
00:15:29.440 cause a problem. So you will need to
00:15:31.760 update your expected messages to match
00:15:35.199 the new quote style using the regular
00:15:37.839 expressions or something.
00:15:41.279 So this wrap ups the list of
00:15:43.120 compatibility uh changes introduced in
00:15:46.399 34. So there are kind of issues you can
00:15:49.600 help fixing your gems. you use today.
00:15:56.639 Okay, so
00:15:58.959 we've gone through the recent Ruby
00:16:02.240 compatibility changes. Let's go to the
00:16:04.720 the second topic.
00:16:07.600 So
00:16:09.120 some might say why CI matters but I
00:16:13.680 think you know when you or someone fix
00:16:16.639 the Ruby compatibility issues to the
00:16:18.720 gems CI helps confirm your changes work
00:16:22.560 on Ruby versions like you know not
00:16:25.279 should not depend on the just Ruby 4
00:16:27.360 something because if your gem uh if you
00:16:30.399 gems support the older version of also
00:16:35.279 but uh I would say Some gems does not
00:16:38.480 have a working shi.
00:16:41.759 So I believe most of gem have shi but
00:16:45.519 unfortunately some of them the shi
00:16:47.440 status is not green. So the learning shi
00:16:52.320 and makes them green are great way to
00:16:55.199 contribute I believe.
00:17:00.000 So now let's take a look at the two
00:17:01.920 types of I refer in this talk.
00:17:06.160 So they are not official terms but I use
00:17:09.520 this to make things you know cleaner
00:17:12.480 differently.
00:17:14.959 The first one is the released Ruby CI
00:17:17.919 that run to be versions that are already
00:17:21.120 released like 3 4 3 2 sorry 33 and 32.
00:17:26.959 Oh,
00:17:29.120 if the
00:17:31.200 it ensures that the gym works correctly
00:17:33.280 on currently supported Ruby versions.
00:17:37.280 This one is the development lubi. This
00:17:40.799 runs luby under the development like 3.5
00:17:44.799 350 de development.
00:17:48.080 So it will help detect the compatibility
00:17:51.200 change it and prepare for the Ruby
00:17:53.520 releases. So today I just explained the
00:17:56.240 introduced three four compatibility
00:17:58.799 changes but there's another version the
00:18:01.520 Ruby 3.5 is in developed
00:18:04.880 so like a CGI maybe removed something so
00:18:08.160 you this kind of setting CI would help
00:18:10.960 to find this kind of compatibility in
00:18:13.679 advance.
00:18:17.120 So this is what I call GitHub actions.
00:18:23.280 Everyone is be familiar with this one.
00:18:26.799 So this example shows a very basic
00:18:29.600 GitHub actions that runs test on three
00:18:32.880 Ruby versions with warning by setting
00:18:36.320 the Ruby op-W.
00:18:40.240 Yeah, I didn't expect this kind of
00:18:41.840 accident, but
00:18:44.080 okay, I got fine. Finally find this
00:18:47.120 timer is working now.
00:18:50.080 Okay. So the for the released version of
00:18:53.360 Ruby just added run test with lubby op-W
00:18:57.840 or if you are using the RSpec added the
00:19:01.679 dash warning to RSpec file.
00:19:05.520 I think uh some of you uh runs the
00:19:09.120 applications in production without
00:19:12.240 showing the warnings but it's kind of
00:19:14.799 annoying but uh for the enabling the
00:19:17.919 warning for the test would catch the
00:19:20.320 compatibility issue very early so I
00:19:22.720 strongly recommend to enable the warning
00:19:24.720 in the test.
00:19:27.120 So and I would say this test is
00:19:29.280 mandatory. So every uh coming P request
00:19:32.960 must pass this uh CI before merging or
00:19:36.880 before released.
00:19:41.039 So this is the development Ruby CI.
00:19:44.720 this.
00:19:46.320 Yeah, a little bit complicated and some
00:19:48.640 of them do not agree with my but um it
00:19:53.360 helps the catchup compatibility issues
00:19:55.919 before Ruby 35 is officially released
00:19:59.039 this December.
00:20:01.280 So this GitHub action setup runs on only
00:20:04.559 a daily schedule. So it's just on learn
00:20:07.360 on schedule not on you know uh pull
00:20:10.000 request and added workflow
00:20:14.640 dispatch it would allow you to learn the
00:20:18.000 CI this actions manually so don't have
00:20:20.720 to wait until the you know till uh 12
00:20:23.760 a.m. on the UTC.
00:20:26.640 So my gem Oracle enhance adapter tested
00:20:30.880 both with and without wet. So this is
00:20:34.720 not to improve the test performance but
00:20:38.080 uh sometimes uh there were some cases
00:20:42.080 where bangs appeared only when the
00:20:44.240 widget was enabled. So right actually
00:20:47.200 recently I don't see this kind of issue
00:20:49.280 anymore but even though this is barely
00:20:52.320 there now I think it's important to test
00:20:55.120 both configuration but and also
00:20:58.400 uh running this kind of CI would take
00:21:02.000 time so should not require
00:21:04.720 the contributors to pass this test for
00:21:07.039 the p request
00:21:10.720 so let's see which Ruby versions
00:21:13.840 explained in DCMO file the
00:21:18.320 the first one is the head. So it head
00:21:22.240 means the development version of Ruby.
00:21:24.799 So it's as of right now this is a 3.0
00:21:29.440 de development.
00:21:32.240 So it should could be unstable because
00:21:35.760 it's uh activity development. So and
00:21:40.400 this is the kind of the default uh Ruby
00:21:43.200 350 de version. The second one is the
00:21:48.000 Ruby version is called debug. So this
00:21:51.360 Ruby is built with the additional
00:21:54.720 runtime checks. So I don't remember the
00:21:57.440 exact name but you know it would help
00:22:01.520 the
00:22:03.919 help define the additional runtime
00:22:06.159 checks. So as far as remember it helped
00:22:09.679 me uh finding the one of the assertion
00:22:12.240 failures when I tested Ruby 3 or 34
00:22:16.240 maybe and then the recently uh Ruby
00:22:21.760 core team or provided the asn
00:22:26.159 luby build it stand for the address
00:22:28.480 sanitizer.
00:22:30.559 So it's a mandatory uh memory checker
00:22:32.960 that helps detect memory corruption or
00:22:35.120 embedded addresses.
00:22:37.520 The this AS
00:22:40.159 uh build requires the Ubunt. So right
00:22:43.039 now Ubunt44
00:22:46.559 and we also enable the warning with D-
00:22:50.000 debug frozen string literal. So I
00:22:53.200 explained the cheer strings and this by
00:22:56.080 adding this option
00:22:58.320 it will tell you the where the string
00:23:02.320 was created. So the the just the
00:23:04.960 previous warning just said if the string
00:23:08.000 is mutated but uh it doesn't tell where
00:23:11.200 the original string was made.
00:23:14.799 All of so the Ruby versions are built in
00:23:17.520 daily. So if you are running this test
00:23:20.240 against uh this kind of development
00:23:24.000 version of Ruby uh you can you know make
00:23:27.200 sure your application or gems work with
00:23:29.760 Ruby 35.
00:23:33.919 Here are some quick tips for the
00:23:36.320 development Ruby CI. So please make sure
00:23:38.720 to check the Ruby-B. So it shows the the
00:23:42.480 commit hash in this examples luby 35
00:23:46.080 master 364
00:23:48.240 something something it's a commit hash
00:23:50.000 of the loop
00:23:52.080 so it would helpful when something
00:23:54.400 breaks and als uh please remember the g
00:23:58.080 bisect
00:24:00.799 recently uh you might not use it now but
00:24:03.600 it can help to debug which commits uh it
00:24:07.280 will help you which ruby commit breaks
00:24:09.679 the behavior
00:24:12.159 And also uh considering removing the
00:24:15.279 currently gem file log and add bound
00:24:17.840 install to the newest gem file versions
00:24:20.159 instead of keeping the old one because
00:24:23.600 some fat gems like a noiri or maybe um
00:24:27.120 some other gems might not be may not be
00:24:30.640 available for the development version of
00:24:32.880 Ruby because it's actively developed.
00:24:36.960 And if this CI fails that's fine as long
00:24:40.000 as uh release CI is green
00:24:46.000 and then you know working with community
00:24:48.559 is very important. I think some
00:24:51.600 maintainers may not prefer the CI
00:24:54.240 against the CI with the Ruby 3.5 but if
00:24:58.320 you think this is helpful explain why
00:25:01.200 please you know have a good
00:25:02.640 communications with maintenance
00:25:05.520 and also if you find some issues please
00:25:08.240 give a feedback to the bugs Ruby or
00:25:10.799 GitHub issues
00:25:13.679 and if you have a chance to open the
00:25:15.520 pull request response may take time so
00:25:18.080 please be patient. and it's very normal.
00:25:24.640 So let's talk about what you can start
00:25:26.400 doing today. So find a gem you can
00:25:28.880 contribute and test for the
00:25:30.720 compatibility issues and set up for the
00:25:34.000 CI and then for submit for your first
00:25:37.520 maybe the contribution to the EM.
00:25:44.159 So thanks for listening. So this QR code
00:25:47.039 describes links to the today's
00:25:49.600 presentation. So find me on these
00:25:51.279 platforms. Thank you.
Explore all talks recorded at RailsConf 2025
Manu Janardhanan
Christopher "Aji" Slater
Hartley McGuire
Yasuo Honda
Ben Sheldon
Chad Fowler
John Athayde
Mike Perham
+77