Do you wanna be a core dev? (You don't have to be core dev...)

Thank you very much. Um so yes. For those who don't know me, my day job is a CTO and co-founder of TradesCloud. We're an Australian software as a service for tradespeople, plumbers, electricians, people like that. I'm also co-founder or so founder of the BWAR project. BWARE is a project exploring the tools that we use as developers to write software in Python. The two most notable components of BWAR at this point are Cricut, which is a graphical test runner, and Togo, which is a Python-native cross-platform 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 but you lose some potential customers. You know, 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 they 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 want to convert them into actual new users, someone who does the tutorial and has it has a try to see if something works. You want those people who do the tutorial and and tries out the try out the project to actually use it and become actual users of your software for real no real production work Those potential you or those users you want some of them to turn into community members people who actually get involved with your community and and start writing messages and on mailing lists and contributing in some little way. You want the those contributions to grow until someone becomes a significant contributor to your project significant contributors you want to turn into core members of the core team and eventually members of the core team graduate until they're considered to be leaders of that community as a whole.

If you're dealing with commercial software, that that process exists as well, but it 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 in an open source project, you can't stop there. Uh if the project is going to be viable and successful in the long term, you want 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. Um the choice of the title of this talk um 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. Uh if you haven't seen the movie, it's about uh a pair of 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 uh 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, another 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 but she knows that she can't. When 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 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 or easy to think that when we say no or if we don't respond, it's because you've done something wrong. But what that misses is that we're all part of the same family. And those in the core team, well, yeah, 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 like a huge contribution to the Django community. You can build a snowman whether you 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. If you win when you invest power in a very, very small group Um or CUs who 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 volunteer energy of those uh the energy of the availability of those uh 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 gener generally and were given voice by Eric Florenzano on uh on a stage as a keynote uh on the other side of the river, uh right here in Portland. Um this this time around there were a couple of different catalysts. Uh 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 centralized power anyway. As a core team, we've tried mo in most particularly most recent years, tried to avoid adding things to core as much as possible, like new country babs 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, no, yet we don't want to 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 wouldn't otherwise 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 have we actually changed? Well the first is the concept of the core team itself. Historically, the core team was everyone with the commit bin. 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 Gayara's code is yet.

We don't know how how uh whether we can trust them with the commit bit for the whole of Django. So what we've done is we've relaxed that requirement. We now have this concept of a core team to 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 backend 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 and and with the the sort of the weight that that carries. Inside that core team there are then overlapping subgroups. Most notable of these is of course the committed 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 mean, I can I can acknowledge I'm not going to have time to Commit code Django for the next six months or the next year without having to step down one hundred percent 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 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 someone sometimes someone needs to make a hard decision. You have two equally good but fundamentally opposed uh or fundamentally contradictory technical proposals, and you just need to pick one.

Uh or in less extreme circumstances, you just need to pick a damn colour for the black shed. Adrian and Jacob filled this role for a very long time, but as their interests moved away and their their ability to contribute moved away, it made these sort of decisions a lot harder for the court team to make, and ultimately it meant we ended up hunting 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 it because no one wants to venture an opinion? And if you do get an opinion, how do you know that that that opinion um represents the broad community consensus that we expect in terms of a long-term driving position of the uh 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

uh who and the and 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 colour are we going to paint this bike shed? Uh 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 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 and 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 it need 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're 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 on performing QA on releases or without giving them any other permissions whatsoever. And as a member of the core team, they are 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 Django Project. com. I've got some ideas, but I wouldn't claim that that's a canonical list whatsoever. Now this isn't good for a project the size of Django. You know, 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 sort of trying trying to drive through here and more broadly that we've been trying to uh 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 for that matter the entire technical community, computing technical community, is capable of achieving and has achieved amazing things. But lurking in the background uh is something much darker.

We have an appalling record when it comes to mental health. In extreme cases, uh I've seen 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 author's 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 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 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 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 in some small way let them know that they're not alone in the burden that they're carrying. And who knows, yeah, there might actually be something you can concrete do in a concrete sense to make this problem, uh, make their bat 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, uh 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 been fail- you've failed to contribute and failed to meet up the 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 been talking about and now are now 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 uh

talking about how to get involved with contributions. So if you do have questions and you don't get 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 per order of permanence are 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 reservedly here. They're only official to the extent that they actually uh they're 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, 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 also 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 you're not spoofing someone else and or 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 Sprints

process. So uh like we do on this weekend, uh on Friday and Saturday, where we've got a whole people, a bunch of people in the room, and there's a bunch of discussions which are basically development related, but there's a A speed and a and a and a churn that doesn't it it helps to keep that out of the 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 you 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 you know 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 the they have knowledge, they have experience. In some areas, their alt 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 to leave. And we we have done that on a number of occasions. IRC is best suited to those sort of 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 a permanent record of why stuff gets done

So ultimately if something happens on IRC, we'd like it to sort of beg 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 forum. Django Dev is discussing the j the development of Django itself. Getting involved in the mailing lists and also for that matter in IRC, the mailing lists 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 what 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 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 uh uh that you can be trusted with your 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, uh 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. Um I I dun it's a little known fact that if you go and a actually ask employers the uh most desirable uh uh characteristics of new employ uh new employees, they will almost always list communication skills higher than technical skills. Because the most technical person, 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 but has moderate skills can work with everyone else. Practicing your technical doctor technical documentation skills is a great way to do it do it out in public, do it on Django Dev, and let everyone know you know it's it's good practice to have

But beyond simply participating, beyond just uh you know uh writing messages to these lists, make notes, take notes. um 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 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 in the core core group to help guide you in that process,

we have that there as a resource for you can jump on board and And say, you know, I'm looking for a little help. Can someone point me in the right direction of 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 , so an issue tracker, and it's a wiki. Now, first off, 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. Problem is that GitHub's 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. Principal 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. Uh 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. Uh it's it's the job of the community to as as a whole self manage and keep the problems to a minimum as much as possible. 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 farmer's 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 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 tickets themselves 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 the point, 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 the in the in 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 a du closed as either a duplicate. We've seen this problem before, it's this ticket over here. Uh won't fix. We've 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. Invalid, 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. Or works for me. I followed your instructions exactly as they go f 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 there's someone someone comes along and says, oh hang on, no, no, no, I I I know what this is. It's actually this version of Postgres that's the problem. It's It's now yes, if you it works for you because you've got a read 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 sort of the code standards that we have, it's It's tested, it's got documentation, it's it's it's PEPA compliant, etc, etc. Um 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 track 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 in, 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. Okay, so what we 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 your ticket changes keep getting reverted, we 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 these 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 may 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 PEPA compliant, it doesn't have uh it doesn't meet some code quality, it's missing some edge case in the problem it's trying to solve. The attach needs documentation. You have provided a new feature, but you have not documented that feature. Bad contributor. You have provided a patch took for 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 uh we can have a flag there that says that it is a UI or UX issue. This is a a way to sort of flag to the people who have design skills that this would be a great way for you to contribute.

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 have a better user interface to it. And then there's easy pickings. 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 track. So you can go to track and say, show me all the tickets. There's 1700 of them. Okay, well 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 uh filter out and show me all the bugs that are in Django 1. 7 uh

that relate to the forms library that are easy pickings, uh have a patch, but needs improvement. And if 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 it uh 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 we as a as a minimum minimum barrier to entry, we're going to require people to have a GitHub account and we use GitHub's OAuth

to authenticate you to get into track. Then pick an area of interest and dig in. Filter 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 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. You know, we don't bite. We want your contribution, and we only move forward if people get over this sort of the nervousness of contributing and therefore don't do anything. We we want you to be bold. But you know, don't be too bold. Uh don't be paralyzed into an action, but don't charge in where angels fear to tread either. If if you don't know or you aren't sure, leave a comment telling us what your gut tells you 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 that the foolish consistency is the hopgoblin with little minds. So we follow PEPA, 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 to the ticket tracker can do so. I I get in my mailbox every every single time someone updates a ticket, I get a mail. says this has happened. And I don't read in depth, but I do

scan 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 and say, hang on hang on, maybe 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'll get kind of politely said, can you, yeah, 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 have found something that might maybe be a security issue, please don't open a ticket. If you have just found some marvelous 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 found something with a security implication, mail security at Django Project. com. We'll get back to you with an initial response within 24 hours. If if it turns out that you're just being hyper paranoid and we want you to be paranoid, if you are just being paranoid or 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 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, you know, 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 want to know why Django's class-based views are laid out and designed the way they are, the wiki actually has a really good teardown of all that stuff I won't go into the um the wiki any more than that. Um 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 tendered documentation that we'd rather have as a sort of a long-term archive. Alright, 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 in 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 want to 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 that uh in which you'd you'd create your patch for that particular issue, which it may be one or 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 observer observers, however, will note that there is now some 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 uh but not limited to importing our old ticket history.

Um 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, um GitHub pull requests are effectively sort of a first amongst equals. The the rest of the GitHub pull request workflow is good enough that it's they're sort of getting a lot more attention than the stuff that is just kind of sitting on on uh 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. The 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 lifespan 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. Oh hang on, that exposes a bigger issue. Oh, now we need to 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 form, but do do your best to try to find the best place, the most broad and most appropriate audience for the thing you're discussing 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 they're they've their their experience has shown that there is a larger or better audience that will pay attention to this. This issue if you take that discussion wherever they say. Lastly, of the official resources is Django Project. com itself. There are actually a number of subsites on Django Project. com, some of which aren't well linked or advertised That is a separate problem that we're working on. But amongst those websites, Django Project. com itself, there's docs. jjango project. com, so a hosted version of all of Django's documentation. There's ci. jjango project. com, a continuous integration server. There is people. jjangoproject. com, which is an index of everyone who's 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 uh

let people know you're a Django user, find other people who are geographically near you. We are also interested in adding new subsites to this list. The thing that's interesting is that the people in particular, people. jango project. com, started as a completely external project. But it sort of looked at was 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.

Um the vast majority of tickets in track are bugs. They're people who are reporting that an API doesn't work as documented or there's some edge case where things crash, so on Not all tickets are bugs though, some are feature requests. How are they 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. They're triaged slightly differently. 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 Uh is there are there any backwards compatibility concerns? Will this back us into an architectural corner? Uh 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 controvers 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 DEPS 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 was composed. So the dust hasn't really settled on how we're going to use DEPS. 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 can pass a judgment on Writing the dep itself will kind of be the end point of the discussion, not the starting point. Perhaps however is just my take, watch this space for a 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 ship it out the door. Would that that were true for 1. 7 uh because it was had such big new features in it, we kind of had to cut a couple more release candidates. However, just because we have feature freezes 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 and our own security release support policies. Django has four active releases at any given time. We release currently anyway any we have a release always in current active development. We have a stable release, we have a long term support release, and 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 for 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 formalised 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. uh 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, um 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. Uh 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 the Django project, you're maybe not with the name may not be the best fit. But we need to know that you're a good fit. before like 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 to 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 can achieve will increase. From my 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 onto 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 fact 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, uh go to outreach groups like Pi Pie Ladies and Django Girls, uh 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 of this sort of stuff. You can do it on your own in a local community or step up and volunteer. Lastly, quickly, what shouldn't you do? Essentially add to the add to the uh people who add to the smoke, not to the heat. Try to uh 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.

Um we need to as a core team need to be sensitive 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 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, you know, 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 uh thank you very much. And if I've got uh time for questions then I can probably knock one or two out.

Yeah.