Video: Dav Glass — Contributing to YUI

Video published 2009-10-29.

• Download iPhone/iPod-compatible video file (320x240, .m4v)
• Slides

Transcript:

Dav Glass: I'm Dav Glass, and I'm going to talk to you guys a little bit about everything I've done in the last year to help open up YUI to the public and get more contributions from everybody. I'm going to talk to you about a few things; I'm going to give you a status of where we're at now and what we're doing. I'm going to try to tell you why you would want to contribute to YUI, what you would contribute, how you would contribute it, and the next steps. What do you do after you want to start contributing something to YUI?

Last year at this time we were on SourceForge, so our releases were up there. You didn't get a whole lot of information, you just got 'hey look, there's a new blog post, there's a new version of YUI out.' That was pretty much it. You'd get this whole new slew of examples and nobody knew what was going on, nobody knew anything was coming along. We had no public source, you didn't know what we were working on from day to day, and we had very, very few public contributors.

In the last year our source was moved to GitHub so that everything we do is publicly available within minutes of us committing it in. You get to see exactly what we're working on, and you get to use exactly what we're working on to build your own things. We have daily builds. The full YUI 2 and 3 source is available online, and we also released four other items this year: YUI Doc, our build system, YUI PHP Loader, and YUI Compressor. Compressor's been around a couple of years, but its source was never around. Now everything we give is actually up and in the public so you see everything everyday. And we have a lot of public contributors now.

This is a little shot here from GitHub; if you've been to GitHub you might recognize it. This is the participation graph and it shows you the 52 weeks of the year and all of the commits that are done to it. Over the last year, this is YUI 2 and 3, when you put those together that makes a nice little bitty chart going across how many times we've actually committed and pushed code in front of developers.

I went through and did a bit of GitFu with the command line and I'm not going to show you that, but I do know that we did 1,170 builds for YUI 2 in 10 months. We did 1,994 commits with 27 committers. Out of those 27, 11 of them were non-YUI team members. That's cool. We had maybe one a year ago, and now we've got 11. For YUI 3: 1,315 builds, 3,000 commits, 20 contributors and out of those 20, 7 of those were non-YUI team members. That comes to a total of 2,580 times this year that we have put code in front of developers to allow them to start testing against it. They can start integrating with it and they can help us out and give us feedback on what we're doing right and what we're doing wrong. I mean face it, we're software, we do stuff wrong.

And they told us that. We released YUI 3 three or four times [preview releases and beta] and each time we got very, very good feedback from people digging into this source code and saying dude, this is not right, this should work this way. They gave us a valid reason to change it, and that's the key, that's the thing we're looking for. That comes down to an average of 7 times a day, so if you work 8 hours a day, every hour we're giving you something new to deal with, we're giving you something cool to start working on. Maybe it fixed a bug that you filed. You're like hey, look, my bug is fixed. I can go on, I can do whatever else I need to do because these guys fixed my code and they put it up there for me to start using.

Not only did we give our source out, we started giving out a whole lot more community things for people to start dealing with. We've got YUIlibrary.com. This was my pet project for the last year, everything we have on there. We have a new forum system — this had over 4,000 posts and I've only done 400 of those.

[laughter]

Dav: Only 400 of those 4,000 posts were from me, and that's huge. As far as I'm concerned, that is really, really huge.

The new bug tracking system. Let's face it, SourceForge sucked. I hated SourceForge ever since I laid eyes on it. Our new bug tracking system is completely integrated with our forums and it's also completely integrated with GitHub, so every time we commit and we push to GitHub, our tickets automatically get updated and they get bound to say: this commit belonged to this bug, and here's the SHA-1 hash that tells you exactly what line of code fixed this bug. And it happens within minutes, not days or weeks. Within minutes of somebody committing it in it's live and ready for you to see.

We also took control over the #YUI IRC Channel on Freenode. For the longest time we didn't own that, but we now own that channel and we have two or three members of our team actually sitting in that channel every day, helping people. Actually, one of them's right back here: Isaac. He and Luke are on that channel all the time, and they're constantly helping people out. And of course we're on Twitter; who isn't? Anybody who posts anything cool about the YUI library is there to actually tell you about it, so you can learn more about what everybody else is doing in the community. So we have been busy, and we ain't done yet.

The key is: why would you want to contribute to YUI? Do you want to do it for fame, fortune, profit? I don't think that's going to happen. The main thing is community. Community is the building block for an open source tool. You want to feel like you belong, so that if you contribute one line or one thing you own this project, this project becomes part of you. And you want to keep doing it again, you want to give more back, you want to help more. If you answer one question and somebody says hey, thanks, you want to do that again, and go to answer five or six more. People start to learn and trust you, and when it comes to things like gallery that's going to be really beneficial when they know who you are, because they know you know what you're talking about, they're going to want to use your stuff. And if they use your stuff and enough people like it, we'll use your stuff and we're going to like it. It's all about building something awesome, helping solve problems and fulfilling a need that nobody else did.

A couple of things I did when I was putting these slides together were to actually ask the community: why would you want to contribute to an open source software? Isaac came back with one of the best lines I have ever read. This is absolutely awesome. Then I threw this one in because I thought it was funny. I just had to put a couple of these in because these are really, really good things to tell people why they would want to contribute. I love that one. But Isaac's, I want a shirt that says that because that is awesome. By the way, I'm a 2XL in case anybody wants to ship one of those.

[laughter]

Dav: Most people think that contributing to an open source project is all about bug fixes, patches, and enhancements, but that's not it. Not everybody writes code, and not everybody writes really good, rock solid, needs to be run really fast code. Not everybody can do that, but you can make an example. If you've got some really cool way of doing something, why not make an example? Let everybody else see it. I'm the guy that you should be looking at for that: I've got 287 examples on my site. I've had to actually spend more money on hosting this year than I ever have, because I'm topping out my accounts when it comes to people searching for examples. That's what got me here. I'm on this team because these guys saw the 200 examples. When I joined YUI, I had more examples on my site than they had. They just beat me this year, they just topped 300, so I'm running a little behind because I've been doing everything else.

There's also API documentation. If you're looking for a method and you don't understand what it says, fix it. Tell us that you don't understand what this says, because when we're writing it, we're pigeon-holed. I wrote this code, I know what this method does, but I may forget that it affects four other things. You might know better. You might know that this method does something else, or it can be used for something a little different – why not tell us that? Let us know that this is too programmatic, that this chunk of documentation doesn't make any sense to you. Tell us exactly how you would change that.

Support is a huge thing, answering questions. If every person in this room answered one question this month about YUI, I'd take a vacation this weekend. I guarantee you, I would take a vacation. Like I said, just one question and somebody says 'thank you', you'll want to do it again.

Things like test cases and new modules. Not everything has to be about code. It can be just simply talking about it, or walking somebody through a problem, or finding that extra comma that they left off and say look, it's right here, now go keep doing what you were doing. So this is not all about code, and everything in the library is not code. We have a lot of CSS. YUI Doc's written in Python. Anybody know Python? I do. Somebody could submit a bug fix, or help us out with YUI Doc. The component build system is all built in Ant. If anybody knows Ant maybe they could give us a little bit of help with that. YUILibrary.com is all PHP and MySQL. If anybody wants to help, let me know; I've got 12,000 lines of code stuck in that thing that I work on every single day. You want to help me out? Fine, I have no problem with that. It's not all JavaScript, it's not all CSS, it's the whole package, it's the whole community that you want to contribute to, not just the library and not just code.

This is the big part: how? Of course I'm going to pimp GitHub. These guys are awesome, I know four of the main team members. They've just hired a couple in the last few weeks that I haven't met yet, but I will. We chose GitHub because it's awesome. That's my word for it: awesome. About a year and a half ago I started using Git, and I transferred everything I owned out of an old CVS repository I had, and started using Git.

This is the perfect definition of Git, and I don't care – this is my definition of Git. It's a distributed system, and when you clone a repository, you get a 100% clone, everything that was in that repository at a certain point in time. I'll rephrase that again: at a certain point in time, you've got to remember that. When you make a copy of it, it's going to copy it over here, and it's going to be everything that had ever happened in that repository, all the way up until the second you cloned it. The key, that I'm going to talk about later, is the fact that you have to remember to update, you have to remember to stay in sync because of the fact that they're separate.

But the thing that makes it awesome is... I was actually doing a lot of traveling over the summer and I wrote three modules on a plane and in the airport, and I made over 100 commits with no WiFi. For me, that's awesome. That's completely awesome. That fact that I can do this, and I can share it with you but not share it with the actual YUI repository, makes it even better. That's one of the reasons that we chose a distributed system: there's not one single source of verifiable truth except the YUI account, and that's our account. But if something were to happen to YUI, there are 100 clones — there could be 1,000 clones — of everything that we have ever done in the last four years, in that source tree, still sitting there on 100 different machines. How can you ask for a better community than that? You've got 100 different people with the exact same code, all the code, all the logging, all the messages, and everything that we have ever done in one space. So that is my input on Git.

The next thing I asked was what is GitHub? Like I said, to me it's just awesome, I absolutely love it. This is another one of those that I posted up on Twitter, and I asked people to tell me what they thought of GitHub. These are the responses that I got within a couple of minutes. The ironic two are the two up there, the one that said GitHub is like Facebook for source code, and the other one is a comment on my post in Facebook saying it's Facebook for coders. They were literally two minutes apart, and it was completely awesome that two different people posted the exact same thing.

I didn't want to get up here and give the big talk on GitHub because we've already done that: YUI Theater has the talk that the GitHub crew did when they were here, so if you want to know more about Git and GitHub that's what you want the talk about. What I'm going to talk about is how you use GitHub and YUI, and that's the big part. The things that I'm going to be talking about, I don't want to get too technical into it, because let's face it, it just looks like crap on the screen, and you don't like taking notes. So these URLs are the important ones. This top one is to Git FAQ — this is the FAQ I wrote over a year ago when we were planning on moving to GitHub, and it tells you everything you need to know about installing Git, getting it running on three or four different OSes, how to do a commit, and how to fork, and how to branch, and how to do all the stuff that you would need to know. Everything is there. The GitHub guys actually refer people there every now and then because it's twice as long as their guide on Git. The other one is the contributors page. Now most of what I'm going to be talking about through the rest of this is all on this contribution page. I'm just going to take the important bits and pieces out of this contribution page, and I'm going to tell you about them, and we're going to explain how all of this works.

Getting the source. There are two options when it comes to actually getting the source and doing something to help us. The first one is getting a public copy. Getting a public copy is just pulling down the source so you can use it for testing and for development, or for testing a bug fix. It's important to know that a public copy is read-only — even though you do have a clone of it and you can still commit to it if you want to, there's nothing binding it there to say that you're going to use it later. It's mainly meant for using bug filing, testing, and developing.

Say you have your development environment up and you're running the latest YUI from source, you'd want to pull in a public copy of this, and then every night have some script that pulls in the latest changes from YUI, and that's what you develop off of. You have the latest stuff every single day, and you always know it's up to date. You don't need it for anything else – you just need it to be sitting there as a read-only copy to develop off of. Or if you found a bug in a nightly release, you just want to submit the bug in, and you want to be able to keep track of it. You can use that for pulling down new changes and checking on it. It's not hard to do: you can go right to the GitHub website and hit download, and download an entire copy of the latest build that we put up in a couple of seconds. Or you can use Git to actually clone it down and then just update every night. Whichever one you want to do, it's fully available. That's the easiest thing to do if you just want to use it in your ongoing development, and keeping up to date, and being able to file bugs.

The second option is to actually fork the project, and this is where all the fun stuff comes in. A fork of a project will make it in the sense of writable. So it's not really writable, it's just in the sense of writable. It's the fact that you have someplace to put it because of how you forked it on GitHub, you can make changes and you can commit back to it and push it all back to [your fork on] GitHub. You can fix bugs at that point, because you have a place to put it and you have a place to push it. And you could add more tasks. Anything you wanted to add to it, you'd be able to do once you did the fork.

I'm going to explain forking a little bit. Again, this is the proper definition of forking, and it is just way too much for you all to read, so this is my version of what forking is. Forking on GitHub is just like branching on steroids – I mean, it doesn't take very long to do, but you get a fully working… it's like having your own source control system in your hand that's exactly the same one as we use. Completely identical to what I'm doing my work off of, every single day, is the exact same thing that you get on your machine. Then you can update it within seconds of me updating it, so if I update it you can pull in those changes, and you know exactly what I checked in this morning, and you know that you can get what Matt checked in, or what Luke checked in, or what anybody checked in. You'll get exactly what we checked in, you'll get all of our commits, you'll get all of our logs, and you can follow it step by step and know that this is exactly what's going on, and that you need to adjust your code in accordance to be able to deal with it.

To fork the project on GitHub, you go to GitHub.com/YUI. We're going to use YUI 3 as the example here. You're going to see this nice, pretty little box. Now, provided that you've created an account with GitHub, which is all of three fields and takes two seconds to do, you'll be able to see this nice little fork button. This fork button is what will take a snapshot of this project at this exact moment, and create an exact copy just for you so it's yours. Then I had to throw this in, because this is exactly what you'll see when you go to fork it. Once you do, it's going to take you to yours, and you'll note now that it says DavGlass/YUI3 at the top, and that is my copy of the YUI 3 project. I have my own personal URL to do all of my cloning with, so this is like having my own source control system in my hand that's all mine, but it's exactly like YUI's. It's 110%, exactly like the one that we use everyday, in my hand, and all I have to do is update it. It's that simple.

I'm going to stress really, really importantly, that you have to keep your source up to date if you want to do any kind of contributing back to us, because you saw those numbers at the beginning – we commit a lot and we push a lot, so if you're not keeping up with us, we can't merge your changes in. Because if you're a week behind us you just lost 1,000 commits, you have no idea where we're at. So you need to be up to date any time that you want to tell us you want to have code, or we're not going to be able to do it for you.

Like I said, this URL will explain everything you need to know about it. I didn't really want to get into a whole lot of technicality on it, because actually I did in the dry run and was told by a bunch of geeks that I was too geeky. [laughs] So I didn't want to jump into a whole bunch of technical stuff, because everything I'm talking about is available right there. If you just go there and read it, you'll be up and running and have your code going. And if you can't, you can contact me and I'll help you with it. I have no problem with that.

So now that you've got the source code, what do you do? Now that you've got this whole pristine project sitting in front of you, what are your next steps? We have a few general guidelines that if you really want to commit this code back to us, you need to sign and submit the CLA. I have a whole stack of them right here if anybody wants them, because you might want them toward the end of these slides, just a little hint.

I'm going to talk about test cases and use cases in a couple of seconds, but having a use case is something that you really need to make sure you have because if you don't know what you're writing this for, why are you doing it? If you can't tell me why your item is important, then it must not be that important, because you haven't come up with a valid reason to use it. If you have a valid reason to use then you'll have a use case.

Create a ticket. I'm going to say this five or six times in these next few slides: create a ticket. You need some form of record. If you're going to submit something to us, create a ticket in our system so that we see it. We will watch it, and because it has full commenting on it you can go in and keep commenting on it. You can post attachments to it: you can attach your use cases, you can attach test files, you can attach whatever you want to it. The important part is that's where the community part comes in, because if you create this ticket that's an enhancement and say hey, I want this, then cool — maybe five other people do too. You just found five other people to help you build this. You just found a developer that would say hey, yeah, that's cool; I'll be your sponsor. That's the big key. Then, like I said, test cases, and then examples.

I want to stress this bottom point: be open to suggestions. We're not one to hurt your feelings, but we might. Just so you know, you need to be open to people actually telling you that there are other ways to do it, because we're very, very particular about how we do things. I'm trying to say this as gently as possible without cussing, because I know this is going online and I have to really bite my tongue to keep from doing that. We don't want to be jerks about it, but you need to be open to suggestions because we do have a lot of experience in this. We've been doing this for four years and it went on even before that; most of the team have ten or eleven years experience in this stuff. We know what we want, and we know how it needs to get done, but we also are very, very good at thinking outside of that box. If you look at us and say: X, Y and Z does this, we'll come back and say it can also do A and B if you just flip that around a little, and you'll get five times the benefit out of it than you would have if you didn't do it. I just wanted to really, really stress that part, that we're not out to hurt feelings so don't take it personally, we're out to help. When I don't have any Mountain Dew I can be a little grumpy.

The next thing is, why the CLA? The CLA is our Contributor License Agreement, and this is a nice little shot of it exactly from our website. This URL is where you can get your information from, and like I said it's right here. Basically the CLA says that you wrote it, and you know you wrote it, so what you're telling us is that this is your stuff and you didn't cut and paste it from somebody else's website, you actually wrote this. That's really important to us.

Now, to talk about the use cases and test cases. This is something that is really, really important, and I've only got a couple of slides on it. You want to make sure you have a valid use case. Like I said, cover your bases. Know why you want something, because I can't guess what you're wanting this thing to do, so you have to tell me what you want it to do.

Then the other part is the test cases – those things are very, very important. I have literally enclosed 50 bugs this year from people giving me an invalid test case. They didn't know what they were testing when they were testing for it, so those are really, really important pieces when it comes to actually telling us that this makes this better. It's going to make this better for a reason, and you've got to give that reason because I can't read your mind, and the other developers can't read your mind, so you've got to tell us why. I'm really trying to stress that. You've got to tell us why, because just giving us one line saying 'I want to add this' doesn't tell me why you want to add that. The thing is, since our API Docs are written by the guys that wrote it, we may not have told you that there are two other methods to do that because you didn't know about it. Now that the developer knows that you wanted this, they can modify that documentation to say these methods do this. Or they can write an example to say look, if you're wanting to do this, here's how you do it.

That all goes to the fact that it's not all code and that you don't have to put one line of code into the library to contribute. For the first year that I was here at Yahoo!, I was huge in the YUI world, everybody knew who I was, but I didn't commit one line of code to that team until after I had been here for over a year. People just assumed that I was on the team because of answering questions and submitting examples. These are the same things, these are still examples. The whole world may not see those examples, but the whole world will benefit from the fact that you have taken the time to tell us that we've done something wrong, or that we could do something better. That's the whole key.

Now that you've got all the stuff, all your code changed, and everything ready to go, the next step is to talk about pull requests. Pull requests are a concept that GitHub came up with — they are 100% responsible for this pull request concept. The idea behind a pull request is so that we know what you want us to do with whatever you've done. You're going to tell us: at this point in time, I want you to take this code and put it here. That's extremely important. We need to know at that point in time, and we need to know what. That's what you do, you tell us about a pull request.

Now, for the first time – I have never told anybody this yet – do not go to GitHub to submit us a pull request. I'm going to make that clear: do not use the pull request system on GitHub. We built our own pull request system because the one on GitHub is made to be so easy that it was too easy for a team of 20 people. There are a lot of us, and there are a lot of components that we work on, so getting one random email saying 'I want you to pull this from here' doesn't do me any good when we have to figure out what you're trying to do and who you want to talk to, or which project you're trying to deal with.

What I did was I built my own. If you happen to go to YUILibrary.com/projects/yui3, this is the YUI 3 project page, and it contains our bug tracker, our project milestones, and everything we do. You'll note right over here in the navigation that we've got this nice little pull request button. If you click that pull request button, it's going to pull up this little form that's going to tell us that this is the GitHub user ID that you're using and that you have a CLA signed. What branch would you like me to get information from? You click that query button and I'm going to come back with this nice little list; these are all the items that are in your fork on GitHub under that branch. You can link to it, you can click on the commits and actually see what they are. When you click the radio button and click the submit pull request, we're going to pop up this little box, and it's going to tell you that this is the GitHub user ID, there's the branch, this is the commit I want you to know about, and it's going to let you pick a component that you think this belongs to. If you're giving me a patch for drag and drop, you can select drag and drop, and if you've got a CLA signed and you've selected drag and drop, I'm going to get a ticket within seconds of you pushing this button that's going to say 'here, I have all this wonderful code for you, take it.' You had your nice little list and I get a ticket.

At that point, I will determine whether it's valid, and I will make sure that I can merge all these changes in. Once I've merged all those changes in, I'm going to create a build, and I'm going to push it back to GitHub. Plain and simple, it is that easy. You just tell me what you want to give me, and if I validate it and say that yes, this definitely works because you had your use case and you had your test case to tell me that this is valid, I'm going to merge it in and put it back up on GitHub, and the rest of the world's going to see it within a couple of minutes after I'm done with it. Very simple. It takes all of two minutes to walk through this, click a couple of buttons and say here, I'm ready to go. I'm going to have a ticket and I'm going to see that ticket, because the way our ticket system works – because of George – is that every ticket that I don't look at shines right up on this big screen and tells me that I need to look at them, so I can't miss them.

Like I said, YUILibrary.com/contrib. I keep pimping that because you've got to read it. I think there are 13 or 14 headings on that page, and it just tells you everything you need to know about contributing to YUI.

I want to just recap a little bit on the ways to contribute. You've got examples and you've got new examples – not only that, but you've also got the ability to update current examples, so if one of our examples doesn't fit your need fully, change it. Tell us what we did wrong, or what else would make this example even better for the next person, and give it to us. We will absolutely be willing to put that in. I guarantee I can speak for every one of these team members – if you give me a new example, I will put it in there. See, I got thumbs up over there in the back. I guarantee it. That's one of the things that we really pride ourselves on, is our documentation. If you want to help us, give us some more documentation, help us out, help us with the API Docs.

Again, support — I'm going to tell you this over and over again. You can submit tickets, you can answer forum posts, and those are some of the biggest things. If you want to help us help everybody else, tell us what you want to change. We're going to read it, and we're going to do it; that's the nature of what we do, that's the nature of this open source system. Of course, writing tests and contributing new modules, those are the big parts. Again, I'm not going to go focusing on the new module part, because it's really, really difficult to get a new module into the full library. I don't want to say that is a bad thing, but we're very, very picky on putting something into the library that doesn't need to be there. Like I said, we'll only put what we think should be there.

That's where it comes to the point of the gallery. The gallery was a concept Eric came up with a long time ago, and we started widening this thing out a little over a month ago, and we announced it yesterday. As of yesterday there are well over nine or ten modules in there served from our CDN — that's the really important part because the whole tagline for our gallery is 'Your code on our CDN', and that's a huge thing. I mean, that is monstrous to have anything you write put up on our CDN, so that the entire world can use it. They can use our edge servers, they can use our caching, and they can use our speed. Quite frankly, if you don't have to serve it, why not serve it? Let us serve the thing. This is the nice little blurb that Eric wrote for me on what the gallery is.

The first thing I want to do is tell you a little bit around the rules. See, I blasted right past that because I hate reading stuff.

[laughter]

Eric: Go back!

Dav: See, I hate reading stuff. And you'll notice there's not a lot of graphics in here because I really don't like that either. I mean, I check my mail in [xx]. I don't like seeing pretty pictures.

Here are the main rules to get your YUI 3 code on our CDN. The gallery has whole other concept to that, but these are just the rules to get your code on our CDN. Sign a CLA. I've got a stack of them right here, I'm going to say that two or three times. Signing a CLA essential; you have to. We will not accept your pull request if you've not signed a CLA. The next step is that you've got to tell me you're going to give it away for free. You aren't going to make somebody pay for it, you're going to give this thing away for free because we give it away for free. Then the last thing is that it's got to be licensed under our BSD license. Those are the only rules that it takes to put your code on our CDN. There are a few nit and gritty things, like don't do evil stuff and things like that, but these are the big things: submit a CLA, give it away for free, and license it BSD.

So you want to know what the process is? The process is very, very simple, and we can prove that with him [Greg Hinch], because we announced it and less than two hours after announcing it, he had already posted an item to the gallery. Actually, I think Eric was sitting right behind him when he did it, so he was watching him actually submit it into the gallery. [laughs]

The first item is adding. This is my recommended way of getting something into the gallery if you want to go to gallery and you want to add your module now, or whatever you want. Because they're named, and there's only one name that you're going to give it — so if you want an accordion, there's only going to be one accordion. You'll have to get 'my accordion', or 'my super cool awesome accordion', or whatever you want to call it. If you've got something that you want to name personally, then name it, get it in there, because the other part is that the gallery will actually help you get your build files, fork the project, and get everything ready to actually put it back up on the gallery. If it knows that this thing is called 'fu', and it requires node and event, whenever you go to create it it's going to give you everything that you need to put this thing in the gallery. All of the files just cut, paste, copy, drop them in, run Ant and submit your code. That's it. It's really going to be simple to do.

The getting approved part is, of course, to cut down on spam. Whenever you submit a module into the gallery it has to be approved. It'll be within a couple of minutes because there's three or four of us that are going to watch it, and we're actually going to approve them pretty quickly. What we're just trying to do is make sure that you're not linking off to some site that we don't want you to put up there or whatever. That approval process is actually really simple to do. We may actually go in and fix some minor issues with the way that you've submitted it.

The other point of this approval process is that we're going to give every single module inside the gallery a forum attached to it. So you're going to get one of our YUILibrary.com forums directly attached to your module where you can talk to the people that are using your module and give them help, let them ask support questions, or let them give you feedback. Whatever you want. Every single one of them gets a forum, and that's the community part. Just trying to pimp that community part up. The more people that start talking in your forums, the more people that are going to start looking at your other components, and they may start using your other widgets and the other things that you decide to submit into the gallery.

Then if you haven't done it, you go fork it. You fork the YUI 3 Gallery project on GitHub; you sign up with the three fields, you click the one button, and you're done. That's forked. Then you just put your files in and you commit. I'm going to actually show you an example of this in the gallery in just a couple of seconds, but these are the really important parts.

After you've committed your code, that pull request process you guys saw a little while ago is exactly the same process you will go to in submitting a CDN request. You'll go to the gallery, you'll click a button, you'll say I want this commit in the CDN. Four clicks and you're done, it's in our queue. Then we will go through and validate it and do everything that we're supposed to do, which is one of the two images in this slide deck. Somebody told me I had to put images in, so this is one of the two. You've got to give us a little bit of time to check and make sure that whatever you're putting in there is exactly what you think it is. We're not going to run it, we're not going to test it to make sure it works. I don't care if it works — it's your problem if it doesn't work, because they're going to come back and post in your forum and tell you your code doesn't work. They're not going to come to me.

So you give us a little bit of time, and then once it's approved it'll be deployed to our CDN. What we're shooting for is around once a week, so we're shooting for around Tuesday or Wednesday we'll push them all out. You could theoretically put a module in on Monday and on Wednesday be using it on our CDN. Depending on how big the module is and how much approval it takes to actually go through the code that's in it – and I will tell you that larger modules will take a little longer, because it's a whole lot of code we have to read.To me, this is awesome. This is totally the most awesome thing that YUI has done to date, and it is absolutely more awesome than Captain James T. Kirk, and that's my second picture in these slides. I was told to put pictures, and I put pictures. That is more awesome than Captain James T. Kirk.

Now I'm going to actually show you how to use the gallery. This is the gallery. I walked in as a test user here. We've got featured modules that sit over here now. We are going to be going through this process several times to make sure we get it right, because like I said, I did it in a month and I think it works really well, but there are snags here and there that we're going to run into. We've got this set of featured modules, and we've got tags. Look, there's Luke, he's bigger than I am. He can actually say that.

Adding an item to the gallery is really easy: you click the add module button, and you give it a title. This is what everybody's going to know it by. 'This is my super module'. I'm just going to paste a bunch of crap in here so I don't have to do all this. So we've got a summary and a description for the module. The summary is what's actually going to show up when people search for it, or when they click on a small view of it, so it's important people see exactly what it is. If your module is one of the featured modules, this is the stuff that'll land on the homepage to let you know that this is what the module's all about. Then you've got a big description here that you can use Wiki text, so you can put images, and lists, and all kinds of cool stuff in there.

Here's the important part, the module meta-data. I'm going to pick a name for this module, and this is the name that's going to be used in my use statement. I'm going to call it 'my module', and then I'm going to tell it that this thing requires node, but it requires the focus manager specifically, of node. Then I'm going to say that optional is animation; I want the color animation to be optional, and it doesn't supercede anything.

The version of YUI that this thing is supposed to run on is 3.0.0. Now it's going to be up to you, as the module owner, when we release to go and test your module with the new release. Then you'll have to go back and manually update to make it work for 3.1, because I don't want to assume that what you're doing works in 3.1. You need to verify that your stuff works in the latest release, and then you'll go back and do a new update, and tell the world hey, this thing works in 3.1, I know it does.

Then you have to tell us whether it's going to be free or if it requires payment. You have to select your license. Now, here's the key with the gallery: you can put anything in the gallery that revolves around YUI 3. It has to have something to do with YUI 3, but it doesn't have to be BSD licensed. The only requirement for the BSD license is that that's the only way you're going to get it on our CDN. You can still use these modules to say hey look, I've got this super cool widget that costs you $5 to toss on your blog – I don't care, put it up there. As long as it's built in YUI 3, I don't care. But you're not putting it on my CDN, and that's the whole point of this.

You can pick any one of these licenses you want to license your software with, but we default it to the YUI BSD license because we want you to put it on our CDN, we want you to give it away under our license to make the community better and to gain the following. This thing is licensed under YUI's BSD, exactly the same thing the YUI Library is, so there's no problem dropping this into the page with YUI because it's the same license. People won't have to worry about whether this is GPL versus LPGL versus whatever the hell they want to license it as, because it's all the same.

Then there we can put in tags. Just simple tagging, and I think everybody knows how to do that. Then we allow you to link off from here, and we're actually going to prefill these with your GitHub stuff. One of the main reasons for using GitHub is that GitHub offers a lot of services that you get for free just by signing up. You get an issue tracker, you get a bug tracker, just by creating a project on GitHub. When you fork our project, you get an issue tracker along with that project, and you get a place to host your bugs. If somebody wants to file bugs against you, GitHub gives it to you for free just for forking the YUI 3 project and wanting to give us some of your code. Same goes for the home page and the source: you can point them directly to your page for the source and say look, this is where I keep my source. You get it for free with GitHub.

Now, with the API Docs, if anybody was in Stephen's talk, you can run YUI Doc against your stuff, and upload them to the free GitHub pages. They give you free static pages to host your stuff under your own name, so you've got a place to put it. We give you every single thing you need to put your API Docs, to put a home page up, to file bugs, to do everything you need to do to contribute to this open source system, and you get it all for free; we're not going to charge anything for it. The same thing goes for examples. You can actually host examples on your GitHub pages; just create a few examples and stick them up there.

Now we've got the code, and this is a really important part. This is a description that tells people what code we're got to show them when we show them your module, so it needs to be something that says 'this is how my module works'. I'm actually going to show a couple of them here in a second.

Then we've got the code snippet itself, and this is the code snippet you can put in. If you put your code in like I have here, which got auto-filled when you put in your module name, I went through and filled in all this information to help you out so you don't have to fill in all these fields every single time. It's just going to do it for you. The really cool part about this is you'll see this nice pretty syntax that gets done at the bottom, and we're going to use that later. This view is going to be shown in two or three different places, and I want to make sure that you see that it's really important that you get that right, because this is what the first person sees.

So I add this module, and the first thing that it does it takes me to this page, and this is the set up information for the module. Like I said, you go here first, this is the first thing you do. When you get it, it tells you that you need to fork the YUI 3 gallery project, and when you're done with it you need to get builder because we're going to use your build system to do it. It tells you how you clone it to get builder. It even tells you where to put it. It tells you what you need, it tells you what directories you have to make so you get into the gallery: you just cut and paste all that in every file you need to build this system, and it's going to be done.

I even give you the sample build files. There's the build XML file – it has your module name in it, and tells you what you're going to do. There's the build properties file, look at that – it tells you where the build is at, it gives you the name of the module, the name of your file. There's the requires statement that you guys filled in, and it even tells you that. It tells you that it doesn't supercede anything, but look – anim color is optional. Everything you need is put in this file, so you can just cut and paste them, and you can run a build, and you can commit it back up to GitHub. It even gives you a sample JavaScript file in case you want to start with that; you can just take this and put your code in the middle of it and start working from there. Then it tells you how to build. That's how easy it is to build with our module – once you put these files in place, you can just type 'add all' and you're done, it's going to build it. Then you can test it and make sure it works, follow the steps before, commit it, and submit a CDN request. It's that simple, that's all it takes, and I give you every single thing you need to do it right here.

At the moment I told you this thing is pending. Actually, it's not pending; somebody did it a little too early, the guy back here looking up in the corner. By default these things go up into pending so that nobody else sees them but you and us, and that way you can go in and modify a couple of things if you wanted to while it's still pending, but that gives us a chance to look over it. Once we do make it not pending, that's when this submit a CDN request button comes up. You'll notice here that this is everything that we saw: here are the examples, here are those links that we put in to link everything back. This works whether you put it on the CDN or you don't, this tells people how to get your code and how to work with it, all from this little page.

So when I submit a CDN request you're going to see it's exactly the same thing I showed you all a little while ago, it's going to go out and query everything that's off of my fork. I'm going to say OK, I don't have any branches, but I want to pick that one – that's the commit I actually want pushed to the CDN, that's one I know that works, and that's the one I want on the CDN. I'm going to submit the CDN request and tell them why and it's going to come back and actually show me how to check that out of Git, and how to see these files. These are exactly the commands that I need to run from inside my project to get this. So you can give this to somebody else and say here, test this out. If you want it before it goes on the CDN, here's how you check that code, because this is how we're going to check the code. We're going to pull it in exactly like this and we're going to look at it before we decide to submit it. It's going to tell you here… Well, it should have. I did submit it, didn't it?

Adam: I did it again.

[Dav laughs]

Audience member 2: Does it give you the history, then?

Dav: Yeah, you're able to go into the history. He's running ahead of me here. Adam denied my CDN request.

[laughter]

Dav: Yeah, so that's what the history log actually shows, that Adam approved a module while I was talking about it, then I submitted the CDN request and Adam denied it. So if I go through and do this again, I'll be able to pull in the CDN request. We won't accept it if you put that in, by the way. I look at my module here and see that the CDN request has been pending since now, and I can view the CDN request at any given time to see that it's still sitting here, and then whenever he goes to actually move it into the CDN queue, I'll actually be able to see it. It's in the CDN push queue now, and that's where it's going to sit while we overview it and make sure that it works, and then once he pushes it to the CDN — which he's not going to do now, so I don't have to worry about him doing it too early — it will just magically show up on the CDN.

I'm going to go here and look at my YQL example. You'll notice it has a nice little marker. It even tells you when something's on the CDN, so you know just by looking at it that something's on the CDN, and this is a featured item, it's something that we thought was really, really well done, and people need to look it. You click on here and see that this is the example of the real nice description being done. Some tags, everything is all filled out in here, and it even has its own forum.

Here's the really cool part: you'll see that that code that it put in before only had YUI with the parens in it, but what we do when we show it here is that we'll actually show you that this is exactly what you need to put on the page to make this work. This is 100% cut and paste. You cut and paste this in to a page, and it's just going to work. The example here, if I didn't open a tab… Here it is. That is my YQL example being pulled from our CDN, and it just works. We're talking all of a couple of minutes.

[applause]

Dav: There's a whole lot more to the gallery if you just want to browse around and take a look, start submitting stuff. Again, there are CLAs up here if anyone wants to fill one out. No pressure, by the way. I don't have a ball bat, they told me I couldn't bring one.

That's pretty much it.

Audience member 3: Dav, did you start [xx]?

Dav: No, actually I didn't. I probably should have. One of the points of going through this is that you see that there's this build tag. You'll notice that there was that date string in there that signifies a build. This was the build number that this thing went out for. So you'll see here that this thing was created at 10.32, and its last CDN push was at 10.26, and the last one that went was on the 27th. If I click on that it's actually going to show me everything I need to get that module at that time from the specific build tag. This is the exact version I want, and since I would keep a history of that, if you don't like what this one does, go back one CDN push and pull the last one that they put in. That way you don't have to worry about it changing out from under you.

At this point you can actually see that this is everything here, but we actually report back everything that our builder kicks out, so our build tool tells you everything that it did, it tells you every file that it copied, every place that it put it, and it also kicks out all the JSLint output to tell you everything right here that everything came up OK. That way you can go back and look at this and say hey, the source is valid, and it ran through JSLint, and I trust it a little bit more because JSLint throws up when somebody does really bad stuff.

So we're trying to make it easy for you to feel confident that this stuff is actually working. You know that the person took the time to actually build this thing so it passes JSLint, and it passes Compressor, and that goes a long way to tell you that something's good. Then you can actually go in by tag and see every module that was loaded, and if you want to load everything that was in this push, there's the entire config you need to put everything into that push. Then you can go through each one of them and say hey, there's the build output for that accordion, there's the build output for that YQL module. We give you everything.

You can also go back and see all the modules. We pushed one, one, three, six, and you can go back and click on every single one of them and get everything else out of it exactly the way you saw it before. So like I said, if you have something changing out from under you, you've got a history and you can see everything that goes on.

Yeah, I think that's it. That's what I've been doing for the last year. I hope you guys have fun with it, because I think you're going to.

[applause]

Questions, yes?

Audience member 4: It looks like you added a Git command statement of YUI, and it seems like YUI pending. [?]

Dav: Yeah, that was something I didn't actually get into this talk because again, people thought it was a little too geeky. The way Git works is that everything after the command… You say Git space something, and that actually resolves to something binary under the hood called Git dash something. So if you put an executable in your path called Git dash fu, you can actually type Git fu, and it will do whatever that application did.

I wrote one called Git dash YUI, and it's all written in Python. It's up on GitHub under my account, and what it does is add a bunch of shortcuts in for you being able to merge and grab forks and pull changes from other people with really, really short commands. It also actually has a one liner for doing everything that that build page did, to show you the build XML and the build properties file. You can just say: Git YUI create and whatever module name you want to do, and it does everything else for you so that you don't have to. The pending part is that I can say 'Git pending', and it will tell me what all CDN pushes are pending. And it has a number, so I can tell it to give me number 42, and it's going to do all those steps that it did before: it's going to branch, and it's going to copy it in, and it's going to merge it, and it's going to reset me right to that point, so now I can look at that module at that exact point, and those are the exact same commands that we're running under the hood when we do the build process to build this stuff in. It's a sugar layer on top of Git that I use all the time, but it's up on GitHub.

And actually JQuery wants to spawn it off with me to do two of them so that they can have the same functionality that we have, because they really, really dig it.