 Good afternoon everybody. Thanks for showing up in, you know, with so many of you. This is a core conversation. We started those, you know, many years ago now, but the goal is for it to be a conversation. So only in five slides. And after those five slides are presented, I would love to, you know, for all of us to discuss some of the things presented in those five slides. The retrospective is something that we tried to do after or around the end of every major release cycle. And the goal is really to learn, you know, about what works and what should we do more of or continue to do, but also what didn't quite work and how can we improve what we do and I think in Drupal we have a culture of, you know, we set a very high bar, I think you're never quite happy. I can remember after the Drupal 7 release, we had these huge release parties all around the world, over a hundred countries. And literally after the release party, people were whining about all the things we didn't do and all the things we should do. And so I think it just speaks to our culture of, you know, not actually always being able to celebrate our successes and all the great things that we did and always trying to push ourselves to do better. And I think we have to do the same with the way we develop Drupal, not just the quality of the software itself, but, you know, how we organize ourselves as a community. And just to go back way in time, you know, many of you may not notice, but, you know, when I started Drupal, it was just a project, you know, for me, it was me building Drupal for my own website. And at some point I decided to make it available as open source. And I literally just created a tar ball uploaded to my site, expected maybe 10 people to download it and install it. And so the way we then collaborated is people would email me patches. And so for the longest time, we had a mailing list Drupal devil. I think we still have it. I don't think anyone uses it anymore. But the way we work was essentially, yeah, sure, email me a patch on mailing list. And other people in the mailing list would look at the patch critique it on the mailing list. And then, you know, like sort of play big one email with patches. And then at some point, we said, you know, we should really use an issue tracker for this. And so that's when we end up building project module, rightly or wrongly. But it is an example of how we evolved our process, right, and how we made it more scalable and scale over time. Another thing that I used to do is like whenever I would make, well, first of all, develop Drupal, pretty much on Drupal.org. So Drupal.org was running head. And so when I would make an API change to Drupal, I would then basically go into the contribute module repository and fix all the modules. So you could literally, like, open every single module, quickly make the API change, commit all the changes. And so if you go to my Drupal file, these random commits in like a whole bunch of modules. And the only thing I really did was make a small API change. Anyway, so that's also something that we've evolved, and that we do much better today. And so, you know, today we're going to start the conversation. I don't think we'll get to, you know, all solutions here today, but we're going to start the conversation for a big perspective, and we're going to start brainstorming some ideas of what we can do differently so that we can, you know, evolve our project. So one of the things we did is we did a survey, and I'll come to the survey results in a second. But before I wanted to talk about the survey results, I wanted to show you this slide that shows some of the things that we have done, things that we have changed during the Drupal 8 release cycle, just to show that we always try to make changes. You know, we never stop making these changes. And so things like we moved to Git, you know, people may not remember, but we used to use CVS, and then we moved to Git, which was a huge, you know, a huge amount of work. We also introduced this idea of initiatives, with initiatives having a goal and a purpose, and there being initiative leads as a way to scale the development of Drupal 4. We really, truly embraced this idea of getting off the islands. So instead of implementing everything ourselves, we started to leverage things like symphony or, you know, libraries like Guzzle and stuff like that. That was more of a cultural change, I would say. We introduced things like core contribution mentoring, you know, where people have mentors for issues that are tagged specifically so, you know, novice people can pick them up more easily. We've already announced semantic versioning, you know, for Drupal 8. Once Drupal 8 is released, we're going to, you know, have minor feature versions and patched versions, and so that will allow continuous integration. We have a dedicated data dot team. The Drupal Association is now helping us with, you know, all of Drupal at org, which back in the day was pretty much a core developers that would also build Drupal.org, which is kind of an artifact of the fact that Drupal.org was always running ahead. We did Drupal 8 accelerate. We raised $250,000 that we used to unblock critical bugs in Drupal 8. We announced some changes to our governance structure as well. And in the process, we had an additional core committers and we formalized some of the roles and responsibilities of each of the core committers. There's people that have, you know, that spend more time on release management. There's people that spend more time on sort of product management and things like that. So we always try to make things better. And so at any given time, you can give feedback or, you know, start the process of trying to make a change. Okay. I think that we did this survey. We had about 48 people respond to the survey, which I thought was pretty good. And a lot of the responses were very thoughtful. Some people really submitted like, I don't know, like multi-page answers. So it shows that people really care. I'm not going to show these answers, but we did summarize them a little bit. And so we asked people these three questions. Basically, what worked well? What didn't work well? And what are some suggestions for improvements that we can make in the future? All right. And so the next slide is a summary of the answers to the first question. So the highlights, and they're ranked by a number of people that basically said this. So the most important highlight is the top. So most people love that we got off the island. And as I mentioned, embracing libraries, removing groupalisms from our code, people loved. But also the fact that we are not contributing to the party projects as well. And that was also mentioned as one of these highlights. Code-based overhaul, adopting PHP-based practices, adopting the object-oriented PHP, people love all of these things. The community is kind of a vague answer. But people absolutely love the way we work and how collaborative we are that we get to gather at events. And just kind of the way we do what we do. Initiatives are interesting because they're both a highlight and a low light. You'll see initiatives also on the low light slide. But people specifically called out, you know, multi-lingual configuration management and views as successful initiatives. And, you know, across these answers, what is clear is what the reason these initiatives are successful, according to the survey results, is because of a plan. People called out the fact that they had regular meetings, that people could join. They also mentioned focus boards and like ways of organizing these initiatives and, you know, getting people, you know, providing insight to others and ways for others to get involved. They all have teams behind these initiatives as well, and strong leaders too. So there's all these ingredients, I think, that we can find across these initiatives and that people called out. The mentoring that we do was a highlight. People called out the, you know, leadership in general, though, you know, from initiative leadership to some of the leadership and then change that we've seen with the core committers as well. I think we do, you know, issue triage calls. I think there's almost a call. Well, there's multiple calls usually every week or all sorts of things get discussed and I could just kind of adopt a more mature way of working. And I think that was working very well. You know, people, different ways of expressing the fact that core developers have financial support, you know, from Drupalier Accelerate to the fact that some organizations employ full-time developers. You know, people thought that was very healthy and, you know, generally wondering how do we do more of that. I think that's a bit of an open question in our community. And then what was nice is that, you know, also several people really liked sort of the end result, you know, that we managed to build, you know, sort of the feeling in Drupalier Accelerate will be, you know, at the great release at the right time with the right set of features. You know, people called out things like Vision Wave or Mobile First or, you know, all sorts of features for a big call. So generally, I think people feel like Drupal 8 will be a solid release. Yes, there's probably lots of things you can do better, but I think overall people feel pretty good about what's in the release. So I guess from a product management point of view, things work that well. Are you ready for the lowlights? Yeah. By far, most people dislike the longer release cycle, which, you know, I think we all agree. People said we did too much. We tried to do too much. It could be a cost or it could be the cost. It could result in this long release cycle. People felt we could do more urban oversight, planning and project management. You know, people expressed that in many different ways, like, you know, lack of clear goals. Some people said we needed to do more requirement gathering in front and more design discussions of front, visual design, but also architecturally and sort of front-loading a lot of these things. You know, that was there and then, you know, schedule and arrangements of release cycle milestones. There's also a very common complaint. People felt like, you know, we started the AAA branch too early. You know, we announced the feature freeze too early. Maybe we should have announced the I3 before feature freeze. Like, various kinds of feedback around the schedule and the release management process. Other people said, you know, the way we work is pretty waterfall. Another comment was that the invada updates took too long. Others suggested that maybe the release shouldn't be blocked on criticals. I'm not expressing any opinions here. Just kind of echoing back what I was in the survey results. Lowlight was also the initiative management. As I mentioned, it was a highlight and a lowlight. Some of the negatives there were some of the initiatives were hard to follow. People couldn't quite figure out what they were doing and how they could get involved. Sometimes lack of technical direction was mentioned or sometimes maybe they were too ambitious. So lots of good lessons learned, I think, from initiatives. Other things were ineffective delegation, you know, too much definition of role to a little definition of role. We saw both of these actually in the results of the of the survey. Difficult to get involved. You know, the signal to noise ratio being very high and just kind of generally overwhelming for people. And then contributor burn-outs, you know. So this idea that the fund got sucked out of, you know, contributing to forth. And of course, that's a very key issue for us. So these are some of the lowlights and we can talk about this as a group in a minute. The third question was, what are some of the suggestions? And what you'll notice is that not all of the lowlights have a suggestion. So it's something that we'll have to circle back on. But there was many, many great suggestions. And again, we kind of summarized and ranked them by how often they were mentioned. But the number one suggestion was, release fewer things sooner. Make changes more granular, as well. You know, people want more small pieces. Do one thing at a time. Personally, a little skeptical about that one. You know, we have 3,000 people contributing. I don't think we can go to doing one thing at a time. But I think what they're trying to say is maybe we want fewer disruptive changes happening at the same time. Maybe it's not quite one, but maybe it's not like a hundred at a time. There's some heavy balance there, probably. Improve or funding is another one. That's a great suggestion. The question with a lot of these is how, right? I didn't do that. And I mean, that's definitely been an active conversation. I'm happy to talk more about that today as well. Improve communication. You know, componentize or decouple, triple, four. And there's, people expressed that in two ways, but primarily it was about the fact that the code was architecturally, that the code was a little bit too tightly coupled. People would love to see smaller components or more isolated components that were maybe more reusable, just like we started to use components from other projects. Can we get to a point where other projects can start to reuse some of our components? And then sometimes people also meant, to a lesser extent, they meant how the core is managed itself. Meaning, maybe it's more about, you know, do we manage it in one gig repo or did we actually split up core in smaller chunks? And each of these chunks could be maintained by, you know, different groups of people. Right? So there's organizationally and architecturally. Improve UX. Quite a few people also pointed out. And then adopt a process for time-based releases, which I happen to talk about in my keynotes. But we can definitely talk more about that as well. Actually, in general, I think the proposal that I made in the keynote, I think, will help with several of these items on the slide. I think it will force us to work in fewer things at the same time. I think the feature branching, some complexity with the mergers, which will make it a little bit more difficult to do a hundred things at the same time. And so we'll have to take a little bit more about when are we going to do what. At the same time, as I mentioned in the Q&A, I don't want to kill this idea of sort of permissionless innovation where people can just, like, get involved and do something great without there being a plan. So yeah. And so with that, I think we can go to the discussion. We have a created a quick Google talk that we're going to try and take notes. That way we track all of your ideas and suggestions and we'll make sure to follow up on all of them. I'd say quick summary of the survey results. What do you think? That's good. Does anyone have any first suggestions, ideas? Is it useful to go back to the previous slide maybe? Just go on to the mic, say your name, and make your point. Someone has to be the first. My name is Erik, BDOTO, Sutorsen. I was missing one thing on your lowlights, but it's related to it. I'm concerned about the time it takes for decisions to be made in this accused past weeks. I've been following and participating in the placeholder descriptions, but in the past as well, issues with hundreds of comments. I get the idea that some people just want to have their opinion in the execute and we only want to make decisions by consensus. I've always been explaining that by the size of the community and the complexity of decisions, but it's a risk, I think, if this gets you along with it. It's related to burnout as well. If you put a lot of time and effort in an issue and it gets solved or it holds and there's a decision that's extremely frustrating. I think it's a great point. I don't have a quick answer. There's no magical solution, but issues, sometimes it's slow, but it's slow for different reasons. Sometimes it's because there's actually no agreement and we can be doing it a little bit of time to figure out the answer. Sometimes it's because the right people aren't in the issue. That can be the source. I think I agree and if we need to break down and think about a quick next step could be to try and break down and figure out what are all of the different reasons why sometimes these issues take so long and which ones are valid and which ones we can figure out solutions for. I think it would be a good exercise to analyze a little bit more. I have no answers to it, but perhaps there are other communities or other discussions for us which do work better. Different tools? Yeah, tools and I think it's also about strategy. How do you come to the decision? Do you wait until every every every idea is in UCQ or do you just take a decision and go from there maybe sometime later a month or hardly later do you change your mind? Well, great feedback. I think it's been an ongoing conversation to be honest over the years. I can revolve the way we decisions have been made. Decisions faster but it's compromising on the quality. It's a very complicated topic obviously. Larry? Hi, this is Larry Garfield, Crell. I agree with everyone who has been stumped on the survey overall. One of the things I want to touch on is on the time management front. A lot of these touch on the tangentially especially early on in the process when we didn't know how long we would have the development, we don't know how long the dev cycle is going to be. That means everyone is thinking in terms of okay what's the most I can possibly do, everyone's thinking big, no one's thinking incremental, and since we don't know when freeze is going to be or we don't know when real freeze is going to be and we don't know when the real real freeze is going to be and you know what I'm talking about that means that the question of do we do this in a quick way or the right way is really hard to answer. And the answer to that was different and for a single issue of do we take the time to refactor this first, do we take the time to make sure this is properly tested, or do we just build something because we have deadlines to deal with, okay the deadline didn't actually happen. So now we go back and do it the right way, no we've got this other thing. So just that pressure of not knowing how much we have to do, not knowing how much time we have to do it in, meant that the code quality I think was very very uneven in terms of how much effort we put into doing things right given not knowing which time we had to do it. And as I said it was extremely uneven from the entire cycle. I'm certainly not going to say I was immune to that myself. That's I think another advantage of December switch for Drupal 8. I hope that when years are now, when we start on Drupal 9, we'll have a tighter known timeline for it as well. Just help us, you know, give us a sense of okay what is that balance point, how can we make that balance point work, when do we take the time to you know do a patch alongside your processes for something, when do we have to do it in one patch. There's better guidance around that, better collective sense around you know what we can do in a lot of time. I think would be extremely helpful for everyone's stress and sadness about this. I agree. At the same time I don't think that just you know communicating dates earlier is really going to change anything. I think I think the feature branching workflow that I discussed in the keynote I think it's going to be more effective. Yeah it's definitely you know multiple facets but I know some of the conversations I had very early back in 2011 were long lines of I don't know how much time we have so let's just go for this and see what happens. It's uncertainty breeds uneven results I guess is what I'm getting at. So having more certainty around the work process and the work timeline will help give us a better co-equality because we know when we can take the time to really invest in something and when we can't. That's something we just never really knew in this cycle. I think it's fair. I think we can always do better communicating. We opened a branch and we said let's just go and then we did announce a feature freeze date you know many months ahead of the actual feature freeze. So you know we did give people that heads up and of course it didn't happen right and so the thing is with the feature freeze like if you if you don't say it then people don't actually either they don't start doing any any work or and then when you do say it of course you miss it so it's like it's really not a very effective way to manage the process to be honest because you know really what it's been like it's been like funneling people through this funnel and screwing the whatever it's called the screws and making them a little tighter along the way down and you know that's something we've been trying to do but it's not a great way. It's definitely more than just announce a date there's more to it than that. It's obvious to a lot of people in the room that your proposal and I think it's more than proposal at this time to make a semantic version we'll address I would say the vast majority of the points in this slide. What about the other points stuff like improved core funding, improved communication, improved UX that are that simply are not a test credit. What's the plan on going further on with it? Especially Eric clearly addressed the improved communication. We might share and we need to pick a lot of issues. There should be a way to copy from somewhere. I think one of the things we briefly discussed this week with a group of people including the other core committers not that that means it's finalized or anything but it's this idea of maybe a special issue that people need to you know submit that basically explains here so I'd like to do roughly how I want to do it. That kind of needs or gets like that thumbs up ahead of time versus people going down the path and then after spending three months six months nine months we're like uh I don't think that's something like sorry is that it? Yeah something like for the tanks for the idea that might be so easy to put into the into the current system we have we could probably improve the system a lot. Yeah we don't need new tools just a relatively small process change and it gives people that like yep you know the core committers look at this and this is something that is forwarding you generally believe this is the right architecture you can include even some design in that you know like this is something that you would look like these kinds of things and then the other thing as it relates to UX I really do think we need to start doing more prototyping early on and you know getting um people to really you know sign off on on these prototypes for these UX mock-ups because that's the other thing that often went wrong like you would just build something and then in the end we would learn that it's not actually very useful. So yeah in our uh in our session on sorry hi I'm Angie in web chick um he did say to Angie so um but yeah in our talk we gave on the the usability testing results the tail end of that talk we spitballed a few ideas around this you know and what normal people do who are building a product is they try really they try to make this loop really fast of building something and then measuring the impact and then learning about that and then building the next thing and trying to do that very very very quickly it's a methodology called lean it's very buzzword compliant um but there's a lot of sense there and we don't do that at all right now we basically build and build and build in this like spiral and then once in a while we have like a university in minnesota come along you give us a dark room in the basement where we can watch people struggle and then we learn a lot but by then we build the thing and we can't really integrate it as well so we've talked about doing some things like for example we have like these uh weekly eurocriticals calls that happen lately like that's a chance for people who are working on critical issues because they're in jam something like a monthly product manager call where it's like get the ux design and product folks have a monthly cadence to them because you're probably gonna need all over the longer window set up an agenda where like this week we're gonna or this time we're gonna handle field ui you get the field ui maintainers involved we look at the ux testing videos and figure out what went wrong we spitball some ideas really quickly and some kind of a prototyping tool and very rapidly get knowledge share between the people who have seen the problems the people who can fix the problems and the people who maintain the subsystems and get synergy happening there sorry i have to stab myself in the face using that word um and then we can do a bunch of other things like for example demo the stuff that's in progress the stuff that's already made it in core get early feedback often because even when we're releasing every six months that's still incredibly slow time to get feedback on what you're doing so anyway when i get back from Barcelona when jubilee is out have more brain space to think about all this but you know boyan louis you know we are they're all aligned with something like this would be really great we need a way to onboard design and ux people because they are not going to battle it out in core issue queue but they would maybe participate in something like this so if you have ideas at least for me they'd love to hear how to make this process better i'd love to see these things happen and frankly i don't think it has to be too hard like just so like we got up the islands with our tools and our codes we kind of have to get up the island with our development process and how we implement things because there are other numbers like years and years of experience of how you build products you know development methodologies like scrum you know all these things and we just need to look at those and figure out how do we you know adapt them to open source not saying that's super easy always but i do think there's a tremendous amount of stuff to learn from but other organizations do whether they're open source or not we're not the first ones to to take any side hi i'm Tilo and i just wanted to say like i discovered it somehow in football one year ago i'm going to say i still struggle to contribute to core so i've read i contribute to some models situation only the bad word then going through the patch system so tooling is very important and one simple but nearly near thing is just using for example tests or i don't know others pre-processing tools that would help improve UX for example or at least the coding on visual side so that's the thing designers do today so i really love the look ahead on each piece seven at the moment so we also have a look ahead for the visual design i think that's one major part of at the moment right so you basically use more modern tools and that will help us attract more more people to help because these are the tools that they will use is that a good summary yeah um they're not tools but they are used to right good advice um you know i guess i can pick up on on a on the previous question a little bit around you know core funding was was brought up as i have another item on the list this is one that i've been pretty passionate about i've done several blog posts trying to encourage other organizations to hire you know full-time core computers and with some success i think you know alex and kathy are two examples which you know two people that have been hired you know to our full-time on core possibly inspired by some of these blog posts but obviously a lot of other people have been doing work in this in this area too um and a good next step here would be to figure out how we can measure the impact of having full-time people on staff and sort of you know trying to quantify it so that it makes sense for others organizations to see like you know chapter three hired alex this was great for us because these are these reasons right it's it's connecting these dogs now i think that will inspire more organizations to do the same obviously the same with kathy and and her employer so like mesh um so i guess that that would be an ask for alex and kathy to try and help figure it out it's not easy but to the extent that we can i think it would help a lot the on the other side the triple association did the d8 accelerator campaign which in many ways was a success you know we were able to raise $250,000 which helped accelerate a lot of the critical you know bug fixing but at the same time you know $250,000 isn't a whole lot of money either and it took a significant effort to raise that money so it wasn't a slam dunk either at least in mind if it worked took a lot of hard work but if i think about what we would really need here is you would probably add the zero to that number and multiply by some number as well so you know if you really want to make sure you know we're building you know we get all of the people that we could use full-time that would be in a completely different ballpark than mine doesn't mean we get there overnight but question there is how do we scale that program how can we get more people to to fund raise and then the third piece of this is that a year ago and people come to Barcelona you know i talked about this idea of selective benefits and kind of more subtle ways to provide incentives for organizations to fund poor development and i still personally believe that that is a good idea and we have made some progress there we have basically commit credits now so for every commit which i was a committer and then who actually funded the work which Drupal shop which digital agency which customer you can specify all of these things and then we translate these credits in benefits like for example yesterday we launched a new marketplace page on the euro and now the marketplace page is listed by no longer alphabetically or some of our best contributors were on page 27 but now they're listed by you know how many commits or how many patches did the help how many issues did the help fix in a time frame basically so these are the things that hopefully will provide a incentive for organizations to tell their employees that yeah sure you you know you can work on on the core for it because here's how we're going to get the benefits and that progress so that is all good we have much more work to do there i would say we've only started to roll out some of these benefits so i think we're trying to attack the problem from multiple handles and yeah i mean i think the other is cultural maybe you know as we build our own companies and as our companies become successful or as they are well funded we you know we should maybe have an expectation that people contribute you know we should we should figure out ways to to make that a standard but you know but that is the accepted behavior no no easy answers on this one i think Hydro is on more and this is more a question than a suggestion but obviously we're then developing any kind of software start on group light needs to be some form of planning at the beginning or inside what more lets this is go into it you know imagine the beginning you know there were the core contributors and the initiative leads and a bunch of other people have been involved i mean maybe there were 100 people really actively involved in that process and then at some point later on the down the line um the kind of the the bulk of the rest of the people less experienced on myself and they were getting involved i mean that turned into a thousand people at some point do you think we got balance right for um you know when when we managed to bring those people in would it have been better if the bulk contributors were more involved in the process earlier or if there was more time with less people getting a real plan together um you know in place so you just didn't come to send in to pay ups really quickly because everyone's on to do a hundred different things great question um probably want to think a little bit about that in terms of um providing an answer um you know i you know i think one of the things we did is we did a survey you know before we started the triple eight development branch and i'm hoping to do one for triple nine too several thousands of people answered the service that i gave us general direction of the kinds of things people wanted to see in triple eight and we could then segment use results by persona developers would like to see this you know non developers would like to see this e-mers would like to see you know this and so we used that data um to then formulate some initiatives but then it was really like identifying the right people to run that initiative that then would make more detailed plans um so that's kind of the way we we approached it i still feel that was directionally the right way to do it um and then over time people would rally behind these initiatives like i think even if it was not an official initiative but you know a lot of people rally behind twig you know people got involved once they knew this is what we wanted to do people started to help um that was also the case in some of these other initiatives um so yeah i'm not sure we could have activated the view of all of these people without some sort of you know without like some concrete direction like here's all the ways you can help but could we have benefited from our planning and upfront design and thinking absolutely so i guess without having thought about the question a lot of things you know i think we did a lot of things right but then there's a lot of room for improvement so um and she was talking about your text testing um this is the minnesota university that does that does the drupal association is paying the university to do that okay maybe uh for me as a developer uh co-op only means about flying people around and taking down bags but maybe you should like put some money to doing text testing and the make down make that more frequent yeah i think it would be great to get more time and effort than money um towards ux testing i mean the truth is that the drupal association is also not like a bag of money you know like there isn't that much money in the drupal association that could be final thing to do for development which is was one of the reasons why we had to raise two hundred fifty thousand dollars to help unblock critical so um you know i think you know so i think while the idea is good i don't know how practical it is for the drupal association to start funding these kinds of things this is the end you just wanted to respond okay um i think that's a good idea i think there's universities who can willing to do this for us for you we should get how far we can that first what i would love to see though is us transition away from the big bang in the way for a university to give us lab space for free and more to have me make a user testing cost that's so lightweight that anyone in the room can do it and we can trust the results and so there's tools that people use like user testing networks like crowdsourced usability testing or we could write up a guide on how to do it so i think the only way we're gonna get the velocity we need is if everyone in this room does this and does it as part of how they do it so i think that's well said like i think you know i think very few organizations have access to these fancy usability labs with you know the mirrored windows and all the tools like most usability testing somebody walking around the hallway of an organization with some paper testing you know i'm not saying that's the solution either but um i think it's i think most of it is really cultural and i'm just making part of the way the way it works just to wrap up yeah i think usability testing is just a black box for me go out in the group room so not for that but for the impression but um quickly um the main unknowns for me during your session was about future crash development and i think this is stacking more than one as you say but it's really um when you when you think about the future the football car would be really nice to have this kind of feature severity and maybe teams working that and the initiative thing was kind of a start that we should really maybe make a survey deeper survey about that great great point thank you so in regards to improve for funding i have to say i just came before this session from a nice panel uh on to on pay contributions that addresses a lot of it and your comment on the new marketplace page i think it's very relevant i think it's one of the only ways that i can that because this is going to be a marketing it's going to be one of the ways that we can get companies to have paid contributors but this gave rise to a new job and we're very bright and and some of us have worked in chipping a major corporation on how to improve our rankings in their front page i think one that knows a bit about SEO kind of knows that and this new change just gave rise to a new job called the Groupal Marketplace Organization Expert and um as an aside one of my mentors Khalid Malaydin he had a company that was amazing for that this company is called Tubits and for years he was the first company that everybody saw on that page uh i'm not saying he did it on purpose but it was nice that he did so i wanted me to fight because i think it works i think what it sorts on and i can pick up one of my modules that nobody uses to start committing to it like crazy and my company is going to rise to first position it's going up from yours five minutes um i'll be stopped it it's not saying that your company should be the first one you know i think first of all i don't think he did that on purpose either you know i think his company was was generally called Tubits many many years before we even had a market marketplace page but yeah that means a great example of how you know as i said some of the best contributors that are name and logo would be on page 97 and then those that maybe don't can contribute at all or very little we get the most visibility which is kind of wrong but sure any of these systems credit systems they're you know they open the door for abuse right and for people gaming the system and so it's something that we'll have to deal with you know i hope that we can also all keep each other honest you know that we have this this you know on our system and if somebody violates the rules by which we like to live then they should be called out for it and hopefully be with them you know undo you know undo the abuse and so yeah very very simple suggestion and i think would defeat my commitment to the salsa module one that's used by like three people it's not been a nice thing though it's mine so one thing that could be done is we do know how many people are using each one and Drupal core of course is the most used one in the country Drupal yet and so if you if you do some kind of waiting on the contributions on that list of how many contributions have been done by company by the usage of the modules or the project that they are contributing to that might defeat well it would truly devise the job of the Drupal market by systemization it's difficult to be really smart about it that's a good idea and along the lines of some you know in my keynote last year i talked about how we can use this system and sort of dial them up all the time based on what we need the most of like for example right now it would have been great if you could have said you know fixing a release walking blood bug is going to get the 10 credits and maybe you know fixing a documentation bug in the module that only two people use is maybe going to get the newer credits but then when we you know once we have released Drupal 8 we could dial up you know people porting modules especially key modules like there's different ways we can you know kind of direct the firehose if you will of where people you know hopefully where people will make a contribution so so i think it's a fair concern people here in the system i'm less worried about to be honest i feel like if somebody who agrees to the number one spot and everybody would be like who are they they would start looking into what they do if it's clear that they're abusing the system i think that would be some sort of you know correction hey michael or schnitzel and i want to turn a bit on the burnout stuff and so larry and me gave a presentation we also made a survey and and we had 75 people responding and 75 percent of these people said that they actually feel burnout or really stressed and for me that number was way too high especially for the future for all of us and what we also did we asked people like if they and know what to do against it and a lot of people just answered no like so a lot of people in the community feel burnout or feel helpless so i think it's a and yeah it's something we should definitely talk about and i know that and the community working group of the of the deposition board currently has it not on the list it's more about fighting conflicts or come first and working with conflicts but i think that's the right place and but overall i feel like if anybody that they that survey and feels like that i think i might be all excited really right in the in the keynote this morning and to seek help and help doesn't mean that you have to run to your doctor doesn't mean to leave noses just talk about it and and if you're more interested and g and just twitter account is full of basically and and a write down of what we talked about reading this into the video but i think it's something that really astonish me that there's so many people there and have that or in the situation i think it's a very important topic and i'm not an expert on burnout to be honest but i think it's great that we talk about it i think we i think it's great that at group of cons we have sessions about it that helps people you know learn about it and figure out ways to prevent it i think some of it is self-inflicted as well i think you know people have to learn how to step out of a situation that's not healthy and it's sometimes very difficult when you feel a lot of pressure right but some of some of it is something that you know people themselves have to learn you know i've been shared in stuff lately but i had a burnout once probably nine years ago it's the only time or last time but at a burnout and you know i didn't handle it well it's i kind of stumbled in it and all of a sudden you know i had a burnout and i really had to step away i didn't think i stepped away from poor development for about a month and i think they learned me a lot of things so sometimes at least for me sadly it's like i have to cross that line to learn if you can prevent that from happening i think that would be great people you know there's things we can do you know like very simple rule should probably be that people in key positions they should they shouldn't be the only person being able to do that job like if we can to rank them with people that can help them if there are a team versus an individual i think it will really give people a bit of space to say i need to step out of this part or if he needs to you know to get to get healthy or to get a better place so and that's also frankly another piece of this is why we have to keep evolving our process all the time to learn because i think um and maybe i'm speaking for myself more than you know like generalizing but at least for me i don't mind doing hard work you know working long days as long as it doesn't feel endless you know as long as i see i have to do this for some time and then after that while you know there's it's going to be better it's going to be different but it's if it's if it if you don't have that you know it's going to be different it's going to be better i think then i think it really increases the risk of burden so we need to evolve our processes to avoid that from happening anyway i'm not the expert on this but right i agree it's mike potter um i i see a common theme in a lot of these things um whether you know i think your your release feature releases address it a little bit but like when andy was talking about the ux stuff and we don't need to wait until we get some huge lab to do it um you know we talked about these issues that go on for you know 300 posts because we can't resolve something i think a lot of us and myself included tend to be a little bit perfectionist and we kind of wait until we can get the perfect solution and in all these things we just need to adopt a more iterative approach um agile whatever if it's just iterative but it's amatade gave a talk on visual regression a few hours ago and he talked about you know hey 40 percent is better than zero percent you don't need to wait to do testing until you can solve it all and do a hundred percent and i think in all these things that we can just kind of be a little bit better about saying yeah you know what in this issue you know this makes it better let's do that and you know create another issue to make it better just keep making things better in all of these initiatives and not get blocked on on waiting perfect i think that's very true um that's what they say perfect is the enemy of the good right so i think that's the part of all the points thank you i'm christian jesner on the own journey to get up um i think the sort of the thing about how we bit off a lot and it took a long time to chew is is something a lot of people have mentioned and what i've been thinking about a lot lately is that that's that's not just the amount we have time but it's the amount that we all still have the time in the future as we now look at supporting all these concrete models and that's that's where relevant to being a lot of the people i'm trying to where i feel like i know quite a bit about d7 but two blades just seems like this big mountain that i don't know anything about yet so that seems like this just something i wanted to mention is continuing to have relevance and that relevance is about to get a lot bigger as soon as i'm over seven rolls around so is there is that is there sort i know and i know there's a lot of stuff i'm going to tackle that but it seems like it's about to be a lot bigger problem are we focused on that yet or are we going to i'm just hoping we don't all just take a break as soon as the rc comes out um yeah i mean we're and there's a lot of things being done before i go there like if you look at the you know if you look at the the past early cycles and this is actually important for people to remember i think you know as you get closer to the release and as we do the release people are really excited right it's like takes all this energy but then what happens is that that that kind of follows um like the Gartner hype cycle if you know if you guys see this and so this excitement then like goes down and that's usually where we have the darkest moment of truth it's like when people have to start pouring the modules and when people have to relearn everything that they know which kind of will happen like you know once actually people is released and then it may take you know months for us to get you know back out of that um that and it's it's during these times usually after the release of people starts um getting all worked up and you know we'll see blog posts that are you know forking and all the things we did wrong because we will get tired for a while so just want you to keep that in mind that actually if you look at the curve you know this is a pretty happy time i really think it is maybe not for the court contributors but you know just from in general as a community you know i think obviously like the court contributors are doing a lot and they're working hard they're just tired but that will like you know other people will you know start to feel like waiting and that's something i shouldn't forget so but we are doing things you know books are being written actually i asked in a tweet you know who's writing a triple eight book i think there's almost uh i think it was a little over 10 books right now that are being written so documentation is coming people are contributing documentation too um you know most of the companies that provide training already have some triple eight training or are in the middle of you know providing more trainings or trying to do a lot of things to to enable i think most of the sessions here are also about triple eight you know which will also help but it is a big mission because can i imagine let's say there's 200,000 Drupal developers in the world you know i don't know if that's the right number but it could easily be you know 100,000 or something like now we have to retrain 100,000 people on on you know triple eight so that's a lot of work and we'll be thankful so all right we have a couple more minutes so let's do these uh yeah do you have any more questions maybe john snow uh that's my real name winter is coming anyway comment comment is about the feature branch development uh other projects have found that long running feature branches tend to be hard to manage hard to merge in harder to review keeping feature branches small seems to be the sweet spot between trunk-based development feature branch development and one way they've found to help with that is the feature toggles or feature flags that allow partially complete features to be merged in but remain disabled is there any chance we could move towards something like that yeah we're talking a lot about this actually and you know we've already kind of you know we've already said that we should when we do feature branches we should really focus on what is the minimum viable version of this feature or how can you chunk off the feature into smaller steps where each step is a shipable you know it is a shipable result in a shipable Drupal 8 doesn't mean the feature is complete but i don't know maybe if you think about layout management to keep it simple you know there's multiple steps involved there there's maybe a layout manager and then there's a layout ui and you know two chunks there but maybe there's even smaller terms so we could ship Drupal a future version of Drupal just with the with the management layer and without the ui layer you know i think a future version so how can we make you know chunk large features into you know shipable sub-desks this one the other thing we've talked about is actually having sandboxes which is where you know teams or individuals who develop features then you know the contributors will then still give patches to the core committers core committers with review you know bite size patches and commit them to the feature branch over the core committers are to actually commit to the feature branch so that way they review a feature every step along the way and then provide a feedback every step along the way so when it comes to emerge technically you don't have to do the whole review process again you've already kind of reviewed every step along the way so just do things that we've been we've talked about without a doubt we'll have a lot more things to learn as we go oh hi yeah um Alex from here um just wanted to kind of reiterate the point but it's just being made about feature branches and i'm not sure that they're the correct analysis of what went wrong or what made this cycle so wrong i think the truth is is that we're really bad at knowing how much work we have to do when we get changed and we assume that when we make that minimal change that we've got a green test run and that's it it's done but so often this cycle what's has seemed a small scope of change has turned out to be something that has been required twice or three times as much follow up so i'm really saying like that the the decisions are open a feature branch the decision to start to make changes where we have to invest more resources and that's a valid point as well i think the advantage of a feature branch is as i explained in the keynote like if something does take twice as long or three times as long it doesn't actually hold up other features right so if you continue to make releases so it will give more predictability more frequent releases yeah we need to you know we need to your point we need to take more upfront about how something will work at the same time except that we can always figure these things out and it's really hard to to predict almost what the impact will be in every aspect of Drupal but the total impact of the feature will be on performance like some of these things you can only know at the end right so i think the i think you know i think we're limited a little bit in what we can do upfront as well i was just gonna respond to the point for a couple of minutes ago this is Angie apparently i love this microphone um about contraband now people are kind of like that definitely is the next wave of things we gotta worry about so i just wanted to bring awareness to a few things that are happening around that so the first one is Drupal module operator module actually works again thank you Peter Preneson and that module is awesome because it will scan your module it will tell you here the specific change records that affect to you so you don't have to look through that enormous list and if you want it will automatically convert some basic stuff like info to yaml and plugins to blocks and this kind of stuff so definitely start with that if you're panicking because it's a good tool to learn some about jubilee if you've kind of been not involved in it recently the second big thing i wanted to point out is that the coding allows last night until three in the morning we're working on a new contrib project called contrib underscore tracker this is going to be a central issue queue to track projects in issues among the reporting statuses so that people no longer have to have a spreadsheet for every single product that they're working on about where's this module at jubilee where do i find the code this kind of thing so one place for the community to bring down all that information and we're hoping that this will help not only with jubilee adoption but also just like tease little details out of people's heads and give one place for all that information to filter up that's community wide so that is hopefully launching tonight and then try and put a blog post together and then if you're interested in working on something cool with his friends tomorrow filling that tracker out with all the major modules would be awesome so that's awesome well thank you everybody thanks for thanks for thanks for showing up on gary you know thanks for willing to to make people better as i mentioned in the beginning we don't have all the answers this is just the start of a conversation i think and you know but let's all work together and figuring out what exactly you want to change and how you want to change it so thank you i think next is the closing session if you guys are interested in that we're going to make some announcements about where the next couple cons will be and so it'd be fun all right thank you