 So, we have a lot to do right now because we're a little bit behind, so let's get started. This is Ferris. And Ferris, just finished writing Ferris says, a rust-flavored Calsay implementation, and they're ready to ship it. But here's the problem, Ferris doesn't know how or what to do to ship their crate. So, we're going to give Ferris a checklist, and we're going to go through every single part of it, and we're going to make sure that Ferris has everything in that crate so they can make it really successful. So this is the first part of our checklist, CI infrastructure and tests. And as we go through, we'll go through items that have your repository as well as how to announce your crate, because marketing is also important. So, you might have heard of this, but it's the not rocket science rule of software engineering, automatically maintain a repository of code that always passes all the tests. It's simple, right? You just need to make sure that if everything passes, everything is good. And how does Rust do it? Well, we have Bors, and Bors here, he's our benevolent dictator for life, and he likes to make sure that everything works all the time, and he won't merge broken code. And it's great, and it catches all the regressions. So Bors here is powered by Homu. And Homu is great in the sense that it's all the code that gets behind Bors and powers it, and it automatically makes sure all the tests pass, and it merges the code if it's been improved. And it does a whole lot more, like, hey, your code broke, or an upstream patch messed things up. And it's a really nice way to automatically just maintain everything. Now, Bors might be a little bit much for your repository if it's a smaller thing, but that's okay. Now, you could be like Nanachi here and have no tests, and you could just hope that no one finds regressions or bugs, but let's be real, we're people, we always write bugs, and it's going to happen. And so you just need to make sure that you pray that that doesn't happen, but actually write the code that doesn't. And so not everyone wants to fix their bugs, and no one wants to fix the tests, and every time the tests break, it's like, oh, well, I could just turn it off and just ignore it, but don't. Because what happens is that something like this happens, and your application stops working, and it's a pain in the butt, and a lot of people are depending on you writing actual code and making sure that all of it works. So setting up a CI system is hard. It's kind of a pain to set up. I'm pretty sure everyone's tried to do it once or twice with Travis, and you have like five commits doing it. And so, but there's some great free open source tools that kind of help this out, and you can compile for different operating systems and make sure that that all works out. And here's an example for myself. I like to call it CI-driven development, where it's five or so commits praying to the CI gods in order to make sure that it all works out. But I've set up a nice little script that you all can borrow from, so you don't have to do this yourself. It's nice. It'll be in the example repo at the end. So here's some core CI tools. You've got Travis, which does OSX and Linux builds, and you've got AppVare, which does Windows. And these are all Tier 1 systems supported by Rust, which means that the core team makes sure all of it works on there, and so you should make sure that your code at least works on there. And you've also got Cross, which is a great tool by Jopark that does a bunch of non-tier 1 systems. It's a Docker container that can do all the cross compilation and everything like that, so you can even test on systems that aren't your own. And one of the nice things, and this is a little feature that I don't think a lot of people know of, is that Travis and AppVare can do cron jobs, and so you can set it up so that every week you run a beta build, and every day you can run a nightly build. And you can have it test to see, hey, does the compiler actually break my code today, which is great for things like larger projects that depend a lot more on nightly features or if you have a compiler plug-in. But even then, it's kind of a way to say, hey, compiler devs, my stuff's going to break even though it's building on stable today, so you might have a regression. And that way, you can also help out the core team in that sense. So you should also enable those on your builds. So there's all those tools that you can use as well. You've got dependency CI that Servo uses. It checks for deprecated packages automatically. And you've also got cover awesome codecov, which do all of the code coverage stuff. Because of the way that tests are in line with some of the files, it doesn't always work out that way. And it's not exactly the best metric, but sometimes people like and care about code coverage having 100% completion. Those are tools that you can use that are automatically there and free for open source. So once you have your CI system and you test it and you make sure that everything is built so you know that when I ship this code, it's going to work. You need to have a lot of different items in your repository that aren't the code. And licenses is one of them. And choosing it can be hard. But it protects you and it protects your code. It lets people know, hey, this is how I want you to use my code. Maybe you want GPL because you want your code to be copy left. Maybe you want to use MIT because you're like, hey, you know what, I don't care. Do what you want. You cannot provide a license, but it actually makes it legally that people can't use your code. And chances are if you're putting something on crates.io, you do want people to use your code. So have a license. But which one should you choose? There's a great website called choosealicense.com. It's got all kinds of information. It can step through, hey, this is what I'm concerned about. This is what I want. So if you do that, you can look through it and it says, OK, here, this is the license you want. And it's also got a couple of licenses for things that aren't necessarily as well known. It's like the unlicense, which is almost just like, hey, do what you want, but I'm not liable. So one of the things that GitHub did is they did a whole 2017 open source survey. One of the important things they said was that licenses are by far the most important type of documentation to both users and contributors. 64% of people say that it's important to them. And 67% of them are saying, hey, I might not use your code if it's not the license that I want. And so this is important. If most everyone cares about licenses, you should care about licenses, too. Code is a legal thing, and you need to have one. So a lot of the Rust community and the community at large uses an MIT patchy 2.0 dual license, sometimes just MIT, sometimes a patchy 2.0. But that's the most common one. And if you do do it that way, it makes it really easy to say, hey, all these crates can work together. It's permissive. It still works with GPL-based code, if you want to use it that way. And a lot of people contribute to your code without having to worry about, do I need to contribute back if I modify it? But it's your code. Choose what you want. Maybe you do really care about free software, and you want to use the GPL. That's fine. But this is just one of the most common things. If you're kind of deciding which one should I use, I don't really know. It's a good default. So one of the other things is the cargo.tomal. And I had to actually change out this slide today because Carol was like, hey, we've got readme's now. So I was like, oh, cool. Great, I have to fix everything while we're doing this. But your cargo.tomal file isn't just how you orchestrate your build system. It's saying, hey, here's all this metadata. Here is everything you need to know about my project. And it's really well documented. It's on this link that I have right here. But it makes it easier to search and find, and it gives a lot of info for potential users. If all of a sudden someone comes to this page and there's nothing there, now I don't know where to look. I don't know what to find. I don't know what to do. Why would I want to use your create? Give me a little bit of information on what it does. Because we like to come up with cool names, but the name's not descriptive. Then it's kind of hard to know what to do. So here's an example of a sub-optimal versus an optimal one. One on the left is pretty much the default one. The one on the right is, hey, let's fill it out. Here's everything you need. It's got badges. It's got categories. It makes it easier to search because it has all this stuff. And it's a lot. But take 10 minutes to fill it out, and you'll find that you pretty much won't have to touch this section again, and it'll just work. So don't skimp on the vital things. You do have time, like, again, you're excited. You're like, oh man, I finished my create. I want to go show the world. I want to go tell about people. But if you just throw it up there and you don't have these things, it's going to make it a lot harder for people to even want to use your code. Having a readme file, a contributing file in case people want to come contribute, docs, examples, and a code of conduct, these are all important things that you should have in your create and take the time to actually think about and put in there. So questions your readme should answer. Your readme is your introduction to your project. People look at there, they look at it, and if it's not there, or if it's pretty nothing's in there, it makes it really hard to know what your project's about, or what it does, or how do I even use a basic example of it. Answer the questions. Maybe you can't maintain it anymore. Have that in the readme. All these things are there so that people can know how to use your project. And it's the first thing that people see. And if it's not filled out, it's going to be hard for people wanting people to use your create. And a contributing file. People think, oh, well, I don't need one, it's small, it's not that much, but think about it. Someone does want to contribute to your code, and they don't know how to contact you. What's the first thing you're going to look for? You're going to look for a file that tells you how to contribute. Fill it out. Spend that 10, 20 minutes to take the time to say, OK, here's how you make a pull request to me. Here's how I'll determine what I want to use. It'll grow your contributors, and it'll be a point of contact and a way for people to know this is how I can help you. Documentation is also super, super, super important. And I have this horrible experience working with Haskell in production all the time, in the sense that there is barely any documentation all the time. And it kind of sucks, because I had to spend more time trying to figure out how to fix the code and get it to work than I do actually writing the code. And the types don't speak for themselves, which seems to be a common feeling. And if you've ever seen documentation like this, it doesn't really tell you much at all about what it's doing. And it doesn't tell you how to use it. And it doesn't tell you anything besides it takes an input, it has a width, and it needs some kind of writer. And it prints out fares. That doesn't help. And it makes most people look like this. And they're confused, like, what? I don't understand. So the regex crate is a really great crate for many reasons. But one of it is that it's got some superb documentation. It takes the time to give inline examples. It has descriptive function names, explains what it does. And one of the other things is that if you do write code that panics, you should tell people why it panics. Too often, people will just throw panics in their code because they're like, oh, you know what? I'm just going to unwrap or whatever. Tell people why. There might be a reason, but the last thing you want to do is have people just use your code and all of a sudden it panics and it poisons a mutex. And now they didn't think that it was and it just ends up being a bad time for everyone. So documentation is a highly valued but often overlooked thing. And this was the common sentimentality in GitHub's open source survey. 93% of people thought it was a problem. And only 60% of people ever don't actually contribute to the documentation. That's insane. Everyone sees it as a problem but no one wants to contribute. So that means only 40% of people are contributing to these projects. You should also be that 40%, actually help spend the time to do that. And I get it, most people feel like this when you tell them to do writing docs and they're like, hey, I don't want to. That's a lot of work. But you will definitely and automatically look, you will make people feel like this when they see that, hey, you spent the time to write really, really good docs. And we all feel that way. It's awesome when you have documentation that makes your life easier. So yes, it's hard. But spend that time to do it. And I get it, writing good documentation is super, super hard. And it's really hard to convey exactly what you're trying to say and have people care about it and tell them the right thing. But do spend that time on it. Trust me, it'll do so much more for your crate if you do it. Now, the other thing that I find super important is often lacking is examples. And too often, you will see a read me have the example in it. And then that will be the only example in the repo. And that's it. There's no non-trivial example that says, hey, here's how you do this really, really, really complicated thing with it. And more often than not, everyone's trying to do the really, really complicated thing. But no one's taking the time to write out how to do it. So things like the Russ Cookbook are a good example of, hey, here are these crates. We're trying to expand it and make it like, here's an easy way to do it. But it's a non-trivial thing. So if you can take the time to do examples beyond just the read me, I think a lot more people end up being happy with your crate. And I think one of the other things, and one that often is a contentious point for many people outside of the Russ community generally, is a code of conduct. You need to have one. It's not saying that you can't have disagreeing opinions or anything like that. It's just saying, hey, be kind to each other and talk in this open space. It's important. And you'll find that a lot of people won't actually do anything with your code or have anything to do with it if they don't have a code of conduct, mostly because they can't feel like I want to contribute because I don't know if I will feel safe being here. And one of the important things is that even Graydon, the creator of Rust, said I would not have built the language nor participated in a project of building the language if I had to subject myself to the kinds of discourse normally surrounding language-building communities. We literally would not be in this room today if it had not been for the very first commit, which was a code of conduct. I cannot understate how important it is to have one. So you may have seen this guy, John DeMore, recently, with all of Google's memos and things like that. And it's kind of weird people are like, oh, it's free speech. And it's not. Companies are liable for their employees creating very hostile work environments. And whether you feel that way about that is a different story. But the Civil Rights Act of 1964 has been around for about 40 years now. And that has always been the winner. And that was why he was fired. Open Source does not have these kinds of legal protections or any financial incentives or anything like that. It really just comes down to us saying, hey, this is what we're going to have. We want to have an inclusive community. So having a code of conduct is important. And so we need to create that environment. It means having a code of conduct, enforcing the code of conduct, and also having a moderation team to do that if your project ever gets too loud or too big, I should say. Because if the core team is the one violating it and you don't have anyone to enforce it, and they're the ones who are supposed to enforce it, it ends up creating a weird kind of thing. So if your project ends up getting big, consider having a moderation team to do it. So there's a couple of different codes of conduct you can use. The contributors coveted is a free one that you can just download and use. You just say, hey, you had to put in your project name or hoot of contact, but that's about it. There's also Rust code of conduct, which will allow you to very easily, is a very good example, very full-featured. So the last thing in our create checklist is announcing your create. And there's a couple of different places you can announce it. The Rust community has this awesome new thing called herald.communia.rs that Florent Giltcher had worked on. And you can easily go to the site, say, hey, this is my new project. And then it gets dumped out onto Twitter, and people can see it. You can also announce it on your own Twitter and just tag Rustling. Steve Kladnik pretty much runs that. And he just retweets everything, or at least likes it. And there's also the user's forum as well as the Rust subreddit. If you haven't been to any of those areas, people often announce in there. You could also announce it outside of the community. There's hacker news in our programming are two good places to put it, but I say caution you. If you go there, it's not as warm and welcoming as Reddit, or at least the Rust community is. But if you do like that and you do want to put it out there, those are also great places to really get some good high visibility. So one of the things that a lot of people feel weird about is self-promotion. And I often do, too. But if you don't talk about your create, who's going to? If you don't tell people about it, they won't find it. So some things to be careful about, because perception is reality. A lot of times people say, oh, it's my first create, or I'm a total Rust new, but that's fine. You can be new. Those are not bad things. But if you're announcing a create, it's a difference between asking and saying, hey, I have a question. I'm new versus this is my new thing. I want to show it off. You have to be confident in order to kind of get people to be interested. And we may not like to admit it, but it's very easy to have biases and go, oh, well, they're new. They won't know it as well. So why should I use it? Just don't do that. But one of the other things is that it's very easy to have an undescriptive title. Like what if I just said, announcing fair says 1.0? That tells you nothing about what it does. So have a little bit extra in there that says, hey, this is the name of the project, and this is like a very brief description of what it does. Like something that would fit in like a Twitter tweet would be about a decent size. So if you have a library, be loud and proud about it. So there's a couple different ways you can announce your create. One of them is through a technical post. It's great because people learn something new. Your post helps grow the community because now people are talking about it, and now people go, oh, hey, oh, Russ is getting some traction, and then maybe you can convince your employers to use it because now more people are talking about it, right? Well, I think most of us here would want that to be a thing. And like most people, you will inevitably forget how you actually did the thing you talked about, and you can go back and look at it, and it's great because you wrote it all out. You can also do a demo. This here was a demo scene video that someone had done, and it was great. It was 52 kilobytes worth of code. It generated all the visuals without media, and it instantly showed everything about it, and it was way more impactful than if they had just written a blog post about it. So one of the other things that you can do is you can also make a bold claim. And there we go. Yeah, I love technical difficulties. It's great. You can make a bold claim and back it up with fax. Yeah. RIP grep is faster than grep AG, get grep UCG, PT, and SIFT. And I think pretty much all of us, when we saw that, was like, what? There's just no way. And Burt Sussie pretty much had all the data to back it up and was like, yeah, no, this did happen, and it's fast, and we all know that now. But it's a double-edged sword. If you do say something that is kind of ridiculous to most people, it can come back to bite you if you can't back it up with the right fax. But do you consider that if what you're doing is really, really cool? You can also make a slick website to show it off. Personally, I like Rocket in that sense, because it's like, hey, cool. Here's what it does. Here's the API, here's the docs, and it presents it in a nice format. So it's a kind of combination of documentation as well as a nice on-the-eye presentation. There's also another example is Exa. It was just a simple LS replacement. It's a tool. It tells you how you install it here. That's where it is. But hey, it tells you what it does. It's short, it's simple, it's to the point, and it looks nice. Now, choosing what fits best for your code kind of depends on what you're doing, right? Like you don't necessarily know if a technical post would be the right one or whatever. It all comes down to what you think is the best thing, and that is, at the end of the day, the important part. Choose what fits best for you. So Ferris has gone through all this. They've done it. It's pushthecrates.io. Actually, it is. You can actually go check it out right now if you wanted to, and it's great. It's all done. And before I close out, I did want to talk about one tool that I think is the most important tool that will help you in pretty much everything with shipping a crate, and that's empathy. Being able to look at the code and what you have as if you were someone else. Would you like the documentation? Would you like the API as it stands? Would you feel safe and welcoming while you're here? All of these things could be done if you peer through your project as if you were someone else. And the answer to some of those questions is no. Then you can go through and fix them. And empathy, I think, will be the easiest thing in order to figure out, hey, what do I need to change? What should I change about my stuff? Because your crate is a lot more than just the code. It's all the metadata, it's all the interactions, it's all the social things. Like, coding is a social thing. So if you have all that stuff that makes it easier for other people, your code will be successful. So, thank you. That was everything I have for today. So, all right.