 How's everyone doing? Let's hear it. Oh, it's pathetic. Come on. I made it here. You guys made it here. Act a little more excited than that, please. Thank you. No, not yet. Save that for the after party. All right, so today, we're going to talk about Ruby Core for tender feet. No, I don't mean Erin, but well, kind of. No, today, we're going to talk about, so contributing to open source has been kind of a theme of this conference. There was, you know, a few talks about it so far. But we're going to talk about specifically Ruby Core, and I want to talk about these four main things. Newcomers, progress port, some things I've been working on. Working with the team and roadmap with some stuff we have going on. I know Koichi covered a lot of the technical details. I'm just going to cover some of the things that I think are important. Not just specifically Ruby Core, but just things that affect everyone, and we should be concerned about. And I'm Zach. I kind of need notes, I guess. All right, so yeah, I don't want to focus on like the technical details. This isn't going to be a very technical talk, so hopefully ease into your morning with some information to help you. We're not going to cover how to run the test suite in Ruby or like, you know, really contributing guidelines or like, you know, how to report a bug. I think Shibata-san's talk, his lightning talk yesterday covered that pretty well, and a lot of that information is already available on the internet. And if you weren't available around for Shibata-san's talk, his slides are online on speakerdeck.com slash HSBT. So check that out. I really want to focus on, you know, what I've been learning from Ruby Core and what we can learn from each other and work together to, you know, to contribute. So our intended audience is definitely newcomers. I think there's a lot of people in here that probably haven't contributed to Ruby itself, and I want to change that. There'll be more later on this, but let's briefly talk about what I mean. You know, maybe some of you, you know, I think Brandon did like a show of hands of how many people have contributed to open source or have their own pet projects in open source, and that's great. But specifically I'm talking about someone that's like, like I really want to focus on people who maybe have an idea of something they want to do with Ruby they want to work on, but they're not really sure, you know, like how to do that, like how to collaborate with us. And like I want to give you basically the confidence to do that. And so that's what we're gonna basically, that's our goal by the end of this talk. I want you to have the confidence to work with Ruby. So everyone has to start somewhere and you know, some of the things that I've been working on specifically Ruby has been working on finding new contributors, onboarding people, adding new core committers and helping them, you know, learn the ropes and like fix some patches and stuff. And Ruby was working on maintaining 187 and 192 with Terrence from Heroku. But that's gonna come to an end. Actually, we're gonna make an announcement really soon and hopefully like just kill that by the end of next month. It was supposed to be this month, but just been like busy with stuff. And definitely like one of the more important things which doesn't get a lot of appreciation, I think, at least like is security announcements. Like these are super important, whether or not like there's vulnerability, like teaching people, you know, like what's how their applications might be affected by Ruby and or the things that Ruby's built upon. It's really important stuff. And I wanna, I've been working on that as well. I also joined the Rails team iron commit bit to Rails. That was big, important news for me. Been working on fixing a lot of regressions, helping get like 406 out and 412 and contributing documentation, mainly helping people who wanna contribute and have patches like clean it up so it's acceptable and get it merged in basically. And basically just anything Rails. So I'm actually one of three people that have commit to Rails and Ruby and now Sinatra 2, which is kind of crazy. But I do have plans like to work on these things. Like I have been working on this stuff. Me and Constantine have delusions of grandeur for what Sinatra 2 should look like and there's been some code written and we're definitely gonna use bacon. Like the three other people that were at the bar last night when we were having like this intense debate about like our spec versus mini test might understand that one if they still remember. Between that and like Keith's magic tricks but he's all out of flame. So I've been traveling a lot, made it here. I also went to South Africa, gave a talk. I went to the Philippines, basically just follow Winston around and like get him coffee and stuff. It's really great. I fucking love you Winston. Yeah, thanks for having me man, this is great. So we wanna talk about different types of contributors. I kind of brushed on like what kind of, what we're targeting and newcomers. We talked about the beginner and I guess entry level or whatever you would call it. But there's also, there's engineers out there. There's engineers in this audience. Definitely people who have like way more experience than even I do. As I saw like with the Elixir Erlang talk yesterday, I had no idea what the hell I was talking about but it sounded really cool. So how do we convince people like that to like give up on Elixir and come back to Ruby and actually use that amazing knowledge they have? Cause really like you can do that stuff with Ruby. I mean you generally don't but somebody out there uses flip flops so someone needs to maintain that. But above all else, everyone here is a contributor to Ruby in one way or another. And if you're not yet convinced, I have a plan right now to turn you all into contributors in one way or another and I need two things. First I need everyone to stand up. And then I need Aaron. Where's Aaron? He's pooping. Timing. We have time. I don't have a whole lot of slides. Just keep standing. I'm gonna drink some coffee. Is he really pooping? That would be ridiculous. I think I saw him leave but I was like that wasn't him, it's some other guy. Yo, maybe I should yo him. I'm gonna yo him. No internet, yo needs internet. Guess. It's tender love. Everyone should yo Aaron right now. If you have yo, yo at tender love. There he is. You know what today is? It's freakin' Friday, let's do this. Who's got a camera? There's a camera. Thank you. Seems like everyone's ready. Yeah, so you're all part of this community now and you're all contributors to Ruby because not only did you do that but you're here. You came to this conference, you company helped sponsor this thing. That's how this stuff happens. This is great. We talked about different types of contributors. What about the actual people on the team want to introduce you to some of them? So you have an idea of what you're actually getting into, right? So I want to break it down into basically three main categories. There's companies, either for profit or not. There's employees, full-timers, part-timers, hobbyists, even I guess you could consider their weekend job, Ruby. And then there's Matt's. He's in the league of his own, that guy. He doesn't even, Shabbat is on how to slide is like, who works on Ruby? And it's like Matt's? No. I still count him because he, I mean he kind of like answers Skype calls sometimes and stuff. But if we break it down into these four groups, like the main companies that we see on the team are GitHub, Cookpad, Heroku. There's some people in Red Hat with Commit. And of course AT&T hires like three full-time employees. And, I mean, we have from the left, Tenderlove, Kintel Marata-san, and that's Nobu with a beard, if you can. He works at Heroku. Nobody really knows that guy though. Yeah, and then we have Matt's. Which without him, Ruby wouldn't be possible. We wouldn't have any of this stuff really. So that's great. But there's a lot of people on the team, not just those guys, not just those companies. They definitely contribute a lot. And what they do is a great help to the language and the community. But we have these people that you can rely on. And since Ruby has grown to this level of maturity as it is, so is the code base. And it's grown drastically. And there's like a ton of libraries and a ton of code in there that we have to maintain. And so basically we break it down. Certain people have taken over gems in the standard library and they maintain them. And those are the go-to people for certain problems, right? And so it's important to recognize who works on what and how to get a hold of them. And that's really, depending on what you wanna touch in the language, that's really the place to go. Outside of library land, like Koichi's, that knows a lot about garbage collection. So if you have a question about performance stuff, you'd wanna go to him or you could go to Nari. But there's lots of people on the team. I think there's almost 100 committers at this point. Not all of them are active, but they all have their place in the team, for sure. And what they really help us maintain the important parts and help others understand why certain things exist. When you take ownership of something, you kind of have to know why it's there and why it's important. Whether or not there's a better gem out there or whatever, doesn't matter. It's still in the language and we still have to work on it and make it better. So for the last few years now, we've been releasing pretty steadily once a year and we've been doing this minor version bump thing on Christmas, that's really great. It's very semantic. It's Christmas-driven development. But our main focus is making Ruby better each year. Each version is better than the last, right? And we wanna encourage you to use those versions in your applications when testing Ruby, when considering things you should definitely be forward-thinking. And if possible, definitely use Tronk whenever you can, even in production. Like, it's my best advice for you. But this requires a lot of communication and given the separation of team members and location and region and stuff, this is kind of an issue. One way we solve this is we have semi-regularly developer meetings. So we schedule these whenever possible. There is one coming up, Shabbat is on his computer outside to ask him, there is one coming up for like feature, there's like a feature developer meeting where you can submit any feature requests you wanna make in. I'm pretty sure this hasn't happened yet. But so if you have like a feature you wanna submit to Ruby, you can submit it and then put it in the agenda for this meeting and we'll discuss it. And basically, it ultimately comes down to Matt's if it's a hard decision in any case. So he gets to be like yes or no and it's a great way to get instant feedback because we sit down whoever is available, whoever we need in the meeting depending on what is going to be discussed and basically go over this stuff and make decisions. And try to scope the next version of Ruby. It's very, you know, we use these meetings to kind of track our progress and plan things ahead of time. We also have RubyKaiki, which is like an annual conference in Japan that it's very important for us to get everyone together. And this year it's gonna be in September and you should definitely go. Tickets aren't on sale yet, I don't think. But as soon as I do, you should grab one. It sells out pretty fast. And it's not as expensive as like WWDC. I don't even have a good joke for that. I wish I did. But the best part about it is we do this thing called the Committers versus the World. And what this is is like a live Q&A session where we take a stage roughly this size and we sit everyone down in chairs and then you guys ask them questions and they answer them. It's like a great, it's a great, great deal. But it's another way to get instant feedback and pick our brains and figure out what you're interested in and ask us questions like when are we gonna move to get or whatever and Matt's can like dodge them. It's pretty funny to see. And of course, a lot of people are worried about this language barrier thing. And the good thing about the Q&A session in Kaigi is all the Japanese talks, including that, have translators as of last year to English. So even if you're not fluent in Japanese, you can still go and you can ask questions in English and it's fine, it's a great time. But people still worry about this outside of this context in the mailing list and stuff. And so I want to kind of touch base on this. As you know, we have a lot of Japanese people on the team and not all of them speak great English. And so you kind of wonder like most of the internal discussions that take place between them are definitely in Japanese. Like they don't revert to English just because they're talking about something important in Ruby, they use their natural language. And that's fine. Like they should just be able to communicate however they want. But when it comes to public facing stuff, we're getting better at translating the stuff, having someone take notes at the meetings so that we get an English version available for other committers that couldn't make the meeting and get everyone synced on the same page. I think this is really important. Not everyone speaks Japanese. And they've been doing a great job at the translations. And so that's really good to see. Still, I've been doing my best to learn about the culture so that I can help with the team and understand things better. And I've been trying to improve my Japanese skills. It's really hard. I've been studying for like a year now and I knew enough to copy that kanji down. That one I didn't draw. The first time I tried to draw a go, I was like, that's terrible. I can't write kanji yet. But I can definitely type it, which is important. So I do have a shortcut for learning the language. And as you'll see, it basically comes down to the more beer I have, the more Japanese I know. Those are supposed to be beer bottles, I guess. So funny story. I was actually, I was in Japan for Oedokaiji and Sasadake, Koichi's wedding party. And getting the point where I can kind of figure stuff out. And I was like working in this cafe with a few friends and I was just like drinking coffee all day. And I really had to go to the bathroom. And so I went to the bathroom and there was like a sign on the door and it was all in kanji. And I was like, oh, this must be important. But the other bathroom didn't have a sign. So I was like, what could this mean? But the other bathroom was a woman's bathroom. And I wasn't confident like going in there as like, I don't know the culture of that's like kosher or whatever. So I went in there, I did my business and went to go flush the toilet and didn't freaking flush. So I just like walked out of there ashamed and like never went back. I was like, no, I can never go to that place again. They're gonna remember that guy that didn't read the sign. I don't know why that's relevant, but. The trials and tribulations of me, I guess. So moving right along. I wanna help make you to avoid making the same mistakes that I have, definitely don't do that. If you see a sign on the door like and you don't understand it especially like don't go in there, just don't go in there. Yeah, so when we're working through the core I wanna provide you some great tips to getting your point across and how to connect with us, how to really get your point across. And the first step is open a ticket. You would be surprised how many people forget this step and it's like, well, did you do anything about it? You're just like tweeting at me about this. Like I have no idea what you're talking about right now. And it's a super important step. People always overlook it but it's like the most important step, make a ticket and sign it and Shabata had the notes yesterday how to report their stuff in the Wiki that will tell you that it's really simple. Let's just read mine, it's not like rocket science. If you don't hear back from us after a little while definitely ping us on the mailing list or if it's not, you know, some cases like maybe you don't need a ticket. Like there was an instance recently where we really needed a release. And so Aaron just like sent an email to the team was like, hey, what are you doing about this? Like is anyone planning to do a release? And then they're like, oh yeah, totally forgot. Like open SSL has this weird bug and like it's segfaulting on Heroku every day. Like please just release it. Effected a lot of people. So it was really like, it's a really great step to just like send an email, ping people, ping the right people and you know, CC them or whatever. And you can easily do this just by sending an email to rubycore at rubylaying.org and you don't even need an account or anything. I'm pretty sure it just goes right through. Yeah, so I kind of touched on this. If it's specific to like a feature or you know, something important, add an agenda item to the meeting and you know, tag the ticket that you set up or if you don't have a ticket like I've put questions in there before like something, something and you know, I didn't attend the meeting because it was like 2 a.m. Pacific time. So I missed it. But I got a nice little feedback and you know, in the meeting summary that was like, oh yeah, you know, someone talked about this. This is how you do it, whatever. And that was great because I didn't have to like bother anyone with an email. I just like put a one line thing in there and they're like, oh okay, we can talk about that. It's on the agenda. It'll just take up people's precious time. And last but certainly not least, Nobu, he's like the key to everything. And especially in ruby, like if you have a question just ask him, he probably knows it. So yeah, if all this fails, those are your basically like four pro tips to bottom line contributing to ruby core. Learn Japanese, avoid doors with signs and ping Nobu. Onward and forward, I wanna talk about the roadmap we're almost through this thing. I'm doing great on time. So I talked a little bit about the wiki. I've been kind of cleaning this thing up. There's certain stuff that like doesn't quite belong or it's like misguided. It's hard to find, it's buried, whatever. It's like no one really wants to work on this thing. It sucks. It's like, you know, it's a wiki. Like who wants to deal with that? But it's actually super important and anyone that goes to the issue tracker should be able to find like exactly what they need and like in relatively quick succession for the things they want and the things they wanna do. I'm gonna keep working on bringing, you know, more people onto the team doing things like, you know, this talk for example and getting people to understand how we work as a team and so that they can better contribute and help us out. That kind of covers that. And eventually I wanna retire someday. So that's why we need everyone here to start contributing. So, you know, my job's a little easier. I can work on other stuff such as RDoC. You probably don't even realize you have it on your system but it's super important. And if you install a gem, you probably like opt out of the documentation but you shouldn't. You should install it. I'm telling you right now. I know it sucks and it's really slow but I wanna make that, I wanna improve that. Definitely starting with Rails now that I have commit I am like fully focused on making the API docs better and easier to find what you need and differentiating between public and private API because Rails has some funky stuff that they do with private methods and public methods are actually private and blah, blah, blah. So working on that, the speed thing, it's really bad like installing Rails takes like 30 seconds to install the documentation. That's ridiculous. It shouldn't take that long. It should be like, you know, instant. It's just some files. Like how long does it take to download like five megabytes or whatever? Maybe it does take 30 seconds. No, there's definitely some improvements we can make there. And the internationalization thing is really important. So one of the other committers recently added support for this in the source. So you could have inline translation, not inline translations, but you could have translations in a similar way that you would have translations in a Rails app. Like you would just have a folder with your translations and you would tag a method or something. So our doc finds out about this method and picks up the translation, the language you want to use. And we're trying to get that out in like the next major version of our doc. But it's definitely like almost ready. And then we eventually have to start writing docs. That's the hard part. We do have Japanese and English docs. And we are working on improving that situation, which is great. Shibata has put a lot of work into this. The Japanese site recently got a facelift and looks something like this, which is much better than if you look at the English our doc generated output, which I've been working with someone to try and get them to redesign the pages because it's like horrible looking and like really hard to find stuff. Someone did recently go through and make all of the pages really accessible for like for blind people so that they can reason about the documentation and find methods and do searches and stuff. And it'll like, you know, it'll read it out to them or do all that awesome stuff for people that wanna learn about Ruby and can't get there. I kind of been playing around with this idea, having a contributor site similar to Rails. So sometimes in like some of my slides, I have like and I think Koichi has a slide where he does like Nobu's patch commit like account. And so I wrote some like script stuff like using the git gem, I think, so that I could like find out, you know, who had the most commits last week or stuff like that. And I wanna like, we basically could build a similar site to this, which would be great to see Nobu at the top of that thing. And you know, like five other people. But you know, we're gonna get there and like this is the things that I think are important. There's definitely other stuff that people are working on that are super important, you know, performance improvements, et cetera, et cetera. And you know, let's work on it together and let's work together to make Ruby awesome. And I'm Zach and thank you so much. Any questions for Zach? Hey Zach, you mentioned that the bad people are not installing RDoC and that you don't want them to. How do people actually make use of RDoC on their local Dev machines? There's two ways. You can run a local RDoC server, which will load the documentation dynamically and serve up the pages for you, just load up the, in your browser. I think it'll even open your browser for you or something. But there's also RI, which is command line, which is great. So you can also use it like if you're in IRB already. So you just type like help and then like the constant name and like the method or whatever, like an instant method. And that'll like load up the documentation basically in like a less and let you like peruse around and stuff. It's really great. I use it all the time. Ooh, thanks. So I think the primary reason people that use RDoC is that when you're installing gems, it takes forever. It takes forever. And then it takes forever to build rubies with documentation as well. Is there another tool that will install the RI RDoC after the fact, after you, like asynchronously, so you funnel no documentation and then it installs the documentation later? Well, it's not async because we don't have the node technology yet, but we're gonna get there. I don't even remember the question. That was a stupid joke. No, so there is a gem called RDoC data. And sorry, Erin, you're gonna have to wait. No, RDoC data is like after the fact thing that compiles the documentation for every version of Ruby and all the core docs. And we use that for like Windows installer because it can't ship the RDoC and it just makes the binary so much bigger. So we can install it after the fact. That's really nice. But it also requires maintenance. Like you have to compile the documentation for each version and release it and stuff. Anybody else? Erin, what were you gonna say? I was gonna say I'm not gonna say that. Thank you. Did I get it right? Great. Success. Well, if not, thanks, Zach. Thank you.