 Thank you very much. So yes, for those who don't know me, my day job is a CTO and co-founder of Trades Cloud, where an Australian software is a service for tradespeople, plumbers, electricians, people like that. I'm also co-founder of the BeWare project. BeWare is a project exploring the tools that we use as developers to write software in Python. The two most notable components of BeWare at this point are Cricut, which is a graphical test runner, and Togo, which is a Python native cross-platform and GUI toolkit supporting both mobile and desktop platforms, hoping to do a lightning talk about Togo later on. But that's not why I'm here today. I'm here because of my involvement in the Django project. I've been a member of the Django Core team since 2006, and I've been president of the Django Software Foundation since 2010. For those who don't know about it, although I've been ranting on this stage already, the DSF is the IP legal fundraising arm of the Django project. And over that time, over that eight and a half years, I've filled a number of roles in the Django project. I've been an outsider contributing patches. I've been a core developer. I've spent time triaging bugs. I've reviewed patches provided by others. I've managed the release process for Django 1.2 and 1.3. I contributed a couple of major features, like Django's original user-facing testing tools. I've mentored seven Summer of Code students, or Google Summer of Code students, resulting in features like multiple database support, aggregation queries, the refactored validation framework in 1.7, and hopefully for 1.8, a refactored and formalized meta API. Django as a piece of software and as a project has changed a lot over those eight years, but the one thing that hasn't changed is that we're an open-source project run entirely by volunteers. And a key part of any volunteer project is engaging new community members. Marketing people often talk about conversion funnels when they're talking about trying to sell a product. The idea is that each step in your sales process, you lose some potential customers. You have the initial audience of everyone possible, someone comes to your website, only some of those people will sign up, and only some of those people will do a trial, only some of those people will go on on purchase. The idea is, each step you lose some potential customers until at the bottom you actually physically close a sale. Now the trick in conversion funnels is to actually make sure that people actually get to the bottom, because if I don't, then you don't have revenue, you don't have sales. It can help to think about users in an open-source project in a similar sort of way. Anyone coming to your project is a potential user. Those potential users, you wanna convert them into actual new users, someone who does the tutorial and has a try to see if something works. You want those people who do the tutorial and tries out the project to actually use it and become actual users of your software for real production work. Those potential users, you want some of them to turn into community members. People who actually get involved with your community and start writing messages on mailing lists and contributing in some little way. You want those contributions to grow until someone becomes a significant contributor to your project. Significant contributors, you wanna turn into members of the core team and eventually members of the core team graduate until they're considered to be leaders, leaders of that community as a whole. If you're dealing with commercial software, that process exists as well, but generally the engagement ends somewhere around becoming a user. If the company that's producing commercial software is really good with community engagement, it might end with becoming a community member, a recognized community member. Microsoft does this when it labels people as MVPs, for example. But at an open source project, you can't stop there. If the project is going to be viable and successful in the long term, you need people to work their way down your conversion funnel. Really successful projects like Django have had lots of people work their way down that funnel over the years to the point where the original founders of the project can step away and the project keeps running. Feeding and caring for this conversion funnel is essential to the long term viability of any project. So with apologies to Disney Corporation, I'm here to show you how you too can get involved in the narrow end of Django's conversion funnel. The choice of the title of this talk is twofold. Firstly, Frozen's a cool movie and I'm always up for a little bit of homage. But more importantly, I think there's actually a pretty good metaphor here. If you haven't seen the movie, it's about a pair of young girls. Anna, the girl who's been shown here at one point fairly early in the movie, sings a song to her elder sister Elsa who's asking her to come outside and build a snowman. Elsa, however, is locked away inside her room because she has magical powers that makes her a danger to others. Anna doesn't really care though. She just wants to play with her big sister, doesn't really understand why she won't come out and play. Now, under part of the story, Elsa is also the princess royal. So when her parents die, she becomes the queen and she has all these political responsibilities in existence to her devastating magical powers. She still loves her sister and she wants to come out and play with her, but she knows that she can't, or she's sad, she's very sad that she can't. How does this relate to Django? Well, if you're relatively new to the community, it's easy to possibly to think of the core team as a bunch of princesses with magical powers, locked behind a door for everybody else's safety. It's easy to think that you need to come to the door and beg us to come out and play and it's probably easy to say that we're easy to think that when we say no or if we don't respond, it's because you've done something wrong. What that misses is that we're all part of the same family and those in the core team, well, okay, we've got magical committing powers, but we want to come out and play with you as much as you want to play with us. If we don't respond and we don't come out and play, it's probably because we're balancing some other responsibilities that you might not know about. And most importantly, you don't have to be a core dev to make a huge contribution to the Django community. You can build a snowman whether we join you or not. However, the power of the core team isn't some magical artifact of ultimate power. Someone has to be able to commit and do quality assurance on a release. Sure, someone has to be able to make a canonical API decision. Yes, these are necessary evils for a small number of administrative functions. But the key point here is that it is or it should be a small number of administrative functions. This is for the simple reason that a broad team is a lot more resilient over the long term. When you invest power in a very, very small group or you invest absolute power in a very, very small group, you become completely dependent upon that group to get anything done. And if that group is volunteers, like they are in most open source projects, including Django, you become completely dependent upon the availability of those volunteers. Being in the core team is certainly something to aspire to and we want as many people as possible to be recognized as leaders and as serious contributors for the work that they're doing in the community. But we also want to make sure that we don't end up deifying the core team and having the core team become the barrier to actually getting progress and getting things done. And it's for this reason that the core team actually spent a good portion of the start of this year internally discussing what it actually means to be part of the core team. This isn't the first time we've had a discussion like this. The most recent time prior to this was around 2010 in response to complaints that existed in the community more generally and were given voice by Eric Florezano on a stage as a keynote on the other side of the river, right here in Portland. This time around, there were a couple of different catalysts. One of the most notable being the decision by Adrian and Jacob to stand down as BDFLs. This left us with a bit of a power vacuum at the top of the project and raised the question of what does it mean to have power at all in the Django project? Now, this is all happening against a backdrop of the Django project that has historically tried to avoid centralised power anyway. As a core team, we've tried in most, particularly in most recent years, tried to avoid adding things to core as much as possible like new contrib apps, unless there is a really, really compelling technical reason to do so. And we've tried to keep community resources in the community as much as possible. This hasn't always been successful though, at a theoretical level. Yeah, we don't wanna reinforce the idea that being official is important. But it's an undeniable fact in practice that giving something an official label gives a project oxygen that it wouldn't otherwise have. So what we've ended up with is a vastly expanded sense of what the core team actually means. So, okay, what if we actually changed? Well, the first is the concept of the core team itself. Historically, the core team was everyone with the commit bit, but this meant that we couldn't actually add someone to the core team unless everyone else trusted them to make commits. And this is constraining, because there are lots of people who have very, very useful skills, but which we don't actually know how good a guy is coded yet. We don't know whether we can trust them with the commit bit for the whole of Django. So what we've done is we've relaxed our requirement. We now have this concept of a core team which we can add people whose contributions are primarily design or operations or documentation. And it means we can add people who have undeniable technical skill or expertise, say, for example, in a database back end that Django doesn't officially support and then give them a voice to speak with authority, to speak with the voice of the Django project and with the weight that that carries. Inside that core team, there are then overlapping subgroups. Most notable of these is, of course, the committer team. This is what historically would have been called the core team. This is the people who can actually commit code. Now, we're going to keep the same high standards for selecting people who are on the committer team, but we're not making those standards a prerequisite for being recognized as a leader or as an authority in the community. We're also providing a way for people to stand down from the community without formally resigning. Now, this means that I can say, I can acknowledge, I'm not going to have time to commit code to Django for the next six months or the next year without having to step down 100% as someone who is interested in Django at all. And as a result of that sort of formal process of being able to step down, we can then monitor those numbers and use that as a trigger for adding new contributors and adding new committers as needed as our team sort of dwindles because people are having to walk away for a moment. Another important subgroup and a newly constituted group is the technical board. Now, it's all well and good to have an expanded core team, but sometimes someone needs to make a hard decision. You have two equally good, but fundamentally opposed or fundamentally contradictory technical proposals and you just need to pick one. Or in less extreme circumstances, you just need to pick a damn color for the bike shed. Adrian and Jacob filled this role for a very long time, but as their interests moved away and their ability to contribute moved away, it made these sort of decisions a lot harder for the core team to make. And ultimately it meant we ended up punting on a lot of decisions that really should have been made. So someone puts up a complex design for discussion and then gets no response. Is that because no one cares? Is that because no one wants to venture an opinion? And if you do get an opinion, how do you know that that opinion represents the board community consensus that we expect in terms of a long-term driving position of the community? So making those decisions is now the job of the technical board, where previously we would have asked the BDFL to make a judgment on a particular position. What we've now got is an elected board of the core team who and the community as a whole or the core team can then ask for the technical board to make a decision. Is this something we're going to do? What API are we going to follow? What color are we going to paint this bike shed? The technical board is elected from the core team for the purpose of the next release. So we are internally just completing the elections for the 1.8 release, at which point we will have the group of five people who will make the decisions about what is or isn't in 1.8 from the point of view of is this an acceptable API? Is this an acceptable design? If there is ever any question. Then there are a couple of other groups in there as well. There's the security team. There's people who get notified if there is a report of a security problem in Django. There are the releases, the people who actually hold the keys are empowered to publish the thing that is called Django. There's the ops team, the people who maintain Django project.com and all the related resources that are needed to be hosted. These are all disparate groups. There's overlap, but there's no requirement that there's overlap. And if you're a member of one of these teams, you are a member of the broader core team as well. We could now add someone to the core team purely because of their expertise in managing security reports or performing QA on releases or without giving them any other permissions whatsoever. And as a member of the core team, they're able to speak with that official voice. It also means that we're documenting a lot of internal procedures. I am the president of the Django Software Foundation and I couldn't tell you with absolute certainty the set of people who have the root password on Djangoproject.com. That's my dears, but I wouldn't claim that that's a canonical list whatsoever. Now this isn't good for a project the size of Django. If someone needs to get something done, I need to update something on the website. You've got to find the person who knows. And if we don't know, we can't tell you where to go. So formalizing these roles basically means we're also documenting who has what responsibilities, who has the keys to which part of the kingdom. Ensuring clear decision-making processes and documenting responsibilities is one important part of the changes that we've been implementing. But there's another important aspect that I've been trying to drive through here and more broadly that we've been trying to tackle as a community along the way. A lot of these new arrangements are structured to directly combat the problems of burnout that we've been seeing in the Django community and more broadly the tech community as a whole. Django and to that matter the entire technical community, computing technical community is capable of achieving and has achieved amazing things. But lurking in the background is something much darker. We have an appalling record when it comes to mental health. In extreme cases, we've seen people in our community and I'm talking both about Django and the broader tech community, our friends, our colleagues crash and burn. And in extreme cases, take their own lives. Aaron Schwartz is in Django's authors file and for his contributions to magic removal back in 2005, 2006. The fact that authors.objects.all exists and that does it that way is basically Aaron Schwartz's contribution to Django. I've had three other people who are very well known in the Django community reveal to me in the last month that they have been in very perilous mental positions and in one case was contemplating self-harm. This is a problem we can't ignore. It is literally killing us. And as a community, we should not allow this to happen. Speaking personally, I've struggled with burnout and depression issues over the years and I know from the experience that there is a huge social stigma associated with it. Dealing with depression is ultimately an intensely personal journey but as a community, we can take steps to make sure we're not contributing to the problem. We can destigmatize the problem. We can take the simple step of saying or asking, are you okay to those around us? And especially to those who don't seem to be coping well around us. Completely aside from anything to do with Django or anything else to do with the core team, I'd ask you, I'd encourage you to do this. Just ask, are you okay? And listen, really listen to the answer for the people who you know around you in your community. It's not about trying to fix their problems and there probably isn't even anything that you yourself can actually do to fix it but the act of listening and making it aware, making people aware that you are listening can help immensely in making people feel connected to the world around them and some small way let them know that they're not alone in the burden that they're carrying. And there might actually be something you can concrete, do in a concrete sense to make this problem, make their burden easier. So, and then as a project, there are definitely things that we can do to help. We can provide procedures and policies that aim to prevent burnout and avoid these problems before they occur. Most of the positions that we've introduced into the core team structure are intentionally time limited. The technical board is elected for one release. Other positions are also release bound, some of them are time bound and we've provided a process by which people can step back into a non-committer emeritus role. This means that when you sign up to do a big task in the Django community, the task has an end point. There is a socially acceptable exit which isn't a failure. It's just the end of a period of time where you're contributing. Which means that it's then easier to frame stepping back as actually stepping back, not a personal failure because you've failed to contribute and failed to meet up with community expectations. Okay, so that's how the core project is organized and the changes that we've sort of been introducing over the last six months, or we've been talking about and now we're introducing. What tools do we use to get the job done? Well, first of all, everything I'm about to describe here is documented. Django's documentation has an extensive section right down the bottom talking about how to get involved with contribution. So if you do have questions and you don't have a chance to catch me either after this talk or the rest of this conference, this is the place to go. We've updated this document as we update our procedures. So make sure you're looking at the most current version, so the slash dev version of the documentation at the moment for the next development release. Django is a lot more than just a code base and a core team. It is the community of resources that are around Django as well, both official and unofficial that we use to develop that code base. The sort of official resources and sort of increasing order of permanence of the IRC, mailing lists, track GitHub and the Django website itself. In addition to these official resources, there are also unofficial ones and I'm using the word official and unofficial reservately here. They're only official to the extent that they actually, their places where we try to document the formal endpoint of decisions. That doesn't restrict anyone from talking about Django in any other form if they want to. Okay, so let's have a look through these resources to see how you can get involved in the Django project using them. The IRC channels, Django has three official IRC chat communications channels. This is sort of those impermanent fast-moving discussions you just need to have with someone. They're all hosted on FreeNode. You do need to have a registered NIC to join in, but that doesn't cost anything. You've just got to register a name so then we know that the name's not, you're not spoofing someone else and pretending to be someone else. Hash Django is the channel for how do I do X type questions. Django Dev is for discussing the development of Django itself and then Django Sprint exists to support the Sprint's process. So like we do on this weekend, on Friday and Saturday, where we've got a whole bunch of people in the room and there's a bunch of discussions which are basically development-related, but there's a speed and a churn that doesn't, it helps to keep that out of the Dev channel itself. As with all Django public spaces, the IRC channels are subject to the Django Community Code of Conduct. What does that mean? Well, it means we expect you to behave like a responsible, considerate adult. You talk like a human who has taken the time to compose their message and is communicating with other humans who have feelings and sensitivities and what have you. When you respond to someone, you respond recognizing that it is a person at the other end and they have knowledge, they have experience. In some areas, their knowledge may be less than yours. That's why they're asking a question. That doesn't mean they're an idiot. It means they probably know things that you don't. There may also be a language barrier or a generation gap and we expect the communications that happen in these channels to reflect that diversity. Your behavior in IRC channels, or for that matter any other public space that's associated with Django, reflects on everyone in the community. So we expect you to communicate like you're taking that responsibility. And if you don't, one of the things, one of the few things the core team is empowered to do is to ask you to leave. And we have done that on a number of occasions. IRC is best suited to the immediate transient discussions, working rapidly through a complex problem, spitballing an idea, going back and forth to try and get an idea nailed down. We have logs, but they're not really a good permanent archive. Like you wouldn't want someone holding a tape recorder next to every conversation you have as the permanent record of why stuff gets done. So ultimately, if something happens on IRC, we'd like it to sort of end up being documented slightly more formally somewhere else. The next step up the chain is on the mailing lists. The mailing lists are sort of the official long form communication channels and archive of the project. They're all hosted on Google groups. Django users, again, is the how do I type form. Django dev is discussing the development of Django itself. Getting involved in the mailing list, and also for that matter on IRC, the mailing list in particular, though, are one of the easiest places to get started as a contributor to the community as a whole, because you can engage whenever you have free time, not when someone else is literally asking a question right now. It requires absolutely no ongoing commitment. If you want to answer one email right now and then not come back for three weeks, that's entirely up to you. It requires absolutely no special privileges. You don't need permission to post to Django users or Django dev. You just need to join in for the first time. Answer what you can when you can. And although it doesn't sound like much, it's a huge help. Some of the best contributions to the community are not code-related. Getting involved in the mailing lists is a great way to get to know the members of the community. Lots of long-term contributors, like myself, still frequent Django users as a way to keep in touch with all the cool kids are doing. And it's a way to get yourself known to the members of the core team and to members of the broader development community as well and establish that you actually know what you're talking about, that you have a reputation that you can be trusted with your expertise. So it's also a great way to introduce yourself to that community and demonstrate you know what you're talking about. If you're on Django users, teaching someone is the single best way to solidify your understanding of any topic. If you're on Django developers, explaining your use case for a particular problem or explaining why a particular technical solution will or won't work is a great practice in technical documentation. It's a little-known fact that if you go and actually ask employers the most desirable characteristics of new employees, they will almost always list communication skills higher than technical skills because the most technically talented person in the world who can't communicate why something is a good idea is almost useless to a team. Someone who can communicate effectively that has moderate skills can work with everyone else. So practicing your technical documentation skills is a great way to do it out in public, do it on Django dev and let everyone know it's good practice to have. But beyond simply participating, beyond just writing messages to these lists, make notes, take notes, either mental or actual about your conversations. Do you keep noticing the same common mistake being made over and over and over again? Maybe that's a documentation issue. Have we failed the community in describing how something should work? Do you notice that there's a common problem that keeps coming up? People keep trying to ask, how do I do X complicated thing? Well, maybe that's a feature in the making or a resource gap that the community needs that we need to fill. We also have, on top of Django users and Django developers, we have a third list, Django Core Mentorship. This is sort of a meta list. If you're interested in taking things to the next step and sort of leveling up in your contribution and you're looking to get someone on the core team or someone in the core group to help guide you in that process, we have that there as a resource so you can jump on board and say, I'm looking for a little help. Can someone point me in the right direction what I might be able to do to move on to the next level? Okay, so the next step up in permanence is track. Track fills two roles for us. It's a ticket tracker, an issue tracker, and it's a wiki. Now, first off, a truism. All ticket trackers suck and all wikis are wastelands. Ours are no exception. The thing is, they're necessary and track sucks in ways that we understand and we're willing to live with it. And for those wondering, yes, we did look, when we moved to GitHub, we did actually look at using GitHub's issues. The problem is the GitHub issues didn't address a number of workflow problems that are sort of key to the way that a project the size of Django works. Principle reason is that we treat track a lot like a community garden. Everyone is welcome to help. What do you want to do? Like, if you've got a community garden, sometimes there are weeds that need to be pulled, sometimes there are flowers and vegetables that need to be picked. We need your help, the garden needs your help and at the end, we all benefit collectively. Now, there are always community leaders, generally those who put in the most time, but the community leaders need the community as much as the community needs the leaders. Like all gardens, we can aspire to perfection but in reality, there is no such thing. Even the most pristine garden, there are still snails and insects. And in the community garden sense, there are always very helpful people who with the very best of intentions, fertilize the weeds and poison the roses. It's the job of the community to, as a whole, self-manage and keep the problems to a minimum as much as we can and educate those who are new to the community so that they become valuable contributing members. It also means that ultimately, you reap what you sow, just because you turn up one day with a bag of fertilizer doesn't mean you get to take home a bag of radishes. This is in the farmers market, just because you've paid doesn't mean you get to take home what you want. There might not be any radishes available, the radishes that are available might have already been allocated to others who have been volunteering for months. So how does this garden metaphor manifest in a ticket system? Well, it means that we let anyone edit anything they want on track and we leave it up to the community to manage and self-correct the mistakes. As far as the ticket sales are concerned, a ticket can essentially be in one of three states. When a ticket arrives, someone logs a ticket for the first time, it goes into an unreviewed state. We know nothing about this ticket at this point. It might be a bug, it might be a feature, it might be correct, it might be incorrect, it might be a misunderstanding, it might be someone who's just, you know, dropping spam in our ticket tracker, which we've had a problem with recently. Someone needs to triage that ticket. Someone's created the ticket. We need someone else to go and say, yes, this is correct, yes, this is incorrect, and work out what needs to be done. This means one of two things will happen. Either it gets accepted, yes, this is a legitimate problem, yes, this is a good suggestion for an improvement, or it's closed as either a duplicate. We've seen this problem before, it's this ticket over here. Won't fix, we've made a decision as a community, we're not gonna do this. Now yes, we acknowledge your problem exists, we're not gonna do it that way. Invalub, I can't work out, you've given a report here and this doesn't make any sense, what you've described makes no sense, or it is in direct contradiction to what the documentation says should be there. Needs info, I can't reproduce the problem you've given me. You've given a set of instructions, I do this and it doesn't work, or you haven't given me enough information to reproduce the problem that you're describing. All works for me. I've followed your instructions exactly as they go, and I don't see the same problem, which probably means either the problem has been inadvertently fixed, or you're not telling me something about your problem. When the ticket is closed, anyone else can come along and reopen it again. If someone comes along and says, oh, hang on, no, no, no, I know what this is, it's actually this version of Postgres that's the problem. It's now, yes, it works for you because you've got Postgres 9.4, Postgres 9.3, this will actually be a problem. They can reopen the ticket and move it somewhere else. So once it's closed, it's not absolute, there's nothing locked down here. When the ticket is accepted, this means we're then waiting for someone to contribute something, usually a patch of some description. Once a patch has been provided and that patch meets all the code standards that we have, it's tested, it's got documentation, it's PEP8 compliant, et cetera, et cetera, this is then the trigger for someone to move the ticket to ready for check-in. Someone has to review that patch, say, yes, it's okay, and move it into ready for check-in. That is then the trigger for someone in the core team to take one last look over the patch and then commit it to trunk. Now, like I said, we let anyone edit anything in track and nothing in track is irreversible. Anyone who wants to help can help. We assume that everyone is well-intentioned and for the most part, that is completely accurate. The guiding principle on all our track activities, we want two pairs of eyes on everything. Someone reports a ticket, someone verifies the ticket is correct. Someone provides a patch, someone verifies the patch is okay and then it gets moved into trunk. Now, like the community garden, we appreciate that mistakes do get made. The important thing is not that we never make mistakes. The important thing is that we don't make the same mistake twice. So what we expect the community to do is kind of keep tending this community garden of tickets. And yet, mistakes are gonna get made. Okay, that's fine. We can correct that mistake by just reversing the state change in the ticket or moving wherever we need to go. But if you're a contributor and you're contributing and you notice that your ticket changes keep getting reverted, we expect you to pay attention to why that's happening and hopefully adapt over time to sort of learn the process. And if you don't understand why, then ask. When a ticket is in the accepted state, there are some additional flags that help people identify what is needed to progress a ticket further. You can use track to filter tickets based upon these flags. So each individual ticket can be flagged as it has a patch. There is code that is associated with this that addresses this issue in some way. It might have a patch, but does that patch need improvement? So that we have a starting point, but something needs to be improved with this patch. It's not PEP8 compliant. It doesn't meet some code quality. It's missing some edge case in the problem it's trying to solve. The patch needs documentation. You have provided a new feature but you have not documented that feature. Bad contributor. You have provided a patch to confirm a new feature and you haven't provided tests. Bad contributor. So there is something that can be done there by someone who wants to contribute. It's, we can have a flag that it says that it is a UI or UX issue. This is a way to sort of flag to the people who have design skills that this would be a great way for you to contribute. It's not code, we just need someone to make this not look quite so ugly or behave in a slightly better way or have a better user interface to it. And then there's easy picking. So if you're in for the first time, if you're triaging a bug and you think, yeah, this is really only a two line fix to make sure that we've updated to, you know, catch a new version number somewhere. You can flag that issue as easy pickings. And then later on, all of these flags can be searched and filtered in tracks. So you can go to track and say, show me all the tickets. There's 1700 of them. Okay, show me the tickets that are belong to this particular component. So we track whether an issue is a bug, a feature or an optimization. We track what version a bug can be observed in and what component of the system it exists. So we can filter out and show me all the bugs that are in Django 1.7 that relate to the forms library that are easy pickings, have a patch but needs improvement. And you just tick the boxes on which ones you want and you can get a filtered down list. That will eventually reduce the 1700 tickets down to three that you can actually work with and find something to contribute. We also track whether an issue is a release blocker. Now a release blocker is something that is any bug in a feature that has been added in this release or a bug that would cause unexpected data loss or corruption. Anything that would give Django a bad name if it was to happen to a large, well-known website. So how do you contribute to track? Well, first off, you need to get a GitHub account. We have had a massive problem with spam over the years and we've just recently moved to essentially saying as a minimum barrier to entry, we're gonna require people to have a GitHub account and we use github.oworth to authenticate you to get into track. Then pick an area of interest and dig in. Fill to the tickets to narrow down. Pick one ticket and just try to move it forward. Try to get it from where it is to the next step in the chain. You need to add a little bit more to the patch. You need to triage it. Whatever the next step is to get it from to the next box along in that chain of tickets. When you're doing that, pay attention to context. Context matters. If a ticket has a very low number, at this point anything probably less than about 10,000, there's almost certainly some history. Read the whole discussion that's associated with that ticket because if you've got an open ticket with a low number, there will be a lot of extra information in there. Track down the mailing list because you can almost guarantee that ticket will have been discussed at length previously. If a core developer has got involved in the discussion and core developers are identified in track discussions, pay attention to them because someone like a core developer saying, I don't think this is a good idea, carries a little bit more weight into the general community discussion than anonymous says, I don't think this is a good idea. But be bold. We don't bite. We want your contribution and we only move forward if people get over the sort of the nervousness of contributing and therefore don't do anything. We want you to be bold. But don't be too bold. Don't be paralyzed into an action but don't charge in where angels fear to tread either. If you don't know or you aren't sure, leave a comment telling us what your gut tells you. And if there are enough gut checks, then eventually that will add up to someone saying, yeah, well they say so and they say so and they say so. Well, okay, let's just move that one forward. Be rigorous. We follow PEP 8, including the most important part of PEP 8, the opening preface that says the foolish consistency is the hobgoblin with little minds. So we follow PEP 8, we expect documentation to exist, we expect tests to exist. So we are rigorous in all of that and you need to be rigorous in your reviews as well. And don't just stop at one. Okay, start slow. Don't just rush in but if you're serious about getting involved long-term, don't just submit one update and then wait to be told that you've done the right thing. You kind of need to build a little bit of momentum and eventually anyone who wants to subscribe to all updates the ticket tracker can do so. I get in my mailbox every single time someone updates a ticket, I get a mail that says this has happened and I don't read in depth but I do stan every update that goes through just to sort of see what's going on. And if I see a name perpetually doing what looks like the wrong thing, I'll go and investigate and then maybe sort of set them straight saying, hang on, maybe you need to not do that. And I'm not the only person who does that. There are a number of others in the community who do the same thing. If you're systematically doing the wrong thing, it'll get noticed and you get kind of politely say, can you, okay, don't do it that way, do it this way or pay more attention to this because this is more important to us. While we are on the subject of track, I'll take this opportunity to make this plea in public yet again. If you think you found us a security issue, if you think you might've found something that might maybe be a security issue, please don't open a ticket. If you have just found some marvellous way to do a distributed denial of service attack on every Django site by some simple procedure, you've just opened up a problem that will potentially bring down Instagram or NASA or the US Library of Congress. Django has a security process to make sure that we as a community do not have an embarrassing event like that. But it hinges upon us being told about serious problems in a discreet manner. So if you think you've found something with a security implication, mail security at Djangoproject.com. We'll get back to you with an initial response within 24 hours. If it turns out that you're just being hyperparanoid and we want you to be paranoid, if you are just being paranoid and say, yeah, okay, we know about this, it's not a problem, it's documented here or it's an acceptable thing, move it to the ticket tracker and we'll correct it. So you can always go to the ticket tracker later, but once it's in the ticket tracker, you can't really bring it to security. And the thing is that if you've found a significant problem, there might even be some money in it for you. We are a member of a couple of bug bounty programs, but if you report issues irresponsibly, you become automatically ineligible for those bounty programs. So there is money tied to doing this right, not just the community reputation of Django. We also use tracked wiki capabilities, like most wikis, like I said, ours is an untended wasteland. There are however a couple of jewels in there. Most notably, it's a good archive of the history of releases and an archive of some of the significant design decisions that have occurred over the years. So if you wanna know why Django's class-based views are laid out and designed the way they are, the wiki actually has a really good tear down of all that stuff. I won't go into the wiki anymore than that. It exists. There are some useful veins of good information. If you think you could contribute by manicuring some of that useful content or by contributing more content to it, feel welcome. If you start making particularly useful contributions, we're more likely to say, can we merge this into the main documentation, please? Because that's sort of our actually tender documentation that we'd rather have as a long-term archive. All right, next up, GitHub. Django has been using GitHub for about two and a half years at this point. Most recently, we started using GitHub lock-ins as a way to manage spam and our track instance. Git is a complex beast, but if you're in software development, it's a beast that's worth learning how to wrangle. And GitHub is a pretty nifty user interface wrapper around the features of Git. Explaining Git and GitHub is well outside the scope of this talk. It is a technical weekend all on its own. All I'll say is that if you wanna contribute to something in Django, you can use pull requests in GitHub, which essentially means what you need to do is fork the Django repository into your own GitHub account, create a branch in your account in which you'd create your patch for that particular issue, which may be one or more commits on your repository. And then you submit a pull request from that branch back into Django's main repository. Django's contribution documentation has detailed instructions about how exactly we use GitHub and how sort of the standards we expect you to follow when you do that. Astute observers, however, will note that there is now some overlap in what track does and what GitHub does. We use track for mostly historical reasons. Track integrates really well with Subversion, which was our old version control system. GitHub provides an issue tracker, but it doesn't meet our requirements, including the community gardening approach that we were talking about, but also, but not limited to importing our old ticket history. So we've settled on a sort of a hybrid arrangement here. Unfortunately, as a result of having a hybrid, there are now two ways to contribute code. You can upload a patch to track and you can submit a pull request in GitHub. Officially, we support both. And officially, we sort of have to support both because there are a lot of old tickets with old patches in GitHub, sorry, in track. But at this point, GitHub pull requests are effectively sort of a first amongst the equals. The rest of the GitHub pull request workflow is good enough that they're sort of getting a lot more attention to stuff that is just kind of sitting on tickets in track. This GitHub track duplication also points out another important feature. You need to pick the right forum for a discussion. There are multiple places that you can physically write a comment on something. Golden Rule, and this goes for basically all the communications channels in Django, you need to pick the right forum. If you're commenting about a specific patch, you probably want to be doing that on the pull request. If you're on GitHub, if you're commenting about the process of diagnosing a problem, that's probably the ticket on track is the right place to be putting that comment. If you're looking for a broad discussion about something, then probably should be on a mailing list. And over the last span of a discussion, it's possible that the discussion will morph from one form to another. You know, you start talking about a particular bug or hang on, that exposes a bigger issue. Now we do talk about how this manifests on a particular patch. No, we need a broader community discussion about how we're going to handle this thing. So don't get hung up on picking the right forum, but do your best to try to find the best place, the most broad and most appropriate audience for the thing you're discussing. But if someone with more experience or someone from the core team suggests that maybe you take this discussion somewhere else, take their lead, take their advice. It's usually because their experience has shown that there is a larger or better audience that will pay attention to this issue if you take that discussion wherever they say. Lastly of the official resources is DjangoProject.com itself. There are actually a number of subsites on DjangoProject.com, some of which aren't well linked or advertised. That is a separate problem that we're working on. But amongst those websites, DjangoProject.com itself, there's docs.jangoproject.com, so a hosted version of all of Django's documentation. There's ci.jangoproject.com, a continuous integration server. There is people.jangoproject.com, which is an index of everyone who is willing to put their hand up and say, yes, I am a Django user. So if you're looking for people around your area, either you're looking for employees, you're looking for employers, you're looking for people to start a users group, you can go on there and let people know you're a Django user, find other people who are geographically near you. We're also interested in adding new subsites to this list. The thing that's interesting is that the people in particular, people.jangoproject.com, started as a completely external project. But it sort of looked at such a useful resource that we decided to bring it into the Django project itself as an official resource. If you've got an idea for something to build that you think would be a useful resource for the community, go ahead and build it. And if it looks like it is a useful resource, then we can consider adding it to the main stable of websites. And at the very least, the DSF has money to throw you, or either money or resources to throw you to host it for you so you don't have to pay for having the entire Django community land on your Heroku instance. Okay, so the process I've been talking about so far is mostly about bugs. The vast majority of tickets in track are bugs. They're people who are reporting that an API doesn't work as documented or with some edge case where things crash and so on. Not all tickets are bugs though. Some are feature requests. How are they handled any differently? Well, it depends how big they are. If they're a small feature request, like say a request to add existing, to extend existing functionality in some trivial way, then they're handled almost exactly the same as a bug report. Their tree are slightly differently. I remember there's a ticket descriptor that says that a ticket is a feature, rather than a bug. But other than that, the process is basically the same. Someone proposes the feature, someone agrees that this is a good idea. Someone provides a patch, someone verifies the patch is good, that it has documentation, that it has tests, and that patch then gets committed. But if the issue is bigger, the idea is bigger, there might be an additional step in there involving some discussion. How much bigger? How much discussion really does depend? The bigger the proposal, the more broad sweeping the idea, the more discussion that will be required. Bigger here doesn't just mean code size or diff size either. The core team will be evaluating the impact on users. Is there either any backwards compatibility concerns? Will this back us into an architectural corner? Are there any internal consistency issues with a proposed API? That's this sort of discussion happens on Django developers. Even if there isn't anything particularly controversial on the proposal, it will probably be raised on Django developers as a point of discussion if only to prove that there isn't any controversy, anything controversial in the discussion. And if it's a particularly big issue, it will probably take multiple discussions on Django dev, at which point those multiple discussion threads might get summarized into a page on the wiki, like we did for the Class Based Views information. A few months ago, Adrian announced that we were going to formalize this process a little bit into a process that mirrored Python's PEP process and create depth Django enhancement proposals. Unfortunately, this was announced and then the process kind of stalled because we were kind of internally in a bunch of other discussions at the same time about how the core team is composed. So the dust hasn't really settled on how we're going to use depth. My personal take is what we're probably going to end up with is a formalization of what we've been putting into wikis for big issues. It doesn't replace discussions on mailing lists or anything like that. It's just a formal document that technical board, technical board, can pass a judgment on. Writing the depth itself will kind of be the end point of the discussion, not the starting point. But that is just my take. Watch this space for sort of more official announcement. Okay, so we fixed a bunch of bugs, added a bunch of features. How does that get turned into a release? Well, release process starts just after release has been made. We pick someone, we have a discussion, a bit of a brief discussion about timeline in which we sort of, we pick a release manager, Django 1.7, it was Andrew Godwin. We haven't decided who it's going to be for 1.8 yet, but I'm guessing it's not going to be Andrew. We have a discussion about a vague timeline that we'd like to hit. The alpha release is the deadline for major features. The beta is the deadline for other features. And then the release candidate is the hard freeze. Ideally, we only have one release candidate. We let it sit for a week to get a bit of testing, do final translations and chip it out the door. Would that that were true for 1.7? Because it had such big new features in it, we kind of had to cut a couple more release candidates. However, just because we have feature freezers doesn't mean we've shut the door on feature contributions. When we hit the beta deadline, we fork the code base and then features can continue to be added. As a result of that sort of general strategy, we at our own security release support policies, Django has four active releases at any given time. We have a release always in current active development. We have a stable release. We have a long-term support release. We have a security release. New features go into the development branch at all times. Bug fixes might go into the top two depending upon the bug. And the last two only ever get security and critical bug updates. When we issue a new release, all the numbers just shuffle up by one, except for long-term support, which exists essentially for enterprise purposes to guarantee there's long-term support for a particular feature set. 1.4 is listed as being LTS until at least March of 2015. So at a guess, 1.8 might be the next LTS release, but that hasn't been formalized yet. Okay, so how do you progress down the conversion funnel? How do you convert your usage into more useful contribution? Well, first off, the Mia Culpa. This is an area where we have, as a core team, have done badly. One of the triggers for our discussion earlier in the year was some internal complaints that good talent was being wasted or ignored, and we need to improve. So if you have suggestions on how we can do this better as someone who's standing on the other side of the door, please make those suggestions to us because we don't want to lose you. But as it stands, the people who really succeed are the people who start small and persist. If you want, we want more people to succeed. We don't want you to feel like you're wasting your effort. So how do you maximize the chance that your contribution won't be ignored? Start small, because this process is all about building trust. Communities are about building trust. We know that everyone comes to Django with the best of intentions. Some people just aren't a good fit, though. Technical fit, cultural fit, people who value different things. That's fine. We're not saying you're bad people. We're just saying that as Django project, you may not be the best fit. But we need to know that you're a good fit as a core team before we start investing massive amounts of time in you. Because there's a time cost associated with engagement. I'm sure your patch is really, really good. But what about your neighbor? They think their patch is really good as well. I'm a member of the core team and absent of any other information. How do I know that this patch is worth my time and this one is not? I want to make the most of my time. I don't want to waste my time. So the easiest thing for me to do is to review patches from people I know or trust. If I see a big patch from someone I know or something theoretically interesting with huge ambitions, I'm gonna need the reason to look at it. So help us to get to know you. Build that trust over time. Make small contributions. And even if they're not acted on, they will be noticed. And if you're focused and you're persistent, your contributions will help you build trust in the community so that over time, the scope for what you're gonna achieve will increase. From our perspective as someone who's on the lock side of the door, this is an issue of practicality. The only way I get anything done is to ignore 99% of the things that pass over my desk. I'd love to go deep into every proposal, ticket and patch, but I just can't. How do you get into that 1% of things that I pay attention to? Make me trust you. Trust is something that is earned. And if you're a key factor, another key factor of involvement in the Django's code base is getting buy-in from the core team. So don't just dump a 10,000 line patch on us. Try to get buy-in from the core team as well. There are lots of other things you can do that aren't coding though. Answer questions, write a blog, write a book, do social organization stuff, do work in user groups, go to outreach groups like Pay Ladies and Django Girls, get involved in conference organization like DjangoCon. These things don't happen magically by themselves. We need people in the community. And you don't need to be anywhere near the core team to do all this sort of stuff. You can do it on your own or a local community or step up and volunteer. Lastly, quickly, what shouldn't you do? Essentially, add to the people who add to the smoke, not to the heat. Try to get involved with the process and be productive and forward-moving. Don't just complain and complain that something isn't working the way you want. If you complain but don't offer to help, it just sounds like a complaint and that sucks the energy out of the room. We need to, as a core team, need to be consensitive to the needs of the community but the reverse is also true. We're humans. We have feelings too. Being told repeatedly, you suck bad and you do things badly and you should be ashamed. Really does take the energy out of the room for being a volunteer. So please consider your actions and remember we're humans as well. But most importantly, quote from the West Wing, decisions are made by those who show up. The core team has been historically a hard group to break into. We've learned, hopefully, from those mistakes. We've added lots of core developers over the past years. We're trying to make improvements to the community to make sure that more people can get involved. The people that are in the core team at the moment have all worked down the same progression that I've sort of been talking about today. So running a bit longer than I thought I was going to but thank you very much and if I've got time for questions then I can knock one or two out, yeah.