GitHub Universe 2016 - Orbit, 28 Sep 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pains & Gains: Five Short Stories - GitHub Universe 2016

Description

Working on open source project has its challenges, and not all of them are technical. We struggle with tools, yes, but also process and culture. Workflows that work in one context often fail to help in another. The success of an open source project hinges on the people who use it, the people who improve it, and the people who are dedicated to helping it thrive.

In this session five individuals involved in open source will tell a short story about a pain they experienced, how they attempted to overcome it, and what they gained from the experience.

Storytellers:
Katrina Owen, Open Source Advocate, GitHub
Lynn Langit, Cloud & Data Architect Director, Teaching Kids Programming
Gregor Martynus, Frontend & Backend Developer, Hoodie
Enrique Carlos Mogollan, Software Engineer, Salesforce Desk
Jason Chen, Author & Maintainer, Quill
Quinn Murphy, Senior Systems Engineer, Netsuite

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

So there's Matt on Christmas DIYing, a 3d printer at my house, because that's what you do right so Matt loves to code. He loves to hack and in the left, there's some of his great code. Who can tell me what language that codes in come on you guys you had lunch, what what language, what language Swift rock on and it's about bacon, so Matt clearly has good taste. Okay, so Matt loves to code. He loves to hack. So I got a question for you guys.

A

What do you think Matt does for a living? Y'all know what do you think? What does he do? What is the guy? Who builds a 3d, printer and Christmas, do for a living developer, wrong, he's a 5th grade history teacher, so I met Matt when he was being a 5th grade. History teacher in the context of the nonprofit that I run teaching kids programming so teaching kids programming is an open source repository on github woohoo that has courseware for middle school age, teachers to teach to middle school.

A

Kids, her middle school teachers teach middle school age, kids. So this is Matt's class, but Matt is not the teacher because, five years ago, when I met Matt, he did not a code. He wanted to learn how to code.

A

Fortunately, my daughter who's in the blue shirt over on the right side and he was 13 at the time and who's been coding since she was eight, was teaching the class. So she was teaching her fellow mineral schoolers to code with our library and Matt asked if he could possibly take the class, so he did and Matt being Matt went from there to here and he's now teaching in his middle school. He not only learned to code. He learned how to teach coding so Matt being Matt not only wanted to teach coding.

A

He wanted to learn how to contribute now being completely new to coding. We set up the environment the first couple years, my daughter and I, and he was not even aware where the code was hosted. He literally said what is github I, don't know what it is. This is our website. You notice we have little octo cat on there and we actually made our website because we've been in business or nonprofit, but for eight years and over and over I hear from school teachers. What is github? So we basically made this website.

A

We got a grant from a crowdsourced contest. We won from Microsoft supported it. We hired some professional, UX and design people and made this front end to our github repositories for school teachers. So that's all well and good. Matt figured out okay. If I click the little octo can I go to github. So he said all right. I want to contribute. I want to write some Java recipes now because I've been teaching this for three years. How do I do that and I said? Oh no, you know it's pretty easy.

A

You just go to the internet and you watch some of these screencasts and you know you can just get you can just get going with it right and about a month later, Matt came back to me and said you know, I'm a little embarrassed, but I couldn't get started and I thought back to how I started and I used the GUI, client and I thought. Well. Here's a GUI, client and I'm going to make some screencasts so Matt and other teachers can get started and I did also we paired up.

A

It's really really important, bringing new people on two pair either in person or over skype. I've worked with tens, maybe even hundreds of teachers all over the world getting them started and they just need that initial help to get going. Here's matt's first recipe, you like it. He wanted to add a recipe into the recursions section, and he and I wrote this- looks like a little computer chip. The kids love it super cool, so your job today is to find a mat. Thank you very much.

B

Thank You Lynn, so this is a session of lightning talks. It's called six short open source stories, pains and gains. It's actually five, because apparently I can't count. We had six speakers and one of them got promoted to be on as part of the keynote tomorrow. So we are down to five. It's like the song with the 99 bottles of beer. Now there are 98 one source for people who are deeply embedded in open source. It's really easy to imagine sorry Chen. Would you set up? It's really easy to imagine that everything is obvious.

B

We do it every day. It's part of our workflows, it's it's part of our subconscious and while there are challenges most of those challenges are in how do I solve the technical problem or the algorithm, or how do I integrate against this technology, and one of the problems of open source it turns out is that we put in place sometimes artificial barriers to actually getting started and making your first come in I'd like to introduce Jason Chen, who runs an open source project.

B

We started the story with your first commit. This is when you have more experience, you've made a number of commits and you might be moving into the the phase of your open source journey where you actually maintain a perfect Jason. Alright,.

C

Thank you, alright, so, good afternoon, everyone I'm going to be talking to you about overcoming maintain early das, and so a lot of you are probably starting wondering what that even means. So it it starts with github issues, which is where most communication happens, for an open source project and a lot of closed source projects.

C

It has a great benefit that anyone anywhere can create an issue that makes get up issues very democratic, fair and open, which is awesome, but it often takes a lot more time and effort for a complete and thoughtful response from the maintainer.

C

And so, if you are the type of maintainer who wants to be welcoming to beginners or just maintain a high quality standard for answers, you oftentimes have to spend a lot more effort to compose a good response, and so some of you, with a networking background, might recognize these two as key characteristics for a denial of service, the distributed nature of an asymmetric resource nature of github issues, and this was definitely something I experienced with my own project, which is called quill when it was kind of gaining in popularity.

C

There was a point where I was spending all of my time answering questions on github issues, instead of having any time to build features, so that, of course, is in sustainable for long term for an open source project if you're not making it better. So an obvious, an obvious solution would just be to spend less time, but this has some. This does work, but has some shortcomings where, for some people, some of your question answers might appear abrupt, blunt or short, and they might get frustrated and then post this on your wall.

C

This is an actual comment on a rejected, quill PR, so it kind of shows well I think it inspires that we can all do better. So the thing I there's a lot of things like you can do to help, but the thing that I'll just share with you all today is what works best for me and that's really simply to just ask for clarification.

C

I think. A lot of time is spent answering many types of when you're, not clear what the user is asking. You spend a lot of time guessing and then you're kind of answering three variants of a question instead of just one.

C

So if you're not clear, you can just ask, can you elaborate or what did you mean by X, and this has a great benefit of you immediately- get to respond to the user and tell them that you're paying attention and you want to help them out and people respond really well to this, and you don't spend a lot of time guessing what the possibilities are and potentially answering the wrong question, but also answering different variants of a question.

C

So I have to admit I kind of stumbled upon this solution, because in general it's my personality to kind of be eager to answer questions. A part of it is I'm sure, like a lot of you, you feel good about being knowledgeable and I feel like I should be knowledgeable about the project that I run. But there was. There was a question that was asked initially that that I had no idea what what the person was talking about, and so I really just had no choice, but to ask them to elaborate.

C

I was pleasantly surprised that they did rather quickly actually, and you can see, they explained in two whole paragraphs, including the code that they were trying, which is very important for trying to figure out what's going on, and some of you might notice that this person actually even edited and polished their clarification, which is super helpful for obvious reasons. So now, I can just answer the one question that they had, instead of potentially actually in the wrong one or spending a lot of time on different variants of their question.

C

As a bonus to this, though, and as I was composing the response, sometimes you don't even have to answer one question, but sometimes in the process of explaining themselves. They just answer their own question. So then you at most have to answer one question. So this is what I found to be super helpful and I, think it generalizes to projects not just open source but with coworkers I'm sure you've done to your co-workers, where you went up to them and dumped a lot information and said: oh, never mind.

C

So if one thing I want to take away from this is if you're unclear on something just ask for clarifications. Thank you.

B

When I first got started, open source, I thought it was about technical problems and I was really excited about technical problems, so that was really cool and the more open source I did and the more I thought it was about open source, technical technology and the really juicy technical bits and pieces of this. The more I failed at it really hard until I started learning about people.

B

This is Gregor, he works at hoodie and he will be bringing us from the the space of the maintainer, maintaining a project and working with individual contributors to the project that has grown so much that there are now people involved who are creating a community around the project. Thank You Gregor.

D

Thank you. So much. Can you hear me well a little.

B

Bit louder closer or all.

D

Right, can you hear me well all right so yeah, thanks so much for having me and thank you for coming over, so I think Lynn made a great point on how we can create fronds on top of github or in front of github, to make it simpler to onboard people and Jason had great tips to use the resources that you have, the people that you have in an open source community to handle more requests and to sustain more growth, and this talk will be more about how you can get more people to actually become active contributors and maintenance to the project.

D

So it's 2016 and thanks to github, I, think collaborating a code had become so much simpler that we could have ever dreamed of like 10 years ago today. I would say that code, a code collaboration, is no longer the problem. It's kind of solved very well. People are just imagine, like people are coming to the open source project.

D

They are entering the space they are looking around and if they don't feel welcome, they will turn around and they will leave and you lost a potential contributor, a potential maintainer and you last and forever, and you won't even know that they have been there in the first place and the people you know who make it true like this often times very intimidating experience, not finding the way around are people who are more confident. Maybe they are overconfident now, maybe they are a little aggressive.

D

Maybe there are little self entitled sometimes does that sound familiar, and this is a huge pain that I want to dress now and with my little talk in open source that we see today, and it's very very hard to correct this problem once your open source community is dominated by a certain kind of personality, but, more importantly, you're missing out as an open source project you miss out on the people you miss out on perspectives, you miss out on creative thinking, you're just missing out on a very healthy, diverse, open source, community I think I'm doing this wrong.

D

D

As hoodie, we are working very, very hard to try to make the most inclusive most adverse open source community that we can, and, despite being you know, incomparably small project without any funding, and we get a lot of recognition for our work and the bottom line is: if we can do it, and every project can do that as well, and one thing that we did is we created a dedicated space, a dedicated place for all our contributors be new or existing ones, as well as for our maintenance.

D

So we created this law website. Hoodie that can and who needed camp is a static website is hosted on github pages, so it does not create any additional work for us to maintain, because all the data that it does place is just loaded from github itself through the api's and I want to give a big shout out to the github API team, because it's really amazing what you can do right out of the browser proved the existing API and boy.

D

Am I excited about the new API is that are announced today, so on the hoodie cam page? We have full control about the user experience we can do whatever we want with it. We are not limited to what github com provides us, so we can make it more unique. You know we can add our branding like all these animals, they have all their own stories and they represent different teams and we can clearly communicate. These teams are equally important to what we do at hoodie and we don't differentiate the code between like coding and non-coding.

D

Instead, we differentiate between coders designers, documentaries, writers and so on, and for each of these teams we show issues that are loaded from github which are all prepared and to be picked up, and when you click on these links, you will be redirected to github com to one of these issues that by themselves clearly communicate that you don't need permission to.

D

You know claim this issue and work on it, and it has a lot of description and step by step, information on how you can get started, and some of these issues are reserved for people who contribute to hoodie. For the first time you created other things like a milestone, app which are working now to integrate into the hoodie camp and there's so many more things that I would love to talk about. But you know time doesn't allow me. So please find me, but two things I want to highlight.

D

I thing is worth it is showing recognition showing recognition and appreciation is very significant for the retention of your contributors and maintenance. And another thing is transparency like what is actually happening in your community beyond just code I think there is a lot of opportunity there encode. What we did is we carved the way for best practices with the right, tooling and I hope we are now in a time where we create more tooling for community management, which will achieve the same thing and I hope that github will lead away.

D

Just as you later, with code collaboration.

D

My favorite quote is by Sauron from code newbie. She once said you don't build community, you build a space and that's what this is all about. Thank you very much.

B

Thank you, Gregor we're gonna move away from the.

B

The from within the inside inside a project and the maintainer xand contributors to someone who wishes to use the product project from the outside at a time when a project has reached that unfortunate place in its life, where it is no longer really alive. So this is enrique who will be talking about how you use a project that is maybe not actually still around. Thank you.

E

How many of you, how many of you have a holla band on a project? Any project I left many of them behind, but don't worry because every forgotten repo is an opportunity. A few years ago, I was upgrading the main app at work and I found a bug in an open source library that we depended on.

E

Let's just call it the mango Simon library, it's not the real name.

E

The next day, I found the bug. Well, the first, the first thing that I did is I open the gate, her be she and reported the bug, but nothing happened that day. The next day, I feel that what was the problem and submitted a pull request and my pull request was accepted. It only took seven weeks, anyways I really wanted to give back to this project.

E

I felt this project was important for me for my company, so I ended up contributing more and eventually one of the main collaborators asked me if I wanted to become a maintainer I said: yes, of course, so what is an abandoned, open source project? Let's just say that is one that doesn't have activity from the owners for a certain period of time, even though the community is still active.

E

Open source libraries often care abandoned people in stark people starting job, they start programming in a new language.

E

Life goes on, but if the people who started the project gives up, why should we care I?

E

Think there are three main reasons: why should we care and the first one is dependency these days, software is built on top of millions of happens on open-source libraries, and we depend on all those libraries for doing our job and innovate, so we should care about them.

E

The second reason is security. Every day, new box, um new security issues are discovered, so I think it is in our best interest to figure out how to solve those issues for all or dependencies. Security and Trust are important. Part are important values of open source.

E

The true reason why I think we should rescue project is because, if you have a fix- and you don't submit it, you're missing an opportunity or even if you don't have the fix, you can just report the issue and maybe sparked the conversation that will bring, will bring back the attention of the maintainer.

E

Or what about that new cool feature that you work on chariot? It might benefit others. How can you start? You can contribute in the area that you want. You don't even need to write, write code. You can start by writing documentation.

E

You can contact the maintainer and to be nice with them. Be thankful, be grateful its more common to interact with someone who maintains an open source project because they care rather than because the good pay.

E

In my experience with the mango sermon project I wanted to make our new release, but I didn't had access to the release platform, so I open a new pull request: I email people I to it and finally, I got the access that I need it, and it was at this point. The writer realized that I have interacted with three different people from the mango seven project from the original maintain errs one who merged my pull request, the other one who gave me a github axis and finally, one cool gaming release axles.

E

They were still acting as a team, even though they haven't been active for a while. They built a good community, and that leads me into my last point. I think that the biggest constraint open source has is time, time from maintain errs developers and everyone else involved and the best tool that we have to figure out. Big problems for a long period of times is collaboration.

E

A healthy community promotes collaboration, do our part of the community, so please consider helping and abandon open source project the future of open source and the software industry is the community. Thank.

B

The next, a piece of the process of open source that we're going to talk about is when a project is so good that you want to use it at work, and you now have to convince people, stakeholders, business people, people who might care about things that you didn't think about necessarily and the trade-offs that you don't know you're making and convince them that this project is ready for production use. This is Quinn thinking.

F

Okay, okay, hear me: okay, okay, there we go all right, uh hi everybody I'm just going to get right into it. I've got good news and I got bad news, so the good news is open sources everywhere in the enterprise yeah, it's not a question anymore of will we use open source software, it's just which open source software to use and that's I think everybody can agree. That's pretty great. Now. The bad news is change is still frightening.

F

It's difficult a lot of times for us to move forward and into the unknown when the we derive comfort and some benefits from standing still. So how does this bad news collide with the good news? I was just talking about. Imagine that you found some really great open source project, that sort of unknown, maybe to the world or at least to the stakeholders and your organization, and so this best tool for the job is a new tool and then that new tool is a vector for change and, like we just covered changes frightened.

F

So what this means is at any time, you're trying to introduce these new tools to stakeholder, your enterprise, that it can mean a fight and for for me, when I think about having a fight, I, think of street fighter 5 I could be a little too literal. But you know it's a fighting game where you can battle with people with your character online and try and climb up the rank ladder, and it seems like a weird comparison, but in in both the context of a new open source project and climbing up this ladder.

F

You're, you have unproven contenders trying to make their case to some section of the world and for both context you need structure and focus in a way that you're going to approach this that'll make sense. So here are some things that I found climbing the ladder that I've also used in the enterprise. That will be useful for you.

F

First thing use a training room, so the street fighter, 5 comes with a really great training room feature that lets you demo and test the viability of all sorts of things before you actually go and fight with it. So in your organization, you want to use a training room by making micro proof of concepts and demos for people to not only for you to test out things, but for people to interact with and to look at when you're talking about it. A show don't tell and why you need to do.

F

That is that the future is hard to see, and so you want to give people the opportunity to interact with it to touch it whenever possible. Next tip, learn to bot. This is important in Street, Fighter you'll hold back before an attack comes in to defend against it. In your organization, you hold back by thinking about what can go wrong with the project.

F

What is bad at not to be only on the good points, and you need to guard the life bar of it as it were, to really leverage its strength by every project is going to have trade-offs. It's going to do some things. Well, it's going to do some things poorly and if you can explain before someone brings it up or that you've thought about it, that will just increase confidence in the project.

F

So now you need to know your matchups you'll have a character in street fighter. 5 and they'll match up against other characters, and you can't play the same way against each character. Every matchup is different and in your organization you need to tell different stories you're going to have different stakeholders and they care about different things.

F

So you want to highlight aspects of the that appeal to different stakeholders and no matter what you need to relay to them, how from what they value they benefit more from moving forward with this new project, rather than standing still with whatever they have so. The last tip and I think maybe the most important is learn to lose I wish. I could tell you, I've used all this advice to amass a huge hundred percent, win streak online and I'm at the top. That's that's not true.

F

I have have wins, and losses, and and organizationally I had wins and losses, but but losing is, is important and a lot of ways sometimes more important than winning, because it tells you what you still need to learn and despite your best efforts, sometimes people just are going to say no often is a matter of timing, either the business isn't ready or your project isn't ready, and sometimes in that, if that's the case, the best thing to do is just let time pass and and maybe revisit it later, and things will have changed and it might be a better fit, and sometimes you maybe need to consider that you're wrong and that you might have evaluated it poorly or something else has gone wrong with that.

F

You missed I've talked a lot about how you can try and push for change, but to be effective at bringing change. You have to be willing to be changed and so um be willing to evaluate your part of the effort and, overall, just keep in mind that this is an iterative process where you're going to try different cleans and you know, move on, win lose and ultimately it's not over till you choose not to continue so whether you're playing street fighter, 5 or you're, advocating the adoption of some unknown, but really great open source project.

F

What I want you to do is go out there. Do your best fight, learn, change, keep trying and thanks for playing.

B

Strikes me: one of the things that strikes me about open source is that we are in this together. This is a story that we are telling to each other as humans and no matter which side of the story you are on. We are humans. There is a concept in psychology called the fundamental attribution error that I run into every day of my life, and it goes like this when I make a choice.

B

I understand the feelings that I have in the context and so I understand the broader context of the choice that I make and when it turns out that it doesn't work out, it's not because I'm a bad person, it's because I'm having a bad day or because something complicated and nuanced is happening, and the farther away I am from the problem. The simpler it looks.

B

So my friends and I make difficult and choices because we're having bad days and people, we don't know, make choices because they're bad people and I feel like if, as open source contributors developers maintain errs consumers. We can remember that the closer you are to the problem and the closer you are to the emotions. The more you'll realize that we are all having a really bad day. Thank you.