 I think we're going to get going. Very nice. Very nice people. This sounds very loud. Is it too loud? No. No? Okay. Is this for you, Phil? It's my doble sit barisone. Alright, so, welcome to my presentation. I know some of you here. I don't know some other people here. My goal here is to talk about how we build really interesting communities in GitHub. I'm going to delve into how this is going to work in a few different ways. For those of you who I don't know, at the time with XPRI I went to really passionate about how to build strong and effective communities. So I wrote a book called The Art Community and founded a conference called Community Leadership Summit. Now, to be very clear, I've been at GitHub for two months. I've got that new employee smell. And it smells like an OctoCat. And so what I'm going to be talking about here is going to be a mixture of some of my perspectives that have been new at GitHub, but also perspectives from thinking about communities and how we can apply them most effectively. So I don't have all of the answers. I'm hoping I have a Q&A section at the end but bear in mind that I'm no expert and he's been around for years so I'll defer all of the hard stuff to him. Now, little competition later on. You can win these. Big OctoCat, Little OctoCat. So later on I'm going to ask for some feedback on some of the interesting stuff that we could do in GitHub. Popular suggestions would win these two different OctoCats later on. So stay tuned for that. So when I joined a couple of months ago, I was thinking, you know, I joined as Director of Community and I was thinking about what do I see as the kind of overall focus of the work that I want to do here. And it's to essentially empower all GitHub users to build strong and productive communities. You know, when I think of conferences like Scale or other conferences, you just see incredible examples of people getting together with a shared interest and building incredible things. You know, we see this in the Linux world. We see this in the web and elsewhere. And my goal here is, I think GitHub is a very important piece of how we can do that, but we can make it way better. And I'm going to talk about that in maybe two areas, speed today to help build interesting and effective communities. And then later on I want to talk about the future. Some thinking around what we might want to do to build an effective GitHub and how that fits into what the ecosystem of different pieces. So my hope here is that the first part of this presentation is going to be very practical. It's stuff that you can take away right now. You can take some notes and you can apply it right away. But then to kind of delve into what the future could look like as well. So let's first of all talk about the presence. In my view, this is really important, communities are fundamentally experiences. And the example I give here is imagine a restaurant. When you show up to a restaurant, your whole experience is mapped out. When you show up, if you drive to a restaurant, do you valet your car? How is that going to work? When you walk in, how do they get you seated? Do they bring your menu first of all? Do they bring you a glass of water first of all? Do you get water at all? How do you order what you want? What orders do they bring it? How quickly do they bring it? And then you've got all the environmental elements such as the look of the restaurant, the music, and all these different pieces. And all this amalgamation of all of these individual bits results in a cohesive experience. And if it's really good, you don't notice the elegance of that experience. And to me, communities are exactly the same thing. When you show up at a new community, wherever they may be, and you've got a successful, it's incredibly enjoyable and rewarding for that person to join. If that experience isn't well-matched, then it can be really complicated and infuriating on what to do. Don't know where to get help and things such as that. So I tend to look at community management through the perspective of, how do we build these really effective experiences for different types of people? So today, for the present practical stuff, I want to talk about the experience of a new contributor. And this isn't very what I think a lot of others might write. They don't think about what that experience is, and consequently, they have all of this new, fresh, brought to join the project. But they make some simple mistakes, or they miss certain opportunities to make that really elegant method of joining. And I think if we get this right, our communities grow, we get new blood get fresh. So I think of it in terms of this thing called the on-ramp, the new contributor on-ramp. And I think there are basically five areas. So imagine the person at the bottom, they may have heard of your project, they may have not heard of it. The person at the top, when they get to the top of this ramp, they're feeling engaged, they're feeling rewarded, they've enjoyed their time. And these five areas, how do you learn about what this community is, and how do you learn that you can actually get started? Because sometimes that's not the knowledge and the skills that you need to succeed. And in my mind, that's not just in terms of the programming language and the tools that you use, but also how do you contribute something? How do you throw it over the wall so that they can bring it in? The third thing is identifying tasks. You've discovered a community, you've got the skills. Now you need something to do. How do you give someone that thing? You want something that's not too hard but rewarding enough that they feel like they can't do something. The next thing is going to be getting help. Everybody's got questions. So how do you get help? And who are the kinds of people who you want to provide help? Not everybody is a people, not every person is a people person. And you want to make sure that people, people, help people. That made no sense. And then finally, when that person has made that contribution, you want them to feel a sense of kudos, a sense of feeling that your path is bigger than you and it's really rewarding. So I'm going to go through each of these and show you some practical ideas and things that you can do today. Let's start with Discover. How do we effectively help people to discover projects and that they can participate in? It's a dead simple thing. You just create a lockdown file in your repo and you just add some big stuff. And what I'd recommend in these is that you explain what the project is. So the link off where you can provide some steps, how you can start using it. If this is something that's a piece of software that you build, explain how to build a thing. And then maybe link off to places where people can ask help, such as IRC or email or stack or something such as that. Step further. Now, a lot of people don't know this but you can actually build a website that's actually hosted on GitHub. And there is some tooling that's already there to make this really simple to do. So this can be essentially your myproject.github.io and it explains what the project is and how they get started and maybe some testimonials and some other bits and pieces. Everybody should have a website for their project and just keep it simple. It doesn't have to be a massive CMS with all kinds of content. Start simple and evolve as you can want and GitHub pages is a great way to do that. The next thing is regularly schedule social media. Social media is really powerful. It's a fairly rare and complicated science in how it operates. There's a great tool called Buffer that's free to use and they have like a pro version as well. We can basically say I want to post these intervals like every Monday at 2 p.m. and 6 p.m. Eastern time. You basically fill a bucket full of social media messages and it will post them for you. So the way I like this is that every semester you fill yourself up and move things out for the week. It's a really useful tool. But also look at some of the best practices that surround social media. For example, on Facebook, if you want to post something on Facebook, you want people to see it, make sure you have it as a high contrast such as what works way better. So there's lots of little tips and tricks that you can do there. Another tip is Facebook. If you want to post a video, my name is Tiny. I'll put it on Facebook. It's a much bigger picture and that's what people will click on it. So get your social media in place. Let's now talk about developing knowledge. So at this point, we've pushed out social media. We're in pretty good shape. Now it's about developing knowledge. What does getting how do we get started? When we think of new countries I think it's important to impact not their expectations of the desire in how they get started. The first thing you need to help them figure out is tooling. If you want to build software or you want to build, we have people using a Bracket or Fedora or Debian or using them. The second piece is providing a tutorial to get somebody contributing something as quickly as possible and break it down into a series of steps. People like tutorials because of step-by-step and a set of instructions is cognitively easier to process than a massive page of text. And I think about within the context of two areas how do you create something and then how do you contribute it? So the contributing piece in GitHub can be relatively straightforward because we have pull requests, we have issues and things like that. A fairly concerned, so you want to make sure that some people who have a new request can get up before. So put together a tutorial that does that and then you want them to link off to all the kind of details about how they can do different things in different contexts. So if you're building a piece of software you might want to have the layout of the code, coding standards, different ways of contributing. So think about what that gives and the next thing I think you should look at is creating a contributing.md file. This is a relatively common in GitHub projects. It's basically a markdown file and again just a really simple set of steps to see how somebody can participate in the project and get started. The other thing at this point is think about the different types of participation. In most of those projects you can do code and documentation and translations and all these different pieces and it can be tempted to try and provide this with everything and that's the optimal solution. You want to make it really easy for those different types of contribution for those people to participate. Let's just start with one. So create a contributing.md file. The next piece which I think is really important is to create a knowledge base. So there's a Wikiball to GitHub. This is a really simple tool for essentially creating material together and there's various projects that have done this very well. But here the screenshot kind of gives a good indication of this list to a sense of resources and translations and think of it as like a manual when you join a company or a company handbook. Think about what your project handbook might look like and the Wikiball is a great place to do that. Now before I move on from the no-hips and tricks I'd like to share that I think is important. The first thing is being on-site. Is there a tool for concisitity? No, I prefer concisitity. Today where so many people are engaged in social media our attention span is a lot shorter than it used to be. I think ten years ago we could get away with big reams of text on Wiki pages explaining how to get started. You just can't get away with that now. People don't want to read that. So really try to get down to their brass tacks of how do we do this thing and keep it really short. And that's why I like Vice-Ups. You told us it was important but really clarify like how think about the linear workflow of how that person goes from this point to provide command-line instructions for how they do that. If you are going to be showing how to submit your first pull request include screenshots to show how they do that as well. So think about if you're the new person what you'd want to see what makes you feel comfortable. Now I think cross-linking is really helpful but also do it within reason. You don't want to create like a litany of little pages of content because that's irritating. So cross-linking makes sense to move between different bits of how you're knowledge-based and think of how you reduce the amount of bouncing around that you do. Alright, so next one is identifying tasks. How do we get the right kind of task to someone to start with something? And my view traditionally here is being you want to give someone something to do where they can be successful in accomplishing something in a couple of hours. So you don't want to give somebody big chunks of work but this is really hard because you may have a very accomplished developer who's brand new. So there's no more support to any of these things but one useful thing here is to create bite-size issues. So in GitHub issues you can tag them create a bite-size tab and then these are for small things string fixes, something we've done quite fun. So when someone joins your project and say hey I'm new, I'd like to get started you can point them to your knowledge base step-by-step instructions and say why do you get started on this issue? This is a nice simple way of getting started. You could use the GitHub API to pull those issues and just say on your GitHub pages website. Another thing that you may want to think about is waffle. Does anyone use waffle? So waffle is basically has anyone used Trello? Okay so Trello is like a Kanban type workflow tool basically that that backends to GitHub issues. So you can create like a project view of how you want to build your project and Trello is really good at that but you can do it with waffle but then the actual cards that you use are actually getting started to organize them in different ways. It's a really neat tool. I have to confess I've only used it a little bit so I'm by no means an expert but the amount that I've done is really kind of neat. So thinking about what your wider says to do items is going to be this is a nice thing that you could do and then you could tag them as bite-size bugs. So getting help because when you join a new community it's nerve-wracking. You know people are coming from a variety of different backgrounds. So you may, this may be your first time in the open source community you may be socially and a little anxious about joining a community with a bunch of people who maybe you look up to. So things like submitting your first pull request is really scary. Just building something yourself can be scary just knowing how to get started. Personally a first issue can be scary. So having a support network and getting help I think is really important. Because you want people to feel comfortable being able to do stuff but also to feel like they're joining a social group that feels approachable. So there's a few things here that I think are good to think about. First of all you could tag issues with question or help needed. I've seen a few projects doing this. So if you've got a question you just basically file an issue. And you could have essentially members of your community regularly go through and review those and respond as you see fit. So this is a relatively simple thing that uses existing infrastructure. GitHub doesn't really today provide a lot of communication infrastructure outside of issues which I think is something we're going to need to think about moving forward because it's really important. So if I want to look at other communication channels so the classic in the open source world is mailing lists particularly popular with developers. You don't have to go and set up your own mailman saying you can go and just set up Google groups. They're simple. But then you may want to have some real-time communication in place as well. Obviously for many years we've been using IRC. I'm a big fan of IRC using it every day. The new contender that's becoming really popular is Slack. I use that as well. It's pretty cool. It's basically IRC in a nice window. So these are great tools for providing the place where people can help. One caveat of the place here is if your community is very small and maybe dispersed in a bunch of time zones maybe wait a little bit until you put the real-time communication like IRC and Slack in place because you don't want somebody showing up or excited to ask that question and there's no one around. So mailing lists are better because they're fast communication. You just respond when you can. Another good thing for helping, for providing offensive help and support is events, things like sponsorship and mentoring. If you have a project helping to connect a new person with an established person is a really useful thing to put in place. So if someone joins they pick off a bite-size issue they're excited to get started and then you can connect that person to an established contributor in the project and they can essentially help them through it. In the Ubuntu project we call it Sponsorship. Daniel Holback has done a tremendous work in this area helping to craft what that process looks like. Someone basically fixes a bug, essentially attaches that to the sponsorship queue and then that's reviewed by people who are established in the project. And what that does is it kind of relieves that tension of your first contribution because you've got a friendly face reviewing it. That's a nice thing to put in place. And then of course you might want to think about things like hack days and bug squashing events. These are great to do online because you can have a global audience or if there's people in the local area you can maybe meet up at a coffee shop and that kind of thing. Organizing these kinds of events before shows such a scale is a really fun way of doing this as well. So as with everything in community leadership there's no single silver bullet solution to everything. There's lots of different options and you just choose what's right for your project. One of the things I think is really important about defining good support resources is creating a culture where asking questions is okay and that means you never tolerate somebody humiliating or belittling somebody for asking a question that they consider to be silly. No questions are silly. You reward people for asking questions. You say, you know what? That was a great question to ask. Let's see if we can document it to help other people. And then the final thing here is receiving kudos. So again you go through this. If you imagine a review and you've got to this point you've had a bit of an experience of this part. You've discovered it. You've learned your skills. You've found something that works and you've worked on it. You've got some help. And you get that in there. Get merged in. That is a watershed moment for that person. It might be just another day for an existing contributor, but that's a big deal. And you want to thank them. And I think we want to thank them in three ways. First of all, thank them for their first contribution. You're the first one to get something in and say, really appreciate it. That's brilliant. That could be on a portal request. It could be an issue. It could just be a personal email. The second thing is to thank them for their first insight. When somebody says, you know what? This could be an interesting way of doing it. Or this could be a different way of doing it. That's an insight where they're thinking about the strategy or the direction of doing something. And you want them to feel comfortable in offering insights. Because not everybody is comfortable at doing that by definition. And then the third thing, which I think is really important, is thanking somebody the first time they challenge you. The first time they say, this isn't the right way of doing things. I think we can do it better this way. I disagree with what you're trying to do. Because that builds a culture of challenging the status quo and doing things different. And that's what we want in our communities. When we all think the same, we get crappy software. So I think these, when we think about doing this for the different people the amalgamation is a rewarding and rewarding experience of people. But then, we want to showcase great work as well. And I recommend doing this in six ways. So imagine people do interesting stuff and you want to highlight that person's contributions. And first of all, check if they're comfortable with that. Because some people like to have a low profile. But imagine Jane blocks does something really interesting. Highlighting on Twitter is a great way to do it. Highlighting it in a blog post is a great way to do it. Highlighting it in your communication channels, on your mailing list, in your Slack channel, in your IOC channels. If you have a podcast or you're talking and doing an interview in a podcast, name check in that person for the great work that they've done is great. YouTube videos. YouTube is a tremendously powerful method of talking about what you're doing and getting the flow down. And again, highlight those contributions in events. Oh, giving a presentation. Mention people have done great work. Sitting in an audience, watching a presentation and getting a name check is a great feeling. So these are... When we start doing this, it really builds that personal connection. It builds that personal relationship. It builds that sense of belonging that's critical in communities. So that's what I recommend is some starting points. And these are not... You'll have to do all of these things. So here's to get you started thinking about some practical ways in which you could build effective communities utilizing GitHub. But now let's talk about the future. And as I mentioned, I'm still quite new. So I'm still figuring out how GitHub works. It's a big-ish company. Lots of remarkably intelligent, passionate people. All who want to do the right thing. It's been a remarkable experience joining. And I'm trying to figure out what the future should look like, not just in terms of how this happens within GitHub, but what I think of this. And I want to share some perspectives on that, and then I want to get into, you know, if we've got some time, some ideas from you folks about what we should be focusing on. My overall philosophy, and some of you have seen me say this, so I apologize. As some of you will know, we're very passionate about communities. And the reason for that is I believe that we, as a human race, are inefficient in the way that we're collaborating with each other. And I think that because fundamentally we see these remarkable examples. We've seen the births of open source, and the impact that that's had changing how we live our lives and how we run infrastructure and how we think about building software to huge collaborative development and people essentially documenting human knowledge to local projects that's just sustainable farming and local communities to then you make a revolution that's happening, which is democratizing how we build and manufacture things. And then significant political change. We've seen communities form and basically say enough is enough. And the basic premise of this is that people are getting together because they have a shared passion for something. My view is that most people don't know how to put communities together very effectively. I'm not suggesting I have all the answers, but what I am suggesting is that this is not about having all of the answers. It's about packaging up the answers that we do have in consumable ways that people can utilize. So my view is that if we can help build some methodology and structure around how community management and best practice operates we can communicate that out widely the ripple effect on how we as human beings create things will by definition increase. We will become more effective. We will become more collaborative. It will be more rewarding than you can imagine and will build interesting technology faster. That's one of the reasons why we have to go to GitHub because I see GitHub mentioned at the heart of how people are building software and how people are innovating. But I think there's a lot that we can do to make it better. So my view is that we have a challenge. This is the parallel challenge that we've got at GitHub today. I'm going to illustrate this with a scenario. So imagine you've got something called Dave. Dave has an idea. He thinks, you know what? I'm going to make a really cool slack killer. I don't like slack. I don't like IRC. I want to make something better than both of these. So Dave has an idea. Spend some time with Jane, a friend of his. And they come up with some neat ideas about how that could look like. And then basically build a prototype and they stick it into GitHub. Put it into a repo because everybody that's what you put into a repo when you want to collaborate with other people. Put it into GitHub. I'm going to spread the word about this. They get a lot of stuff, too. And they spread the word. And they hope that they get people interested and they get crickets, which really happens. They stick it up there. They maybe get a couple of people who file a few issues, a couple of pull requests, the old Wiki page. I have no data to back this up. But I'm guessing that this happens in the majority of cases that people put stuff up on the GitHub. And what these people want is a community. They want a passionate group of people getting together, working collaboratively on that code on various other ways, and bringing to the surface the very best in what human beings offer to make that thing better. The problem is that building a community is really hard. And when I joined GitHub, I sat down and thought, I've been thinking about community for years, but I've never been able to really firmly articulate what's really hard. And this is everything. It's in progress. This will change the next time I present at scale. But the way I look at it is that building a community is hard because you're essentially building a workflow. I think a workflow that looks a little bit like this is that, first of all, you have all these different pieces that fit into an effective community. And this is just an example. This is not the be all and all of what it looks like. But how do you have ideas and how do you communicate with each other? How do you define which ideas are the most interesting ideas and communicate with each other to bring those to the surface? And then, how do we plan the implementation of those ideas? Some communities plan very explicitly to have work items and burn down charts and things like that, and pursue a good example of that. Some communities are much more freeform. You show up and you write a patch and you shove it into GitHub and you're off you go. How do you build software? What tools do you use? How do you test that software? Which frameworks are going to use? There's books and books written about just that piece. And then, how do you build quality into that? How do you test the contributions that are coming in? How do you maintain code? How do you ship? Shipping has been books written about it. What's your release strategy? How do you segment your releases? How do you support your releases? Do you have a regular release cadence? When you ship something, how do you promote those releases and how do you get the right eyeballs on it? You've got things like participation. How do you get people involved? How do you build an effective participant base? How do you build a effective user base? How do you represent diverse and underrepresented groups in your community so it feels not just a bunch of white dudes? And how do you govern? How do you lead and build effective leadership around your community in a way that feels independent that doesn't feel forced, doesn't feel like you're serving somebody's own personal agenda? This is really hard. And I'm positive that most people don't really know how to get started with this. And they get some of these bits in place and they don't get other bits in place. And my view is that if we make this repeatable, it helps to build more effective communities. But it's not that simple. Because I think when you look at that, the different ways in which you traverse that workflow depend on the types of people that you're thinking of. And I consider these to be different experiences. So you remember my example earlier on about the restaurant? Different experiences traverse that different way. So as an example, with new developers, it's essentially the on-ramp that we already walked through earlier on. That's the way I think of it. And the way you construct that on-ramp within that workflow is going to be different than if you did it for a core developer. So you have various considerations like new developers generally lack context. They don't necessarily know the community. They likely need to develop knowledge and skills to participate. They're probably going to be pretty self-conscious about the first contributions. So these are some of the considerations to make. But then also if you look at another example, such as core contributors, then context is essential. That's really important. Contribute is going to spend a lot of time thinking about they've got the benefit of high insight, the benefit of knowledge. And you see this all the time in communities where a new person shows up and says, why don't you do it this way? And the core contributors thinks, we have talked about this so much. There's no way we're doing it that way. Because they have context, they have experience. And core contributors, you know, they have a repeatable workflow. They're doing the same thing over and over again for the new contributors the first time they've done it. So you want to make sure when you're having to do something over and over again, you want it to feel sleek. Because if it has any spiky bits put on the side, it's going to scratch its skin a little bit and it becomes annoying. And core contributors also play important mentoring roles. You know, because they've got the benefit of high insight, the benefit of experience. And if they're the kind of people who enjoy mentoring, then you can connect them to new people. And importantly core contributors set an important leadership example. There's a lot of discussion and debate about what's acceptable in those communities in terms of conduct and communication. And my view is that whether you like it or not as a leader, you should set an example. And you should set a good example. It doesn't mean you have to be politically correct about everything. It doesn't mean that you have to treat everybody with a key of gloves. What it does mean is that you have to instill the culture that you want to grow in your interactions. And that in itself is a hard topic. And it's something that we can provide a lot of guidance around in terms of communities. And also of course with core contributors we have governance. Core community members cannot just be governance members, but they can also influence governance members as well. You know, when we look at particularly large resource communities, there's a delicate fabric of politics. And you know, many people at scale who I've met, I'm sure all of you have, all in having conversations about the various political climates of different projects. This person's doing this, this person's doing that, what are their intentions? And core contributors play a big role in how we define the culture of that. And then importantly, core contributors often build relationships with partners. You know, if you are a big open source project you're a leader in that, then you're going to start having companies knocking on your door or other projects. And you have to figure out those details as well. So my overall goal here is I want to help GitHub users be able to create that workflow, build those experiences as efficiently and as effectively as possible. You know, it shouldn't be, I wrote a book called Carve Community. People shouldn't have to read that book to build great communities. People probably shouldn't read that book anyway. But people shouldn't have to do that. The terms of the systems that we have in the world today should make that easy for us. A big inspiration for me in this thinking, and I know some of you are not going to find this because it's a non-free product, is Meetup.com. Meetup.com is unbelievable in two primary areas. First of all, the experience of creating a new Meetup group is really slick, it's simple, and it sets you up for success by asking for the most important piece of information, setting up your expectations. One screen is, I will commit to organizing in-person events, degree. Just that tiny step, like a little reminder in your head that lives there, that you should be doing that. But not just that, it's the discoverability of Meetup groups as well. You sign up for Meetup.com, you specify where you live, you say what you're interested in, and there are actually really interesting suggestions of local groups to go to. So, I think we should be thinking about how we infuse that spirit and that methodology into actual tooling. And obviously, I'm focusing on this in GitHub, but GitHub is not just GitHub.com or GitHub Enterprise, it's a wide fabric of integrations. We want to make sure that GitHub is working well with Jenkins and various other tools. Let it work here that you want to set up. So that's basically my broad vision and goal of how we do this. Then there is another piece here, and then I'll shut up and we can start talking together instead, is just what the GitHub community looks like. So I see it as having two communities, which is a horrible mental image. One bucket is the person who creates a repo and they want to build a community for their project. That person who's having a slap in their idea and they create the repo and off they go. And those are the people I want to empower to build really strong and powerful communities. But then the other group is the wider GitHub user base. Whether you are a maintainer or you're just a user, I want to find an explore way in which we can build a strong GitHub community so that we can help each other, we can support each other, we can bring the best of what we've got to the surface. That we can understand the needs of our users as effectively as possible and respond to them as effectively as possible and build the real relationship. And I'm not going to deny that really hard. And it's really hard because, for example, I was a clinical and I was working in the Ubuntu community manager position. By definition, everybody who joined our community was sharing an ethos, which was a little passionate about Ubuntu. And even if they were members of Ubuntu or Zubuntu, it didn't matter. They were all part of the same basic group of people. GitHub doesn't like that. We have radically different communities across millions of repos. So building the overall GitHub community is not like everybody has a shared perspective, a shared ethos, which is the typical sticking point that people have and how people are glued together in communities. So this is going to be a very different type of thing and I'm really thrilled about the challenge because I don't think there's any clear answers to this, but I think there's a lot of very clear opportunities to this. So that basically wraps up my main talk and we should give these away. Let me just show you what this looks like in person. Yeah, earlier on, Brandon, this is a wonderful human being. I showed him this as I really... Like, these are pretty rare. Most people don't get these. So if you come to the GitHub office in San Francisco, we've got this big swag store and we give free T-shirts and stuff like that. But these are pretty rare. This is a very special, a little special giveaway. So I was thinking in the spirit of just conversation because I'm new to this and I'd like to understand about GitHub and share your ideas for what you think would be cool to see in GitHub or if you want to ask ideas so things will be cool for the first time. And then for each suggestion, I want the person to get this. Make sense? Hold on, hold on. Oh, we have mics on. Oh, yeah. It went really bad the last time Jono gave me a microphone. See how this goes? Maybe. Great. It does work. So my question is this. There's a lot of components in GitHub and a lot of things that you can use. There's bug tracking, there's a website, there's all these pieces. But when I fire up a new project, I kind of have to spin up all of these. And it's quite labor-intensive to tie them all together. It would be nice if there was a very basic, essentially completely unformatted website with at least links to all these basic components every time I set up a new source code repository so that there's at least something there and I don't have to go find the issue tracker. Or, you know, hey, go to this actual GitHub page to submit a pull request. There's at least a basic page up there with all that information as well. So having all that prefabbed out when I say, hey, GitHub, spin up this new tree for me, that would be a huge time savings. So then I see a quick question to just, before we ask for the vote, are you thinking about, like, so for example earlier, I suggested we get a page to site. Are you thinking, like, kind of like a pre-built, templated website that you make it look like what you want it to be that links to all your issues and whatever else? Right, that links to all the components that GitHub gives you when you commit a source code tree for the first time. That it just fires up a basic web page to link all those resources together that you don't have to go hunting. Or so that a user doesn't have to go hunting in the community. If another developer comes along, where's the issue tracker for this? Where's the repository for this? Where's the support for this? Where's, you know, where's the, and eventually that would be replaced with the pages? But, you know, where is that for now until that stuff's flushed out? All right, what do we think? All right. This is another pretty concrete one. I've noticed in many, many projects and organizations across GitHub, especially as people tend to start doing this micro-services thing, there's like OpenStack and a million repositories for all of the different pieces of it. And something that I feel like is kind of missing is a deeper bucketing level or tagging level for repositories. If I'm a Ruby person and I could go to the OpenStack agency, like some random piece of the project is written in Ruby where most aren't, I might be more likely to go towards that one. You know, something like, these are grouped together. It's front-end tools, these are grouped together, it's back-end tools. So when you've got to look at an organization because it's on a list of repo, it's something that's more illustrative of how these bits sit together. That would also be useful if you've built two complementary but not the same projects, say a client and a server which talk to one another, but they're two separate. That brings back guys, I did not mind. Guys, I did. That felt stronger. If you see me typing, I'm not checking my email, I'm actually writing this down. Let's go... The thing we use on Launchpad a lot for elementary is cross-project issues. So if there's a common issue that affects multiple projects, we can file that as affecting more than one of our repositories. That's one thing that's lacking a lot for us on GitHub that we would really like to see. Cross-project issues, what do we think of that? Okay, I'm just making notes to where we're looking in terms of popularity. I got to bear with me. All right. I did not move to this side. I promise I'm not just prioritizing all these. If you want to refer back to this, it's in your email. My thing is we have a ton of developers who follow us on Google+, but the same people who follow us on GitHub. It seems kind of silly that all the time we're putting things in Google+, and then linking back to GitHub when they're already watching our repository on GitHub. It'd be nice if just on the right-hand side of the repo, there was just a little... I can put notifications in there, put information in there that maybe even shows up in their feed whenever they look at the notifications. It's like a micro-blogging thing but it's specifically related to this repository of this organization on GitHub. All right, what do we think of that one? I want to move to this side. Just increase the visibility into any given project. A lot of projects you go to, unless someone's taking the effort, you kind of have to know that if you go to whatever slash wiki, you can get to a wiki, you can get to this, that, and the other, when you go to a lot of GitHub pages, unless someone's put the effort to put that there, do you have no idea that's there to begin with? So you're thinking about when you go to github.com slash whatever slash whatever. When you go to github.com slash sizzling bacon, you know, that it says, you know, wiki issue tracker and all that at the top of those, which sounds like this chap suggested about it. Yeah. So we're seeing some commonality of feedback here, which is good. Chap in the red. Right. Oh, yeah, let's do a vote. Well, it's the same one. I think four already. All right. Wait, do you think it's the same one? Then I'll give you a different one. I want to get right. I think I need this. This is about building communities and what he's talking about is being able to use github as we all use it, but have the community portion of it actually be I hate the word wizard, just be able to pick and choose. Yes, I want to add a public side to this. Yes, I want to add a wiki to this. Yes, I want to add this. He's absolutely right. That's sorely needed to support any sort of project where you have interaction with people. Just to reiterate, I wasn't sure if everybody could hear it, but the idea was essentially like more of a witty type onboarding for the community members. What do we think of that one? What do we go with my friend over here? You want? Building community theme that we're on here. Because usually when you go to github you know exactly what you're... You're going to go there, you're going to contribute, you're going to look at the single page. But building community as a new github user because honestly I started with github like maybe a year and a half ago, two years ago maybe. It would be nice to be able to take... Now I don't know if it does this yet but it's kind of an underlying tagging system for each repo to where the repo not tagging is like branch tagging, but say it's using Postgrease or using the technologies that you're using and you can tag it and then as a new github user, once you start watching one github or one project, github might say you know you like this project and this project is pretty similar and it's more active and it could kind of drive new users and old users to new projects that they might not have ever heard of otherwise. So you're thinking this is within the wider github this is not for a specific repo organization. I'm interested in foo and it shows you projects that relate to foo. And stuff that you're watching and github just says you know, you're watching. Right, so finding projects. Cool. What you mean type 6 site? Yup, you. For me at least I'll frequently do a Google search trying to find an answer to some small problem and I'll see a bunch of github repository come up for programming stuff but I know I'm going to have a large code base that I'm just shuffling through or possibly an issue I'll usually click the stack overflow link because I get a nice concise code sample I can reference. Github already has the concept of like a paste bin, a chest there that you can paste and I think it'd be nice to try and expose like incorporate that into the repository. So for repository is a really good example of the proper way to do a puppet deployment or of some really clean Ruby or something like that. Try and expose not the repository per se but try and expose the specific snippet or the specific issue there a bit more. Use it so that people can use github as a better reference for learning more and by doing that if they're frequently finding the same project or individuals or anything like that it'll be another incentive for them to try and contribute back. See I'm thinking I'm wrong because I'm usually wrong. But it's essentially concise nuggets of information like stack overflow stack exchange for a particular project but essentially like a library that within the repository gets the google juice that can bring people into it. Yeah, it's something like that. I don't know necessarily about the library but try and expose at a finer level than just a project. Right. This is getting difficult. Let's go up the back. Let me write that down. So for public projects particularly feature requests I would love to see upvotes for issues. So there's not a shitload of plus one comments and then maybe a filter or something. I don't know it could be just a new view on the issues page but being able to sort issues based on upvotes. So for open projects when people have feature requests or even just high impact bugs you could instantly get a gauge of what the community actually desires in one side of the project. So quick question about that. Are you talking about the way of voting the overall issue or are you talking about upvotes for individual comments on an issue? No, for the overall issue. So it could be feature requests to be like a new thing but it could just be a new view on issues itself. That would be awesome. It's kind of similar to the hotness rating in Launchpad. It's kind of similar to that. What do we think of that? Oh. The plot thickens. A couple of people have touched on this but they haven't said it exactly which is better searching. So I have had this problem. I was working on a project and it was in two different repositories. There was no way to search both repositories. It's really difficult. So sometimes I jump out to Google and search from there so I can get back to where I'm going. And I just think it would be very helpful to have more modern search. Just to clarify, do you mean the search ability of finding stuff overall in GitHub? Yeah. So basically a lot of times I'm looking for I want to see how they did something like I was looking for a particular piece of code. There's a company called Shotgun. They make software. They have it on GitHub. But rather than just going and asking, hey, you know, is this broken? I can just go look at the code and see what they did. Oh, I see. And so I would do that a lot and actually have them fix it in GitHub as opposed to me fixing it. But it would also be nice to be able to say, hey, I found this broken piece of code and have a nice way to tell people. And the other thing that I've found when I'm searching is sometimes GitHub pages go away but then it's not very pleasant when you get there. Other people have referenced it like in Stack Overflow they'll say, oh yeah, this solution is here on GitHub. But sometimes even the person who wrote it says that but then their GitHub has gone away for some reason. What do we think of that idea? Better searching. You. I'm terrified to ask you. This is actually a real suggestion. Be nice. One of the things in the community as a project maintainer is to ensure that you're not really, really annoyed by the experience on issues. So as a project maintainer, please, please, please, a plus one button so people don't just post plus one as a comment. Like. I'd say it's different. You're talking about the individual comment, right? Yes. Or is, I think the suggestion of bear was likes for the overall issue threat. Is that correct? I don't think the account was the same thing. So the idea back there was that instead of posting plus one people would hit an up vote button. That'd be it. Don't mind the same idea. Give that guy the account. See you after the camera. Terrible humor thing. Coming from the Wunder Community, one thing that's missing on GitHub is proper translation solution because everyone has a GitHub account. But translations are pretty hard and it wouldn't be great to have a translation solution which is usable for everyone even if he or she doesn't even know how to use Git. So you think a translation solution is still available into GitHub? Right. Okay. Thoughts on that? Hmm. I'm looking forward to figuring this one out. I'm going to get a niche. I wish a Bromance for cats. Any, many, many, many, many, many, many, many, many, many, many. That's it. Let's chat here. Well, I work with JavaScript a lot and looking up new packages and MPM packages and variably gets me to a GitHub page but usually if I'm looking for a cryptography package or a new MPC package I usually have to backtrack back to Google because I don't have a sense of how popular that package is and what other alternatives that they are. So along the lines of enhancing the search within the MPM, sorry, the GitHub Web site if GitHub could have a sense of package repos so I could maybe add an MPM filter and then I could get a list of the most popular MPM packages that have their source code hosted on GitHub and GitHub already has a great sorting methodology using the stars and that would really simplify my search for high quality packages and make that really quick. All right. What do we think of that one? I think I found that one. So first of all, a big thank you to all of you for your wonderful suggestions. I personally and I know you're all going to disagree with this because there was lots of similar clapping. My view is that the winner votes for issues. So come and get your OctoCat and my feeling not just because of the applause but also the regularity from a few people I think a GitHub page's templated Web site is one of the most popular too. So... You're going to have to share this OctoCat among the four of my people. I can't comment on the upvotes for issues. I don't know just if that's on the roadmap or something like that. One thing I can tell you at the templated Web site is that's actually something I've already put into my project plan is I think that that's really important making it really easy for people to get started so I'm hoping that we'll build to see something like that in the next six to eight. In my mind you would deploy yourself. You wouldn't be forced into it. The other big thing that they do is to make it get actually really usable to make one thing they could do to make it really usable someone needs to finally get a clue and copy OpenSUSE's build service. So building something like the OpenSUSE build service behind Git to where you can have the packages built there so now we have a more trusted system for package builds. If I'm pulling down RPM from the creator I'm not pulling it from them I'm pulling it from Git where I've got a little more trust that they're not doing something to manipulate the file. Alright thank you everybody and this was like the end of the day thank you for coming along. Thank you Mr. Vincent