 All right. So welcome, everyone. This is a session about Drupal.org, obviously, about how it is changing and how it has been changing over the past few months. And we really have three very, very different topics to cover. So Josh and I will go through all of us really quickly, and then Ryan will talk about Composer, because that's what everyone here for, right? Okay. Is here anyone who cares about content? Thank you. You are my favorite people. So I will give a very brief overview of the content-related changes, which are all part of sort of the larger content restructure initiative we have going on on the website. Firstly to give you some background, last year we developed the overall content strategy for Drupal.org, which sort of includes recommendations on a number of new content types and also on better ways to structure content on the site. So for more information, I won't talk much about that, but you can go follow those links. The first one is my session at DrupalCon Barcelona. We also had the same session at DrupalCon Los Angeles, and the second link is issue which has like 20 child issues with all the details you will ever want to know. So this year we are focusing on implementing those recommendations, which came out of last year's project. So essentially what we are doing, we are restructuring all of the content on this huge website into a new structure, into new groupings called sections, they are based on different types of user activity happening. And behind the scenes, those sections are actually organic groups, which gives us various perks, such as flexibility to have different user roles and different permissions in different sections. For example, some sections could be more editorial content, so only specific people can be able to edit it, and no one else can. Also we'll be able to display a single piece of content in multiple sections if we want to, and perhaps we might even use different themes for sections, which sounds crazy. So at first we wanted to test our assumptions and ideas on some place, which is less visible and has very little traffic, so no one could see it. And so the first section created was about Drupal.org itself, it is sort of a meta information about the website, various guides, and it primarily is aimed at people who develop Drupal.org or contribute to Drupal.org in some way. And the content is mostly produced by our internal team. So that section worked pretty well. And then the next one, and the first sort of highly visible one, we created was about, which is general information about Drupal and also various promotional materials. So to create this section, we actually audited all the content in the old about Drupal area, which used like book content type previously. We rewrote most of it, and we recreated it using the new content types we now have. The third section created was Drupal 8, and this one was created from scratch specifically for Drupal 8 launch last November, which was a fun few weeks. All the content was written from scratch by our communications team with a lot of help, review and feedback from core people, core committers. And for this section, we went one step further. Not only it has a unique content, it is also designed to look completely different from anything else on the website. So to make this happen, we actually created a separate theme, which is only used in this particular area of the site. Again, this is something organic groups let us do fairly easily, maybe. Yes, no problem. So another thing we did in the last few months, we introduced a new way of communicating information on Drupal.org. Right now, we have topical blocks in some of those top-level sections I was talking about. For example, this is a Drupal blog. It is located inside of about section. And we will see more and more of those coming up in the future. Around the same time, we also introduced possibility to follow individual pieces of content. For example, you can follow a post in a blog and you will receive email notifications for all the new comments. And this is also possible for forum topics, case studies, and book pages, I think. In the future, we also plan to add ability to follow the blog itself. So you will receive notifications not only for comments, but for the actual new posts where email or where your dashboard, which will be really cool. Along with those content changes, we will be also introducing visual changes on the site. And all of them are part of the new design system for the site we are developing right now. You already can see some of them in the header area, in the Drupal 8 area. And more of them will be coming soon. And by the way, I have those links at the bottom, many slides. Each of them is like a very long blog post about this topic. So if you want to know more, you can always read more, because we write a lot about what we do. So speaking of features which are coming soon, the next big thing we are working on is a major redesign and improvement of documentation. In fact, we have a whole session about documentation in this very room at 3.45. So if you want to know everything about documentation ever, you should come. And with that, I will let Josh talk about issue credits. All right. It's also going to be a workout. The good news is I can talk loud enough that the microphone could probably pick it up. All right, there we go. So we're going to talk a bit about issue credits at the marketplace as well. I feel like Tatiana is messing with me, because I didn't have to slide in here. I have to click there. Okay. All right. So to start off with, I've gone into a lot of detail to explain a lot of this in a blog post that we did earlier this year. It's the guide to issue credits and the Drupal.org marketplace. How we capture those issue credits is kind of an interesting process. If we go back and talk about how it all started, it was a conversation that Dries kind of opened up. And I can actually remember sitting with him around a table at DrupalCon Austin, and he was talking about this idea of doing commit credits and how we could do a better job of tying commit credits back to organizations that are contributing to Drupal. And if you saw the Amsterdam keynote later that year, he talked a little bit about this idea of the commons, the common good that comes out of a public project, an open source project like Drupal, and how if we can figure out a way to get people engaged with the idea that giving back to it is of actual benefit, then we're going to get greater participation by a wider range of companies. And I really wish I'd actually kept the napkin that we were playing with when kind of drawing out what some of this stuff would look like because it was a great initial conversation. And initially it was going to be something really simple like, here's the shorthand for it. That started falling apart whenever we started looking at, well, how do you save that shorthand into the database? Because if one person says that they work for the Drupal association and another person says they work for the DA, they mean the same thing, but they're using two different words. Or maybe just adding Inc or LLC to the end of a company name actually makes the idea of doing it based on text formatting and parsing kind of fall apart. And we don't really want to push people to this idea that they have to know short names or that they have to have a special number that they contribute to organizations. We're like, we can probably figure this out with software. It's kind of what we do. So we basically started with this simpler idea before we released the full issue credit concept. And that was, well, what if just every project could say, here are the organizations that are supporting this module theme, whatever it may be. So we added a very simple field there. If you are a business owner and you're actively contributing to a module and you have a maintainer on a module, you should absolutely ask them to put a little information about the organization and how that organization is contributing back. It's usually time for their developers. It might be money related to contractors. There's a lot of different ways that organizations can actually make a module more successful by giving it some resources to make sure that it has the time for support and maintenance and ongoing improvements. The next step after that was, OK, where do we do, and by the way, shout out to the Bear King. Brendan, he's on my team, we call him the Bear King. There's a story behind it, but I'm not going to go into it. So we said, OK, well, if we really want people to track how they're contributing, the best way to do it is to put it at the point closest to contribution. So in the case of issue credits, what it really comes down to is when you're contributing in the issue queue, there's a comment. Maybe you're uploading a file, maybe you're posting a review, maybe you're submitting a patch. All of these things are at the point of contribution, and we added this very simple interface that basically says, hey, you can attribute this contribution as a user to an organization. Now I will say, in order for you to associate it to that organization, you're going to have to take the step of creating an organization profile. So if your company doesn't already have an organization profile you want to contribute, then you need to create one. There's some spam prevention measures in place that require someone creating an organization profile to have been confirmed, which is one of the tools we use in our community to basically highlight people that are real humans and that are doing something that's helpful for the community. So if you post to an issue queue, it's your first time doing it. It's something helpful, likely someone who's been around for a while is going to come in, hit the confirm button, and then you would be able to add an organization page or case study or some of these other content types that we have some little gates on. After that attribution has occurred, the kind of next step falls to the maintainer, and this is basically at the bottom of any given issue. There's this little widget that lets you see who's participated in that issue and how they've participated. Maybe they've uploaded a bunch of files, maybe they've made a lot of comments. The maintainer of that project can look at that issue and say, this was valuable contribution. This person deserves credit, and they basically check a box. It remembers that they checked the box. So at any point that they're participating in it, they can save a little bit more metadata. And they keep working along in that issue until the point that it closes. And at the point that it closes, it tallies as a credit in a couple different places. So the steps, again, if you're going to do this, you have to start with the create an organization profile. To do that, you just go to the marketplace. There's a nice little add your listing button there. Click on that. You're able to go through that process. The users, if they want to be able to add an employer that's just kind of always there in their little form, they need to add that organization to their profile. And to do that, it's just part of opening up your personal user profile, going to your current work, adding a reference to the company that you work for. Right now, we're doing an exact text match is what causes that to appear. Eventually, that's going to shift to organic groups as well. So there can be a little bit more maintenance and management by the organization owner as to who actually belongs to the organization. We do occasionally get requests to remove somebody who's moved on to another organization or who no longer works for that organization. I should also add one of the cool things with this process. It doesn't have to be a company. One of the biggest non-company contributors is the Drupal Ukraine community. Tatiana's giving a shout out there. They created an organization to denote the work that they were doing that they felt was for their community. So it's kind of a cool way to do it. I would also encourage if you're helping to organize a Drupal camp, have them create a Drupal camp organization and attribute that as your customer or as the organization you belong to as a part of the issue queues whenever you're working at that camp. And we can start seeing the kind of growth of contribution in that particular location. It'd be a powerful way to use issue credit. So if somebody has a camp, I highly recommend you do it. If you're in the contribution sprints this Friday, attribute the credits to the Drupal Association. Say, hey, this is related to DrupalCon, that sort of thing. As a customer, not as an employee. That'd be weird. I'd have to remove a whole bunch of you as employees and I don't want to deal with that. So again, the credits are awarded by the maintainers. So that's one of our fail safes in this. It's really hard to game the system. I've seen it happen once in one year. And that person did it accidentally. They were actually legitimately wanting to participate, but they were just doing it the wrong way. It's a very successful system so far without a lot of abuse. We only display the last 90 days of issue credits on an org profile or on the marketplace listing or even on an individual's profile. And we have a reason for that. Participation is ephemeral. It has a shelf life. If we only did total credits, then the really big organizations who can throw a lot of money at it would just stay at the top at all times. And so by making it a 90-day swing, what we've actually seen is some of these really powerful stories of, like say, Fauci, which I mentioned in the keynote introduction this morning, who once they found out about it, they started truly contributing back to Drupal.org, making sure that their staff knew how to do it. And they rose from obscurity in the organization pages alphabetized at the time, letter F doesn't get you very far in a community as big as ours. They're all the way up to number four. I could say the same thing about Value Bound, which is another organization that's done some amazing work in getting their people to actively say, hey, this is who I'm working for. Those are both relatively large companies. I've also seen companies that just have an incredible spirit of contribution, like say, MD systems. MD systems is currently number one. They're a head of Acquia, even though they are, frankly, one, I think they're like 0.5% the size of Acquia. I mean, the scale of their contribution is phenomenal. They're just always on top of it. They also have Berter, who frankly is a machine, I think. Not literally, I've met him. He's a nice guy, but I think he might be cyborg. So those last 90 days, it gives that ability for people to move up and down in scale to show up in the top 50 organizations that are contributing back. We've never done a listing of users by issue credits that we do have this data and I do occasionally pull it and put out thank yous to people who are doing a particular high amount of contribution back. That we never really wanted to create the grand leader board. Though I have been tempted with the 90 day concept because it would pop around and people would go up and down and you'd be able to see like, hey, they had a lot of time to contribute back or they had an awesome customer who let them do a whole lot of extra work that they got contributed back. They'd be kind of interesting to see that stuff, but I understand some of the hesitations there. Lots of, oops, again, lots of really fascinating ways to do that contribution. I mentioned the last 90 days. One of the things, I would love a little bit of UI help in this particular area because I don't feel like we've quite got this nailed down to what it needs to look like to really highlight organizations quite the right way. But what you see is how many issues they've contributed in the last four months. You see the projects that it was contributed to. You see the issue count. Dries was just telling a great story in the board meeting a few minutes ago about how there was a company in India that came up to him and said, hey, we really want to contribute more, can you teach us how? And he was like, well, why are you wanting to get involved? And he goes, well, the reality is we just lost a couple of projects to companies that have these contribution profiles where they've got all this credit on their profile and they're getting the business and we're not because they're able to show they know Drupal. And I thought that, wow, that's really fascinating and it's within a year of releasing this we're already beginning to see it kind of impact how companies are able to sell themselves as being Drupal experts. And so this is kind of a powerful way of doing it. I think this is also really important to that kind of Drupal resume sort of thing. GitHub may have your current streak, not the most healthy way to measure your contribution stats sometimes, but GitHub has current streak. We have the, hey, these people really know this stuff. Look at the types of projects that they've contributed to, which is really powerful. For those of you who haven't seen it, this is what the marketplace looks like right now. It's ordered first by issue credits, second by, first by issue credits, second by whether or not they're a supporting partner of the organization and what level that is. So if you're giving money back to basically fund Drupal.org, it's not giving money to the DA so we can go have fun. It's literally empowering us to do things like build tools for collaboration and contribution. It's giving us the ability to do things like release the composer endpoints that Ryan's about to talk about. These supporting partner sponsorship programs are really key because as a nonprofit, we actually don't make any money off of building these tools. So without a business model behind it, we're encouraging contribution to help strengthen the community and through that we get the benefit of being able to do it more and that's pretty awesome. So help us by giving feedback. There's a couple of issues out there right now about different ways of contributing. I would love to hear more from people about things that they see that are key ways of doing it. We're going to do some updates to the organization content type and I actually have an issue out there right now that's going to remove some of the roadblocks to getting listed. It's one of those processes where right now there's a community review process as to whether or not you show up in the list at all. I actually believe we should remove that because if you haven't done any contributions and you're relegated to alphabetical, you fall on, frankly, the third or fourth page of the marketplace right now. So there's no reason for us to prevent people from showing up on page four. I think there's some questions we can ask about organizations that will help us better identify customers, people who are actually using Drupal for their business rather than selling Drupal services as a business, which is what we're primarily good at right now. And I also think it will give us a way to better track volunteer organizations such as the Drupal Ukraine community or, for example, a Drupal camp or a local user group. I would love to be able to track more about how those particular organizations contribute and give back and what they do. So please help us on those issues. If you search the Drupal org queue on Drupal.org, it'll give you an opportunity to weigh in and provide feedback. So that is it. And now we're going to talk about the composer Fakade. The Fakade. It's facade. Sorry, I just realized that it's missing the little curl under the sea, which is really hard to type into Google Docs. Like everywhere else, it's a lot easier to hold down a key. What buttons is the magic one? All right. I'm just going to start with a real high level overview of composer. Just in case not everybody in the room is familiar with it. So composer is a tool for dependency management, PHP. It allows you to declared libraries your project depends on and it will manage and install and update them for you. And how we want to use it, how it helps Drupal, is it'll allow core, core is using it now to pull in libraries from packages and other things. It let us get off the island in ways that we didn't have to invent every single piece of code that Drupal is going to be dependent upon. And soon it'll allow contrib developers to also use those non-Drupal libraries in their modules. And the facade allows us to have site construction using Drupal modules and themes that are proudly invented here. So that's kind of it in a nutshell. So the composer facade, what is it? It's an officially supported service from the Drupal network infrastructure that provides the metadata the composer can use to declare dependencies on Drupal modules and themes. So it's essentially serving as a replacement for a community built tool that's packages.drupalcomposer.org. How many of you are familiar with that? Using, okay great, we've got a lot of folks in here who know that. They were all just waiting for you. Does the transitions work this way too? Okay cool. So just another real high level of how the ecosystem sort of works. You've got a composer repository which the default is packages.org or if you're using Drupal Composer or packages.drupalcomposer.org. And then you've got code somewhere else like GitHub or Bitbucket. Normally a developer posts new code and it triggers a hook to go update all the metadata on packages.org so that the information about which version it is and what its dependencies are located on packages. And then from the command line a user is able to say I want to require, say, Guzzle, HTTP as a library into my project. They can say composer require Guzzle. Composer is going to connect to that packages repository, download all the metadata for Guzzle, parse it apart, figure out what its dependencies are and figure out what else Guzzle needs. And along with everything else in your project figure, determine what it needs to download then it'll go and get all the different components that it needs from GitHub or Bitbucket or wherever else they're stored, whether it's a Git checkout or a tar ball. And so the Composer facade that Drupal.org is supporting is essentially the same thing except we've got our Drupal.org project database and our Git repos since everything's stored on Drupal.org and it's going to act as the metadata repository for all of the Drupal projects and modules and themes. And so, of course, you add new commits. It updates the facade. You want to add, say, the token module to your project. You say composer require Drupal token. And then the Composer command line interface is going to hit the Composer facade, get all the metadata and download stuff from Drupal.org. So it works essentially the same way and if you're using all of this, we'll be part of how it would work in the future. It'll be pulling stuff from packages. It'll be pulling stuff from our facade to build your entire site. So this is kind of my favorite side. Like why did we do this? Why did we build this? Why didn't we just use packages? Why didn't, you know, there's a lot of questions surrounding that. And so one of the main ones is, you know, there's a big difference in the data model between packages which have a one-to-one relationship between I need this package and it's in this Git repository. And so a package and a Git repository are essentially the same thing and you depend upon that package. But Drupal has projects and it has modules inside of those projects. Sometimes the modules and the projects are the same thing like, say, the rules module. You have the rules project and the rules module inside of it and it's equivalent. Sometimes you have things like the features extra module which there's no features extra module. It's just a project but within it there are separate sub modules that are not named the same way. So in order to support these sub modules and have dependencies on these sub modules if you only need one part of a module we needed to find a way to translate our data model into something that mapped one-to-one with what packages would do. So we also wanted to have comprehensive support for all D7 and D8 modules out of the gate. So there was some talk of, well, we can organically move it forward but that requires everyone to submit their own Composer JSON and it would require packages to come and parse that and it would be kind of a slow process before modules would be available. And we were like, well, we have all the metadata that we need without the Composer JSON so we can do this on our side without requiring a slow process. We can have it out of the gates. Another issue that we were facing is the one of semantic versioning. Contrib doesn't have semantic versioning right now but Composer really needs semantic versioning. It's a valuable way that you can have a dependency on a module and updates can happen to that module and you know that if it's a patch level release it probably should not break any APIs and you should be able to just upgrade to it to get your security releases or get bug fixes and if there's new APIs you should be able to depend on those. And our version mapping didn't map very cleanly to what Composer wanted because we have our human readable versions because we have different platforms. We've got 7, we've got Drupal 8 and it's really useful for us to say, well, this is the 7x module or this is the 8x module but it has the same 2.0 branch and they have our feature complete between the two things but that didn't map very well to Composer's concept of here's a package and it does this thing with the platform you're working on. Additionally, there's usage data that takes place. Whenever someone uses Composer it updates the endpoint and says, ham, downloading this and so we use that usage data whenever people download modules whenever there's update stats all of that feeds into what are the top 40 modules? What are the modules that are important? What are the modules that we need to make sure get upgraded to Drupal 9 and we don't want to lose access to any of that usage data we wanted that to keep coming back to Drupal.org. Finally, additionally, project discovery. We didn't want there to be multiple places for people to find where to find modules go to packages and look for Drupal modules go to Drupal.org and look for Drupal modules and the information might get out of sync. We wanted it all to be in one place on Drupal.org itself. Additionally, we have a distributed infrastructure. We're talking to someone recently about they were using the packages DrupalComposer.org and also packages and those only exist in one place globally right now and people in Asia have a real hard time with the latency of trying to resolve all their dependencies because it adds an extra 500 milliseconds and there's a lot of HTTP requests that take place and so this allowed us to build this and put it behind our fast CDN gates because we already had the infrastructure in place for the CDN and so it's already distributed and I've already heard reports from some people that it's like it sped them up considerably. All right, so speaking of versions this is just kind of a map of how we decided to map our current versions to the existing versions and it's relatively simple. For the ComposerJSON files and then the metadata we're just dropping our notion of platform and we're adding an additional zero in for a patch level thing. So a 7.34 beta 2 becomes 3.4.0 and what this will allow us to do is we'll be able to add an additional patch level version to contrib without having to remove the 7.x on Drupal.org we can still have the human readable notion of like well this is a 7 module, this is an 8 module but the machine readable version fits with pure semantic versioning. So one thing that we have to kind of note is that Drupal historically is supported unstable as a type of not quite ready release and the rest of the world supports alpha, beta, RC and full releases and so unstable and alpha are essentially the same thing so we're kind of wanting to deprecate unstable as a type of release. Ah, yes, that's coming right here. So how to use our endpoint? So we've got full documentation on Drupal.org at that link and if you want to add this to your composer JSON it's packages.drupal.org slash 8 and packages.drupal.org slash 7 and we're offering two separate endpoints so that the semantic versioning works so that there isn't any confusion between your modules like which one is it trying to download. It's actually getting the metadata for either the Drupal 8 module version or the Drupal 7 module version. And this is just what the JSON looks like inside. It's a new composer repository it'll try that one first and then if it can't find it it'll go to packages. There it is. So using our endpoint from composer once you have that in your project you should be able to say a composer require a Drupal in the module name and then the version constraint that you need for that module if you want to lock it down to whatever versions and that should add Drupal modules to your project. Additionally we've implemented a couple of features oh wait, I'm sorry there's a couple of other composer features that are also supported like if you do a composer search it's going to hit our search API and hit our solar servers and then it's going to go to all of the other stuff that composer can understand and then composer browse works as well so if you're just like I want to go straight to the project page you can just type composer browse Drupal slash token. I remember one of the things I'd like to point out is like when you're doing a composer require Drupal slash module name that could be the project name or it could be the sub module which is called the API module which is a mutual credit API the project is called mutual underscore credit but you can require either of those and it's a and composer it's a meta package so it basically says oh this is a sub module we're going to go up one level higher and download the full package because again this is that translation between our we have a Git repository that holds multiple modules but you might only want to express dependencies so I'm not sure what best practices are just going to reveal whether or not it's better to try and say composer require Drupal slash project name or whether it's going to end up being better to say composer require Drupal slash individual module name that'll probably be more like they're both supported but we'll find out whether one or the other is probably better so if you're a project maintainer and you want to add a requirement on another module my project requires token I need at least the 1.0 version of token for Drupal 8 and so this is what you would add to your composer JSON in your module one thing to note is you will need to have this here but you also want to still express your dependencies in the info.yaml file because core is still going to look at info.yaml to see what's your dependencies and what's your dependency constraints and so you probably want to have these match now the composer facade is actually going to look at the composer JSON and whether or not you have and what you have in your info file and it's going to join that information together and it's going to for the requires it's going to use what's in the info file because since Drupal needs that it's going to default to that but for all other data fields it's going to default to what's in the composer JSON so if you've got projects on packages DrupalComposer.org you should be able to just drop the major version requirements that either the 8 or the 7 and then add a 0 at the end of those version numbers so if you had 8.1.0 it becomes 1.0.0 and then you want to change the URL to hours instead of the packages DrupalComposer so what's missing what's next what else do we need to make this just fully supported to make it a really nice clean thing we want a subtree split of DrupalCore because there's core well there's Drupal the project but then there's core which is the code base and often times you don't want the same front controller you don't want to use the HT access you're on engine X and you don't need all the stuff that it comes with so you want to use just the core of Drupal and maybe you have a project that's not even going to be running Drupal but you just want to have access to a whole lot of the Drupal libraries so you can include DrupalCore so we want to get a subtree split of that going and additionally want to have a subtree split of the Drupal components so there's several components in the in Drupal 8 that have a ComposerJSON associated with them that you should be able to use completely independently from Drupal and a good example of that is in DrupalCI we're using the plugin architecture from Drupal 8 and right now we can't pull in that plugin architecture we're literally copying and pasting it every once in a while to get that into our project and so we're you know, we want to use it on DrupalCI we like to add distributions and install profiles as a thing to support so that you can say Composer require an install profile as a baseline to start with a lot of essentially a distribution works like a meta package in that sort of that sort of realm but we don't have that baked in yet patches right now there isn't a real good way to add patches to Composer they're not out of the box there's a module that Cameron a Drupal community member has written that allows you to add patches to make Composer work a little bit more like Drushmake that's I think that's built into Webflow, Florian's Drupal project scaffold setup we want to switch DrupalCI over to using Composer for its dependency management right now DrupalCI has a problem that we're running off of project dependencies and project dependency is having a hard time figuring out dev versions and whether or not there's specific versions so especially right now in the Drupal release cycle when people are working on contrib modules and well my contrib module depends on the alpha version of token or a dev version of token it's hard for people to test specific and exact versions and so we want to switch DrupalCI over to using Composer to figure out which dependencies it needs to download and and that would you know as soon as we have that it'll make it a lot easier for people to test exactly what they want. There are still some version issues in some Composer JSONs Path Auto is one that comes to mind where they have put dependencies on other modules in their Composer JSON using the packages.drupalcomposer.org versioning scheme so there's like dependencies on 8.1. So we should open a few issues if we see Composer JSONs that have that I can probably just automatically do that or something but we'll want to migrate those over to using the official one versioning. There's still some complications when using dev versions because the Composer facade does not provide a dist tarball for the dev versions because we don't have a tarball. So if you're using prefer dist then you want to download all the tarballs unless it's a dev version then you want to get a clone of it and lock it at that hash. That way your Composer lock file actually has well I had that dev version that dev version works and it doesn't become a moving target. So we removed dist from the file and so there is a there is a I meant to put this in the slide. Florian has something called Composer Deploy that works kind of like Git Deploy does and it pulls information out of the metadata that we're providing to which dev version you've downloaded so it can be added to the info file. So that's another thing. Does anybody have any questions on everything I've talked about so far? Oh, oh, sorry. It's totally changed where and how does that like stay the same, contrast or stuff that other types of games? It's sort of a limitation of the way Composer works. There's installers that are plugins to Composer itself and so when we provide the metadata we say this is a Drupal module and it'll put it in the I believe it sites all modules directory but there's I don't that's something that still needs to be solved is to figure out how to like say you had a multi site and you wanted it to go to different places that's still sort of an issue of like no it does not, it won't put in the vendor folder it knows it's a Drupal module and it'll put in the Drupal module location. And you can specify in your Composer JSON where things go as well. It the namespace was locked down so nobody else can add anything to it and there wasn't a whole lot of modules I mean, yeah, we should go and make sure it gets cleaned up so that people don't end up with the wrong version, you know, but it seems like a lot of those are like the Drupal console is on there and Drush is on there but those also kind of kind of fall outside of the realm of modules and themes as well, so but yeah, we can definitely look on packages to make sure it's not too polluted with multiple versions of the same thing Yeah, I think I'm not sure I understand I'm not sure I understand Yeah, full projects are listed in there and depending on which version constraints you put on there it depends on which version you'll get of it No, it won't do sandboxes right now Thanks Yeah Do you want to start with that? I'll start with it Yeah, yeah Yeah Absolutely I've actually been doing a lot of research on this. I consider the first two years of having a dedicated technical team for Drupal.org that are paid staff working on it full time as kind of a lesson in fire hose discovery and pointing a fire hose at you and just flooding you with lots and lots of information Early early on when I came on and started building up the team I was getting a lot of when are you going to move to GitHub? When is that going to happen? To give a bit of context the great Git migration where we moved off of Subversion that was a two year project It took I don't know why I said Subversion Sorry The The examples I can't give an example with Subversion WordPress is still on Subversion They take pull requests from GitHub but they run their own Subversion infrastructure because migrating off of it would be a huge endeavor The Linux Foundation still uses Git and a patch based workflow with CLI tools and email They use patches and they email them back and forth to each other Really big projects, it's difficult to do one of these migrations That's not to say it shouldn't be done In fact, I really do believe that there are GitHub integrations we should do But as Dries mentioned the other day whenever it came up in the keynote question to him it would mean having to refactor quite a few things like issue credits Everything I showed you in issue credits requires that we're using comments on issues in order for us to even provide that information about the community Could we come up with some sort of deal with GitHub where we can build in some sort of integration and do some automatic things? Maybe That's definitely some stuff to look at but those are big projects That great Git migration off of CVS to Did you like how I reiterated that? To your project, you're talking about a year of discussion a good six months of a few people moving it forward a little bit and then a good solid six months of let's throw some contractor time at this and get it over the finish line That typical two year project for the community has always been the norm Something like Composer Frankly, it would have taken that long for us to deploy a Composer endpoint if we had done it the old way Having dedicated people working full time on it and having them interact with core maintainers and with key contrib maintainers that are already in that space was helpful GitHub is infinitesimally bigger It would replace about four services out of 20 or so collaboration services that we use Those four services though have 16 integration points that would have to be refactored 12 of them would absolutely be critical to kind of how we do our workflow So it's not a thing to take on lightly even though we'd love to do it and I think what we'll probably end up doing honestly is we'll end up coming with some sort of contrib interaction where you can more easily clone your contrib-based GitHub project and you can pull it into the Drupal.org repository so that we can have all the project browsing and Composer facade and everything else I think there's something there that's a nice middle ground compromise And then Ryan also has done some great presentations on the possibility of taking the way we do core and even some of the bigger contrib projects and moving it to like a more pull request-like workflow that matched the Drupal community a little bit more And those are some great ideas that I think we should still continue to explore But the race isn't over yet GitHub's big, I want their contributors I absolutely because of JavaScript and everything else I think it's going to be necessary but we're going to have to figure out a way to do it while still retaining some of what makes Drupal Drupal Absolutely Actually an interesting workaround from a training perspective that I think would be interesting for some mentors to do is when they're teaching people how to create patches Most people don't know this but for every pull request you create on GitHub there's a special hidden URL where you just add dot patch to it and you've got your patch file just upload that to Drupal.org and you've just fixed the process of them understanding how to create it There's some workarounds we can do in the meantime and I know they're workarounds and they're irritating and not as smooth but they're really necessary because of all these great tools we do have like Drupal CI now the composer in points all of the project browsing stuff are usage stats like all of these things depend on our Git repose and so whatever we come up with we're going to have to keep part of that there's no cost savings or like mind share savings of not spending the time thinking about it by moving over to GitHub because it's actually harder than what we have right now it's just not easy it's not it's definitely not easier to contribute to so we're trying to figure out that middle ground and that compromise What's that? I was going to let him talk but I was just going to mention that we came up with some ideas a while back for issue work spaces and just other priorities have pushed it off the road map and we're not sure where it lands yet but there is architecture and design for how we can improve it on Drupal at work if we don't do a wholesale move to GitHub or it's another option on the table it's something yeah I gave it he was wearing fancier clothes then come on I got big foot you were wearing plaid pants come on you might be surprised you might be surprised on page one of the marketplace right now there are no less than five companies that have fewer than ten people it's issue credits over it's really it's primarily comments if you do a patch or a comment if you're participating in the issue you have an opportunity for each issue to have one credit so you might have a larger company three people participating in an issue and three people will get credits but that larger company is only going to get one issue credit so that actually does help with the percentages based thing there is a skew to a couple companies that have just an incredible amount of resources that they're pushing towards it and that definitely keeps them in the top ten but if you're talking about the top 25 there's a company that I saw in the top 25 within the last six months that had three people it takes about 30 issue credits to show up on the first page now that may change as more people get used to it and start using it and whatnot I think the challenge then will be figure out ways to segment the marketplace so that people who are looking for a Drupal shop are picking the right size Drupal shop for their project and being able to identify that and that's more kind of UI around how we do that listing rather than what are the top contributors because if we start doing it by percentages we skew it in a different way and I just want to add it's difficult because a lot of larger companies will also like their front desk staff will sign up for an account on Drupal.org be a part of their be a part of their company and buy tickets for their employees for DrupalCon and that's their only activity but then it starts to be like percentage of whom you might end up with a lot of people who aren't going to be getting issue credits but they still have accounts on Drupal.org and maybe they're just reading documentation accounts or a company with a lot of juniors versus a lot of seniors so it's hard to figure out how do you percentage of which type of contributors yeah there's an issue on Drupal.org I'll add it to the slide deck so I can make sure that people can get to it so when we post our slides afterwards you can add that to the session you'll be able to see where that's at but there is an issue where I've kind of talked about all the different types of contribution that we know about whether or not we currently collect the information whether or not we currently display the information or whether or not it would be possible to display the information at some time and it's a huge list we're talking about 100 different contribution activities that you could be doing everything from contributing documentation to running a camp to being a sprint mentor to speaking at a camp, speaking at a con like all of these things there's a lot of really powerful contributions because if you're looking at Drupal 8 and getting it released it was the most important thing to do we're still in that phase right now with Drupal 8 module upgrades I don't think we're out of that phase yet but I think as we add more things to the profiles and we make a richer picture of contribution we're absolutely going to be looking for some of these edge cases that aren't really edge cases they're the stress cases that Sarah was talking about this morning they're the opportunity to really highlight the importance in the community and highlight people who are doing great things but frankly if we just have subjective information on their profile they're never going to show up anywhere we have to figure out a way to make that data objective and then we can truly show it and highlight them I just want to add one more thing I just find it fascinating when I see signs in places and it says drilling holes on lecterns is prohibited there must have been a lot of hole drilling for them to require that thank you everybody I can't think of a better way to end the presentation than that