00:00:11
Hi everybody, I'm Eileen Uchitelle. I live in upstate New York, about two hours north of the city in a town that was the first capital of New York until Sam Phippen and the British burned it down, like, twice. You can find me online at the handle @eileencodes, which means on Twitter, Instagram, email, GitHub, anywhere that I actually want you to find me.
00:00:36
I'm a senior systems engineer on GitHub's Platform Systems team. Platform Systems is the team responsible for Rails, Ruby, and other libraries and how those interact with the GitHub application. I'm also the newest member of the Rails core team, which means I'm allowed to tweet from the Rails Twitter account, which is the only important part of being a Rails core team member. But for those of you who don't know, we're also responsible for defining the future of Rails, releasing versions, and fixing bugs for all of you.
00:01:12
Today, we're going to talk about the unbearable vulnerability of contributing to open source. Before we deep dive into that, I want to give you a bit of background on my involvement in open source and what I mean by vulnerability. When I talk about vulnerability and open source, I'm specifically referring to how contributing exposes our insecurities and makes us feel like we’re not good enough to contribute.
00:01:37
The vulnerability we feel when contributing can inspire us to change the software we use and the communities we belong to, or it can be so unbearable that it paralyzes us because our vulnerability makes us afraid to contribute. I’ve been contributing to open source for a long time, and I still feel vulnerable, especially when I contribute to a new project or build a major feature.
00:02:05
Vulnerability is an inherent part of contributing to open source, and I don’t think it’s something I’m ever going to fully overcome. I opened my very first pull request on GitHub in 2012. It was a pull request to fix a typo in the README of a project that I had been using. The PR was never merged because the project had been abandoned for a few years. Almost a full year later, I opened my second pull request.
00:02:29
Mini Profiler is a database and request profiler for Rails applications. I noticed while using Mini Profiler that there was this little extra space at the bottom of the page that was really annoying. I thought, 'Oh, this is a CSS bug. So easy to fix!' I quickly found out it was not a CSS issue, and it took me two days to find the invisible UTF-16 character that was hiding in a JavaScript file or something—it was so bizarre.
00:03:00
Even though I had spent a lot of time looking at that issue and was confident that I had fixed the bug, I was still worried that I was wrong or that my contribution wouldn’t be welcome. I felt vulnerable because I didn’t know what to expect. After giving a talk in 2014 at Mountain West Ruby, I learned that I had found a bug in Active Record. Aaron Patterson, who most of you know as Rails and Ruby core team member or just as Tenderlove, asked if I wanted to pair with him to implement a fix for the problem.
00:03:33
Shortly after pairing on that fix, I opened my first pull request for the Ruby on Rails framework. Even though I had worked with Aaron and knew that I had the right fix, I was still really nervous about opening a PR against a repo where 2,000 people get notifications every time you open an issue or pull request. I felt vulnerable because I was a new contributor. What if somebody thought my fix was stupid? What if someone thought I was stupid?
00:04:00
These thoughts might seem irrational, but they are embedded in contributing to open source because we're dealing with people, not code. The other side of that fear, though, is the high you get when your pull request is merged. I continued to contribute to Rails regularly after that first pull request. Maybe it was because I had someone mentor me and help me understand the Rails internals; maybe it was because I had such a good experience contributing that first time.
00:04:34
One of the goals of this talk is to provide ways in which you can improve your communities so more contributors experience that high instead of the unbearable vulnerability when contributing to your project. This past year, I worked on a large feature for Rails called System Tests. Previously, a lot of my work on Rails had been refactoring code, fixing bugs, or improving performance—those things that no one actually cares about. This was my first experience adding a major feature to Rails, and by major, I mean it was literally the highlight of the Rails 5.1 release.
00:05:01
Working on this project reminded me how hard contributing to open source can be. I had been contributing to Rails for over two years, but I was still nervous about opening this pull request. I had those familiar worries: what if everyone hates this feature? What if someone thinks my code is bad? Even though DHH, the creator of Rails, literally asked me to build this feature, I still had to deal with reviews and comments, and I had to defend the decisions I made.
00:05:29
By the time I opened the pull request, I had already put three months of work into it. The project was personal to me because I had spent nights and weekends working on it, and I had become attached to the code. Throughout the time the pull request was open, I received over 150 comments and eleven reviews; that’s a lot of other opinions to deal with. I felt stressed and vulnerable, just like I had when I opened my first pull requests.
00:06:00
Someone even tweeted about the PR, which only drew more attention to it. Don’t get me wrong; attention is good, and reviews are good, but I was drained by the endless bike shedding and nitpicking of details. None of the reviewers meant any harm; they were genuinely excited about the feature. Still, there was a level of discomfort that startled me. I had been an average contributor to Rails for two years and helped release Rails 5, and I had commit rights, so why was opening this PR a nail-biting, stress-inducing event in my life?
00:06:18
I figured I’d be over the unbearable vulnerability by now. While thinking about this, something struck me. I realized that even if we get used to working on open source, we can still experience vulnerability when we work on a new project or a large feature. The more time we spend on open source, especially in our free time, the more attached we become to the work we’re doing.
00:06:56
There’s only one explanation for why this happens: if contributing to open source was only about writing code, it would be easy. But we all know contributing to open source isn't easy. We're not just dealing with code or ones and zeros. No one would be worried about opening a pull request if open source was merely about writing code. Therefore, if open source isn't about writing code, that means that open source is really about people; it's the people who make us feel vulnerable.
00:07:30
Contributing to open source is about our insecurities, our fear of being wrong, and our fear of showing our peers our work. Often, just the thought of pushing code to a public repository can cause anxiety for me. Given that while people are the source of vulnerability, they are essential to the open source ecosystem. Let’s take a moment to consider what open source would be like without people.
00:08:05
Say you write a gem or a library in open source. Sure, it's public for anyone to use, but if no one downloads it, is it really an open source project? Open source doesn't work without users; otherwise, you're not genuinely sharing your code with anyone. No users mean no bug reports, which means your work doesn’t improve. If you stop improving, no one's going to notice because they don't use it. While your code might be public, it's just public code until someone uses it.
00:08:40
Let’s say you have tons of users but no contributors. Sure, you get to control the project, and you never have to deal with differing ideologies, but is that really open source? If you stop improving the project or move on to something else, the project won't be useful anymore. Open source can't survive without contributors. Imagine for a moment a world where Matz created Ruby but had no contributors. Would it be as robust as it is today? Definitely not. Would all the engineers who learned Ruby and got jobs not writing Java be as happy as they are today? I don't know; maybe everyone would have adopted PHP instead.
00:09:04
But the community and tools would be very different from where they are today. If we had done that, I wouldn't be here today giving this talk if it wasn’t for Ruby, Rails, and the success of all those contributors who contributed to that success. So, I’ve convinced you that you need people, both users and contributors, to have a successful open source project. In that case, what are we going to do about the unbearable vulnerability?
00:09:41
Vulnerability can be harnessed as a motivator for change, or it can deter us from contributing. There are ways we can foster a welcoming community and attract more contributors rather than deter them. Before we explore ways in which we can improve open source communities, we're going to look at the ways in which maintainers can make vulnerability unbearable.
00:10:18
Unbearable vulnerability can be a deterrent for many new and longtime contributors. Feelings of inadequacy can keep folks from contributing to your project, which means maintainers lose out on changes from other viewpoints that could make their projects more robust and stable. We want to avoid creating an environment that fosters fear of contributing in favor of an environment that is welcoming and inclusive. We aim to create environments and communities that cultivate creativity and inspire contributors.
00:10:54
One of the ways maintainers deter contributors is by closing pull requests without providing feedback. When maintainers do this, they leave no room for contributors to improve in the future. Maintainers should always explain why a pull request wasn’t accepted; otherwise, contributors might take it personally. Contributors spend a lot of time and emotional energy on contributing, and it can be demoralizing to not have your pull request accepted.
00:11:32
Asking clarifying questions if you don’t understand why a change was made or what their use case is can help. Being dismissive and not giving feedback will cause contributors to feel like their time isn’t respected, and they may not contribute to your project again. Another way maintainers can make contributors feel more vulnerable is through violent communication. An example of violent communication is saying 'this code sucks' or 'did you even try to fix the problem?' This communication style passes the blame onto the contributor and shames them.
00:12:01
This will lead to contributors feeling defensive and more vulnerable. It will deter them from contributing in the future because they don’t feel respected. It’s easy for context to get lost in written communication, so try to over-communicate with nonviolent techniques to convey your points without alienating contributors or future contributors. If you want to learn more about nonviolent communication, you should watch this talk by Nadya called 'This Code Sucks: A Story About Non-Violent Communication.'
00:12:42
Her talk explores what nonviolent communication means and the benefits of using it in your communications at work. Often, I see bad behavior being tolerated by someone who’s a high-impact member of the team. They respond to lots of pull requests or open and send lots of patches. Even if a contributor or maintainer may seem like an asset, if they’re abusive toward new contributors, that will deter other contributors from joining your community in the future.
00:13:12
It’s important to protect your contributors from bad actors and not to tolerate behavior that’s exclusive or offensive. A power dynamic exists between maintainers and contributors. It’s important to recognize this because maintainers inherently have more power than contributors. This will always be true because maintainers decide what gets merged and who gets to contribute. Because of this power dynamic, it’s up to maintainers to set and reset the tone of the conversation.
00:13:53
There are always going to be people who come into your project and demand free time from you, but most of the people contributing to your project mean well. It takes a lot of energy to be rude. Wouldn’t maintaining be easier if we could learn to defuse stressful situations instead of making them worse? As a maintainer myself, I have felt the urge to tell someone off when that happens. I try to put myself in their shoes and take a walk before responding.
00:14:31
They’re probably frustrated; maybe their boss is breathing down their neck to get this fixed. Maybe they dropped their production database. Often, taking the time to tell the contributor that you know they’re frustrated quickly transforms the conversation from defensive to productive. This doesn’t mean giving the contributor everything they want; it just means treating them the way you want to be treated in a stressful situation.
00:15:03
Vulnerability can be harnessed as a motivator as well. Being vulnerable isn't a bad thing. We have all felt it before; every single maintainer and contributor has at one time felt vulnerable, and they probably will feel vulnerable again. However, when we feel safe being vulnerable, we’re more creative, more inspired, and more open. If we can change our open-source communities to be more welcoming and supportive, they will be more sustainable, and the vulnerability will be bearable.
00:15:44
So why is it important that we create a welcoming and supportive open-source community? Why does it really matter if contributors don’t feel safe being vulnerable? Open source is a funnel. At the top, you have your users; some of those users become contributors, and some of those contributors become maintainers. The more maintainers you have, the more sustainable open source can be because you have more backup.
00:16:15
Making our open-source communities more welcoming will attract more users to become contributors, and more contributors to become maintainers. If we don’t do this, we will end up on an island alone maintaining projects by ourselves. This leads to fewer users because you can’t sustain the project alone, fewer job offers because no one is using your project, and fewer friends because, let’s face it, you’re spending all of your time working on open source instead of having a life.
00:16:59
Imagine a world where, instead of burning out on that island, the funnel didn’t lose so many potential maintainers. I just realized how much has been talked about at RubyConf. I just threw a skull up there as the theme, but don’t worry; you will all live and learn to live better.
00:17:37
What would the ideal open source world look like? It might look like something where users, contributors, and maintainers move equally among roles. In today’s open source world, maintainers often stop being users of their own product. Some even stop contributing beyond approving and merging pull requests. It doesn’t have to be like that, but I also think that this ideal world is hard to achieve because of open-source and the political structure of everything.
00:18:08
So, this ideal world isn’t really possible. What is possible? I’d like us to aim to get the funnel to be a little bit more like this: users are still the majority of people who are involved in your product, but users are more likely to become contributors, and contributors are more likely to become maintainers. I’d also like there to be less friction in moving from users to contributors to maintainers and back again.
00:18:42
Open source needs contributors; without them, open source will cease to exist and thrive. We need to make open source more sustainable so that people continue to contribute. Open-source software is the present and future of technology, and without it, innovation will stagnate. So how do we create a welcoming and supportive open-source community so that new contributors join and open source communities thrive?
00:19:23
There are many ways in which we can make open source a better experience for everyone. Healthy communities benefit maintainers, contributors, and users. One way in which maintainers can attract and retain more contributors is through mentorship. Many of my first contributions to Rails were the result of pairing with Aaron Patterson. Mentorship doesn’t need to be official and can happen organically.
00:19:54
I met Aaron at a conference after my talk. He told me I discovered a bug in Rails and offered to pair with me to fix it. Before I made my first commit to Rails, I never thought I’d be on the Rails core team. Rails is a really complicated codebase, and it can be difficult to get used to. On top of that, the community is massive; Rails has over 2,000 contributors, and at least that many people get notifications when issues and PRs are opened.
00:20:22
I didn’t think that I had anything more to offer than they did. Aaron and I started pairing regularly, which helped me learn faster and feel more comfortable contributing. It didn’t erase all my anxiety, but instead of feeling unbearable dread when contributing to Rails, I felt excited. Aaron’s guidance helped me navigate both the codebase and the community, making contributing to Rails less stressful. I knew he had my back and would help me defend the decisions in my PRs.
00:20:56
Mentoring can take place in various forms, from pairing to email to inviting contributors to a group chat with other maintainers. I’ve helped folks get their first contribution through Twitter DMs, pairing, and email. Mentorship doesn’t have to be formal or time-consuming. The point of mentorship is to act as a guide for your mentee and help them feel welcome in the community.
00:21:36
Writing up clear guidelines for contributing can help make maintainers feel more welcome to your project. It’s always easier to contribute to a repository when it’s explained what’s expected instead of guessing. Each open-source project has its own rules for contributing. For example, the Rails project doesn’t accept feature requests on the GitHub issues tracker, while other projects may be okay with that type of issue. Clearly setting up the guidelines for your project allows contributors to focus on contributing rather than worrying about breaking unspoken rules.
00:22:06
Be sure to add a CONTRIBUTING.md file to your GitHub repository and include any rules about contributing that are unique to your project, like requiring all pull requests to be a single commit or not allowing cosmetic changes to the code. The Rails team provides bug report scripts that can be used to replicate bugs experienced in Rails applications. This means users don’t need to provide us with a full application to reproduce the bug that they’re experiencing.
00:22:39
If the bug can't be reproduced with one of our scripts, then we know it might be a gem or something specific to their data. This helps us triage issues faster because we can see directly where the behavior is caused instead of playing guessing games. This helps contributors by reducing the amount of work they need to do to give us a reproduction so they spend less time stressing and more time contributing.
00:23:14
One potential use is to employ bots or scripts to handle pull requests, triaging, or ensure contributors don’t feel ignored. On the Rails project, we use a bot to auto-assign a pull request to maintainers. Rails gets so many pull requests that it’s hard to give everyone attention, but with the assignment bot, we can mainly focus on those assigned to us. It still gets overwhelming, but it helps new contributors know that someone is paying attention and will respond to them soon.
00:23:46
We also use linters to instruct contributors on what needs to be fixed and thereby help reduce bike shedding and nitpicking about small details. After all, no one wants to argue with a bot. Everyone makes mistakes, so if you see a new contributor fail to add a test for a documentation change or if they open a feature request on the issues tracker, kindly tell them how to contribute better in the future.
00:24:22
This will ensure that even if, in that case, their pull request hasn’t merged or you've requested changes, they don’t feel like you’re nitpicking on them or making them feel bad for a tiny mistake that doesn’t really matter. For example, Travis running one extra time is probably a bigger deal for Travis than it is for me, but there’s no point in putting someone down. That will only chase away folks who are trying to help you.
00:25:01
When you’re the maintainer of a project, it’s easy to think that you have to do everything yourself. I think it’s important to know when and how to ask for help. You can use your README to document areas where your project needs help. When I first started contributing to Mini Profiler, I knew exactly what Sam Saffron wanted help with because he laid it all out in his project’s README. In fact, he still needs help in some areas.
00:25:45
If you're interested in getting your first contributions, this is a great project where you know exactly how to help, and Sam is super awesome. Contributors will feel more welcome to push changes to your project if they know the work they’re doing is wanted. This reduces vulnerability and stress when opening that initial pull request.
00:26:19
One way to ask for help is by promoting contributors to maintainers. Rails wouldn’t be successful today if DHH didn’t share the burden of making decisions, releasing new versions, and shaping the future of Rails with us. The Rails core team currently has 12 members, which means that we all don’t need to be available all the time for Rails to thrive. While smaller projects might not have a team as large as Rails, it’s important to find contributors you trust to cultivate the community around your project.
00:27:30
Trying to maintain a project by yourself is a fast track to burnout. We can create more sustainable communities if we are nice to and respect everyone. Maintainers set the tone of the conversation. Yes, difficult contributors will always exist, but the majority of contributors come to your project with good intentions.
00:28:16
One of the most important things to remember as a maintainer is not to review pull requests before you’ve had your morning coffee. If you’re like me, you’re very grumpy before coffee, and maybe you haven’t even recovered from the nightmares you had the night before. I have personally jumped to snap conclusions when I review pull requests before having coffee.
00:29:00
Often, it’s more likely I’ll be short with the user and dismiss the pull request without a proper review. Take the time to take care of yourself before reviewing pull requests. Contributors will feel more welcome and won’t have to put up with your negative attitude. Being dismissive or rude because you haven’t had your coffee could prevent contributors from helping you in the future, which, let’s face it, is only going to make you grumpier.
00:29:44
As we talked about earlier, employing non-violent communication tactics is the best way to interact with contributors. You should probably employ non-violent communication methods in all areas of your life, but for now, we’re just talking about open source. Using nonviolent communication will keep the conversation open. Remember that as a maintainer or contributor of a project, you set the tone of the conversation.
00:30:40
Recently, we had a situation in the Rails project where an issue was closed quickly without a conversation. This, of course, resulted in the contributor getting defensive because we weren’t listening to them. I took the time to respond to the contributor and let them know that I understood how they felt, and I asked what solutions would work for them. This immediately changed the tone of the conversation; instead of being annoyed, we could discuss solutions.
00:31:28
This doesn’t mean the contributor is going to get exactly what they want or that we’re going to fix the issue, but they no longer feel that they were ignored or dismissed. As a maintainer, you can show respect for your contributors and future contributors by adding a code of conduct to your project. This will attract new contributors because they will see that you’re serious about maintaining a professional and respectful community.
00:32:19
While codes of conduct benefit everyone, people from underrepresented groups are more likely to feel comfortable and welcome contributing to your project if you implement a code of conduct and ensure that all of maintainers and contributors treat each other with respect. Maintainers can use GitHub-provided tools to signal that their community is healthy and welcoming.
00:33:10
A great feature that GitHub added a few months ago is the first-time contributors badge. This badge clearly indicates when contributors are new to your project. When you see this badge, give that contributor a little extra time and be a little extra helpful. When I see this badge, I like to take the time to congratulate the contributor on their first pull request.
00:33:52
As a maintainer of Rails, I want contributors to have a good experience. I appreciate the time they put into Rails, especially as first-time contributors; they will be more likely to contribute again in the future. Another GitHub tool that was rolled out recently is the community profile tool. The community profile tool shows GitHub's recommended standards for creating a welcoming and sustainable open-source community.
00:34:38
The community profile is located under the repository insights tab via a link called community. The community profile page will show you six items that make a healthy open-source project: a description, a README, a code of conduct, contributing guidelines, a license, and issue and PR templates. Each of these items will help make your project more approachable and sustainable.
00:35:10
If your community profile is not complete, GitHub provides a wizard to help you add the missing items, like a code of conduct or picking a license that works for you and your project. We’ve talked a lot about how maintainers can build better communities, and all of this is to help contributors feel welcome and inspired.
00:35:48
The goal is to make vulnerability bearable for our contributors. Now we’re going to examine ways that contributors can find healthy open-source communities where they know their contributions will be welcomed. One of the easiest ways to find a project to contribute to is to look at the tools you use every day. If you build Rails apps, look in your Gemfile for ideas of projects that might need your help.
00:36:31
That’s how I ended up contributing to Mini Profiler. Contribute to the tools that you use because that’s where you’ll be most useful in open source. Users become contributors, and contributors become maintainers, so with that logic, the easiest way to become a contributor or maintainer is to first be a user.
00:37:14
A great way to find a community or project you want to be a part of is to spend some time observing the behavior of maintainers or other contributors first. Make sure the project is active. Active projects have recent commits. Look at the top bar of a GitHub repository to see when the last commit was made. Projects that are active will have pull requests merged or issues closed in the last few days to months.
00:37:56
My first open-source contribution was for a project that had been long abandoned, and it didn’t feel good to make a contribution that would never be accepted. There are a few ways you can go about making changes to abandoned projects. You can offer to take over maintaining the project or open a PR with the expectation that it won’t get merged. Don’t open an issue that asks, 'Is this still maintained?' especially when it’s obviously not maintained.
00:38:31
Once you’re sure the project is active and accepting new contributions, take a look at how maintainers respond to new issues or pull requests. Subscribe to a few of those pull requests on the project and see how maintainers treat contributors. Are they kind or dismissive? Do questions go unanswered, or do they help contributors get their pull requests merged? This will help you know what to expect when you open that first issue or pull request.
00:39:00
Most maintainers are volunteers, so being unresponsive doesn’t mean they’re rude; they’re just busy or burnt out. However, knowing the communication style of maintainers upfront can help you be more prepared when you open that first issue or PR. Just as most maintainers are volunteers, so are you; you don’t have to work for free for anyone. If a maintainer or other contributors aren’t respectful of you and your time, it’s okay to say no and go work on other open source projects.
00:39:40
There are projects that I have used in the past and applications that I wouldn’t contribute to because I didn’t think the maintainer treated people the way I wanted to be treated. I didn’t want to interact with them just to get my bug fixed and then feel bad because they were rude to me. There’s no requirement that you voluntarily work on open source projects where maintainers or contributors are rude to you.
00:40:23
A big part of contributing to open source is learning how to accept rejection. It’s demoralizing to not have your pull request accepted, but often maintainers have a vision for their projects. That’s a big reason why pull requests are accepted or rejected. I’ve had many pull requests rejected, and I know it’s not fun, but don’t take rejection personally; it’s all part of contributing to open source.
00:41:11
Ask for advice on how to do better next time and apply that to your future work. Once you find a community and projects that you want to contribute to, treat them with respect, just as you want the maintainer to treat you. Hitting a bug in an open-source project is frustrating, but maintaining a project is hard. Most maintainers are volunteers, so while the majority of this talk was about how maintainers can do better, contributors can do better too.
00:42:10
Treat maintainers the way you want to be treated if you were a maintainer. There are a ton of resources to help contributors and maintainers have a better experience and build more sustainable open-source communities. FirstTimersOnly.com can help you find your first pull request and GitHub.io and CodeTriage.com can help new contributors find projects that need help and are actively seeking contributions.
00:42:55
The Open Source Guide is written by my lovely colleagues at GitHub and is a resource for contributors and maintainers with ideas about building more welcoming communities, finding your first pull request, and implementing open source Fridays at your job. Open source isn’t about writing code; it’s really about people and our insecurities. Interactions are unbearable; vulnerability—the thought of contributing to open-source or interacting with toxic communities—can be paralyzing.
00:43:46
However, open source cannot survive without contributors. It’s our responsibility to build welcoming communities so that open source is sustainable and inspirational, instead of paralyzing and toxic. We can achieve this by mentoring, asking for help when we need it, and demanding that we all treat each other with respect. Let’s build a world where, instead of ending up on that island burning out from maintaining projects alone, we get to work with bright minds and share ideas in a healthy, sustainable community.
00:44:36
The benefits are endless. Building a better community will attract more contributors, and this makes open-source communities more stable and sustainable. Maintainers and contributors are less likely to burn out because there are more people to share the burden of contributing, with less demand on their time and more emotional support.
00:45:08
Let’s build open-source communities where contributors experience less dread and fear when contributing. Instead, more contributors experience that high because they were inspired by their vulnerability to build something amazing for your project. We must all work together to create more sustainable open-source communities. The future of open source depends on all of us.
00:45:42
I hope the maintainers in this room feel inspired to go out and build better open-source communities. I hope the folks in this room who have never contributed to open source are inspired to move past their vulnerability and contribute. And I hope that everyone will respect each other and recognize the vulnerability that everyone has to overcome to contribute to open source.
00:46:20
The job of growing these communities doesn't lie solely on one maintainer, one contributor, or one project's shoulders; the responsibility is all of ours. We can build a community we want, whether we’re contributors, maintainers, or users. Together, we can ensure that open source thrives by building welcoming and sustainable communities.
00:47:00
Together, we can make the unbearable vulnerability of open source bearable. Thank you.
00:47:39
If anyone has questions, I think I have time—wait, I have time.
00:47:55
Okay, and afterwards, I have stickers from GitHub, so if you haven't gotten enough stickers, I have more.
00:48:10
About five minutes, okay? Questions?
00:48:20
The question is: how much time do I spend triaging, reviewing, and other things? I’d say that since joining the Rails core team in February, I spend less time writing software for Rails and more time triaging pull requests.
00:49:06
I don't know exactly how many hours I spend, because some weeks I don’t work on it at all and some weeks I spend more time—probably around five hours a week—so I should spend more time on it, that's really what I'm getting at. I don’t feel like I’m spending enough time because we have, like, your issues tracker is insane right now.
00:49:48
But that’s why all of you need to become contributors to Rails so then you can join the core team, and then we will, you know, never have inbox zero—it’s fine! But you can all help me triage issues.
00:50:20
I don't think that was a good answer to your question, I’m sorry.
00:50:55
So, I talked about the funnel and how contributors move, users move to contributors and maintainers. I also talked about how Rails has a lot of open issues and does seem like maybe we’re not moving that funnel around a lot. How can we improve that funnel?
00:51:29
I think Rails is a hard example for that because it’s such a complicated codebase. I think there are things that we could do better; we could mark issues that are easy more often. We don't really do a good job of that.
00:51:58
I think we could pair more with new contributors. We could do a better job of explaining how we figured bugs out because I think there are a lot of people who think that we on the Rails core team are like magic unicorns who understand the Rails internals. But it still takes us hours to figure out problems sometimes too.
00:52:32
If we talked more about, like, I don't know if I ever even see Richard's name when he like does his blog post about debugging everything and that's really it. It would be great if we all, I say that as me too, I should do this. It would be great if we all wrote more about finding those problems and solving them because sometimes they're not, sometimes they are really hard.
00:53:15
Sometimes it’s just, 'Oh, I knew that this was in this gem,' and like this is how to make a script to test it. Here’s how to bisect, and then that’s how you find out most of the time how we figure it out.
00:53:49
Yeah, by sorting that best tool ever.
00:54:04
Does that answer your question?
00:54:16
Okay, I don’t see any hands, but I will be around—come ask me questions. I have stickers. Thank you!
