04:33 - Inspired by Scott Hanselman: Bring Kindness back to Open Source 

06:02 - Cultivating a Community

08:53 - Making it Easier for People to Contribute

19:33 - Responding to PRs

20:52 - Contribution Guidelines

32:38 - Being an Effective Contributor

41:18 - Responding to Unrelated Pull Requests & Opening Issues

47:55 - Working with Large Open Source Projects

Picks

lite-server (Joe)
The Goldbergs (Joe)
Review: In ‘The Diary of a Teenage Girl,’ a Hormone Bomb Waiting to Explode (Ward)
Code Folding in Visual Studio Code (John)
How Lucasfilm made Star Wars’ first official VR lightsaber battle (John)

 

 

[Sings] Don't be cruel to a heart that's true. Don't be cruel…

[Inaudible] be no other lover.

To a heart that's true. There are two bald men on this show. Where are the other two or three that we have?

It's too many bald men.

Bald is beautiful.

Hey everybody and welcome to episode 86 of the Adventures in Angular show. This week on our panel we have Ward Bell.

Howdy.

John Papa.

Doody.

I'm Charles Max Wood from DevChat.tv. And this week we're going to be talking about being a good open source citizen.

Does anybody actually know who Howdy Doody is? [Laughs]

That's [true]. Look it up. We'll put it in the show notes.

I think only one of us is that old.

Yeah, I know Chuck. It's…

There's only one of us that looks that old. [Chuckles]

Ooh. Now we're all wondering.

Yeah. Alright. So, John this was your recommendation. I think we all got behind it pretty fast. But I'm kind of curious what you were thinking when you recommended this topic.

Yeah, so there's… I'm an owner of many different open source libraries up on GitHub, several of them. And I'm a contributor to many as well. And it's been interesting. Lately it seems like the topic keeps coming up from different angles. As an open source owner for a library, what's the best way to encourage and to keep the community to help contribute to things? Like the style guide or [something that's] more codebase, like Toastr JS which I own. And the other side is: how do you make it more palatable for people who maybe are noobs, who want to come into it and try it out for the first time, and people who are more experienced who want to do it as well? Because it can be a scary proposition.

how do you be a good citizen from somebody who's contributing to a library? Like we've all used something before and then found out, “ah, library XYZ isn't doing what I want. So, I just want to tell that person Ward Bell he's awful and his library Bard.js is just destroying my life.” What's the right way to actually pose the question and get a good response from an open source project to get what you want?

You put in a pull request that rewrites the entire thing. And then you call the pull request “Fixed it”. [Laughter]

I think the right solution there is to create an issue that outlines your specific environment-specific bug and then expect the creator to solve it for you.

“Me no like this library.”

So, this is going…

This is going exactly the direction that I was thinking it's going in. to some degree much of what we were going to talk about is inspired by actually a Scott Hanselman post called 'Bringing Kindness Back to Open Source' in which he, and we're going to put that in the notes, in which he makes a case that we're going to discuss up here for how open source owners like us should treat the community, treat our community. But we as open source owners have immediately turned it around in the first five minutes here and want to talk about how those people who consume our stuff should be nicer to us. And I can't wait…

I can't wait to talk about that, too. [Laughter]

It's not just for us, right?

Yeah.

It's for everything. I don't own the Angular library for example and I see a lot of the comments up on there. I own some small libraries and some of the comments I get are, “Hey, I'm having a real hard time with this and this is what I tried. And how does this work?” or “I'd like it to work this way instead of that way.” But then once in a while you get one that's, “Your library bad. You fix. Me no like you.” And the way you respond is important. I've got a certain way that I respond but I'm sure it's different for other people, too. So, as an owner of an open source library I think it’s really important to keep in mind that it's easy for people to sound worse over GitHub issues than it does in person. Nobody's going to come up to Ward Bell's face and say “You're terrible. I hate your library,” except for me.

Yeah.

But people will write that very easily. And we've got to keep that in mind as that these aren't bad people. These are just frustrated people. Sometimes it's three in the morning. They've been banging their head against the wall for four hours and they just want some help. Ward, you own Breeze right? Well, your company does.

Yes.

I'm sure you get stuff like this, both positive and negative. How do you cultivate that community?

It's really a challenge for us because we need to look behind the statements that we sometimes get, which can be very challenging and very aggressive. And as you say, put ourselves in the position of that person who has been struggling for so long and just didn't find a way to say it that would bring out the best in me. And what do I do about that? If I'm smart I put that one to the side until I cool down. How about you?

Yeah, sometimes I get some that I just have to read. I have a general philosophy by the way. Unless it's an immediate, quick answer, I generally let my questions sit for a day, maybe two, if they're not urgent. And I let the community chime in. And I find a lot of times, especially in my larger repos where a lot of people are keeping an eye on them, other people will actually answer the question for me and there'll be a nice conversation going which often I learn something from.

And then sometimes they actually make a pull request out of that, which I find awesome.

Yeah, no. that's the good stuff. And let's state for the record that it's mostly really good stuff.

Oh, by far, yeah.

That one of the pleasures of open source, being an open source provider, is the conversations that you get with the people who care about your product. That is just one of the greatest rewards of doing it, I think, is that interaction you have in the community and the discovery that somebody actually cares about something that you put your heart into. So, that's really the brilliant part of it.

It's really funny to me that the way you're talking about this (I've done both open source software and podcasts) is the way I feel about podcasts and some of the feedback I get on the shows.

It's really about just how you interact with humans, right? Let's say if you've got a spouse or friend, a child, whatever, an enemy. [Chuckles] If you want to talk to somebody and you actually want to get something, let's say you want your buddy to go to lunch with you today, or you want your wife to make you dinner, or you want your husband to go get the groceries, or whatever it might be, if you want somebody to do something for you, you don't say, “Hey, go do that,” or, “What you just did was awful.” The way you come out with it is saying, “Yeah, I'm kind of hungry. Are you hungry?” “Do you have a few minutes? Would you like to go do some groceries with me?” You try to look from that person's perspective to motivate them to work with you.

And it's the same way that we do that, we should be doing that with open source and say, “You know what? I've got this problem. I know you tried to solve it. But here's my scenario and this is why it isn't working for me. Help me see what I'm missing or help me solve this in another way.”

We should really divide this show into two parts: how to be an effective contributor on the assumption that many of our listeners would like to contribute to open source and have had a bad experience doing it; and then also from the perspective of an owner of open source, what we could do better to make it easier for people to contribute.

And why don't we start with that latter one? Because I think that's probably more important right way, right? Because if that's not happening, nobody's going to be good. Let's start from the owner's perspective.

Well, I think that adopting the 'no meanness rule' is probably pretty good. A good place to start is to welcome…

Can I clarify that?

Yeah, sure.

What do you mean by the 'no meanness rule'?

That means that…

That means don't let Ward be part of your community at all. [Laughter]

Seconded.

Oh, gosh. I'm feeling wounded. You guys so mean! [Laughter]

Let's talk about Star Wars. [Laughter]

Oh [that's the cruelty] of the first order. [Laughter]

Goodness. You know, it's actually… it's easy to be inadvertently mean. The obvious thing is when somebody puts something in there you don't say, “Hey, you putz. What an idiotic suggestion. Get off my lawn.” Alright, so that's kind of obviously mean. But there are… it's easy to be mean unintentionally. And there are a couple of ways that I can do that.

For example, I can get on my horse or my platform or my soapbox and start going off on why, without actually really listening clearly to what the person was doing, why there's a right way to do something. I haven't listened at all to what that person was, where they were coming from or anything like that. I just want to tell them how it is so that they come back better educated next time. This is not a good approach. That's really discouraging to people. Because you know what? The people who get on here for the most part, they worked hard on their own in the dark before they came and put that issue in there or that comment in or whatever. And they come with their hat in their hand and I just slap them. So, I didn't think I was being mean. I thought I was helping. But I'm not helping when I take that attitude.

So, that's one of the ones that I have to look in the mirror and change about myself. What have you got, John?

I want to chime in here. There's another easy way to be mean and that is just bring straight up critical of how the… if it's a PR or an issue was phrased or formed like saying something like, “There's bug in this,” or, “There's grammar errors in your request,” or something like that instead of saying, starting off something with, “Thank you for putting those. There are a couple of issues I'd like to have adjusted. Could you make these fixes?” or things like that. But sometimes, just bluntness can actually come off as very off-putting. As much as honesty is valuable…

Yes.

Saying that, “Well, there's a bunch of grammar errors in here,” makes it sound like, “You're a thirdgrader who wrote this?” rather than saying, “Oh, we're missing a period here where there should be a period.”

Yeah, etiquette's a huge piece of it. And I chime in and agree with you wholeheartedly, Joe. It's so easy to say, if somebody puts in a PR and says, “Hey, can you fix this instead of that?” and maybe let's say I disagree and I'm the owner of that repository. I could easily just say, “Nope. Don't want to do it. Not whatsoever. Ain't going to happen.” Or I could say, “Hey, thanks for chiming in. I hadn't thought of that before. Could you help me understand why you feel like that's an important change? Because maybe I don't agree with that or maybe I do, but I'm not totally understanding what you're trying to accomplish.” Or you just try to word it out in some way to draw out more information.

A lot of times I find that when people ask questions on the issues or they point something out, they have in their heads the context of what they were trying to solve but they don't always communicate exactly what that is. So, when we're reading it, one of the reasons I initially think that knee-jerk in my head is I don't quite understand what they're trying to do. So, I try to pause and then ask a question back, say “Thank you. Is this what you mean or is that what you mean? And if that's not what you mean could you please further clarify that?” And I find a lot of times that just encourages the conversation and maybe other people chime in, too.

Yeah, on the Rails repository a lot of times people make suggestions. “Oh, Rails would be so much easier if you did X,” or, “Things would be so much better if you involved such and such or so and so.” And a lot of times their response is, it's three letters. It's PDI. Please do investigate. And so, basically what it is, is “We're not telling you no. Instead we would rather have you look into how we could possibly implement this or what would go into this particular change that you're asking for. And then once we have more and better information, then we'll make a judgment call about whether or not this is something that we can do.” And so, it's an open call for somebody to be involved rather than a, “No, this is stupid,” or, “It doesn't fit with our project.”

There's a lot to consider when you're answering these. And if we're getting good productive questions and issues, there's a good way to answer that, too. Like be overly thankful. When people make… like all the time for example I'll use my Angular style guide as an example. I've had over a hundred contributors to that. And I got to say, I'm going to guess, and I don't have any facts on this but I could figure it out, that of the hundred contributors maybe 70% of those are typos. People will come in and fix where I used the wrong spelling of a word or I wrote form instead of from where spell check didn't pick it up. And they'll make a very simple pull request to change things like that or fix a broken link, very low-hanging fruit. And I try to say thank you at least, every time I accept those pull requests on the things and just to say, “Look, I appreciate this. I didn't catch it. You did.” It's kind of patting somebody on the back for it, because sometimes those people, that is their first pull request, too. And you want to encourage it.

When I'm typing John…

Yeah, so…

They're ty-ops, not typos.

Ah, [right].

Oh, okay. [Laughs] You lost me there.

You had me there. [Laughter]

I was like, what? [Laughs]

Right. So, that brings me to another one that's easily overlooked particularly because we're often in a hurry to try and process through these issues and stuff like with PRs. And that's that, we may even… gosh the other day I did it. I accepted the PR and I pushed it right through but I forgot to say anything back to the person. And it just said “closed”. And they had no idea that I had actually appreciated their work and incorporated it right into the product. To them it just looked like I had slammed the door in their face and hadn't done anything with that PR. It just takes a little extra moment to thank the person for the contribution, the effort that they put in.

It is. And I'm a victim of that, too. Sometimes I accept without saying thank you and it's so easy just to say thank you. You should definitely do that.

Yeah, definitely. I'm kicking myself because it's…

Oh, you know all of it. I just think about the things that I do so unintentionally that are easily misread, that I would misread if I was on the other side of it. It would be easy to say, “Get over it. We're all in the coding business. This is the way we play this sport,” and all that stuff. “Dry your tears.” But you know, life is short and nobody wants to be treated that way. So, it's an opportunity to be nice and be grateful, show the gratitude that I actually do feel but didn't take the time to express.

Right.

Yeah, for example I got… so, here's one that I denied as a pull request. And what's kind of funny is I didn't even look at this. On the Angular style guide there are more pull requests than issues, which is interesting. It's kind of backwards in my mind. But so, the pull requests, I'm looking at some of the closed ones and here's one I declined. The gentleman here was looking to add a PDF. He took the time to create a PDF for the style guide. And this is probably not a great example of me being kind. So, that's why I picked it. And somebody else chimed in and said, “Hey, it's not really using the format that you want.” They had a little conversation.

In the end I decided, this is a nice idea but I don't think hosting a PDF on a GitHub repo is a great idea. Folks can create one as they need to. And so, I closed it. But I never… I said thanks but I never really properly thanked him. He spent time doing this, right? And just because I disagree with it which is another topic we have to talk about is it's okay to disagree by the way and it's your repo, I think it's important to let people know, “Look, you took the time to do this. I appreciate it but it's not something that we're going to do here.”

Yeah, rejecting somebody kindly is hard. Because for one thing, you are rejecting them, right? So, being able to reject somebody with… reject their work without rejecting them is difficult to do. And it certainly bears more… it behooves you to spend a little bit more time and patience on something like that.

Oh, yeah. Having been the rejected one on occasion, that's actually very instructive. You all must go out there and get your PRs rejected a few times so that you remember what that feels like.

And reasons for rejection. We should talk about what are good and bad reasons or ways to reject. Like, disagreeing is fine. Ward's team, they own Breeze. Breeze is their product at IdeaBlade. And ASP.NET is Microsoft's product, and Angular is the Angular team's product. They're not mandated to accept every PR that comes in. it's their products. Just because I want it to work this way or that way, and I may have a good reason, it doesn't mean they have to accept that PR. So, it's okay for them to say no. It's okay if you want a repo to say no. But just be polite about it.

Yeah. And there has to be some way to keep it open. You're reminding me of one I… or a direction. It wasn't a PR but it was, “When are you going to do this? When are you going to bring immutability into Breeze?” My first reaction is that's like saying, “When are you going to make cats and dogs get together?” It's sort of, runs against the grain of what the library's about. But that was a great opportunity to think about it, try and work through the thoughts and engage in a conversation. And so, one of the things I had done that kind of… I may have done it there or at least somewhere else where what I did was I closed it but I said, “Look, I'm closing this because I don't think it's going to go anywhere. But if you are still hot about it and think I made a mistake, just let me know here and I'll consider reopening it.” That little wedge of light can make the difference, I think.

It can. And you know what's nice is sometimes I'll get a request and I agree with it but I have no time to do it. And this happens a lot, to be very honest with you. All the repos that I manage, I don't get paid to manage any of them. [Chuckles] So, for me to sit down and work on some of these, oh I just don't have the time. I've actually got a job and I've got a family. And frankly, both of those come first. But I love this idea. So, what I've done as an owner is I, on my more popular repos I create labels for things like 'help needed' or 'community contributions', I'm looking for those. So, I put them up there like help wanted signs. And then other people then know by looking at those labels, “Oh, that's one that I could take an opportunity and probably contribute to. And it does work.

Yeah. So then, the next level of accidental insensitivity for me is not getting around to responding to the issues at all, or the PRs.

When is it too late? Let me ask you that. How long do you think is too long to respond at all?

Well, some of them, I just went through a repo that wasn't mine that I was taking over and there were issues six months back. And they're concerned with state of affairs that doesn't exist and hasn't existed for a very long time and that you just basically have to close it out. But it's a sad state of affairs if you're looking there and you're hundreds or thousands of issues behind and you haven't said anything to any of them and you haven't done anything about any of them. That's not a healthy state for an open source project. And by the way, as one's energies comes and goes, that happens.

So, you brought up Bard. I'm behind on that one. And I feel bad. [Chuckles] at this point, I throw up my hands and say I just haven't time to get back to it. I want to, but I'm reminded that I owe those people at least the courtesy of, “I hear you. I don't have time this second. If you want to contribute, that'd be great. Hang in there with me and remind me again if you don't hear from me in a while.” That's the best I could do. But you got to do something, because just sitting there saying nothing leaves people feeling the door's been slammed in their face in another way.

So, then there's the next level up in degree of difficulty about how not to be mean which is when you don't even tell people how they can contribute.

Ah, so you're talking about contribution guidelines.

There are no contribution guidelines. Just having some contribution guidelines is a good thing, particularly if you're unwilling to take something without [laughs] if they don't follow the guidelines.

If you don't tell them the guidelines, it's kind of tough.

So here's one I have. And we can openly bash my stuff or not on this. On the style guide, again this is just a document for Angular, at the bottom of the first page [is a] contributions. And my process for contributions in the style guide is relatively short because it's not code. So, I don't need unit tests or anything there. But my process says number one, discuss the changes in a GitHub issue first. Number two is open a pull request, reference the issue, and explain the change and why it adds value. And then number three is the pull request that we evaluate and either merge or decline. And I don't promise that people are going to get it in. It's going to be one way or the other.

But really what I'm looking for is… what happens most often is people don't know how. So sometimes, they just open up an issue and they want something but they want me to do it or they want someone else to do it. But I do encourage and I think maybe this has worked because as I pointed out earlier there are more pull requests than issues on here, but I think those are pretty simple rules for a non-code repo. For a code repo, there's more to do, right Ward?

Always. Although some repos as you say are harder to contribute to than others. So, if you've got a code-based repo then you probably have tests over it. And then there's a whole development of the product can involve just an incredible amount of apparatus that isn't necessary for using it. And it's tough. What do you do? Do you force everybody to go down that gauntlet? I'm not sure, because there are certain PRs that I can take. Like if they're going to change the documentation on it, I want that one. I don't think they need to have to write tests [laughs] unit tests to change the comment or to add a comment into the API. But if they're going to change the code, then I have to have them do it. And if I don't make it easy for somebody to build the product and test the product then I've effectively cut them off from that avenue of contribution.

Well, let me turn this around on you guys. So Joe, let me ask you this. Have you ever called up customer support somewhere and asked them a question about how to use something and they kind of just gave you one of those, “What are you, a doofus?” type answers?

No, I've never been accused of being a doofus. [Laughter]

You know…

I can't think of a specific example. But I'm certain that's happened.

Yeah, it's happened to me where the first question they ask me when I go and I call in about my printer or something that I buy from HP…

Oh, yeah.

Have you plugged it in?

Comcast.

Comcast is the worst. It's like, “Well, let's see if…” Like, I've already diagnosed 10 things on this. It's got to be on your end, guys. [Chuckles] It's either your modem or [inaudible].

Yeah, but like, “Does it have power?” [Laughs] Have you jiggled it a little bit? [Chuckles]

Right.

Things like that. Is it near a wall? So, you get those kinds of things and what I'm getting at from that point is you know what? If you don't want to be asked silly questions as an OSS owner, then put those commonly asked things right in your contribution guidelines.

Right.

If somebody does a PR against my repo where I actually have code, which I've got several of those, I put right on my contribution guidelines, this must follow these guidelines. There must be a PR. You must have an issue that it's referencing. It must be something that has a unit tests that tests the capability for both pass and fail where applicable. I've got these little bits of guidelines that it should follow so people don't have to wonder, what's the right way to do this? And I think that really cuts down on a lot of the frustration that people have when they're trying to figure out how to contribute. I know it's helped me get cleaner pull requests that I can literally just run through and click merge, merge, merge, merge.

I have a question about the contribution guidelines. And this is something that comes up periodically as I discuss with other developers, and that is having a code of conduct. Do you feel like open source projects deserve or need a code of conduct?

Wow. That's an interesting one, because I read about that. There's a Contributor Covenant kind of thing. And it must reflect my lack of awareness of what's necessary there because I guess the things that I assumed were proper behavior can't be assumed. And…

Yeah.

So, I wonder about… I see this at conferences, too. At ng-conf you got a code of conduct and it asks you to do… it asks you not to do all kinds of things that I have a hard time thinking that one would do in the first place. So, why are you telling me this? Maybe you guys can talk about that.

So, I love this. I love this and I was waiting. I was hoping Joe or somebody would ask. Chuck did. But Twitter has one that I really like to follow. And I just put the link in the show notes. And they've got six simple things that I'll read quick. Be friendly and patient for the community. Be welcoming. Be considerate. Be respectful. Be careful in the words that you choose. And when we disagree, try to understand why. So, this is basically just about how to be a good person too, right? [Chuckles] When you follow these kinds of things, I think it makes it a lot easier not to be… sarcasm doesn't translate well through words. We've all gotten one of those text messages or emails from somebody, probably that we love, that said something and you're like, “Wow, that was hurtful.” And it wasn't meant that way, but that's how it got interpreted.

So, I think following some kind of code of conduct is a good idea. But frankly Chuck, I don't see them a lot on repos. And I know I don't have one. But it might be a good idea to add.

I…

I'm reading one right now and I should put it in the show notes. And it's just incredibly well-written. I agree with it, just as I do the codes of conduct that I'm asked to sign when I attend a conference. And I guess they're necessary. I'm one of those people also that say, “Really? I got to tell people to open the door for somebody or be nice?” But I guess I do.

Yeah. So, I can tell you… I'll give you a few examples here. One of them is kind of embarrassing because I love the Ruby programming language. But recently there was a motion to basically add a code of conduct to the contributing verbiage for the Ruby programming language. And a bunch of people came out and said we've never had one and we don't need one because Rubyists are supposed to adhere to the principle of MINASWAN which is Matz Is Nice And So We Are Nice, and Matz is the creator of Ruby. But then a whole bunch of other people came out and basically proved the need for the Contributor Covenant by arguing in very off-color and off-putting ways about why they didn't need one. So, it's interesting. I don't know. Initially my reaction was, “Yeah, we don't need one. We've never had an incident with it.” But the nice thing about having one is that when you do have an incident you can say, “Hey, that's against the code of conduct. Knock it off or you're gone.” And yeah, you don't need one until you need one.

Yeah, you sold me. I'm coming over.

Its, yeah.

I'd like a pull request. So, if people are looking for it, people go ahead and put a pull request up in my repos for that code of conduct. [Laughs]

Yeah. And most people that I know use Contributor Covenant. But it's just really interesting because I think for the most part people are nice people and they're not going to go out of their way to make other people feel unwelcome or do rude or mean things. But there are those people out there and we've seen it with some of these movements like GamerGate and some of these other folks out there that are doing all the way up to and including the things that I think even the people who don't necessarily agree with the social justice movements that these groups vocally oppose would say is not okay when you're actually saying, “Go out and hurt these people because now you know where they live.” And so, just by putting that up there and saying, “Hey, we're not going to tolerate any shenanigans here,” it just tells people we're committed to having a welcoming community around our project.

Yeah. And by the way, this reminds me. Because first of all if you want to remember a bad example, there was that infamous 'Code like a porn star' that really opened people's eyes to what you shouldn't…

Wasn't that a conference talk?

Yeah, it was a conference talk. Opened your eyes to what not to do. And then what follows on that is the defensive posture about the first amendment and stuff like that. And so, I think we should just settle that. You know? The first amendment is how the government behaves. There is no first… this is our choice here to say that there's kinds of speech that you're welcome to do out in public sphere but you're not allowed to do here. And don't beat me over the head with the constitution because I'm not run by the constitution. I'm run by a different set of rules.

Yeah.

There is no freedom of speech here. There is how we choose to speak to each other and how we're going to govern ourselves.

Yeah. I kind of chalk it up to a metaphor of private property.

Yeah.

If you're on my property and you're doing something I don't like, I have the right to ask you to leave. And you still have your freedom of speech. You can have it off my property.

Yeah. So, I guess it's necessary. And during the course of the five minutes we've talked about it, I've come around. [Laughs] Maybe that'll happen to somebody who's listening.

Well, we all want to think that everybody's going to be nice to each other. But the fact of the matter is, is that there are people out there who are going to act badly.

It doesn't take long to look in the mirror and think about a presentation or part of a presentation that I put together that I would now look at and say, “Maybe that… maybe there's a different…” Humor, there's lots of opportunities for humor and maybe that one didn't need to happen.

Mmhmm.

If there's a way to…

I guess that wasn't so funny.

Yeah. Doing humor in a way that works for everybody is important.

Yeah.

And humor on OSS is an awful thing to do. Trying to be funny in text when quite frankly most developers are not comedians, right?

Yeah.

A few differences to that, Scott Hanselman if I believe correctly actually used to be a stand-up comic. If he's not, he should be. But…

Most people are not very good at that, humor. I'm not so good. Ward's not so good at [some] stuff.

I'm great at it. But I just don't think it has any place here.

It just doesn't work great. The person wasn't looking for you to have a joke. They were looking for a serious answer. So, why not give them a serious answer and have a discussion?

And just because you can find that kind of humor on the web doesn't mean it's appropriate humor here.

And besides the natural human implications of just being a good person about this, I think this is massively important for us to be good OSS citizens. Because as repository owners, we effectively share because we wanted somebody else to share in what we have. So, if you want to share with people, you have to also be open and welcoming to those people. If you didn't want to share it, don't put it up there. So, I think that's a base piece here is don't create something up on GitHub if you're not willing to share and be open with other people. And I think most of us want to be that way.

We want to be effective. So, take all of that worry about political correctness someplace else, because this isn't about political correctness. This is about trying to be effective and supportive of each other. And that's more important than any individual's desire to express themselves in some way. It's just not about that. It's about the product and it's about getting there together. And anything that gets in the way of that is friction.

Well-put. I was going to say, I derailed the conversation about how we can make it easy to contribute.

WE were talking from the angle of being an open source owner, right? And what we can do. And we talked about a code of conduct, we talked about being welcoming, being responsive to issues and pull requests, correcting people. Like what's the polite way to correct people? Do it politely, right? Tell them, “This is great but hey, there's a merge conflict in here. Could you please address that and then reopen a pull request?” Or, “Hey, could you please add this because I'd like to make sure there's a unit test on it or go look at our contribution guidelines.” I think all of this is just about common sense and what it's like to be a good person overall. Is there anything else we need to add to this?

That would fit into a radio show? [Chuckles] I don't think so.

I'm ready to now go the other way. Suppose I want to be effective. I want to visit your open source site and I want to raise an issue or I want to offer a pull request. What are the things that I can do that will make, improve my chances of being well-received by you, John?

Well, let's think about this from what's not a great thing to put on a GitHub repo in my mind. I try to answer this, by the way. So, sometimes I get on both my code repos and my [style guide] repo, which is really just an [inaudible]. It's a more rare case, right? Most repos are code. Sometimes I'll get a question like, “Hey, I'm trying to do this with Angular and I want a service to do that. Should I use this factory or a service? And if so, what's the syntax?” Those kinds of things are more Stack Overflow in my mind…

Mmhmm.

Than GitHub. Angular, I see a lot of these up on the Angular website especially larger code repositories. They get these all the time. And to me, the correct thing to do is to redirect that to Stack Overflow as more of a convention. Because to me, GitHub issues work really well for solving problems with that particular set of code, not how to use it.

Right.

The how to use it should go up to Stack Overflow.

It's not a support forum.

Right.

And…

And I think that's an easy thing to say, but it's harder to articulate when somebody is frustrated and just wants your help.

Yeah. So, that leads to the next thing which is that when you present a problem it's great if you can also present a solution or at least a direction…

Yes.

In which you would like it to go rather than just say, “This no work,” unless it's obvious that they don't need any justification or they don't need a way out. But it really is helpful if somebody can provide a recommendation to go with what is there they're having an issue with.

Well, at minimum you've got to start with what is your question? I try to… I'm going to pick on let's say lite-server, a product, a very tiny repo I put out there running the Angular 2 stuff. So, lite-server is a little tiny server. It's eight lines of code at most. And let's say I have a problem running it. I might say in there I had a problem installing it. I ran 'npm install'. That's what I tried and this is the error message that I got. And then maybe you should also provide, “I'm running on Windows,” or, “I'm running on OS X, this version with Node 4 dot whatever and npm 3.” Giving more information about your environment, what you tried, what happened, and also what you expected to happen. So, sometimes you might not have a solution but you might just say, “I think I followed your readme but it didn't work so great and here's all the data.” That doesn't happen all the time though and I think that's a great thing to do as somebody looking for help is to provide all that information.

Yeah, provide the details that you think would be relevant.

Well, it might just…

Because that's the first thing I'm going to ask for. [Chuckles]

I'm just going to pile on with a few of these relevant details. So, any command line switches, any variables you've put in there, any modifications you've made to anything, any environment variables that you think might be playing into it. A lot of times people just say, “Well, I ran the server command and it didn't work.”

Yup.

And that doesn't help. But if you say, “I ran this exact command. I'm using,” like you said, “I'm on this operating system. I have these environment variables set up.” And so, then you can look at it and you can say, “Okay, I have a whole bunch of information here,” and you can start to narrow down what more you need in order to be able to solve the problem.

So, let me give you the next best thing. Because that's nice and all that but then I can be drowning in details that you think matter that I know don't. So, you know what I really like? I like a repro. And it comes in two flavors. One is a set of instructions, short instructions that I the owner can follow to reproduce the problem. And the other which is even better, is if they give me some, and it's only possible for certain kinds of products, but can you give me a Plunker or a CodePen or a something or other, JSFiddle, that I can run that reveals the problem.

Yeah, and that only works for things like Angular, that works right? The Plunker. But the first one is critical to me, is give me the steps you follow to reproduce this and I'll add a third one. How about a video?

I was about to suggest that.

It is so simple to do a 10-second video with a lot of free software out there. I use Snagit sometimes to do an animated GIF and just say, “I'm doing this. I don't know how to describe it. Here's a video of what's happening to me.” And I've actually submitted this to the VS Code team when they couldn't understand what I was trying to articulate. And that video saved us, it could have saved us hours but I did it at the end. [Laughs] I should have done that right up front.

Yeah. It saves the author [inaudible] time. You know what it takes to describe what you did step by step instead of just recording it? It's just yeah, you're right John. And I didn't even think of that until you just mentioned it. Of course.

A picture is a thousand words, right? And…

[A video] a thousand pictures?

I just think it helps so much.

And this leads me to probably the best PR I have ever seen and this is what I was sharing with Ward yesterday. A buddy of mine at work, we use Angular at work, and a buddy of mine at work was using Angular cookies in 1.3. And Angular cookies has a bug in it. It wasn't working just right. So, what we did internally was because it was a pretty massive shift on how we needed it to work, we actually wrote our own version of cookies that did what we needed to work with Angular [inaudible] service. And I asked the guys, “You know what? The Angular team's aware of this issue. Here's an issue on GitHub about it. Could you do me a favor? You took the time to create this library. Could you open a pull request against the Angular team's library? Show them the issue and make this a pull request that they could pull in.” And the guy wrote the instructions up on why the problem exists, linked to other issues reporting it, how you reproduce the issue with running samples as Ward said, like Plunkers you could re-run, a video describing and showing the problem, and then linked the solution to the problem to it. [Chuckles]

If you could put that link in the show notes so that people can see it. It's kind of over the top.

It's amazing.

It's amazing. It's one of the best issues that I've ever seen. It sets a bar awfully high but it gives you an idea of what you could do. Any fraction of that that you could do in order to make it easy for the hardworking time-stretched owner of the open source project to do something.

And I want to give a call-out to the guy who did it. His name is Chris Akers and really, just did a great job on it. I put the link to that actual issue up on GitHub in our show notes and then you can go from that issue. There's overview and motivation, what version is affected. By the way, that's the number one thing people forget to do on my repos. They'll tell me I had a problem with your code but they don't [inaudible] what version. Because you might have multiple of those. He tells you the browser it happened in, the OS, how to reproduce the error, related issues, gives you steps, shows a video, and suggested a fix. And it had a pull request. [Chuckles] I was like, “Wow.” And you know what's great for the Angular team? Their answer on this was, “Wow, awesome write-up. Now this is what you call a good bug report. Awesome summary.” So, they did the great citizen side of it as well, is owning that repo in Angular and said, “This is awesome. Pat this guy on the back.”

So, before you get all too excited out there let me tell you about one of the things that I don't want you to do that I've had many times, which is when somebody ships me their entire application. [Laughter]

Oh, god and they paste a stack trace that's 16 pages long into the issue and…

That's not a repo, by the way. [Laughs]

Oh no, no. It's…

Or if they submit a pull request that comes in and it's got 20 commits and it changes stuff everywhere.

800 files, 20 commits, and you know that they're not only addressing the one issue but a hundred other issues that they see. And it's not going to happen. It's not going to happen. And I'm not going to run your application for you. You got to pull it out, you got to boil it down, as close to the bug as you can and then help me work. Give me something to work on, because I just can't learn your application. I can't solve your problem.

You've got to keep in mind how many issues get raised on these repos. And you've got to make it easy on open source owners to want to help us with things. Like when I was interacting with Guy Bedford on his SystemJS library and I found some bugs early on in some of the betas, I gave him the information. And he was so responsive it made me want to be better about narrowing down the issue for him. So, his good behavior back prompted me to want to be even better about helping him out because he was so fast in responding, which brings me to another question. Ward, have you ever gotten a pull request from somebody where they said, “Hey, here are two things I fixed,” and it's a pull request. And the two things are completely unrelated. How do you respond to that when they're completely unrelated in one pull request?

Yeah, I get a fair number of those.

Is that good or bad?

It depends on what they are. If they are typo fixes, I'm kind of grateful. [Laughter]

Alright. I actually am grateful because each PR takes time, right? And so, if you're sweeping the docs… I was reading your docs and I found this typo and this one and that typo and that one and this typo, that's cool, alright? Because I can manage those in one thing. It's not so cool when it comes to code. And that's the differentiator I think for me.

Let me give you an example.

Because I can actually pull them apart, right? Like let's suppose there are 10 things that they think are typos or infelicities in the text, they change… one of those 10 is something I actually like. I want to keep. I don't want… I like their other changes but that one, they got it wrong. I can deal with that. I can deal with keeping the other nine and getting rid of this one. I got the skills for that. So, that's okay. So, I think for certain kinds of PRs it's okay. But as a general rule, it's suspect if you're fixing things all over the place.

Yeah, I have an example from my library called Toastr where I can't remember exactly which one it was. But I distinctly remember the situation where this gentleman, he made two changes in one pull request. And one of the changes was awesome. It fixed a bug that I never caught that he found and others have been reporting and I just never traced. And it was great. He fixed this bug. I was so grateful. But in the same PR, in the same commit even, he had also added something that broke an API to another method. And I'm going to make this up. It was something along the lines of, “I don't like the way this method works so I'm going to add this to it.”

Mmhmm.

And the problem with that is that would… if I pulled it in it breaks everybody who's using my library.

But I wanted the other parts of it. So, now I'm stuck in this situation of I can merge it and fix it or I could not merge it and [43:25]. So, what I actually did is I said this is lovely. It's awesome. And please remove that piece or separate them so we could look at these individually. It wasn't like the second one was a terrible idea. It was that by combining them it made it much more difficult to just say yes, accept.

Right. So, the lesson learned out there for folks, because I agree with you John, occasionally I'll just fix it myself but…

Yeah.

But generally it's probably a better idea to just ask the person to come in and separate those out. But if you're the person contributing, when in doubt keep them as separate commits. Because the person at the receiving end can do something. And certainly we don't want one giant commit that fixes things all over the product.

Let me ask you something. I know we're getting close to the end but I've heard a lot of controversy over this and I have a very specific opinion on it. And that's, let's say somebody the first time they come to your repo, they didn't even open an issue. They just went right to creating a pull request. Some communities, people feel like that's really bad form, that you should open an issue first and discuss it. And other communities are like, I really don't care about that. I'm happy with the pull request as long as the pull request also describes why and follows the standards. And there are people who fall on both sides of that. How do you guys feel about it?

I know my answer but I'm going to wait to hear what somebody else says.

Just go with your answer, Ward. We want to hear it. [Laughter]

We all want to hear it. You know we do.

Oh, I want to say it too. I'll take the [PO]. You said something earlier where you were saying you were shocked that you had more PRs than issues. I wish I had more PRs than issues because PRs, I can decline them. But at least they may provide the fix. So, for me as long as you describe… for me as long as I understand what the PR is about… and remember a lot of them, it just so happens at the moment that… I think it's very product-specific. So right now, I'm spending a lot of time accepting PRs in documentation. And those are largely typos and things like that, that I don't need an issue for that. Just…

Yeah, and you don't need to explain it. With a typo, you don't even explain. Just put the typo in there and fix it.

Just fix it, yeah. So, I do a lot of those. Now, if somebody was about to… let's suppose somebody wanted to create brand new content. Or let's say they want to create a brand new feature for Breeze. And they just take it in their heads to create that and chuck that in there, well again first of all, it's like, “Wow, couldn't we discuss this first?” But at least with a PR I've got code that I could potentially use. So, I'm happy with a PR, John.

I am too as long as there's, [and leaving typos] out of it, as long as there's some kind of explanation. Which is why like in the style guide especially I'm thrilled with the PRs I get because people tend to look at other PRs before they make them. At least I think they do, because most of the PRs I get, they follow the same suit of, “Hey, I would like to make this change and here's why that change is something I'm suggesting.” And that's in the PR itself. It gives me the opportunity to skip the whole issue idea and just say, “Yeah, I like this,” or, “No, I don't,” or have a conversation right in the PR itself. So yeah, I'm cool with that, too. I don't feel like you need to open an issue. There's an etiquette where you're a bad person if you don't but I do think it's something you should be aware of because maybe in the contribution guidelines of a specific repo somebody might really want it the other way. And frankly as a person who uses a lot of other people's code too, I always look for any contribution guidelines to see, how do these people want to be communicated to?

Yeah. That's certainly true. If we're going to put the guidelines out there, somebody should read them.

Yup.

I will tell you also, folks out there, I don't know if other open source owners are the same way but I clear the PRs before I clear the issues. I just look at the PRs first. That shows a greater degree of dedication in my mind generally because…

Yes.

You don't just tell me something's wrong, you're giving me a solution. I like solution-based stuff. If I've got limited time, I'm going through the PR queue first and then I'm going over to issues. And I

may just not get to issues. [I might] run out of time.

I look at issues as a great place to discuss things when you don't know exactly what the answer is.

Yup.

And PRs is a great place to discuss it when you're pretty darn close to what the answer is.

Yup.

So, do we all feel better about ourselves? Should we have a hug?

Let's have a hug.

Skype hug.

I tell you, it's hard. Being an open source owner is hard. Being an open source… contributing, from you folks out there who contribute, it's hard. It's a challenge. I have to say, I like it a lot better than the olden days when it was all proprietary.

It's [inaudible]

And the only requests I got were from the boss. [Laughs]

The boss. Dun-dun-dun.

I think…

The boss. The boss man.

The one thing I'd like to wrap up with is there's a lot of large open source projects out there. ASP.NET, Angular, Linux, a lot of these things. And I think we have to keep in mind that when we're talking with them they have their own rules on how to contribute too. And it's important to, if you want to put an issue or PR in with them, it's really important to read what they're doing. Because some of those are companies and some of those are supported by companies but they might have specific rules that differ from how a Ward Bell or John Papa puts their stuff out there. So, it's really important to at least when you're walking in somebody else's house to at least understand. Do they want you to take your shoes off or not? So, respect the place that you're living in. And if you don't appreciate or like what they're doing you can always pick up your business and go somewhere else, too.

Yeah.

The other side of it is I look at a lot of OSS repos and if they don't keep up their repos, like if you don't answer questions and you don't close PRs and you've got… haven't had activity or a commit in three years, that's probably not a great project to be using.

Can I throw one more thing in there because I'm suddenly inspired by gosh, Ruby of all things. DHH just write, and I don't really know. Somebody knows what DHH stands for. And there are days when…

Dear Happy Husband? I don't remember what DHH stands for.

David Heinemeier Hansson.

Thank you. He just wrote…

Thank you.

He wrote a post that was 'Software has bugs' and we all [inaudible]. But his point in there was some people have a way of getting really upset that there is a bug in the software. And those of us on our side really ought to jump right on that thing and fix it. And I know I feel that when there's a bug with John's software.

And I'm super annoyed that he doesn't get on it as fast as I know he should. But I don't like being on the other side of that one, the person who has the bug. And it's like… and let's have a little understanding right here. A lot of OSS software is done by people in…

Spare time.

In their spare time. A lot of it's paid for. So, that's good. You should have expectations that understand who the person is behind it and how they're getting paid. But wow, software has bugs. It's a fact. And your bug may not be the top of everybody else's list. So, a little understanding would be nice.

Alright. With that, let's go ahead and get to picks. Joe, what are your picks?

Why do you make me go first every time? Gosh. Alright. I want to pick John's, gosh what is it John? Lite-server? Life-server?

Lightsaber.

Lifesaver.

He went silent. It's lite-server isn't it, John? It's lite-server with a T. It's a super cool, this little [inaudible]. It's amazing what he does in [inaudible]. I'll be honest. I don't think it's perfect. I have some issues with it, right? But I think it's awesome still. And if I was a very responsible adult I would spend some time and contribute to it and make it better. And people should, because it's actually a really great server. It's a lot better than, well a lot more features than HTTP server. Even more features than live-server which is the one that people go to when they don't think that HTTP does quite enough for them. It's a great little product. So, I want to pick that as [my first pick].

Let me just call out… pile on with two thoughts about that. There are two things that it does that are really valuable. One of them is the browser sync part of it, the browser refresh, live reload.

Mmhmm.

And the other is, which is why we use it in a documentation is that we do a lot of stuff in Angular with routers, right? And that allows you to do a deep link into something. And unlike the other servers it doesn't fail when you paste a deep link into the address bar.

Yeah.

It realizes… the server realizes that that's not for the server. That's supposed to be answered client-side and it does the right thing with it. And it's for that reason in particular that it wins the day for us.

Yeah, it's a huge deal. So, you don't have to do hashtag routing.

Nope.

You can do HTML 5 routing. And it still works when you refresh the page. It's so awesome. Without having to build an actual, real server. It's like the only product out there that really does that, that I know of at least, the only popular one.

And I'm surprised, but that was what motivated John to write it, because we wanted to be able to develop a router.

Right

An application with a router on it.

Yeah, so cool.

Good choice.

Yeah. And then for my other pick it's going to be the TV show The Goldbergs. Been watching that a lot recently. Absolutely love it. Hilarious. Written by a guy basically about his childhood growing up in the 80s. Me myself being a child of the 80s I appreciate it. But it's also just a great show, regardless of whether or not you were a child of the 80s or can appreciate the 80s or even were alive in the 80s. It's still a hilarious show. So, that's going to be my pick, my other pick.

Oh yeah, we're at the point in time where people listening to this show may have a career and not have been alive in the 80s. That's just weird to me.

[Laughs] Yup.

Alright. Ward, what are your picks?

Well, curious that you should say something about the 80s because I have to go back a little farther. [Chuckles] I'm putting in a movie I saw that had my hand over my mouth the entire time called 'Diary of a Teenage Girl'. It's the coming of age story…

Oh my god, I [would]…

Tears streaming down his face.

I don't even know what it's about.

It's a 2015 film. It was at Sundance. I'm pasting in a New York Times review of it. It's a story of a 15-year-old sort of, yes, so don't watch this with your kids, sexual awakening thing in the 70s. Her mom is played by Kristin Wiig. And her mom is kind of like out there. This was an era in which people discovered that you didn't have to behave the way you were told to behave when you were a kid or by your parents. And this included their parents. And they suddenly are [inaudible] and they're going off and they're doing their drugs and their parties and stuff and not being particularly attentive parents. And you're watching this kid make decisions that you're cringing. I was cringing the whole time. And it brought me back to the 70s, sorry. And I remember being in those perilous situations that I didn't even realize were so perilous. And here's what it did for me. I used to say that as a parent I would never tell a kid not to do something that I did, right?

How can I tell them not to smoke that when I smoked that? Not to [do] that, have [inaudible]. After watching this I said, “Nope, no.” This is a time… there are times when you need to sit down with your kid and say, “Although I did that, I skated very close to the edge of the cliff. And I want you to know that that cliff is there. And that you could go over. I didn't happen to go over the cliff but I could have gone over that cliff and I didn't know it. And I want you to know that,” my child, my daughter, my son, whatever, that that cliff is there. And this movie brought that really home to me.

So, it was very powerful and I recommend it.

Cool. John, what are your picks?

Wow. How do I come up… follow that? [Laughs] I'm going to do a technology pick. [Laughs] So, Visual Studio Code, my favorite editor now has code folding which is the most popular feature that's out there. So, I am very, very excited with that.

Also, and I'll put the link into the show notes, there is a new very cool virtual reality thing that we can use. I'll make you explore. I won't give you too much information. But it's basically something that you hold in your hands and it lights up and you can then battle things like stormtroopers with it.

And maybe we should get one of these for Ward Bell.

That sounds not safe for work, John. [Laughter]

It sounds awesome, whatever it is. I want one.

It's fantastic. Lightsabers with virtual reality is basically what it is.

Oh gosh. [Laughs] Geez, Louise.

Well Ward, if you hate Star Wars so much then you can get into virtual reality and kill some of the Star Wars with the lightsaber.

Hey, it's a win-win.

That's right.

[Laughs] I'd turn it on myself first.

It is actually really, really cool. So, I'm actually pretty excited to play with this. But I'll put the link in there. It's a nice little thing, so a VR with lightsabers. It's from something called Star Wars The Trials on Tatooine.

Very cool. I'm going to wrap up just by letting some folks know. First of all, John when you said, “I don't know how to follow that,” I almost said, “Bacon!” Anyway, and I don't know why I said that now but I did. So anyway, I'm going to be traveling the next several weeks. When this episode comes out it's probably going to be the day that I am doing a meetup in San Francisco. So, I'm going to find a place close to the Build conference since that's where I'm going to be. JavaScript Jabber and iPhreaks were invited out there. So, two of the shows will be there. I'm going to strong arm the hosts into showing up to meet up, which I think from JavaScript Jabber it's just AJ and I. But anyway, so come out. Meet us. I love meeting people who are out there in programmer land listening to these shows. It really just helps me connect with you and who you are in a way that I can't really do over the podcast or even over Skype. So anyway, it'll be March 30th will be the night of that meetup. And then April 2nd…

I guess I'll have to show up for that, you know.

You should.

I'll be there. So, anybody in the audience that wants to meet me, I'll show up there.

Awesome. And then on April 2nd or 3rd I'm going to be in Las Vegas and we'll be doing a meetup there. I'm not quite sure where 'there' either. So, watch my Twitter feed because I'm going to be putting details up there. Also if you go to AdventuresInAngular.com and you fill in the form that says get the top 10 Adventures In Angular episodes in your inbox, that gets you on the email list where I send these things out. So, just to throw that out there. So, on May 5th during ng-conf JavaScript Jabber…

Why isn't it on May 4th? I'm sorry. It's got to be on May 4th. Joe?

They're doing an event that night for ng-conf and I don't want to overlap.

[Inaudible] party.

But that's May the fourth be with you.

Yeah, it's the party.

I feel less bad making people miss part of the game night.

Ah. Well, Ward likes the Star Wars theme, so we'll have to do [that].

That's right.

Oh, you're killing me.

One of the special… we'll call it Ward Day. May the fourth Ward Day.

You know…

[Chuckles] Oh no.

May the Ward be with you.

That's international labor day. You can't do that.

Too late.

If you're handing out prizes you should require anyone who wins a prize that day to be dressed up in Star Wars.

Oh, that's an awesome idea.

Anyway…

Great idea.

So May 5th right after ng-conf there's about an hour break for dinner. We'll take advantage of that probably a little bit more somewhere near the conference in Salt Lake City. We'll be doing a meetup there. Now Joe and I live in or near Salt Lake City. But this is an opportunity again for people who are at the conference or people who are there but don't necessarily get out to other events to come out and meet us if you like the show. So, that way we can connect and it'll be a lot of fun.

And then in July, July 9th…

Wait, [don't] forget the live episode on Friday.

Yes. Live episode on Friday, don't miss it. [Laughter]

We did one last year. It was a lot of fun. Anyway…

Yup. Lunch time on the ng-conf stream, which is free to everybody.

Yeah.

You can watch us live. You can actually see our ugly faces.

And then…

Well, there's an enticement.

July 9th I'm going to be in Chicago.

So, I'll be out there for Podcast Movement.

I'm not going to be there for a code thing. But I'm actually staying an extra day so I can meet people. So, please come out. That's on a Saturday. And we'll do a dinner get-together thing. All of these are dinner get-togethers. We'll just find a restaurant that we can pack with 20 or so people. More if more people RSVP and then we'll hang out and chat. And I'll try and make sure that I make the rounds and get to meet everybody. So yeah, so that's what we're doing. So, those are my picks I guess.

Alright, well thank you all for listening and we'll catch you all next week.