Maintaining Sanity
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/37477 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Place | Miami Beach, Florida |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Ruby Conference 201318 / 50
2
3
7
13
15
17
18
19
28
29
35
39
44
48
49
50
00:00
Software maintenanceProjective planeExecution unitWeb pagePressureMultiplication signSoftware testingSpeicherbereinigungNumberSpring (hydrology)Speech synthesisMultiplicationPlastikkarteFunctional (mathematics)Software bugSelf-organizationGateway (telecommunications)Process (computing)Software maintenanceOcean current
03:28
Software maintenanceProjective planeDecision theoryPatch (Unix)Open sourceVideo gameSoftware maintenanceProcess (computing)
04:28
Open sourceSoftware maintenanceDecision theoryVideo gameDependent and independent variables
04:58
Maxima and minimaCodeProcess (computing)Process (computing)CountingoutputCodeSoftware maintenanceOpen sourceDifferent (Kate Ryan album)Patch (Unix)MassForcing (mathematics)MereologyChemical equationProjective planeSoftware bugContext awarenessMultiplication sign
07:23
NP-hardRight angleProjective planeQuicksortOpen sourceSoftware maintenanceOpen setBitSoftware repositoryProcess (computing)Context awarenessProduct (business)Squeeze theoremHypermedia
09:43
Projective planeMultiplication signOpen sourceSoftware maintenanceSoftware bugWeb pageExistenceNetwork topologyComputer animation
10:41
Software bugNetwork topologyElectronic mailing listMultiplication signProjective planeDigital rights managementOpen sourceSoftware bug
11:29
Dependent and independent variablesMultiplication signSoftware design patternStandard deviationProjective planeContext awarenessCodeLattice (order)Software maintenanceMathematicsFigurate numberBitTelecommunicationLine (geometry)Differenz <Mathematik>CausalityExpected valueGenderCovering spaceSoftware testingRow (database)Online helpDigital rights managementRevision controlInstance (computer science)
14:39
VolumeMathematicsVolume (thermodynamics)Multiplication signAdaptive behaviorWeb pagePatch (Unix)Context awarenessSoftware testingDependent and independent variablesOpen sourceComputer animationLecture/Conference
16:07
Open sourceMultiplication signFeedbackCausalityProcess (computing)Software maintenanceLecture/Conference
16:57
1 (number)Multiplication signTerm (mathematics)InternetworkingFeedbackPatch (Unix)DataflowArithmetic progression
17:39
QuicksortInformationDifferenz <Mathematik>Queue (abstract data type)LoginInformationOnline helpQuicksortQueue (abstract data type)Gateway (telecommunications)Digital rights managementProjective planeTerm (mathematics)FeedbackProcess (computing)Multiplication signMathematicsDifferenz <Mathematik>Computer animationLecture/Conference
19:04
AliasingInstallation artCoding theoryMultiplication signSoftware repositoryCloningKernel (computing)Software maintenanceDirectory serviceOpen sourceEmailGoodness of fitUniform resource locatorBranch (computer science)MereologyArtificial lifeElectronic mailing listUniform boundedness principleIntel
21:05
WebsiteSlide ruleMathematicsWindowFormal grammarComputer fileView (database)Normed vector spaceSimultaneous localization and mappingComputer iconExecution unitMaizeMoment of inertiaParameter (computer programming)Hill differential equationOnline helpSoftware repositoryCausalityArtificial lifeMultiplication signMetropolitan area networkComputer animation
21:59
Graphical user interfaceMenu (computing)Bookmark (World Wide Web)View (database)WindowRule of inferenceGamma functionCone penetration testCommodore VIC-20Computer fileData storage deviceGateway (telecommunications)Interactive televisionCodeSoftware testingComputer animation
22:54
View (database)Gastropod shellWindowObject (grammar)Total S.A.Insertion lossComputer fileHash functionToken ringMaizeCausalityBranch (computer science)Control flowMessage passingSoftware testingComputer animation
23:24
BootingComputer configurationToken ringWindowView (database)Gastropod shellComputer fileMathematicsWeightRevision controlLogic gateRow (database)Point (geometry)
24:09
WindowBookmark (World Wide Web)View (database)Lemma (mathematics)Computer fileMathematicsLogarithmParity (mathematics)Cohen's kappaHash functionRevision controlDirectory serviceGastropod shellOnline helpMessage passingText editorComputer animation
24:41
WindowComputer fileView (database)User interfaceStudent's t-testComputer animation
25:12
View (database)WindowBookmark (World Wide Web)Sign (mathematics)Computer fileLogarithmMathematicsDirectory serviceGastropod shellInsertion lossToken ringLogicMathematicsArithmetic progressionSystem callCommitment schemeExistential quantificationLibrary (computing)Computer animation
25:51
Insertion lossMathematicsGastropod shellWindowView (database)Token ringComputer fileUser interfaceDirectory serviceCore dumpHash functionCASE <Informatik>Computer clusterCommitment schemeComputer animationSource code
26:23
WindowComputer fileComputerBookmark (World Wide Web)View (database)Token ringMenu (computing)Pascal's triangleStandard deviationSlide ruleFile formatNormed vector spaceData typeNormal (geometry)Coding theoryLogarithmMathematicsWeb pageRight angleRevision controlMultiplication signGateway (telecommunications)Disk read-and-write headMathematicsResolvent formalismSoftware testingMultiplicationCodeComputer configurationAsynchronous Transfer ModeMereologyComputer animation
28:05
Rule of inferenceSoftware maintenanceQuicksortOpen sourceRight angleLecture/Conference
28:57
Software maintenanceQuicksortOpen sourceCodeProjective planeContext awarenessLecture/Conference
29:28
CodeOpen sourceProjective planeDependent and independent variablesSoftware maintenanceContext awarenessCodeCivil engineeringExtension (kinesiology)
31:22
TelecommunicationOpen setExpected valueSoftware maintenanceTelecommunicationEmailSystem callMultiplication signWeb pageAddress spaceElectronic visual displayElectronic mailing listProjective planeOpen sourceBitGame theoryLecture/Conference
32:37
Electronic mailing listGame theorySoftware maintenanceKernel (computing)Projektiver ModulEmailNP-hardMultiplication signSoftwareProjective planeQuicksortOpen sourceElectronic mailing listDigital rights managementSystem administratorMathematicsDrop (liquid)Metropolitan area network
35:10
MultiplicationOpen sourceMultiplicationCore dumpQuicksortPoint (geometry)SpeicherbereinigungGateway (telecommunications)Process (computing)Video gameSoftware maintenanceProjective planeCausalityPlastikkarteCapillary actionMereologyGodCodeMarginal distributionMetropolitan area networkPatch (Unix)
37:48
SoftwareVideoconferencingSuite (music)Event horizonComputer animation
Transcript: English(auto-generated)
00:18
About time to get started. Thanks everybody for coming
00:21
out on a Sunday afternoon. I knew one friend who did a fair amount of speaking and he said he always told the conference organizers that he had to leave before the last, before the last day to make sure that they would schedule them earlier in the conference. So. But
00:42
somebody has to go on the last day, and I appreciate you coming out for this talk. My name is Nathaniel Talbot. I work at a company called Spreedly, and we do a lot of payment stuff. We, we process payments and make it really easy to work with multiple gateways, vault
01:02
credit cards. This number is like ticking down in a way, like, I mean, no pressure. I'm gonna we process payments and do a lot of work with payments, and I've been in the Ruby community
01:22
for a long time. Way back when, I made this little project called test-unit in the early days of Ruby, and that somehow ended up in Ruby itself. And thankfully somebody else took over maintaining that. And I'm one of those groupies
01:43
that's been to every Ruby conference, so that's, that's how much I'm into Ruby. But this thing happened as I was going along, and suddenly I found myself a maintainer of a rather large project. I don't, it's one of
02:01
those things that I don't remember exactly how it happened. All of a sudden. But, no, I was working along on the ActiveMerchant project. Who's used ActiveMerchant? OK. So actually a fair amount of the room. Which is awesome. And I was working along the ActiveMerchant project. Spreed uses ActiveMerchant a lot. A lot of our
02:22
functionality is built around it. And I was committing, I was doing pull requests, and generally the, like, I was sort of insistent enough that my pull requests were getting merged, but there was like five pages of old issues and pull requests or more, and it just started to bug me
02:42
that they were all there, and I didn't want to wait for people to, for the current maintainers of ActiveMerchant to merge my stuff. I'm like, hey guys, maybe, maybe you could just give me commit privilege, and then I could take care of my own stuff. And then I got commit privileges, then I got annoyed that there were so many things in the
03:01
issue tracker, and I started actually dealing with other people's issues, and all of a sudden I was a maintainer of ActiveMerchant, and one of the primary maintainers. And I didn't realize it until Matt's keynote, but I had become a garbage collector, which is actually pretty awesome, and we're gonna talk about that
03:23
a bunch and why being a garbage collector is actually pretty cool. But before we get into that, you might be saying to yourself, well, Nathaniel, you're gonna talk about like how to be a good maintainer, but what if I'm not a maintainer? Well, the thing is, understanding the issues that a
03:40
maintainer has to deal with, the things that they run into as they're taking in contributions and trying to maintain the project will make you a better contributor. So even if you're not a maintainer, you can be a better contributor by understanding these things. And being a better contributor means it's more likely that your patches and your issues get resolved.
04:02
And I don't know about you, but when I go to the trouble of submitting something to an open source project, it's really nice when something actually gets done with it. And so if you understand what maintainers are dealing with, you're much more likely to get your stuff merged. And also, you could be like me and just be going along and all the sudden you're like, what happened? And you're the maintainer on
04:22
a project. So this could happen to you too. So listen up. Now, one of the things about becoming an open source maintainer is you didn't, like, for me, I didn't think about, oh, OK, this is a big life decision and I really need to think this through. What does it mean
04:40
to be a maintainer? And actually putting this talk together was a really great opportunity to think about, what is a maintainer's job? What is it, as an open source maintainer, that you're trying to do? What are your responsibilities? What makes you effective? So let me just go through a few things here. First of all, I think it's a maintainer's job.
05:01
Every maintainer's job. To maximize the contributions to their projects. Open source works because many eyes make for small bugs. And the more people that we can bring in, and the more contributions and the more contributors we can get involved, the better our projects will be.
05:23
However, that has to be balanced with the second job of a maintainer, and that's to ensure that the code improves over time. It's not enough to just say, oh great, another patch. Let me hit that merge button. Fantastic. Another patch. Hit the merge button. Because before long you've got a big bloated mess. Because there's a lot of different forces that are
05:41
coming to play on your project, and it's the maintainer's job to ensure that that code gets better over time and isn't just, you don't count as a maintainer if you just merge every patch. You've got to, your job is to make sure that it gets better, because you are in context to that project.
06:03
Thirdly, I think that it's a maintainer's job to ensure that the users of their open source project are happy. And it's really important to understand that this isn't happy contributors. This is happy users. Because open source is just like anything else that takes in input from
06:22
a crowd of people, and that is you'll have ten percent of people who actually contribute stuff back. And you've got this great, a mass of people who are using your code you don't even know about, you've never heard about them. And you've gotta be thinking of them, not just to the people who are coming in and are contributing to your project. You've gotta
06:40
balance that out and, and ensure that everyone that's using your code and the project you're maintaining is happy. And then fourth, I think it's really important, and it's part of an open source maintainer's job, to actually enjoy the process of maintaining open source. Because it really stinks when there's a good maintainer
07:00
of an open source project and then they quit because they get burnt out. And it does the community no good for that to happen. So, but we, I as an open source maintainer am responsible for managing that. And making sure that I can actually do this for the long haul. So this is definitely a critical piece of my job.
07:21
So here's the thing. This is hard. It's not something that you're gonna go and take a course on in school. It's not something even, like, you can go and talk to open, other open source maintainers, and they'll kind of throw some anecdotes at you, and that's great. But it's hard.
07:44
It's context-dependent. And so what I want to try to do today is say, OK, great. Now you're a maintainer. So as you're starting to do your job, what are the hurdles that are gonna pop up in front of you? What are the things that you're gonna run into? And what are some ways that I've learned that have
08:02
helped make me more effective and I hope will make you more effective as an open source maintainer? Now, I'm gonna make some assumptions. First of all, and these are assumptions for the sake of the narrative, not assumptions that you can't tweak and apply to your own situation. I'm gonna assume that you're a maintainer right now. So everybody in the room, you're now an open source maintainer, whether you
08:21
are or not. I'm going to assume that you've created a project, and that that project actually has users. I know that we probably all have those projects we pushed up to our GitHub repos, public repos, and we're like, open source, and it's us using them. And that's fine. I mean, we all do
08:42
that. We all have those repos. But that's not really what I'm talking about. I'm talking about projects that actually have some users and, and a few contributions rolling in, at least. And I'm also gonna make the assumption that you're using Git and GitHub. I'm actually a little curious. Who in the room today maintains an open source project that's not on GitHub? It's OK. You can admit it. So, like,
09:03
two people. And just for context, who maintains an open source project on GitHub? OK. Yeah. So I'm gonna make that assumption. I think these things are adaptable other than a few of the more technical details, and I'm gonna get into the middle, where we talk a little bit more about Git
09:21
and how it enables maintainers to do their job. So let's start talking through the issues. This talk is kind of a little bit of a sandwich. We've got sort of people stuff, and then we've got, is the bread on one side? We've got meaty technical issue, a few meaty technical things in the middle, and then we've got the, some more people stuff on the bread on the
09:41
other side. So here we go. So the first thing that I ran into when I started maintaining ActiveMerchant was the BigPilo issues problem. And you'll see this on open source project after open source project as you go out and look at them. Issue trackers that are chock full of like five to ten to twenty to, like,
10:00
so many pages of issues. And a lot of them are like, the issues are like three years old. And you're like, what is this even? I don't even know. And this was, this is, I think, especially common if you are becoming a maintainer on an existing project, which was my scenario when I started maintaining ActiveMerchant. It, it had maintainers, and they were,
10:23
they were making sure that it continued to work, but they weren't really spending much time integrating things that contributors were bringing in, and, and gardening and taking out the trash, as it were. And so there's a really simple solution to this,
10:40
and it is triage without mercy. Like, when it comes down to it, as an open source maintainer, I have so much time. And if there's an issue that's been there for three years and no one else has even come in and commented on it, that sucker's dead. Like, why, I wouldn't spend another minute on him. Close it out
11:03
with a nice comment. Say, hey, thanks for this. If you have anything else, and they're probably going, I don't even remember submitting that issue. But you close it out, and so really fast, if you triage really aggressively, especially in a project that's built up a lot of this history, you can, you can quickly slim that list down to
11:22
a manageable list of things that are really active and really, really need attention. The second thing that I've seen as a big problem is low quality contributions. And, I find that, well, this isn't necessarily low quality coders. Sometimes it's
11:45
just people not understanding the project. And so my first solution to that is just to take responsibility for it. I'm the maintainer of the project. I'm in the context of the project, you know, several times a week. I know what the code standards are. I know what the design
12:01
patterns are. I know how to interact with the project. I've got to take responsibility for the contributions that are coming in. And if all of them are crappy, I need to take responsibility for the fact that that might be my fault. I might need to put up some contributing guidelines. I might need to clean up the code so that, you know, the, it, it's more obvious how to contribute to it, or it engenders better code and better contributions.
12:23
I've gotta take responsibility for the fact that, if these contributions are coming in, and also take responsibility for the fact of, if it's a two-line change and it's slightly crappy, who cares? Like, I'll just fix it. Like, it's not, like, it solves a problem. I can take it in, make
12:42
a tweak and change it. And that kind of gets to the second thing that I do to help manage low-quality contributions, and that is, I rewrite history all the time when I'm taking in contributions. So I'll get a pile of commits, of like, four commits, and I look at the diff and it's like one line change. Cause they like,
13:02
tried something and then, no, that didn't work, and let me try this and, oh, this is what it is. Well, I mean, that's cool, but I don't need all those commits in my history. And so I leverage git regularly, and we'll talk about that a little bit more later, to rewrite history and just make it look good. And it's
13:20
cool, because I get to make the contributor look good, cause it actually, like, squashes all their stuff down. I changed and fixed some stuff. It goes in with their name on it and just says, committed by me. And I don't need credit for that. I just want clean code. Communicate expectations. I covered this earlier. Have a, have
13:40
a contributing guideline. If a low-quality contribution comes in, just clearly say, hey, here's the issue. Can you correct this? And that kind of goes to making it their problem, if it is. If, if I get something that's really like, like, for instance, sometimes I'll get an issue. So it's the, it's the, hey, this thing doesn't work. I'm not
14:03
actually gonna tell you what doesn't work, and I'm not gonna give you any details as to how it doesn't work. But could you please fix it for me? Well, no. But if you give me more details, so I'll push it back on them and say, give me more information, tell me more, and I'll try to help you. But I, I have no trouble pushing it back. You know, if it comes in and it's a big change and it has
14:21
no tests, I'm gonna say, hey, can you give me some tests for this? If I can't, if I've tried like five times to merge it in and there's so many conflicts, I can't figure out how to do it, hey, look, can you get this cleanly applying to master? So it, there's no trouble pushing it back to people.
14:41
The next problem, and this is a really good problem to have. You want this problem. But that's the overwhelming volume, when you've really got a lot of changes coming in really fast. And you're trying to keep your issue tracker from ending up at ten pages. And, you know, the
15:01
first, the first thing that I do for that is I adapt effort to volume. So some months, ActiveMerchant gets like, you know, three contributions. In some months it gets twenty. And depending on which of those months it is and how much time I have to spend, I will, I will push things back onto contributors more if there's more stuff to do.
15:21
Like, normal, I might be like, oh, I could write a test for this, but I've got like ten other patches that might be more complete that I need to spend time on. Hey, contributor, can you, can you give me more on this? So really just adapting it, recognizing that it's not your responsibility to do everything, you're trying to, again, going back to the goals, you're trying to maximize the contributions you can take
15:41
in, and that means doing what you can. And of course, you can always add contributors. Like, look for those people who are coming in over and over again with high-quality stuff. Cause if somebody comes back multiple times, it generally means that they're using it for something really actively. And they're gonna have, they're gonna have the context and they're gonna be able to contribute.
16:00
And don't hesitate to add contributors once you see high-quality contributions from them. Now, what about when it's not so much the volume, even, it's just that you've got a lot of stuff to do, open source or otherwise, and, but there are also contributions to take in.
16:21
This is, this is an ongoing struggle, I think, for every open source maintainer, cause we typically have day jobs, and we, we have a limited time to do open source in. And I know for me, there are definitely, I feel sorry sometimes, cause I get this, I get this chance, and I
16:42
go through and I add comments and ask for feedback and stuff, and then people are like, oh great, he's paying attention! And they come in and they're like, yeah! And I'm, and then like ten days later they're like, hey! Are you still there? Did you forget about me? I'm like, no, I'm coming back, I'm coming back. So the first thing that I try to do is really have some focused time. It doesn't,
17:01
there's some kinds of things you can do in terms of giving immediate feedback on patches, et cetera, but to actually merge, to actually get in and take in contributions, you gotta have focused time. For me, it's like thirty, at least thirty minutes, an hour is better of time when I can just put my headphones on and be like, I've got some internet here, and I'm just gonna look at patches, I'm gonna merge the ones that I can.
17:22
And I put that together with a getting things done workflow. And just a really simplified one that allows me to process through things, make sure I'm making forward progress, not getting hung up on things and really moving through things. So what I'll do is I'll hop into
17:41
GitHub issues on GitHub, on the project, sort by updated. First, I'd really try to be really good about first in first out. So if you can if it's been like two weeks since I worked on stuff, I want the guy who submitted something two weeks ago to get feedback first. The guy who submitted something yesterday, I hope to get
18:02
to you today, but you're gonna have to wait. I gotta, I gotta really respect the contributors who have been waiting longer. I do a quick review of the submitted info and the diff on GitHub. And then I'm basically trying to figure out, look, is this something I can merge like in five
18:20
minutes? Does it look ready to go, and I just need to load it up, write a, read me, or change log entry, and it's good? Is this gonna be a bigger contribution? Like, for ActiveMerchant, that to me is somebody added a gateway. When I need to add a whole new gateway, that's like a big process. That's gonna take me a half hour, forty-five minutes.
18:41
So I want to go through and try to get the smaller fixes first. And then I'll queue it up, queue up those bigger things, and by queue it up, I basically mean skip to the next thing, and then when I get to the bottom, then I go back to the top again and start working on longer things. But I know I've knocked out the smaller stuff.
19:01
Now the next thing in terms of time management that I've done that has been a huge help, like when I first started, I really sucked at being an open source maintainer. Like, I was just spending so much time working, like, doing busy work. Doing stuff that I
19:21
didn't need to be doing, but I didn't know I didn't need to be doing it. So the first thing is hub is your friend. If you're using GitHub, hub is awesome. How, who's used hub? OK. If you haven't used hub, like even if you're just, like, you just work on private repos for your company, hub is amazing. It basically wraps the git command in all kinds
19:42
of GitHub-specific goodness. It allows you to clone a repo off of GitHub without having to figure out the whole URL. You just, like, intallet slash whatever, and boom, it'll clone that for you. And the really cool part is it wraps the,
20:01
so git am is what the Linux kernel maintainers use to take a mailbox directory and pull the patches out of it and apply them. And hub wraps the git command to adapt that where you can paste, you can say git am and paste a GitHub URL, pull request URL, and it'll apply that locally, just like it would apply
20:21
a patch off of a mailing list. It's awesome. And then you can go in and edit it, you can rebase, et cetera. You don't have to, like, go and, like, add a branch for that person, like that person's branch and try to muck around with it. It just takes in the chain, the stuff for their PR. So let me actually show this to you.
20:41
Let's do a little live coding, which is always fun. We're gonna actually take in a contribution and merge it for ActiveMerchant. So I've got a few here. I'm gonna, let's try 896. So.
21:07
So this is the ActiveMerchant GitHub repo. I'm gonna hop over here into issues, which of course includes pull requests. I'm actually gonna skip over a bunch of stuff, cause there's a bunch of more involved stuff here that I need to work on later.
21:27
Eight. Which one was it? 896. Yeah, this one. So this is a really easy one. I like really easy, especially for live coding. So basically all this does is fix some docs. Awesome.
21:43
You know what? Honestly, this is the one time when I'll actually use the merge pull request button on GitHub. I do not usually use it, but this is the one time. We're just gonna do that. Done. There you go, my man. OK. I've got another one, though. 898. I'm actually
22:03
just gonna, OK. So somebody's contributed something for the Mercury gateway. I'm loving their, their following the convention that we have in ActiveMerchant of referencing the gateway. You'll notice I've already had interaction with him. I asked him to
22:22
change something. He came back in and changed it. So we've got two commits in this pull request, which is great. We'll just go over and look at the diff real quick. He's basically added a store method. And the backing code for that. He added a test, which is awesome.
22:41
And so what I'm going to do is really cool. Oops, that's not what I want. GitHub, you broke the back button. OK, so check this out. So we're gonna go over here. I've already got Git, ActiveMerchant checked out. I'm actually gonna do a pull, cause we just merged that thing. And now, check this out. Get am,
23:07
and I paste the pull request URL, and it applies those two commits right there on top of my master branch here. And then what we're gonna do is hop over,
23:21
well first we're gonna run rake and make sure our tests pass, which I expect them to. I don't know the reason they would not. Sweet. All good. If you look at the git status, you'll notice there aren't any local changes. There's just
23:40
the two commits from this, from this guy. I'm gonna go over and actually add something to the changelog now. So this is another thing. I ask people who contribute to ActiveMerchant to actually not change the changelog. It turns into merge craziness, because everybody changes it, and then it becomes this point of conflict whenever you're trying to merge in, especially if you're
24:01
doing a bunch in a row. And so it works much better for me to just come in, make that change, and then merge it into their change. So I'm actually just gonna go over here, since he has this awesome message already, and let's give him some credit here. KC Dragon, you're awesome.
24:22
And we're gonna save that. And then I want to go over here. Now, you'll notice I have another commit here. So I'm just gonna git ci dash a. I'll pop up my editor here. So I'm gonna add that. And he had
24:41
this nice comment here too. Just take that in. Paste it in here. OK. Now, the other trick
25:10
I'm gonna do here is I'm actually gonna add magic comment to close this out automatically. Because what's gonna happen is, when I merge this in, because I'm gonna do a rebase, it's not going, GitHub won't
25:21
know that I'm actually merging that pull request. So I'm gonna put that there. So now if I go over here, you'll see I've got three commits. Well, I don't want three commits. This is one logical change. There's multiple commits here. And I like, call me pedantic,
25:40
but when I want to go back and figure out why something's broken, I don't want to be looking through people's work in progress commits, or even my work in progress commits. Especially in a library like this. So what I'm gonna do is I'm just gonna git rebase dash i origin master, and I'm going to fix up this one and
26:03
squash this one. And that's basically gonna pop me in here. I'm gonna delete that. Now. Check out the git status. One commit. So now I've got clean history to work with. I'm just gonna do a git push. Now,
26:24
if we go over here to GitHub, that's cool. Is that cool? It, like, knows that I just closed that, and automatically updates the page. And if we go over now and look at active merchant, you'll see, kcdragon still gets full credit for that, and I'm just the committer, which is
26:40
exactly how I like it. So to run over that, again, really quick. I do a sanity review on GitHub. I use git am to pull that thing in, resolve conflicts.
27:01
There's even a little dash three option you can pass to git am that does a three-way merge. And will sometimes merge stuff that basic git am will not. Sanity test run, review it, clean tweak. I'll do everything from nothing except adding a changelog line, or maybe even not even that if it's really
27:21
minor, to completely changing the code and cleaning up a gateway, because I understand how a gateway should be. Do a final test run, add a changelog entry, do a git ci. If it's just one and I'm just, like, adding a changelog entry, I'll just do an amend. If it's multiple stuff, I'll go ahead and do the rebase and squash it all together. And sometimes, not very often, but
27:41
sometimes there are actually multiple logical changes in one pull request. Sometimes I'll ask the contributor to actually split those up, but sometimes I'll take them together and actually have two, two commits, and then push it up. So that's, that's a big part of how I've managed to just manage my time and make it so that I'm really effective when I'm in
28:01
the mode of it's time to take in contributions. So next problem. Original poster does not deliver. This happens a lot. Somebody comes in, they're like, this is a problem, or here's this awesome PR. And you're like, OK, well that's cool, but I need this or I need that.
28:21
And silence. And more silence. And you're like, a while later, you're like, hey, anything. Silence. It's just like they disappeared off the face of the earth and that's cool. I have a thirty day rule for that. Look, if I've given you feedback and you haven't gotten back to me in thirty days, this must not be important to you. And it's not important enough to me to,
28:42
to want to work through the issues that I brought up, and I don't think it's serious enough for that. I put a nice comment on there, say, hey, if you have more for me on this, please reopen it. I invite them to reopen it, but I'm gonna close this out for now. Nasty contributors. Thankfully, this isn't one I've had to deal with too much. I've had a
29:01
few heated sort of exchanges, but nothing really major, but I've seen them. Oh, have I seen them. I mean, we've all seen the ultra-open source maintainer versus contributor flame wars, right. Like, yeah, I could name some from, like, Rails history and I think Ruby Dramas has, like, a
29:23
nice little history of them. You know, the first thing that I try to do with anything like this is I try to make it about the code, or about the problem. It's like, there's no personality here. I don't even want it to be about my style versus your style. I just want to talk about the code, what works best in the
29:42
context of this project, and what makes sense. You know, a project like ActiveMerchant, it's about getting stuff done with gateways. It's not the prettiest thing. It's plumbing. So there's not really, like, tons of stylistic things. It's really about, hey, does this make it simpler to maintain? Does it make it simpler to contribute to, et cetera. So I try to make it about the code.
30:01
Secondly, I will like, I will squash people with civility. Like, you will not get me mad. I dare you to try. No, don't. But, no, when people come in, they're kind of heated, it's like, I'm just nice. I'm just like, cool, chill. Like, I don't care if you're like, heated. I'm just gonna tell you it's cool. I'm
30:22
not, I mean, honestly, if people get really heated, I'll just like, patronize them to some extent. It's like, it's OK. So I just, I don't find that huge amounts of return anger is very productive as a maintainer. And then the third thing, I think it's really
30:42
important as an open source maintainer, is you are a volunteer. This is not, like, you do not have this huge responsibility to the contributors. Your real responsibility is to the project. You getting all heated at a contributor and going off in that's bad for the project. Don't do that. Just be like, I'm a volunteer. I'm gonna back out
31:01
of this. Maybe there's another contributor, or another maintainer you can hand it off to and say, look, I just need to back away from this. Can you take this guy and deal with him? Hopefully your other maintainers have your back and they'll just hop in and do that for you anyhow. But be a volunteer. If you need to walk away from it for a week or two, that is fully your prerogative, and it's better that you do that than that you get burnt out and leave the project.
31:22
Now, other maintainers can be a problem. Again, I haven't had too much trouble with this. My, my fellow maintainers mostly do just what they need for the project. They, but they don't really, like, create new messes or anything like that. But I think it is really important to communicate expectations to fellow maintainers. Especially when you're bringing somebody new on. Just
31:42
be like, look, here's how we do stuff. You've been contributing for a while, and that's awesome. Here's some things that you should know about the way that we maintain the project, and just make sure everybody knows what's up. Secondly, I think it's really important to open up channels of communication with your fellow maintainers. A
32:00
lot of times this means a channel other than GitHub. Like, a private channel. You need a back channel with fellow contributors. You need their email addresses so you can just, like, email everybody and be like, hey, this flame war has opened up on this issue. We should probably talk about this a little bit. Not so much to gang up on anybody, but just so that we're all on the same page and, and
32:21
aren't working at cross purposes to each other. So it's more like, if something happens, and you're like, ooh, why did you do that? You don't have to, like, call them out in public and be like, hey, you idiot fellow maintainer, why did you do this? You can say that in private email instead. Now, these are my, but what about Xs? And
32:40
these are the things that I haven't figured out yet. I'm still trying to figure out this maintainer game. It's not, there's always new stuff to learn. There's always ways to get better. These are things that I haven't figured out. The first one is mailing lists. Mailing lists for open source projects suck. And, especially if you're not
33:01
a big enough project like the Linux kernel or something that has, like, dedicated sysadmin neckbeards to manage archaic mailing list software for you. GitHub issues are cool. I find, like, you can use them sort of like a mailing list, but it's not quite the same. Sometimes you just want to, like,
33:20
open up a topic and see what people say. And it's also challenging, too, because it's so disconnected from sort of the GitHub workflow. You can have, like, this thing over here. And, but people don't know about it, and they, like, they don't, and you kind of have to reach a certain size before you have enough people signed up where you're having interesting conversations and stuff. So mailing lists
33:42
is, like, that's an open, painful thing. I think if you want to get acquired by GitHub, you should go and write a mailing list awesome thing that latches onto GitHub and they'll just buy you. I promise. No, I don't, I don't know. But I would think that, and I, I've dropped this in a few different circumstances now with GitHub
34:04
people around, and they always just give me this knowing look and they're like, yeah, we're working on it. I'm like, come on. Give me something. Another one that can be really hard as a maintainer, like, a lot of times you're down in the plumbing. You're fixing stuff. And you're taking in contributions from other people. But sometimes a
34:22
project needs a big sweeping change. This is hard. Like, and I still don't know how to do it really well. ActiveMerchant needs some significant changes, and some of it's just time. Like, when I have time, it's like I'm spending it taking in contributions from people, and I need some time, and probably I just need to add, we need to add some more contributors and some more people doing
34:40
maintenance stuff so that we also have time to work on some of the big sweeping stuff. But this is a hard one, and it's something that I'm still thinking about a lot. Forks could be a problem. I feel like GitHub's made them less of a problem. It's never been a problem that I've had so much. And since I haven't had to deal with it, I haven't really sort of figured it out, but it could be a problem for
35:02
you. I don't know. I threw it in there, cause you have, you can't talk about maintaining open source without talking about forks, or, that's what they tell me. Now, the payoff. So, great. Wow. You told us about all these problems. Why would I ever want to be an open source maintainer? It sounds really hard. It is really hard, but
35:20
there is a big payoff. You know, for me, the multiplication of value that you get out of open source is amazing, and it's why we see so many companies now even open sourcing things that are sort of a core competency. I mean, Shopify, open sourcing active merchant. I mean, I remember Toby said at one point, I think, he was just kind of
35:42
amazed at how many of his competitors were using active merchant. And kind of like, thought that was awesome too. Just like, that they'd been able to do this thing that was so useful even to competitors. But there is so much value. I mean, Spreedly currently supports fifty-three payment gateways all via active merchant. And active merchant actually even has even
36:00
more of those, cause we only add them as customers request them. And we wouldn't be able to do that. Like, we wouldn't have nearly that many gateways if not for the contributions that come in via open source. So it's totally worth it from that perspective. It's awesome to get to be a hero. I don't know exactly what the garbage collector superhero costume looks like, but it is pretty fun. And
36:24
it's, it's pretty, like, when people, like, to me, I take in a patch, I merge it, I'm like, OK, like, I'm just doing my job. But then people come along and they're like, yeah, thanks so much. I got that in. That makes my life better, simpler, whatever. And that feels good, man.
36:40
Accelerated learning. I've learned so much from being an open source maintainer. Even just about Git, but then about code, and you're taking in all these contributions from wicked smart people and getting to, to review them and change them. You get to start to understand some of the things that make it easier for other people to contribute to code, which is a useful thing no matter what project you're
37:01
working on. It's a really great way to learn stuff really fast. Sometimes the hard way, but really fast. It's an opportunity to give back. We've all benefited so much from, from open source. There is definitely, and this is maybe actually my favorite one.
37:21
There is just this amazing thing of working on something that's so much bigger than anything you could have done yourself, and getting to be a part of that. Like, being like, wow, there are all these people writing this awesome code, and I get to be like a part of bringing that together and making it happen and getting it out there, and there's just something really thrilling to me
37:43
about that. Maybe, maybe I'm just awed that way, but I, I think it's really pretty amazing. So that's all I have. Thank you so much. I'm not gonna take questions right now, but feel free to come up and ask me whatever you want to.