 Good afternoon everyone. I know if you're like me you're a little bit sleepy at a post five o'clock session on the day after so many evening community parties but we will do our best to keep energy levels high and get through this conversation and talk a little bit about the Drupal.org engineering team, the work that we do, some of the recent progress we've made on a few projects and also some things that we're working on moving forward to help build more tools to enable the community to continue doing what you all do to help build Drupal. So I do want to start off with a few introductions. We'll introduce the people who are here and then talk about some of the other folks who contribute to this team who are not present right now. So for myself I'm Tim Lennon, Hestanet on Drupal.org. I'm the CTO for the Drupal Association and so I manage this small engineering team and the projects that we do as well as interface with other companies and projects and other open source communities to see how we can collaborate as an engineering team with those folks. Ryan, do you want to introduce yourself? Sure. Hi, I'm Ryan Aslet. I'm a mixologic on Drupal.org. I'm the back-end services developer that works on things like Drupal CI and packages.drupal.org and I've been the coordinator for the composer initiative most recently and lots of other things like just database queries and stats and figuring things out for the community. Cool. And Neil? I'm Neil Drum. I do more of the site building development side of things, managing our Drupal sites and yeah, some automation and infrastructure stuff. Cool. And then some of the team members who are not here, the last staff member who's currently not present is Beeman up here. Oh, are you not getting our... I don't think you started the slides yet. That's interesting. There we go. Beeman up here. Brendan Blaine who is back in the States right now who supports, if you ever submit tickets to help at Drupal.org, you probably got a response from Brendan. He also does some feature work for things like the event site, stuff coming up for DrupalCon Minneapolis, just a variety of other things for the team that kind of amplifies and provides some user-facing features. Well, Neil and Ryan are focused on a lot of the kind of core tooling and things that are enabling development of Drupal itself. So that top row is all the staff in terms of the engineering team on the association. However, we have some key vendor and volunteers. So, Narayan Newton with Tag1 Consulting is our sort of infrastructure partner to help us manage both the bare metal hardware and the virtual servers that we use to host the infrastructure. And then Michael Hess is kind of the key super volunteer who helps us out. You may know him as leading the security working group and being part of the infrastructure working group and supporting just a lot of initiatives and projects that we do. Want to send out some good wishes to Brendan because he is in Los Angeles where there are some very, very serious fires going on right now and he may be under an evacuation notice soon. So, we're wishing him the best at the moment. So, talking about what we've been working on recently, probably our most important priority has been everything related to getting ready for Drupal 9 and everything related to updating Drupal.org's infrastructure to support Drupal 9. So, just generally speaking, I think you're aware of the way that release cycle for Drupal works. There's a six month release of new minor versions, but then the upcoming release of 9 as the next major version. And this means that there are many different elements of Drupal.org that need to be updated to support the presence of a new major version and to support that kind of brand new idea of having features and modules and things like that that work with both Drupal 8 and with Drupal 9 and needing to be able to indicate that kind of compatibility. So, Ryan and Neil, if you could perhaps, the monitors misbehaving, if you could perhaps talk to a few of the challenges that have come in supporting the release of Drupal 9? So, yeah, Drupal.org provides services to Drupal sites, update status, localization or two of the big ones. So, yeah, when your site checks for updates, it checks a URL on Drupal.org that has a 8x in it or 9x in it, except that API compatibility, like this is a Drupal 8-odd or Drupal 9-odd module, is going to go away because you can have a module compatible with both. So, finding places like that and figuring out what we have to deal with them and get core updated to not be requesting 9x stuff because that's less and less of a thing. And there's just other parts where we find there's an 8 part could it somewhere, so those down and not doing that anymore. Yeah, and there's other areas of things that we have to support that might not immediately pop into your mind when you start thinking about it, but for example the project browser on Drupal.org is going to need to have some way of understanding well, how do I find things compatible with my 9 site, all that kind of stuff. There's just a number of problems that we're having to solve recently and things in the back end infrastructure to support the kind of the developers who are working on 9 and the people who are trying to test the first releases, whether they're going to be testing them with straight composer downloads or whatever other way they might want to do that. So, do you have anything to add, Ryan? Just basically that it's you know we've gone from having one possible version and everything fits in a silo it's either eight or it's seven to where there's multiple now that work and so it's yeah like dependencies, the composer the releases, the you know there's just things all over that we're you know discovering and finding they're like oh well this needs to handle both and this needs to handle both, so. I think also a really big part of getting ready for Drupal 9 has been just supporting the testing infrastructure that's made it possible for the core team and all the contributors to ensure that Drupal 9 is going to be ready for release the same way that we've ensured that all the you know previous releases of Drupal are available and maybe you can talk about the scale of just what Drupal CI does in the testing environments and that kind of whole Cartesian product of things that we test on a regular basis. Yeah there's probably like 50 something different environments we have at this point so we've got you know PHP containers that are testing the head of PHP and just the other day Alice Pott was asking me if you could get a PHP 8 container so that we can start to surface you know like he's been doing a lot of work on getting 7.4 to work even though 7.4 is not on yet and because of that he's revealed upstream bugs and like five different packages that they didn't know they had even though they thought they were 7.4 compatible so you know we've got a lot of those sort of development PHP ones and then we've got all the different databases that exist and then we've got all the stable PHP versions and so between all that we have tons of environments that we support and then you know I'll tell it I think since since Drupal inception of Drupal CI we're up to like a million and a half tests and testing jobs that we've run that all take about an hour so you know there's it's it's pretty big yeah it's a lot and so like any individual patch that gets admitted in the core issue queue for example will take around an hour or longer to run on you know a dynamically spun up machine on AWS running the Drupal CI test week and these are big machine instances and so it's like 40 cents a run and you can imagine with the pace of development something like 10,000 open issues in the core issue queue how that adds up pretty quickly but it's sort of expanding on that and recently and hopefully coming up soon you've been working with Gabor in particular on deprecation testing and using that to support the idea of understanding what modules in Drupal 8 will be ready for Drupal 9 and who still needs to migrate and those sort of stats that you saw in the Dries note about you know how many modules need online changes versus how many are already ready versus how many need more come from this sort of effort to support deprecation testing so you want to talk about that a little bit as well right as Gabor had put in the keynote he had shown a upgrade status module that you can install and shows you what's deprecated with a module but we're also going to be running this on Drupal out of work to run against all of the currently supported modules and put that data on the modules pages so that we can kind of make it visible to people who are looking to you know get a new module for the Drupal 9 site oh is this one ready or not and that that way you know soon soon there will be deprecation data available on all on all the individual project pages so sort of a you know using that static analysis tool that Matt Klayman wrote right so I'll add here as we go into other topics that if you have questions as we're going along feel free to come up to the mic and if it's a convenient time to pause we'll do that and let you ask questions as we go we'll also take questions at the end but and if anything really occurs to you that you'd really like to know more about feel free to just come on up as we're speaking and we'll make sure to slip that in so the nice thing about deprecation testing is if you follow the twitter handle for you know drop is moving you probably saw that these this looks slightly different than the stats that were in the keynote because the stats in the keynote were about all modules whether they were originally for seven or eight but if you look just at eight modules over 40 percent of them are actually already non-compatible so that's actually extremely exciting and something that because of how many how because of how many only need like one line changes to fix can rapidly grow and it's something that the contribution days tomorrow I think a lot of people here at the con could make significant progress on it so very excited about that. Yeah just one more thing I'd like to add about the Drupal 8 to 9 right this thing is you know we're we're trying to avoid having like 9.x dash module names we're trying to transfer transition over to using semantic versioning on core or on on contrib modules on Drupal.org so that's also part of all this prep work is getting getting it so that there is no longer a you know a 9.x branch. Yeah if you're a module maintainer in the future it really should just be that you have you know version one of your module version two your module whatever and hopefully that's both eight and nine compatible or eventually if it uses things that have that have only come in and minor releases of nine it's not only compatible and things like that but using proper semper in that contrib space is a kind of important advancement for the project moving forward as well so please. Hey I was just curious if you oh this one actually works here I was just curious if how you envision that in the long run transitioning into like a module of theoretically moving module could be compatible with like eight nine and ten but like it might only be compatible with nine or ten so like is there anything you could speak on if you had any thoughts on having a long term viability of semper? What's a good question there's been some debates going on about so we we have a monthly call with the core team the core committers to talk about how we're going to handle like again the project browsing side of this is compatible with x y z and you there's you know there's the composer style compatibility information that can say compatible with version whatever and above or with this between this and this and that and we're probably going to start sort of parsing similar sorts of more complex but more accurate compatibility information and trying to make that available it becomes slightly difficult to browse so what we're sort of thinking about is you know how could you go to a module page and be able to perhaps say well here's my current version you just tell me yes no is that going to be compatible yeah and it's not just compatible with eight and nine it's compatible with five or later or detail than that so yeah it's a it's a thorny problem that we've run into because of the new six month release cycle and the dual compatibility of eight and nine and it has huge benefits in terms of being able to upgrade sites and deliver features faster but from kind of a ui point of view of discovering modules on Drupal at org it's going to give us some problem some challenges to solve cool so i'd like to talk also a little bit more about automatic updates in just a little bit more detail perhaps than you saw in what was in the keynote presentation i won't replay the video because i can't stand the sound of my own voice but uh but we can talk through it a little bit more um so i just do want to give a shout out to the erpy commission sponsorship of this initiative has been huge that kind of partnership um you know we would not be here saying hey there's going to be a stable version of the even the first phase of work uh by the end of the year without the benefit of significant sponsorship to accelerate that so it's been really really important um but there's a variety of things that are you know there's building the automatic updates module but there's also sort of infrastructure around supporting it um so neil maybe you can talk about what happens when the automatic updates module is sort of looking to drupal at org to know how to update a site yeah so yeah automatic updates that's another service that we're starting to provide another api part uh so automatic updates that has some pre-flight chats you know you don't want to update your site automatically if you have changes to files if you've hacked uh you know some something else into one of the core modules uh automatic updates will be could break your site in that case so uh we have an api for um the hash that's about all the files in every release so you can uh use that to check if your uh site is consistent with what it should be uh that your code base um and the we also have a api for um learning sites if there's a security release coming up um initially the scope of automatic updates will be um your site will update automatically that there is a critical highly critical security release so we have a api that when the announcement comes out that uh there will be one of those next Wednesday um your site will be able to say hey the site will update around this time the pre-flight checks are passing or failing um and lot of site owners know that that's coming up um and the actual updates themselves were packaging in a different way so we send only the files that have changed uh from version to version um so and can you speak to whether do i have to if i'm updating my site do i have to go from 8.7.4 to 8.7.5 to 6 to 7 to 8 going up or yeah well uh so for our site we'll make uh update file for anything that gets requested uh you could request an update from 8.6.3 to truple 5.10 and truple will tell you about box change and it's up to the automatic updates uh you know automatic updates module uh what's going to core uh it's module right now um that's responsible for having a same ui yeah uh and but yeah jumping around version numbers is possible um and yeah the in general taking things a little bit slow on the ui side of things uh just because this is new and updates do occasionally break sites so we don't want to update iMac left everything all the time but uh yeah we're not building a ci system for every truple site yeah so the the contributed module which is the basis of the first phase of work has an uh i believe the latest release is an alpha three release and so that does support all of the preflight readiness checks it it supports the included file backup so that if it like fails in flight of doing uh like something fails on the request to get the package or something like that it should be non-destructive and roll that back and it also includes the ability both to manually initiate that automatic update or to begin setting it to run on cron so we do have some uh brave souls who are testing you know staging versions of their sites to to let us know if anything's causing trouble but it's actually working remarkably well and if you are interested in digging into the guts of it it's um actually a remarkably concise module in terms of the total lines of code and things like that there's nothing too crazy going on there but you know even just that psa feature i think is kind of a tremendous improvement because as you know that red message that says there's a security update available for your site is something that only happens after it's been released after it's been published being able to publish the psas that come you know maybe two weeks before or however long before at least gives that extra breathing room to people who maybe don't follow what happens on Drupal.org as closely as perhaps they should so we're hoping that the broader base of sites will be more secure as a result of this and then eventually you know those small to medium-sized site owners will have just a lower maintenance way to keep up today with their Drupal sites so and also the updates API we're providing is we're building a tiny infrastructure as well so yeah so i'll introduce this a little bit more and then you can talk about it some you know but this the there's a lot of other projects a lot of other cms's that have begun implementing and automatic updates infrastructure but there's been some controversy a little bit of trauma about how secure the updates are because obviously if you are enabling a system that can request some package of files and overwrite your doc root with whatever files are there that's potentially a truck-sized security goal if there was any kind of impersonation of the update server or sort of man in the middle situation right so from the get-go we want to make sure that the updates we providing are we're providing are highly secure and there's a few different elements going into that including a related project that we're going to be using that is agnostic to cms systems that the wider php ecosystem can use but uh meal will let you speak to the parts of it you'd like to um yeah we're figuring out uh getting a isolated building out a isolated server to do the actual signing to kind of reduce exposure from the rest of our infrastructure uh and the software uh it was based on vsd uh signified and we're adapting uh that a bit uh so it should be good for any uh any project if they want to use it and yeah yeah we're freaking out uh what the best practices that are for like key rotation handling like we have to meet somewhere and exchange keys and stuff like that yeah meet in the park wearing a low a low hat and passing a newspaper to change the signing keys every quarter no but we'll figure it out we are going to use some uh hardware-based uh keys as part of the signing uh the chain of trust that we're using to sign these we'll have package expiration so that when a package is signed from Drupal.org there'll be a period of time for that uh for which it works and then it'll be re-signed maybe that's a quarter quarterly process um but all of that should help ensure that we don't get some sort of major vulnerability uh as a result of just creating this automated update process and we think that's kind of critically important every Drupal calling did exchange keys every Drupal calling it's a good it's a good possibility actually it might be uh it might be kind of an event yeah I I don't know about the east coast of the US and they live on the west coast of the US so yeah we're gonna spend too much money on exchanging keys yeah exactly I do think we have a key exchanging ceremony though yes we'll probably get some robes and fancy hats for the whole affair um so I'd also like to spend some time talking about the composer initiative and this is um this is an interesting case study for us on the uh Drupal association engineering team because historically the DA has actually been kind of deliberately firewalled off from things related to Drupal core there was a especially around the early creation of the DA there was this perception that okay the the purpose the fundamental goal of the DA is to provide support infrastructure but stay hands off from the product in order to allow the community to just keep building Drupal as it was um but truthfully uh even then but especially now Drupal.org really is part of the product like so many of the services like the update system localization all of those things come from Drupal.org anyway so it's important for us to be more closely involved and having Ryan be one of the initiative leads for the composer initiative that was talked about in the Dries note um has kind of proved out the value of that collaboration so do you want to speak to um kind of what went on there yeah sure um if you come to my session seven hours ago you will see or watch the video yeah that's true it's online um so there was uh you know composer in core has kind of evolved over time to where we started with um just core itself was using composer packages so that it could you know leverage the power of symphony and leverage the power of third-party development and you know expand out into the broader ecosystem and then community members were like well i'm going to do that with my module too and so they started building things um making you know the composer manager module was a tool that people were using for a while and then somebody said well i also want to be able to install my modules using composers so a community member built a um package repository and then as we saw this package repository we saw it like kind of gaining speed we're like we should offer another service and so that's where we added packages dot dribble dot org that all the composer um sites use as their um as their you know package repository and then it became even more mainstream and some people were saying well like how do i actually use this how do i make this work because i you know i download a copy of uh core we're using a git clone and i start doing stuff and then when it comes to time to update everything is a mess like i have to like do this merge conflict and things are broken and like what do i actually do and then we realize there's no real official way to do it because it's like okay well there's this there's this you know secret door you have to knock on and someone will knock back and you go on the inside and then they tell you the the password to the you know the special github repository where somebody out in the community has built this thing and it was like you know it's never not easy to find it wasn't like prom and andrew blood org uh so some people were in the know and knew to use it but it wasn't necessarily official so we're like well we need to you know eliminate the possibility for people to like shoot themselves in the foot we need there to be an official supported this is how you do it with composer and this works and it's tested and it's in core so that was um sort of the genesis of the composer initiative and um what we've done is kind of incorporate a lot of the tools that the community had already built like we had taken the scaffold file that was basically with any composer project you know when you have your the git repo with core you've got your robots dot tax and your ht access and like all of these other files that are um not really part of the product but just kind of scaffolding um well in a composer project those were getting put into place by the scaffold tool that was calling back to uh seek it or now git lab to pull up those individual files every time someone was installing their site so Drupal network was getting hit with thousands of file requests and we were like why is millions yeah millions of millions of requests and especially like when there was a major upgrade or security incident you know it's like everyone's upgrading at once and everyone with the composer site is upgrading at the same time and it was like whoa our git server is suffering how can we fix this so we changed the scaffold and approved it so that now the package shifts with ships with its own scaffold files so like Drupal core comes with its own scaffold files and then tells you where to put them when you get it so now we've made it so that there doesn't have to be any requests in Drupal network they just come in the package just by default and so we've got that um the various meta packages that uh web flow had built you know a version that is like here's all your dependencies that are going to lock um your site so that the upstream dependencies don't break you because that was another issue where we're like we're using composer yay and twig changed the thing and it broke everybody's site we're like well we don't want twig will still change things and break things but we don't want everyone's site to break so we want to have like a nice stable like platform of which we don't upgrade above unless we really want to and that's when you do core upgrades and so we've you know created the core recommended meta package and the core dev meta package which is like the development dependencies and core dev pin which is development these but specific versions so we've got all these things in there and now now there's an official way to install composer which means that we can now finally go to the Drupal page and go to the downloads page and say you know here get started with Drupal here's how and you know and put the composer instructions in there from the get go instead of like download this tarball but you really should use composer you know it's it allows us to kind of actually start funneling people down the right path of you know making composer work really well in core and so now you know the the next step phase the next step is to make composer much more performant because it is slow it is uh cryptic uh it tells you things that are hard to parse and hard to figure out and we've got ideas and ways to solve for all these and if we can get it pretty fast then someday it might be the composer replaces all of core's extension management and then it's just it's in there it's quick and it does what it needs to do but there's still a lot of work to do though but yeah that's that's kind of basically where that's at and you know speaking of the tarball or zip file downloaded and all that kind of thing the other benefit of doing all of this work and standardizing on a single way within core is that as of 8.8 when if you do start by downloading a tarball you're not you're not screwed because it's not set up in the same way that a composer scaffolded project needs to be set up you'll be okay if you need to convert to a composer project um so oops lost my mouse there we go so in addition to like this sort of fundamental work on kind of key features that support um Drupal as a as a product as a as a software project you know we're also maintaining Drupal.org as the home of the community so there's a variety of smaller features that we've gone through we'll go through very quickly on these because there's some other big topics I know we wanted to talk about as well but we've done little things like update the case study browser and the case study format fix the way that it's filtered so that people evaluating Drupal can better find related case stories to their own use cases and understand that their peers can also have been using Drupal successfully and maybe they should too. Neil deployed this work to automatically regenerate the table of contents and community members were involved in sort of speccing this out and getting it ready to go but all the documentation now automatically generates this sidebar makes it much easier to navigate um and then similar things as well um uh uh just a fish uh Sally uh contributed some code to add the language tags that you've probably seen in the issue queues if you've been contributing recently um and the location information that allows us to give those sort of cultural context clues so that when people are collaborating internationally they actually know okay um is this person being stubborn or obstinate or maybe they don't quite understand the language I'm using and maybe I should be a little bit more compassionate and emphatic about how I'm interacting with other folks on Drupal.org so we just want to provide those little clues to help promote kind of community health there are a few things coming up next um uh well really there's about a million things on our roadmap but there are some that are in the kind of more near term um related to you might remember this slide if you saw the Drupal con Seattle uh presentation this was about kind of the current demographics of our community there's a completely opt-in demographic section on everybody's user profile we've got about 30 percent more respondents in Seattle than we have before but I'd encourage people to fill that out and that's giving us information about the diversity of our community and who's been included um we're going to be deploying additional work like expanded options for gender identification that comes out of the open demographics initiative uh we are working with a organization that Zixware has uh volunteered to kind of put forward a prototype initiative that we hope might become a core initiative to create a project messaging channel that would take a feed from Drupal.org and create news and announcements directly in the admin interface of Drupal so we can reach reach a presumably much much wider audience um of Drupal users out there site owners who might have no knowledge of what goes on in Drupal.org like it's 97 percent of the traffic to d.o is um not authenticated traffic not logged in users right so we have to assume that there's this huge percentage of people who probably aren't highly engaged in our communication channels and could get some really valuable information if it was pushed into the Drupal admin interface so we'd like to work with the core team to see if we can get that work in um there's other some extensions we'd like to think about Drupal groups and community events and how we can work with say the team that maintains Drupal Cal or to create something like maybe a submission feed and then a published JSON feed of events through Drupal.org and things like that so it's figuring out details about how we would do that but we want to support global community events um and all that work um merge requests um this is something that I know is like top of mind for a lot of people and something that you know a few months back well maybe at the end of Seattle we were sort of hoping we could we might have been able to be here and say hey they're ready but all that work to support Drupal 9 and make sure that Drupal 9's release would be ready to go on time kind of took over the priority but Neil maybe you can speak a little bit to where we are with get them and merge requests work uh yeah so have kind of proof of concept about whole stuff working uh the plan is uh when we're ready to roll it out project by project so a few pilot projects will use it probably some of the modules we maintain for built in Drupal.org um and then once that's figured out cut through the how collaboration works in merge requests um then rolled out to the core issue queue and every project uh the key difference we have from what you've seen on github or getloud.com is Drupal issues are collaborative multiple people come through in post patches and a single stream of comments yeah into a yeah single stream of comments and merge requests on github tend to be one person driving an issue uh and solving it there's not a lot of collaboration and if you do collaborate you have to figure out how to fork someone else's fork and you can't post it back to the original issue uh so providing forks that everyone can access and push to and then you have to figure out the access control on top of that so you know get it's easy to overwrite your own work uh you also uh don't want to make a mistake and overwrite someone else's work yeah so there's a lot of work there in terms of just really the most of the work around this at this point is um is not so much the technical challenge of implementing it I mean Nils had a proof of concept on one of our dev sites that can make a fork for an issue and then be able to start opening branches and things on that but but it's the sort of um in a corporate world you'd call them business logic like it's the it's the user logic of how we want the collaboration to work with those branches and forks and what we want the UI to look like as things get posted back to the issue queue that we really need to work on but hopefully this is more like a matter of months than than much longer um so it should be quite soon yeah another part will be um you know in all of these systems you have a the issue and then uh you have other conversation uh on the merge request so uh which is good you separate the high level we want to build this thing from the uh nuts and bolts of fix the coding standards here um but providing the visibility in the issue then there's stuff happening in the merge request will also be a UI thing to figure out yeah so we're beginning to run a little bit long time so move fairly quickly again do feel free to jump up to the mic if you have a few questions for the last session so hopefully we can spend a little bit extra time if we need to the other huge thing that we have is Drupal.org's own eight slash nine migration process uh Drupal.org relies on a lot of custom modules that basically only we use um and so that means there hasn't been a big community effort to port those modules to new versions it's all just you know kind of on us when we're ready to do it so 2020 is really going to be the year of figuring out that migration process for us and we want to do it in a progressive way um we're looking at there are some examples out there for um of other sites who have used their cdm layer to route some traffic back to their old site and to do a single section of their new site at a time and just change the cdm direction so that you have your seven sites still in place and the new eight sections going out piece by piece uh we want to look at that and see if that's something that'll work for us so um they'll likely be a lot more information about this um if you did want to help with anything related to that you'd want to check out the readiness of some of the modules that maybe aren't just Drupal.org specific but that we do use um or help us reduce scope um we're trying to find you know there's a lot of technical debt in in 15 years of Drupal.org or however much it is so there there's whole features and areas of content that probably don't need to be there anymore and rather than migrate them we should remove them and save ourselves the work um and just have some patience because it'll be a really large undertaking um the very last thing I want to talk about and the thing that I'd if we need to I'll hang around afterwards to talk about a little bit is the contribution credit conversation so uh you know the sorting the marketplace by contribution and the addition of credit uh in issues for individuals as well as for organizations is something we implemented into 2016 um and those changes that were proposed in the Drees Note are things that we're going to be supporting from a technical level and there's it's conceptually pretty simple but there's sort of two problems to solve so one is more completely measuring the different types of contribution activity right we need to capture every kind of thing that people do whether it's event organizations sponsorship activities on Ditto or off Ditto um and capture all those completely but having measured that activity we do need to to decide how to weight it what multipliers apply and realize that as we do so we are deliberately creating incentives for certain things right if we choose to for example say that um having case studies is really important to the project right now and so we weight highly having case studies we can expect that that's going to introduce a behavior of bringing along our case studies if we weigh heavily on project usage as we currently do right now that encourages contributions to core and the most highly used modules but maybe that has a negative impact on up and coming modules that might be the next views or something like that so we have to think carefully about how we're going to do all of those things um but the goals are dramatically increase the types of things that we recognize um in particular finding ways to do the non Ditto activities like I mentioned before having this robust and tunable system of weights and measures that we can adapt as the priorities of the project change or as we find issues um and then having that committee that Mike Lam spoke about in his original message um to talk about this so just like you know general examples there's some things we measure now some notions of what some multipliers on those might be but there's also a lot of things that we don't measure that we're already aware of right that we would like to be able to measure um and then once recorded in the system it's pretty simple it's the count of how many times that activity has been done any relevant multipliers and the weight we set overall to give a kind of priority to it um to be added up and created this sort of background contribution score and you know the other thing we should say there is it's it's not our goal to create the sort of one two three four ranking of individuals organizations so much as support this conversation about recognizing and rewarding the people who make Drupal and encouraging others to do more to become those same good Drupal citizens so i'm sure this is going to be a hot topic there's uh the uh contribution credits committee that you could nominate yourself for there's an issue where people have been providing a lot of feedback on their ideas on what we should measure what the weights might look like so feel free to participate there um just as a reminder to everybody who's in the room i threw this in there because it's a message that should get out there uh Drupal 7 and Drupal 8 both have extended uh have end of official end of life on in November of 2021 um there will be extended support available from a couple vendors for those folks who need it but it's just something that's good to keep in mind um and maybe if you're a Drupal 7 site maintainer in the room oh like us you should you should probably get on your migration pretty quick um and so uh please join the contribution activities tomorrow um you can contribute to making sure that modules are ready for Drupal 9 those one-line changes to switch from like Drupal set message to the new ways of doing messages or an easy way to contribute there's all sorts of things you could do um we'll be around you can certainly talk to us as well um and you can of course leave your feedback about the event as a whole or individual sessions so if there are any final questions i know we're technically pretty much out of time but please come up to the mic so the recording has it thanks for all you do number one thank you um this is a weird one so i don't i i've got my own ideas but how do you deal with old content on d o when you're searching for something and answer to something and you're like oh i found it note jupal 5 um i mean just to share the ideas like is there any ideas or work going towards like a tagging system or a voting system on documentation or content on the website where if i just found something like that i could just hit the button say i think this is old yeah maybe then um you know if enough people do that or i'm god um you know that gets devalued in google or whatever you know yeah it's interesting nemo's more about the solar indexing than i do but yeah we don't have a lot of control over about google uh indexes uh but we have uh for really any control uh so i mean at a point you could like uh block no index so yeah uh with our last documentation refresh uh we uh started a migration uh we're still doing a migration to the new documentation system and part of that was let's actually delete pages uh so deleting things that completely is less that are completely old uh so that's something that historically wasn't done as much yeah i think and yeah our solar index it's it does uh have the date something was created as a factor a three minor factor but yeah we could uh do more of that and as research for the documentation migration there was a one-off kind of survey uh to uh on each documentation page we could think about having the yeah this is helpful stop uh there yeah and maybe probably after truquel nine yeah migration yeah i think i think that would be interesting i think you know we we don't intend i hope to i hope we our current intent is to finish the migration of the old stuff to the new content types before we would migrate anything and at that point hopefully we're getting rid of a lot of that cruft um uh but yeah i think that's reasonable and i think some notion of like setting a no index thing if it if it's been marked like out of date or obsolete this is not a bad idea it's not supported anymore or unsupported yeah we do have the uh the newer documentation system has a uh flag on it for incomplete or outdated stuff so we do we actually could index that yeah please thank you for all your work and i just have a quick question about the federated login oh right um yeah enable any number of things yeah so federated login um sso off uh all these sorts of topics is something that's come up a lot um and could enable actually quite a lot of things for the community so if you could use your drupa.org or blog in on campsites on uh chat programs on all sorts of things you could kind of carry your drupa identity throughout a variety of different places so it is absolutely still on the plan to have some kind of offering for that we are actually sort of it's related i think at this point you thinking it's been evolving a little bit on this but it's probably going to be part of how we handle some of the um migration process is start pushing some of the core profile information into an identity provider um as we were thinking about our eight and nine migrations so we're still planning to do it um it's likely that we'll use uh particularly if we can get donated services we'll use a cloud vendor for identity management of some sort we haven't picked the exact one we're talking to a couple of them right now so um i think that's the most i can say because i don't have an exact timeline did um did we ever get our policy straight on that too like yeah we did publish a draft policy on how um federated identity could be used uh i probably did that at drupa europe i think i'll publish that first draft i don't know that there's been a huge amount of feedback but i think it's enough to move forward with uh when we get the technology lined up so any last questions well if not thank you very much and by the way all your support and help as individual members or supporting partners all those things is what among other things pays our salaries but also pays for those drupal ci tests pays for the hosting of drupal.org you know there's 20 terabytes of traffic to the updates system every month um it's a lot of work that we and a lot of resources that it takes so thank you for all of that support