I think I've given everybody about enough time to finish up their lunches and meals. It seems like people have trickled into everywhere. I'm going to go ahead and get started. I'm Ryan Aslet. I'm the infrastructure QA engineer with the Drupal Association and presenting today on what our strategic roadmap is for 2015 and what we're going to be doing with Drupal.org and all of its subsites. First of all, a little bit of background on where we're coming from in 2014. Drupal.org has historically been maintained by mostly volunteers. As a consequence of that, the community has driven most of the initiatives of how Drupal.org should work and what sort of functions and features Drupal.org has. And it's reached the point where we need to do more with Drupal.org and can't necessarily rely on solely the community to get these things accomplished. And so the Drupal Association staffed up our tech team. So there's now 11 of us working on Drupal.org and all of its subsites. So we started with two full-time staff members. That was Neil Drum and Tatiana, if you're familiar with them. And they kept things going for a long time, but it was hard for them to develop new initiatives or take on new things that would improve the way we work with Drupal and our access to things and et cetera. So here's a little growth chart that shows where we've been. So Neil and Tatiana there have been holding down the fort for the last three years. And then we have Brendan, came on staff. He's our technical coordinator internally. Gets us all our laptops and keeps everything running inside. And then we hired Rudy, Basic, and Liz. Liz helps manage the community. Basic is one of our infrastructure gurus. He kind of keeps all the servers running, keeps everything going on the back end. And then in March, we hired Josh, who is our CTO. And he's kind of set the direction and the pace for what we're going to be working on and how we're doing things, followed by Oliver Davies, who is a developer. So he's doing a lot of work on Drupal con sites and on Drupal.org itself, of the various features that we've been working on. Archie came on staff as another member of the infrastructure team. So he's helping Rudy. And then myself, I joined as well, and I'm also on the infrastructure team. So we try to keep all the servers running, keep all the backups going, make sure that everything is accessible and everything is always available. That's how we want, we don't want Drupal.org to be down. So that's one of our goals. And then recently in September, we hired Jacob and Emily, who they've been working on the con sites. They helped build Drupal.con Latin America. They also put together a new site, events.drupal.org, which will be housing Oliver con sites in the future. And then finally we hired Tim, who is a project manager, and he's helping us keep everything in line and figure out what we're doing next and keeps us on track. So since we added an engineering team, lots of things have been happening at a kind of a much more rapid pace than they have in the past. I don't know if you've noticed in your interactions with Drupal.org, if you've seen some of the things that have happened, but we wanted to change Drupal to run semantic versioning. So we wanted 8.0.0 and to break the really huge release cycle. And we had to do a lot of things on the infrastructure side as far as Git and all the database back end to support that. So we've added that. We removed some Drupal 8 beta release blockers, things that were stopping the core committers from being able to proceed with Drupal 8. We added, we took over the test spots. The test spots were managed by community, and oftentimes it would break, and there were some issues with them. So now we manage them and we're kind of on the hook for all the test spots. A new thing that's happened recently is we've imported a feature from Dredditor, which is how to give commit credit to users as your, as users add patches to things. We've now got this feature that shows who participated in the issue, whether they put comments or patches in. That's been deployed as well. Our old user profiles were still an artifact of Drupal 6, where they were kind of stored as a profile field, and we've converted those all to entities and fields. We recently deployed the blue cheese as a responsive theme. So I don't know if you've noticed and looked at Drupal.org on a web phone or a tablet, but it should be a lot easier to navigate on various devices. We've improved the new user experience, and as new people come into Drupal.org, there was a lot of kind of outdated best practices, as far as like logging in and then going to your email to get a validation and then coming back, and oftentimes we would lose people through that process of trying to accomplish what they wanted to do. So now we have a much clearer workflow between Drupal.org and all the subsites. So if you register in a conference site or if you register in groups, it'll take you back to Drupal.org and we have kind of a more unified user process. And as I mentioned before, we've launched events.drupal.org, so all of our Drupal cons now instead of being individual Drupal sites can all run as subsites of one large site, which will keep code maintenance down and give us a lot of options that way. And then finally, we launched Drupal jobs. So Drupal jobs is the place where you can find talent. If you need people, there's hundreds of people in the database that are looking for work, and we've also got hundreds of jobs listed of people who are looking to find talent. So that supports the Drupal association as well. Other things, we added a CDN. Everything used to come directly to Drupal.org servers, and now we have the Edgecast as our CDN, so that's offloaded a lot of work from our internal servers, particularly updates. I'm not sure if you guys are aware, but when you turn on updates and it tells you that your site is out of date or you need to upgrade this module or there's some security features that have come out since then, every Drupal site in the world that has that turned on is hitting Drupal.org every five minutes or every hour asking us for updates. So it's a really heavy amount of traffic that we get for that, and the CDN has helped a lot with that. There's a new REST API that allows you to access issue queues and nodes and users and find data that comes back as JSON, and there's details on Drupal.org on how to leverage that. Some people have already started to build tools like Kanban boards and project management tools to rather than scrape the data off of Drupal.org, they can actually find the data they're looking for. We implemented a change notification policy because sometimes things would change and people would not know that those changes were coming or really wanted to know when they were coming from. Internally, we've introduced scrum project management and we have a much better product planning and lifecycle, so now that we have a team, we have a good way of organizing that team, so we have organized what we're going to be working on in the future. We have new database servers. The database server that ran Drupal.org was seven years old and didn't quite have enough horsepower to run everything that we wanted to now, and our new database server is a machine, it is awesome. The page load time should be a lot, lots faster now that we have that in place, so all of our metrics have shown that we've dropped 300 milliseconds off every request, so happy about that. And we are performing a lot more support, so there's a lot less reliance on community getting around to answering questions about the infrastructure, and now we can, if someone has a problem pushing to get, we can immediately respond and be like, oh, I'm sorry, let's help you fix that. So those are just some of the wins that we've had since we introduced our engineering team. So just to give you an idea of the scale of all the things that we're responsible for, we move about 20 terabytes of data a month, like just that much volume in and out. Yeah, it's pretty huge. In fact, this slide is really dense, but it kind of gives you an idea. Every one of those blue squares is a server, is a site. QA.Drupal.org updates infrastructure, all the code browsing, all the APIs, the association site, all the Drupal con sites, the Drupal store, the job site, the security site, I mean, there's this many sites in the Drupal ecosystem on Drupal.org, and these are all within our responsibility. And it's running on a lot of machines. We've got four web nodes, a couple of file servers, four database servers, a couple of load balancers, solar search servers, and then an entire infrastructure of development stuff inside that allows us to stage and develop changes to Drupal.org. So it's a lot of machinery and a lot of moving parts. The red stuff is all things that people would perceive as core to Drupal.org, but are actually community supported and community developed. So things like Drush and Simple Test Me and Dread Editor, et cetera. Okay, so with all of the history of how long we've been around and all of the things that we want to accomplish and all the things that people have asked for for years, like, oh, why don't we have this or why don't we have that? It'd be great if Drupal.org did this. We kind of had to go through all of that and prioritize what we were going to do and say, well, something's got to come first. So how do we do that? We started with user research. We decided to go to the community and during Drupal con Amsterdam, Drupal con Austin, we interviewed 30 different users of all different spectrums from developers to site builders to end customers to kind of find out what they needed from Drupal.org and what were the features and functions and kind of to figure out who our audience was, to figure out... And so we came up with these user personas to kind of put people in categories that are using this site to give us an idea of who we're currently serving and who we need to serve better. So we've got learners. Well, we've got newcomers. People they've heard about Drupal. They've run a Google search and land on Drupal.org which is a surprisingly large number of traffic comes from a search for just the word Drupal.  They've started to install sites but they're not customizing too much. They're just kind of getting their feet wet. Skilled, these are people who... They've got an understanding of Drupal. They're fluent in Drupal-specific terminology. They know what a view is. They know what content types are. They're often engaged in the community but not totally, they're not necessarily going to camps yet or Drupal cons. And our experts, these are the people who really understand Drupal. They are the ones that are hanging out in IRC. They're the ones that are answering questions when people ask. They've got a deep understanding of Drupal. And they actively contribute back. They're building modules. They're submitting patches. And then finally we have masters. And these are the people that have been around the Drupal ecosystem since the beginning or have really dove themselves in really deep and they're committing to core. They understand everything that's going on. They've been to all the cons. They're the Drupal rock stars to put it in that terminology. So when we evaluated this skills pyramid what we found is that we were having, we were pretty much serving the masters pretty well. They knew their way around the way everything worked. The experts weren't having too hard of a time figuring things out. But the place where we needed to improve is getting people from newcomers to learners or learners to skilled or skilled to expert. It was really the bottom half of the pyramid that when you first started working with Drupal.org it was probably easier to collide with information that was outdated or you didn't know where to look for what you were looking for or it was just organized in such a way that made it harder for those people. So we definitely need to increase the number of successful developers that use Drupal. And so that's where we decided to put some of our focus. So with that research in hand then we wanted to turn it into a plan. So some of the goals that we wanted to accomplish with this was we wanted to make sure that we continue to fund Drupal.org and pay for all of this because the association has to get its funding from somewhere. We need to make sure that everyone has support and has all the maintenance and keep all the servers running. We want to drive everything from community initiatives where people have put in time and effort over the years and they're good at it and we need to leverage as much as we can out of that. And then finally the board and the working group priorities help us kind of set our direction. So the working groups, they were established in early 2013. They had, there's a content working group and the Drupal software tools working group and documentation working group and I'm sure some other working groups that I'm not sure of. They ran an ideation process which was like, well, what do we want to fix? What do we want to make better? How do we want to improve Drupal.org? And every year we kept coming up with the same themes and the same things kind of kept happening and we're like, well, these are the things we should work on. So we set out some objectives. What did we want it to be? We wanted it to be the home of the Drupal community, the central source of relevant info where everyone comes to collaborate and this is where all the talent is. We want Drupal.org to be the place where everybody goes for Drupal information. We're trying to keep it from being spread all over the web in different places and different spots so no one knows where to go. We want it to be centralized. We want to provide all the tools everyone needs to advance within the Drupal ecosystem. We want to provide all the documentation and all the code and all the tutorials and videos and opportunities to advance and we want to encourage people to develop themselves and their Drupal proficiency and also build their own career. So we set up key performance indicators to say, well, okay, how do we measure this? And some of this stuff is like, well, some things we know like page response time and test spot response time and up time and how engaged are our users to let us know are we making things better. We keep up with the issue queues and make sure that our issue response time is minimal if someone's having a problem with Git. We try and get back with them within 24 hours. We were improving our testing. We've got a BDD infrastructure for Drupal.org that makes sure that new deployments keep from breaking. Well, we keep bad things out of production with the tests. I'm not sure what the development and employment bullet is for and we also want to maximize our hardware. We're running out of the open source labs out of Oregon and we run some stuff on Amazon Web Services and we use the Edgecast CDN. So we want to make sure that we get in the most out of what we've got and we've got a lot. So there's a lot of opportunities for keeping our performance going there. Sure. Well, it's a combination of Edgecast and now we're also looking at Fastly for FTP because that was another piece of the infrastructure that we're looking to improve is when you download modules with Drush or when you download them off the website, it's using kind of an antiquated system that's only mirrored to three spots. So based off of all of that input from what we want to improve and what the community's asked for and the kind of things that we're targeting, we've got seven key strategic initiatives that we're going to work on in 2015. So these are the main things. So new user engagement. So with new users, we want to fix the account creation and login process. We're pretty far down this path and are almost finished with this, actually. So it should end up that we have one unified login across all Drupal subsites and it'll be really nice that we have that and we won't have to worry so much about someone's logged in here but not there and they don't have an account here and there. And that'll also facilitate things like if people want to sign up for a con and they want to buy a ticket for the Drupal con but they don't have an account yet and they create the account and then they forget about it because they have to login to their email and we're just making that user workflow and user experience a lot better. We're introducing organization and user profile improvements. So the user profiles used to be just kind of a list of a bunch of things and we've organized them and made them look a lot better. I don't know if you've seen them but now there's pictures of mentors on there that used to be links and all in all it really shows a lot more how much you participate in the Drupal community if you've seen your profiles. But the introduction of organizations is a new thing as well and this kind of falls on from Dries' keynotes and direction which is that we want to give organizations more credit. Traditionally, individuals have been the only people allowed to have accounts on Drupal.org and that was so that organizations didn't take credit for the individual's contribution but now we're going to have both and people will be able to have credit for stuff that they do but then also put that on the organizations page to say this organization sponsored this module this organization paid for me to work on this patch and that way orgs get credit as well as users and hopefully help sustain the ecosystem because not everybody can work in their spare time on this sort of thing to contribute to the community. We're working on a content strategy for Drupal.org. One of the things you may have noticed is that everything is node slash number in the URL which doesn't give the user any indication of where they're at whether they're on a forum or an issue queue whether they're reading documentation. So even just the URL structure is something we're working on and figuring out okay well do we need forum posts should we move this to some other type of content type what type of content do we actually want to have and so rather than take the well we've got the content that's evolved over the years into what it is now we want to kind of reassess that and come up with a actual here's what would work best for the community to help the newcomers, to help the experts and to help the skilled people grow their career and along with that we'll come and redesign including like a design strategy and so that we can have reusable modules of design to be able to introduce new initiatives without too much work to build new content types or new displays. We're going to work on the issue workflow with Git as I'm sure you're aware the patch based workflow is a relic of the CVS era and we're still on it even though we have Git in the background and a lot of people have asked for well how about pull requests or how about something of that nature and we're working on it we've got a plan for that and so we're going to change the way that code gets added and worked on on Drupal.org we're going to make search usable does anybody use the search on Drupal.org or do you go to Google and type site Drupal.org right? yes yes and so we're going to make it much more usable we're going to make it so that it's valuable and along with the search kind of tied to that is finding modules because when you look at the number six the improved tools to find and select projects when you look at a module there's some signals that we that you know the longer you've been around the Drupal ecosystem the more you know oh I'm going to look at how many times it's been installed or oh I'm going to look at what the maintainer is or I'm going to look at you know whatever there's a whole bunch of signals that you kind of learn over time to figure out how to evaluate modules and when we think about us hosting all of the Drupal modules in one place we're really like an app store for the Drupal ecosystem and so we need to get a better process in place for getting new modules into the ecosystem as well as being able to quickly and easily evaluate the quality and usability of those modules so that people can find what they're looking for to extend their sites and finally we're going to update Drupal groups it's still running on Drupal six and we're going to yeah pull in some of its functionality make it Drupal seven and kind of give it a little bit of a refresh so those are the seven strategic initiatives on the Drupal or Roadmap that's hopefully what you can look forward to in 2015 we're working on it pretty quick so some little bit more details on the account creation login so why do we focus on this well the workflow is hard for newcomers we need to engage our users and encourage them to contribute Spammers really love how easy it is to get started with Drupal.org we get 10,000 accounts a month that are just sleeper accounts that Spammers are automatically generating they're hard to stop because they're just account creation and the roles and permissions in Drupal.org we want to change to reflect people's position in the community so we're adding a new role progression that allows people to become confirmed and community members that allow them to trust other users we're basically making a web of trust out of the roles and permissions plus this account creation is kind of the key to security for Drupal.org which back in March we had a breach I'm sure you're aware of March 2013 a long time ago so we've been focused on sealing up all the possibilities of making sure that that doesn't happen so we've simplified the registration process we've added a lot more spam prevention systems in place to prevent account creations prevent people from marketing their SEO on Drupal which has pretty high page rank so we're a pretty big target we're tracking engagement so we're trying to figure out who's using the site how are they using the site and how much of the site do they use and using that as a metric to kind of decide we're doing these things to improve the engagement, did it work so this is one of the things we have added our new user role progression so people when they first create an account they're just authenticated but I don't know if anyone's created an account in a long time but I've seen that not a spammer role that people are asking for we have a honeypot module that was often trapping people stopping them from promoting their first question saying oh sorry and it kind of makes people feel not welcome if they're just trying to ask a question and they get shut down so we want to make sure new users are welcome so we have this confirmed option that we're going to be rolling out to the community to be able to confirm other users so there's anybody in IRC that's been around the community a long time could just automatically confirm a new user if they have a problem so kind of spreads the load out and then of course we reworded everything that was worded by volunteers at one point by some really savvy and sharp wordsmiths so these are just some of the ideas that were attached for possible user profile improvements of how like people can actually see what you've done and how you've contributed and who you work for and organization pages didn't know that animation was there so for the improved profiles these are the things we heard in user research of like why people wanted their profiles improved so when you look at someone's page you want to know who they are in the community because hey you should do X and Y and Z it's nice to be able to go to their page and say oh this guy's credible he really knows what he's talking about he's been around for 13 years working on this which is what leads into knowing whether they have expertise in the area you're asking about or they know what they're doing it also helps to know how long they've been a member plus it makes it easier to find other members of the community if like you go to someone's page and they list four other people as mentors you're like well who are these people then maybe you'll see them at a con and be like oh I've seen your page before and you kind of know a little bit more about them and finally just having a page it's kind of like a resume you know to allow people to come and look at your Drupal.org page and say yeah here's my profile here's what I'm doing with Drupal.org I can help your company I can help your clients this is what I know so you can trust their answers and code so some of the improvements that we've already got organization pages we've focused on organization pages this isn't how they look now I need to update this slide and that was another profile thing so organizations they're the key to our growth so both providers and customer organizations so we've got some media companies that build a lot of Drupal sites and we've also got major clients that have a Drupal site on staff like government agencies and other large organizations so we're looking for both Drupal shops as well as customer organizations we want to highlight their contributions we want to turn their contributions into successful case studies to demonstrate to everybody else what you can do with Drupal as they help support modules and themes we want the rest of the world to know and we want to incentivize organizations to help do that to help tend the comments because we've got this great product that's been built out of community effort after 13, 14, 15 years and it's reaching the point that it's so huge that we need all all the time that companies can give us to keep running and keep it going and keep it having momentum so we want to incentivize those companies to participate we want to incentivize companies to send people to Drupal cons and incentivize companies to do things and this is one of the ways that we're going to do it is with organization pages so our content strategy and redesign being responsive is more than just the theme we want the content that people are looking for in the places where they would look for it so we have new content types we're coming up with a better content governance model so there's a lot of content on Drupal.org that there's documentation pages that are out of date there's information that's inaccurate sometimes because we don't really have a gatekeeper of who can post what it's pretty wikipedia free form anybody can add and additionally we're going to add a design system to that so that we can leverage leverage those design pieces the get workflow so how many of you submitting patches to issue queues c1 anybody else work with the issue queues very much this is the initiative that I'm going to be help driving so it's the way that the code is written and the way that code is built on Drupal.org is like I said before it's a kind of an antiquated patch workflow and so we want to move more towards something similar to what github has with pull requests such that we can use leverage the power of get to be able to move change forward on Drupal.org so we've got our canonical project repository and every time an issue gets created we'll start an issue workspace repository so this is instead of like here's my patch there will be a whole it'll almost be like a fork for that entire issue that'll be integrated with the test bots as it is now and there'll still be the issue queue conversation that goes on so additionally contributors will have their own repos which are versions of that issue workspace and we're going to add inline editing to the workflow which will allow users to I mean often times the patch gets submitted and everything's fine but you need to change some spacing and you need to change some vocabulary it'll be a lot easier people can just change that inline rather than clone the whole repo, make another patch and submit it well sort of the I'm going to get into that a little bit it's actually a function of get that it's called issue namespaces it's called get namespaces it allows you to have a whole other set of branches and tags internally to get that is not part of the like if you just clone the base repository you won't see those but if you clone the namespace for that issue you will see those and so it allows kind of another workspace where people can work and not interfere with like wherever the core mainline is happening so it's similar to a pull request but the workspace is created on Drupal.org and then you'll clone that and so instead of forking the module locally you'll do it on Drupal.org kind of like you do with GitHub where you fork and it creates it, it'll do the same thing so one of the things that we heard and why are we doing this instead of moving over to GitHub or something similar well the core contributors didn't feel like the pull requests implemented on GitHub would work for the current workflow so core definitely has a much more collaborative community-based workflow that doesn't would not translate to GitHub but they also know that the workflow that they're used to doesn't help new users come in and there's a 14 step process to make a patch and then another 16 step process to change that patch and add an inner diff so you have to learn about 30 things to be able to even contribute which we want to want to change that, it works now, people have built Drupal on it but we want to make it better so our options were keep everything the same which no one's really happy with or we could move to GitHub or we could switch to a new internal software tool like GitLab or Fabricator or something like that and host it internally or we can modernize our current Drupal network workflow so pull requests not something new, people have been asking for it for years, this is one of those things that comes up again and again so when you look at the slides online this gives a lot of links to all the different places where people have talked about this and options and reasons why but the main thing that we kept coming back to of why not to move to GitHub is that pull requests versus issues there's a fundamental difference in the data model between pull requests and issues with the pull request you have a code delta this is what code we're going to change and then you can discuss that one change if that change isn't adequate or needs to be modified then you have to fork the pull request and then another conversation starts up in another place and if that's not quite right there's another pull request and so the conversation gets forked along with the thing that you're trying to accomplish and so on Drupal.org we don't want that, we want to keep it to where all the conversation happens in the same place and we can keep multiple code deltas associated with one issue workspace so none of those options that we were talking about is moving to get number easy like we can't just move to GitHub with other interdependencies on the inside as far as updates go and other packaging scripts and downloading new modules just moving everything to GitHub would be a lot, a lot, a lot of work plus it would require people to learn some new tools if they aren't using GitHub even though a lot of people are but then somebody might say we're on an island because we're not in GitHub but this is such a hard problem that WordPress hasn't, you know, they're still on Subversion they don't want to rock there about either so it's just migrating as a huge problem so go ahead I'm sure you've considered it but was there another way of using the GitHub API to get what you need in in other words behind the scenes and forth and forth but using the API you fixed that would that, as an alternative to making a whole system? Well, yeah, we had considered that but it again then adds another external dependency to the whole system now we have to rely on GitHub always being there and always working in order for our stuff to work and additionally the integrating with the API part it's just as much, I mean it really only saves us the we still have to have all of the interface on our side that does all the same functionality but then just makes the calls to their API as an alternative to our our function so it ended up being kind of a wash we did look at that so the way that we can do this on Drupal.org is with issue workspaces so this is a modernized version of the current workflow which maintains a collaborative data model that we currently want to maintain so it's not a new idea in fact when they were talking about the great Git migration from CVS years ago this was always part of the plan they were saying we want to have work issue repository and work on code on an issue by issue basis so we're going to update the issue queues to support a pull request like workflow as well as adding inline editing which as I said before will be a huge boom to people that need to make just small changes to things as an initial bonus we can keep the patch based workflow in place because that's what we really want to do is everybody's used to something we don't want to just throw it out and say here's your new tool and everyone has to adapt immediately and be completely disruptive we're going to change this such that you can still submit a patch and in the background it will create an issue work space with a commit on it and other people can come and clone it and pull and you can keep adding patches and it will still work so that's kind of a win as far as like process workflow continuity we don't have to disrupt everybody so this is an example of an actual issue that happened on Drupal Core a number of years ago and here's kind of how it would look like so it starts off Dominer created an issue work space and this is kind of in the future like he would create an issue work space clone it and push that change to his branch on that issue work space so he's got a work space called 1740419 and then Xjam sees his changes and says oh hey you know we can clean this up this patch is good but we just need some other you know change the word in here add some spacing there and so she would use the inline editor instead of submitting another patch like she did before and he pulls her changes says oh okay great that works I'll pull that and I'm going to add some more commands and keep changing things because this doesn't quite work the way I want it to and then this is where currently we have to do patch re-rolls so patch re-rolls would go away because you could just merge back in from head so that you can be like well this thing I'm working on it's out of date let me catch it up so he would work on that work space and then Damian comes along and says oh I want to work on this now so I'm going to pull off the latest and he makes some more commits and those numbers and parentheses are like the actual commit message numbers yes the the question was what about unit testing for the for those patches as people add commits to their repos and then push them back up to the issue workspace that'll trigger the new Drupal CI infrastructure to run test against it which is going to be a lot more robust and have a lot more options as far as I want to change which databases runs on I want to change which PHP options are set those are the kind of things we're looking to expand in the testing infrastructure so that you'll have the ability to kind of move test what you want to test and make sure it works the way you want them to so in this example Dolaner likes Damian's changes and pulled them back in his and moved forward and then Dostro came along and was like oh I have some ideas on how this will work so he pulls the patch or he clones the latest issue workspace adds another commit to it Dolaner comes back to the issue says you know I don't think I want those changes so I don't have to worry about it, I don't have to look at which patch is the latest or what I'll just keep working on my own branch in the issue queue so he added some more patches and then Jay Hodgson comes along and says oh well this needs some documentation edits so let me fix the documentation out of this patch so she can use the inline editor to make the change to the documentation and then Dolaner pulls it back in takes her suggestions pulls him back into his his local branch of the workspace and then when he's done with it he'll say okay I think this is our TDC this is time to push this up to the community and then as Bob takes it he can say okay let's merge all these let's squash all these commits together to make one nice merge commit to say here is this change that's going to affect Drupal Core and he'll merge it and push it back into head and so that's kind of how the new get workflow will work there's we've got a lot to do on that that's probably where we're aiming to have that like implemented so any questions about the get workflow I'm not seeing any hands great so we want to make another initiative is we want to make search usable so our search, yeah like you said pretty much everybody uses Drupal uses Google to search Drupal to find what they need on Drupal and so people want to find what they want to find they want to figure out whether a module is worth using they want to know what modules are available they want to be able to find documentation they want to be able to find a solution to their problems so it's not rocket surgery we can fix this pretty easily we're going to improve the way we have solar setup we're going to improve the way the display modes work so when search results come back from solar it has the relevant information you're looking for in a condensed package we're going to have better facets and this comes back to the content strategy of like when you get a module back what are the pieces of information you might be looking for without a module I mean maybe you just want to filter by D8 modules and that's you know those sorts of things should be available on search and then we also want to make organizations and users show up in search so if someone searches for views you should also respond with Merlin and Chaos profile because he built views for example or anyone who's been maintaining it and in addition with search we also want to improve how people find and select projects so like I was mentioning before this is how you can find out the quality of a project and this is a problem that's kind of universal to the web like I have a lot of products which one's the best one to choose I have a lot of restaurants to go to and I have some in the App Store which one's the best one to choose so there's a lot of design patterns out there that we can follow and emulate and some of those are you know ratings and reviews health metrics things like oh there hasn't been any commitment on this module for two years yet there's been 20 new issues that no one's responding to those sorts of metrics that let us know that this module looks like it's not going to be maintained because and we'll be surfacing that information in a much easier way as opposed to just kind of happen to know what to check for we'll be able to have project comparisons so make it easier to say well which twitter block module do I want which one is going to integrate with the API or which one is going to be just their JavaScript version I just want to be able to reference case studies on project pages so every time a module is used to do something really impressive we want to be able to say oh and this site used it so whenever there's a case study that says these are modules we use to build we want to give credit to the module maintainers that hey you help make NBC.com possible you help make Tesla possible so better tagging and classifications of projects that's again back to our content strategy and our taxonomy of how we'll find projects and modules on Drupal.org and finally Drupal groups so there's some things we heard from user research they want to find out when Drupal events are happening and connecting with other members of the community and making those local user groups and they want to find news and updates from the local groups and they want to know where's the next Drupal user meetup so groups is where a lot of the community happens we want to keep that momentum rolling we want to keep groups is kind of like our meetup.org for Drupal so we want to enhance what's there upgraded to Drupal 7 so we have a lot less maintenance burden and keep its value and expand its value for us so what's next the Drupal.org roadmap we're keeping updates there we're tagging issues in the issue queues with specific tags for what we're working on we're always welcome to volunteer assistance if people have ideas on how these things could work there's pretty much all of these have a community based input phase where we're like okay this is what we think we want to do and we put it out to the community and the community can come back and be like well did you think of this or did you think of that and it's awesome because we have you know hundreds of thousands of people who know what they're doing in our community and so it's great to be able to have that sort of feedback so we appreciate anything that you would want to contribute anyhow is there any questions about Drupal.org and our infrastructure sure you mentioned that you're using a scrum methodology what is the decision making process exactly for example the changes where the organization has a profile and they get credit for what they do the algorithm that's used in edge cases where is it the credit for the individual did it or for the organization or both who makes those decisions it doesn't necessarily come up in our scrums our scrums are really just a daily check in to say who's working on what so but the decision making process on those sort of things we have tech team meetings once a week where we'll have something like that where people are stuck on well this has an impact on how the actual functionality works and so we've got some people who are product owners and managers like Tatiana is the product owner of Drupal.org so she kind of has the final decision authority based off of her knowledge of the community and how things should work of if it comes down to who should get credit on this a user and organization I think there are just some judgment calls internally that people make on those sorts of things but at the same time we definitely put that out to the community any time that has a judgment call we're like okay here's what we think it should do does everyone agree and there's usually an opportunity for the community to get involved and say well actually I don't because if this edge case affects me so that's usually how the process works where is the space for the community input it's in the Drupal.org issue keys so we've got we maintain that as our place as we're working on stuff we put it back in because we don't want to just develop things in a vacuum because we know that the community has built what's there now and it's great and we're just going to drive it forward from there and we definitely want to build something the community doesn't want so we always want community feedback anybody else have any other questions about the future of Drupal.org I see no hands so thanks


So this is all from my side, so Martin, the floor is yours, 40 minutes. Thank you, Özlem, for the introduction. I will talk about a particular type of bias recommendations, which we call inflated recommendations. That's a situation when a product is recommended too often or is recommended to too many consumers. As mentioned by Özlem, this is joint work with my colleague here in Mannheim, Anton Sobolev. So what I want to say is this is an issue of policy relevance, but I don't think that there's anything which should bias me in a major way. And that's what the slide is supposed to tell us. Now, we have a model of bias recommendation. You can think about a firm, say an intermediary who recommends, has to decide whether to recommend a new product to consumers. And there are different types of consumers. And the important ingredient in our model is that there is some extant heterogeneity among consumers. There will be some consumers who can be pleased all of the time, but others cannot be pleased all of the time. And that's one way of reading this phrase, which I've put up here. So a key ingredient of our model is that you can't please all of the people all of the time. Recommendations play an important role in many markets, in particular in the digital economy. We have recommender systems. So these are then algorithmic solutions which tell consumers which kind of products they may want to look at. They may want to buy an important and that's an important ingredient. What we have been seeing in the digital economy is that many of those recommendations are personalized. So they're conditioned on some characteristics of consumers. The kind of recommendations we're looking at here are recommendations for a new product which will be an experience good. So that means consumers are initially, or at least some consumers are initially uncertain about the value, the consumption value they will obtain. And the recommendation becomes biased if consumers end up buying products which are not in their best interest to buy. And clearly in an experience good setting that can be a product which delivers a valuation which is less than the price. I mentioned that there are some policy interest in bias recommendations. We see this in particular in the case of first party content or first party products and to the issue of self-preferencing, but it applies more generally. Also two cases where only third party products are offered, but for example they generate different commissions or they generate different conversion rates. What we aim to do in this paper is not to have a general theory, but a very specific model which allows us to look at a particular type of bias recommendations. And as I mentioned already, the key element here will be some extant heterogeneity. In particular, and this is the basic idea of the model, there will be two types of consumers, some consumers we call flexible consumers. They like this new product, there's some positive valuation they get which is above the cost or above the opportunity cost of providing that product. And this gain, if you think there's some base product out there, this gain is above what the base product can offer. And then there are the picky consumers and for them it depends. So it might be that they very much like the product, but it might be that they have somewhat lower consumption value compared to the flexible consumers. These are then the consumers who can benefit from advice, who can benefit from a recommendation such that they are recommended the product only in case where this new product delivers a good consumption experience. To place this in an e-commerce setting, we are allowing for two distribution channels. There will be a direct distribution channel and an indirect channel, the indirect one. That's when the consumers buy through an intermediary. This intermediary offers is different from selling from the direct purchase in two ways. First, consumers, all consumers obtain a higher benefit using this indirect channel, maybe superior logistics. And the consumers who rely on recommendations, they may benefit from the recommendations provided in the indirect channel. So it's the intermediary who can provide those recommendations. Those recommendations are not available on the direct channel. And in this setting, the intermediary may maximize its profits by inflating recommendations. The inflating recommendations here means that picky consumers receive a recommendation not only when their consumption experience will be good, but also with positive probability when the consumption experience will be not so good. And the reason the intermediary wants to do this, it has to deal with this eccentric heterogeneity of consumers and what it is doing. It is reducing the heterogeneity of the expected consumer valuations for those consumers who buy. And this allows for a better surplus extraction on the consumer side. Intermediary may pick this inflated recommendation outcome. So it means recommending it to some of the picky consumers who dislike the product and all consumers who buy will buy through the indirect channel. So in the sense of thinking about is it efficient where consumers buy. Yes, it is efficient because indirect channel provides the additional consumption benefit over the direct channel. But the inefficiency here is that some of the picky consumers buy who actually dislike the product and that reduces surplus. The other possible outcome is one which we call inefficient bypass. Here the recommendation is not biased and it will be only the picky consumers who actually like the new product will buy the product from the intermediary. The price will be such that the flexible consumers will not buy through the intermediary. They will buy on the direct channel and therefore the inefficiency from a total surplus perspective is that some consumers buy through the less efficient distribution channel. There is a question Martin from Jacques Kramer. So he's asking whether the indirect channel you meant here is for instance buying a game or an app or subscription through the app store rather than directly from through the publisher, for instance, would that also apply to that context. To the extent that these recommendations also matter on the app store. Yes, that is also applicable so you can think it in the in the app store context. I think when I will phrase it I will more I will put it more in an e-commerce setting that you have sellers. For example, a hotel you can book directly on the hotel or you can do it through a hotel booking portal. Okay, so here's a very simple model. We have an experience good, which is introduced in the market. They are picky and flexible consumers. The fraction is exogenous fraction alpha is picky. The picky consumers have high or low valuation here for simplicity just suppose that the probability is one half one half. And then they're the flexible consumers and for this presentation they have some value they derive some consumption value vm and that is greater than the marginal cost of production. Consumers know their type so they know where they're picky or flexible. However, the picky consumers do not know upfront whether the realization will be VH or VL. We're assuming here that the the flexible consumers have a higher expected valuation. And then these valuations are the valuations buying in the direct channel. There's the convenience benefit of buying through the indirect channel B which comes on top and that applies to all consumers. And in addition, what the intermediary does it is providing a recommendation. It's easy to see that the intermediary will always recommend a good match. So the probability of recommending a good match is one and therefore the only parameter the only variable we need here is the variable beta, which is the probability that a bad match is recommended. So when a picky consumer actually has VL which the picky consumer doesn't know but the intermediary knows and the intermediary then can decide to recommend the product to this picky consumer even though the intermediary knows that the valuation is VL and can do so with any positive probability between 0 and 1. So here I put another parameter restriction in there, but I don't think that this is important, but we have to the full analysis depends a little bit on where we are in the parameter space. So here we have the marginal cost being above the expected valuation of a picky consumer buying through the indirect channel. So let me illustrate what that means in terms of willingness to pay. So consider first the case that the intermediate that the recommendation is fully informative. This is beta is equal to zero beta equal to zero means that none of the picky consumers with a bad match receives a recommendation.  They are those consumers who are picky and have a high valuation so they are willing to pay VH plus B. Next come the flexible consumers with a valuation VM plus B. And finally the picky consumers with a bad match with valuation VL plus B. The opposite case would be to have a fully uninformative recommendation say recommend the product to all picky consumers in that case. Picky consumers cannot update their belief and what we have is the the valuation of VM the willingness to pay VM plus B for the flexible consumers and VL plus VH over to plus B for the picky consumers. Okay, and what we see under the assumption that actually this marginal cost is above VL plus VH over to plus B, two prices can be profit maximizing it's either VH plus B, or it is VM plus B. And what we can see then if we want to sell at VM plus B, we can actually do better than having this fully uninformative recommendation policy. We can pick some interior beta so as to equate to equalize the willingness to pay off the flexible consumers with the expected willingness to pay of all picky consumers who receive a recommendation. Okay, and you can see that's of course better than running beta equal to one. Therefore we have two possible outcomes one with inflated recommendation the other one where only the picky consumers with a good match will buy they will then have to pay VH plus B. And the the flexible consumers will be served outside the intermediaries channel outside the indirect channel. Okay, so let me look first at what is the vertically integrated firm so it's one firm which is both selling and doing a recommendation. The recommendation policy as I said is then just this beta the probability of recommending a product to a picky consumer with a bad match and the firm will set prices on the indirect and the direct channel. Consumers observe that type and they decide whether to go to the direct or the indirect channel and if they go to the indirect channel, they receive a recommendation. Important are only the recommendations here for the picky consumers and this recommendation is then used by the consumers to update their beliefs. What I spell out on this page and I think I can rather go through this quickly because I already gave the intuition of what is happening that to potentially optimal strategies inflated recommendation or inefficient bypass. The inefficient bypass outcome is straightforward. So here the price on the indirect channel is the VH plus B as we saw on the in the drawing and the figure. And the price in the direct channel was again is now the full surplus extraction of the flexible consumers and their willingness to pay for the direct channel is the end. Here there's no recommendation bias and we can write down what are the profits of the firm using this strategy. Alternatively, the firm can use the inflated recommendation strategy in which case it will extract the surplus from the flexible consumers and the indirect channel. That's the M plus B everybody who buys will buy in the indirect channel and beta is just picked such that the conditional expected willingness to pay of the picky consumers or those who receive a recommendation is just equal to what's the consumers.   So it depends on the fraction of picky versus flexible consumers where there is inflated recommendation or there is inefficient bypass. So if this fraction of picky consumers is efficiently small, there will be inflated recommendations and otherwise there will be inefficient bypass. It should be clear if they're just there's a very large fraction of picky consumers, then you don't want to give up on the surplus of those picky consumers and want to extract as the as the firm V H plus B, and therefore there will be an efficient bypass. Whereas if that fraction is small, well then you're rather want to enjoy the the price VM plus B instead of VM you can get from the flexible consumers and then do the best to extract surplus from the picky consumers and this is by introducing inflated recommendations. So we can then embed this into the setting where now the intermediary and the seller are not identical. We have now the intermediary formulating a recommendation policy. So this beta is now conditioned on the retail prices. And I believe that that makes a lot of sense recommend a recommender systems recommendations do depend on the prices which are set by sellers. And here we are looking at the intermediary who commits to such a recommendation policy and asked for a share of the profit in the in the indirect channel for from this seller. Second, then given the intermediaries recommendation policy and the price or the profit share it asked from the seller. The seller sets the retail prices on the indirect channel and the direct channel and then the game continues as we have seen before. Consumers learn their types make a choice between the two channels and if they are in the indirect channel they receive a personalized recommendation. What will happen in this model well will exactly the same thing as in the vertical integrated models or the solution will be in a way decentralized. And why that is the case it's easy to see that the sellers outside option is always to sell to flexible consumers in the direct channel so it can sell at VM incur the unit cost see and sell to the fraction one minus alpha consumers. So that's what the seller can make for sure. But the seller cannot make anything on top of that the recommendation policy beta can be formulated such that all the additional surplus which can be extracted from consumers then goes to the intermediary. And this is done by adjusting in the inflated recommendation outcome the lambda in a way that the seller is indifferent as to whether to sell through the indirect channel or whether to pick the outside option. And since we have the same outcome it means we obtain exactly the same critical alpha which separates the case where we have inflated recommendations from the one this inefficient bypass. And this is stated in this proposition here. So again, we have this critical threshold alpha bar. And what the intermediary is doing to implement the inflated recommendation outcome is to have a recommendation policy such that when the seller sets the price in the indirect channel equal to VM plus B. And sets a sufficiently high price in the direct channel it will use inflated recommendations according to beta star. And otherwise it will be completely uninformative. And this is one way of implementing implementing inflated recommendations. The associated welfare in our solution is the blue straight the solid blue line. And clearly here we have an inefficiency and this inefficiency is due to the ex ante heterogeneity of consumers and the borderline cases where there are only picky consumers are only flexible consumers. We obtain the first best outcome but they are welfare losses whenever there is a mix of flexible and picky consumers. So this was my claim that this model really relies on ex ante heterogeneity and the welfare loss is depends on whether we're under inflated recommendations or inefficient bypass the inefficient bypass case. There the welfare loss is due to the fact that some consumers by so the inefficient channel which is the direct channel and the the welfare loss and the inefficient. In the inflated recommendation outcome is that some picky consumers with a bad match by now you may find the model. Particularly in some ways special. The message I want to convey is that this kind of inflated recommendation appears to us a very robust phenomenon relying here on ex ante consumer heterogeneity. So here we have the specific setting just of two types. One type there's this uncertainty it's V H or V L the other one there's no uncertainty so there's a change. There's a difference both in the expected valuation and in the variance. Now you can keep the variance the same and just change the expected valuation. This model becomes somewhat richer. That's why we focused on this one here that different types of inflated recommendation outcomes which can then obtain but the general message that recommendations will be inflated is preserved and this we can also then write down with a continuous type model. Another alternative is to actually work with heterogeneous consumer and ex ante heterogeneous consumer information instead of working on the preferences and also that's the way how we can generate bias recommendation. So in that sense I think we have a the outcome of bias recommendation is not specific to one particular type of modeling ex ante heterogeneity. But ex ante heterogeneity in general is a reason why recommendations will be biased. Let me make a comment on the related literature. I only put up here one reference for each bullet point and I understand that the audience is an expert audience. And there are some other contributions so we do cite a few more papers in the references in the paper but of course if you think that for some strange reason we have overlooked you shout out and we're happy to to improve our exposition on the related literature so quite clearly we are contributing to the literature on recommendation biases. A different way at looking at what we do is call this targeted advertising when you think about advertising a product and as the advertiser or the intermediary deciding on which adds to put. You may have information on consumer characteristics and if you use that information then you can go for targeted advertising what we show here inflated recommendation means that you're not fully targeting you could be provide a better targeting but you decide not to and the reason is that this allows you to sell more units at the general level. This is just an particular instance of Bayesian persuasion what we're doing here looking at the direct and the indirect sales channel is a contribution to analyzing the dual mode and looking at what firms possibly also partially vertically integrated firms optimally do. I was showing you the distribution of the willingness to pay and the derived demand curve depending on the recommendation policy in a way you can see this as a kind of demand rotation or at least yeah you'll just stretch and rotate demand in the sense of Johnson and Myatt and this also relates to paper by Rhodes and Wilson on false advertising where here you can call the recommendation of a bad match as a false advertising if you want. And what we have is that this is an equilibrium phenomenon without any punishments by outsiders for false advertising. Here you want to use this kind of false advertising inflated recommendations because of Exante heterogeneity among consumers and so that's the new our new ingredient. Now if you think about these picky consumers who can have a high valuation or low valuation this you can think about two different states of the world. Then if you recommend the product only in case the valuation is high then you sell the product independently or you can recommend it both if it's VH and VL in which case you're essentially selling the bundle. And what inflated recommendations then is is a mix between selling the product in separately and selling the pure bundle because we're you're selling the product with a good match with probability one and the product with a bad match with some strictly positive probability probability is strictly less than one. In terms of the outcome we have recall that by using these inflated recommendations, the picky consumers will buy the product with strictly positive probability when they experience then a bad match. Now think instead of a refund contract a refund contract is when you sell a product and give the option to consumers after purchase to return it if they didn't like it. Now if we introduce a refund contract where you have only a probabilistic return right then this the outcome is essentially the same as what we have here because then consumers with a bad match will try to use this option to return the product. They only can do so with positive probability and this is then the same thing as those consumers not receiving the recommendation to buy the product and therefore they don't buy it in the first place. So that's our my quick relationship to the literature. What we then do in this paper is to look at a number of regulatory policies where the the regulator imposes restrictions on the recommendation policy. First, suppose that the regulator can fully condition this recommendation beta on the retail prices on PI and PD. And then we move to a much more restrictive recommendation policy, namely one where the intermediary is not allowed to recommend the product to picky consumers with a bad match. And then we introduce a recommendation cap where the interpretation is well this is the regulator is more lenient and allows for up to a certain level it allows for these this inflation to take place. And well, so I think these are the the ones I want to want to mention in this presentation. Now if the the regulator can fully control the recommendation policy without controlling any price or neither the lambda that's the price or the profit share extracted by the intermediary nor the retail prices itself. It is actually able to implement the first best so that means when only when the regulator is more limited in its instruments will we get something which is different from the first best. Now clearly, if the if the regulator imposes a very strict rule, namely that inflation inflated recommendations are not allowed, then we obtain a deviation we obtain a result which is different from the first best. What will happen now if the fraction of picky consumers is sufficiently small, then this policy improves on the laissez-faire, because in the laissez-faire the intermediary would introduce some level of inflated recommendation now this is ruled out. But then the intermediary still prefers to sell to everybody on to choose a policy such that everybody who buys will buy through the indirect channel. However, for some intermediate range alpha, the trade off between selling everything on the indirect channel or having some sales on the direct channel and another fraction on the indirect channel this trade off is different. Now for a smaller critical alpha, do I want to move as the intermediary to the outcome, which is then inefficient bypass and therefore this regulatory policy can backfire and deliver an outcome which is worse than the laissez-faire. And if alpha is then sufficiently large, this policy is neutral, we will get the inefficient bypass outcome in any case. If we allow for recommendation caps which are here conditioning on the alpha, then we can show that this policy weekly improves on the laissez-faire. And here what we get is an intermediate range where the policy allows for some inflation so as to make sure that all trades still happens on the intermediary. And this is then this line which lies above the laissez-faire outcome. What is important for our result to hold is that while prices here depend on the distribution channel, they do not depend on the consumers in the sense that there is no personalized pricing. Clearly if there was a possibility of using personalized pricing, then there wouldn't be any reason to keep consumers outside the indirect channel and this benefit B would materialize. So therefore there wouldn't be also then any reason to inflate recommendations because inflating recommendations reduces total surplus and since personalized pricing allows for surplus extraction in any case, this can't be the optimal thing to do for the intermediary and the seller. And also I think it's important to see what our model does is assuming that there is this new product out there and it can really deliver bad experiences. If there's a large set of products out there such that consumers can always make a good experience, then there is no reason to make a recommendation favor towards a product delivering a bad experience compared to one with a good experience. So that means what we are essentially implicitly assuming is that we don't have a variety of products out there such that all consumers can obtain a high valuation. The intermediate price instruments do not matter here and price parity clauses here are not beneficial for the intermediary. So that means our results do not really rely on this. Now one variation you may think is perhaps more realistic is that the recommendation policy should apply for all alpha. So that means there's a different product categories out there and this with different with the composition of consumers is different and the recommendation policy should they not condition alpha. This means this would imply that inflating recommendation becomes somewhat less attractive, but it will still be an equilibrium outcome. So the critical alpha will be above zero, but less than the critical alpha we have determined here. Perhaps one last thing I want to mention given time is that we also look at platform leakage. Platform leakage is then the situation where consumers can first go to the indirect channel, obtain a recommendation and then still decide to go to the direct channel afterwards. If that applies to a fraction of consumers or not to everybody, but to a fraction of consumers, then what we will actually get is more inflated recommendations. So it's not only that inflated recommendations remain robust on top of that these inflated recommendations hold for a larger set of circumstances. I think I used up the pre-assigned 40 minutes. There's much more one can do and there are quite a number of things we do in the paper. And if you're interested, well, the paper is publicly available. Excellent. Thank you very much, Martin. You are very good on time. Thank you. So Hesky, please floor is yours for five minutes of discussion. So thanks to the organizers for giving me the opportunity to read the paper. I read some of it. It's 90 pages with the appendices. So when Martin said there's plenty more to chew over in the paper, this was not just for effect. There's plenty here. I want to sort of step back from the details for a second and then I'll talk you through my perspective on the paper from the literature that I know. So I was very happy that in the related literature section, Martin put Chemnitz and Genska, which in the version of the paper that I have, there's no reference to, but to some extent, I think that's the closest reference. So, I mean, I think the big picture overview is one that's familiar to this group and has some novel economics, which is the importance of these gatekeepers in managing what retail competition looks like in managing what consumers know. And I think there's been a focus in the last few years on this gatekeeper role in part due to reports like Jacques, if he's still online and others. And this recognition that through their, through, in large part, the information that they provide through consumers, whether that's rankings in positions or information directly is, or opportunity to acquire information is stuff that Fithenton Guillermo and I were thinking about a while back. That has the capacity to influence what demand looks like what prices look like what the nature of competition looks like. And I think these are important questions and finding nice tractable models, where in particular we can think about the effects of policy which is what some of these 90 pages are about a good chunk of that is geared up to try to think about some plausible policies I think is important and is very valuable. Anybody who knows me in these seminars know that I like to start from thinking at specific applications. So that was something that I was missing a little bit in the paper. Are we thinking about Amazon are we thinking about her. What are we thinking about a little bit delicate because consumers have the choice of whether to go to this indirect or direct channel first. And then once they've gone to one channel or another, having observed prices in these channels that that's it that they're done. So that was a little bit hard for me to think about I appreciate the extensions. Much easier for me to think about is what what Martin calls the vertically integrated case. I think actually another interpretation of the vertically integrated case that's a bit more natural to me. It's just to assume away the direct channel. So when I go to Amazon, it never even occurs to me that a lot of the stuff I could buy, I could go and find somewhere else. So in the model, you know, that is just the vertically integrated channel, or you could think of setting be up to infinity or thinking about some comparative statics with be would be relatively easy to implement. But that's a much easier application for me to think about. And I think it brings it a lot closer to existing literature, like whether that literature is cabinet and chance cow or I'm realizing now that I'm very old I still think in terms of Lewis and Savington, you know, who had these models of providing information that was a very specific form of information provision that we then saw evolve with Justin and David's work and there's a very nice version of Lewis and Savington that the, you know, even before cabinet and chance cow that deals with an unstructured format that's an economics letters paper by Alex back, and I can provide translator that just says you know for a monopoly. If I could choose price and if I could choose information, all I'd want to tell you is, is the evaluation above marginal cost or not and then I can extract the full consumer surplus. So, what we have here, I think kind of builds on on those intuitions that, you know, if I'm targeting a price I'm just going to lead you to have an average valuation equal to that price and here what gets me to target specific prices potentially is the presence of this heterogeneity, which I think is very interesting so for me it's like easier to come at it from that way and then introduce the indirect channel. I mean, for a lot of the results for this inflation you don't need the indirect channel at all. And so I think kind of being sorry the direct channel at all and the bypass associated with the with the direct channel. There's these two forms of this inefficiency. So the paper is titled inflated recommendations, but then this other form of inefficiency is buying this stuff directly and paying this higher penalty from not having the convenience of Amazon or whatever it is. And I think if you want to have that second form of inefficiency you have to justify it a lot more discuss what it's relevance it's importance and explore it to a greater extent than than you do. I've probably gone over time already. So I hope that was of some use again the kind of big picture I very much appreciate and in terms of the paper. I think I would start with just ignoring the direct channel. I'll move closer to some existing literature. So Camelich and Jen scowl and stuff like that for me should be the first reference and then move from there, but great stuff.


I am a recovering alcoholic dynatic. September 3rd will be eight years clean and sober. I've had some pretty rough struggles in my past and made some pretty poor choices. I'm a convicted felon for drunk driving. Not too long ago, I was sitting in Tachita and really trying to contemplate on what I was going to do when I was released. It's just amazing the way Nicolay College was able to really embrace me for who I am and not my age or who I was. I believe that it's important for people who struggle with making positive choices in their lives and thinking that they're not good enough and that they're not okay to know that they are good enough and they are okay in expanding your knowledge and starting your education for that matter because in the end you are who matters to you, not anybody else. My name is Kimberly Solter. I am the state ambassador for Nicolay College.


Hi everybody, today we're going to be talking about pico-pico. Hi guys, I'm Lisa Larson, animal communicator and ordained alakai in the Huna tradition. Huna is a Hawaiian philosophy, it's not a religion, it's a philosophy that incorporates shamanic techniques to help heal and there's one specific technique that we're going to be talking about today. It's called pico-pico, P-I-K-O and it means center to center in Hawaiian and this is just going to be a short video but a lot of my clients ask to have me do it because there's a lot of clients that I give this to when I talk to their animals. So what pico-pico is is it's just a short little focusing technique. It means center to center in Hawaiian and the basis of it is that energy flows where attention goes. So any two points that you put energy on, attention is going to flow. So in other words, if you hold your hands out like this and you focus on your right hand and then your left hand and then right and then left and then right and left, you will start to feel the energy flowing through those two places. Energy flows where attention goes. So that's the basics of how this works and what it does is it's just a very short technique that can calm you, center you. I'll use it a lot of times when I'm in the grocery store and there's just all of a sudden too many people or whatever and I just need to to calm it down or I use it to start my meditations. You don't have to use it for meditation but I start my meditations this way and it's not a breathing technique but I do sometimes use breath just to time it. So this is what pico-pico is and you guys can do it with me. When you breathe in, focus on the top of your head. When you breathe out, focus on your navel. Breathe in, focus on the top of your head. Breathe out, focus on your navel. And one more time breathe in, focus on the top of your head. Breathe out and focus on your navel. And if you did that with me, you should just be feeling a little bit more centered, a little bit more relaxed and you can use this at any time. I give this a lot of times to animals who have trouble going out on walks or something. I'll give it to them and I'll give it to the people so that everybody can calm down before the walks or something like that or high anxiety cases. But one of the things that you can do if you use it with your animal is this. You can do it on yourself first just as we just did it and then do it on your animal. They can be lying wherever.  And you would be amazed at how calm you can make your animals when you do this if you really focus on it. And it doesn't take long. I give this a lot where people are trying to have a better relationship with their animals. So I have them do that like every day at the same time. So it'll be something that that animal and that person have to look forward to. Now there is one more step that you can take if that's the case. If you're trying to become closer to an animal, you can do it on yourself first, then do it on the animal and then do it on your heart chakra, their heart chakra, your heart chakra, their heart chakra. Now I'm using the word chakra. It's not really a Hoonah thing, but I think people understand it, your heart center and their heart center and start that flow in between going back and forth. And if it's something that, you know, like I say, you're trying to develop a relationship with an animal, start to do this every day at the same time. So it becomes routine. Animals love routine. If an animal, like I say, there's one dog I work with who has anxiety getting into the car. So she does the pico pico with her dog before they get into the car. Anxiety issues, anything like that. So you can use it for yourself. You can use it for your animal. But remember, it just it is based on that energy flows where attention goes. So you can feel it in doing that little exercise with with your hands. You can do it when in feeling the exercise and doing it with your head to your belly, which are the two center points of our body. And it doesn't take long. Like I say, I start my meditations that way, but you don't have to get into any big meditative state or anything. It's just that simple. It doesn't take long, and you'll be amazed with results. So I just wanted to make a short video for you guys. If you are enjoying this video, please hit that like button and subscribe. That would really help me out. And if you would like to be notified of future videos, go ahead and hit that bell. And I will look forward to seeing you again soon. Take care. Bye bye.


October is Energy Action Month to reinforce energy-saving behaviors. See how some service members do their part to reduce their energy footprint. In support of Energy Action Month, the CFAS Public Works Department held a bike or walk-to-work event complete with Bright the Light bulb and free giveaways. Just always remember that when you're leaving your house, make sure everything's turned off. You're leaving your office at the end of the day. Make sure the light switches off. Your AC is set at the right temperature or your heater is set at the right temperature.  It's all going to help out and it adds up to every year at the end of the year and that supports the installation, which supports the Navy as a whole, which gives us a chance to give you more back. Energy Action Month recognizes the critical role energy plays in our ability to complete our mission. Petty Officer Zachary Hale, Fleet Activities, Sasebo, Japan.