 So let's discuss this very important topic today, which is about creating a new user-facing core team slash creating a new design for Drupal Core. So just a disclaimer, this presentation is non-technical. We won't discuss any of the technical details about the implementation. I won't be offended if you leave at this point. You can discuss your technical details with the other people outside of the room, but not here, not today. I will have another presentation tomorrow, where there will be plenty of technical details included in the session. So let's start with the why, because that is the common question, why would someone want to have a new design in Drupal Core? So the first reason that I would have is that we need to improve our first-time user experience. We want to give the users that we have somehow got to try Drupal to actually stay using Drupal. So we should give them good user experience. The first five minutes that we give for the users should matter. Maybe they won't use Drupal again. This is always just about the one person who is trying out Drupal. It's also about the people that they are going to tell about Drupal. So it might affect multiple people than just the one person trying out Drupal. Also, we should have design and brand that supports our technical capabilities. So whenever someone looks at Drupal, it should look like what you can build with Drupal, so that they get an idea what is it all about. Because as we are going to see soon, it probably doesn't really represent how we would see Drupal as a software. So I just wanted to make a short demo about how this different open source CMS default team designs look like. I'm not trying to hurt anyone. I'm not trying to tell that anyone has done bad job by designing. I'm just trying to point out that maybe there is a need to think about something like this. So let's start with very popular fellow competitor, WordPress. This is the design that they have currently. This is how WordPress looks right after installing it. So you can see that they have a little bit of content, but the design itself is very, very plain and very, I would say it's not complicated at all, very simple, but it still represents something relatively modern. Something like this would be very easy to build in Drupal. I think one front-end developer could build something like this in a week of full-time. So good design doesn't always have to be complicated. It can be simple as long as it represents modern values. Also, WordPress works pretty well on the mobile. You can see that some of the things are put away at this point, but especially on the mobile, this is very, very simple. This is Concrete 5. They have little bit more design elements on their site, so they would have a slider and they have some blocks where they are demonstrating what you could do with that system. Also, this is pretty simple design. There's nothing complicated or fancy again, but they've brought a little bit more complicated elements on the site compared to the WordPress, which doesn't have anything at all. Also, you can see on the top the menu, so they are demonstrating different kind of features by default that you could build using that system, which can be also pretty handy. This is also because sometimes we think that if we want to build, so what we want Drupal to be out of box, has to represent something that is realistic. It doesn't have to be anything realistic. This is absolutely just a showcase. This is not a real website, but it's a showcase of different features that you could build using this system. So we don't have to build anything realistic. It can be purely on demonstration purposes, like this is. Also, this system works fairly well on the mobile devices, so everything has been designed pretty well for the mobile. Next one is Joomla, and as we can see the designs are getting a little bit more rough, but you can see that they are also having a little bit of pictures over there. They have also default content, and actually Joomla even allows you to configure while installing what kind of default content do you want to show on the site. I don't know why, but they allow you to choose a team that you want to use for demonstrating the site. You can see a little bit of different kind of elements, components on the site, so that's what they provide for their users. That also works pretty well on the mobile device, but what I was surprised in the most part because it didn't look like mobile first design, at least for me, for some reason. Anyway, it was working pretty well, and this is what you get when you install Drupal. So when we look at this, I don't think the design says much. We have blue, we have white, and we have black, and we tell our users welcome to whatever site they've built, and that's all. So this doesn't demonstrate at all what Drupal could build. This doesn't represent any of the technical features that we have or advantages that we have. This is all that we show to them. And the thing that I most like is that by default, there is like an RSS link on the front page. That's absolutely the most important feature to have on the front page. Yeah, that's a sign of a modern system. Yeah, and on mobile, yeah, I mean, it's the same, and yeah, you can see how this design was created. Like first, there was something, and then it was put into another form, and yeah. It's very, very messy on the mobile currently at the most part. So because of this, the plan is to create a new Drupal default team. One thing that I forgot to mention was that during preparing the presentation for DrupalCon New Orleans, me and Scott went to look out first time for the order open source platforms. And that was when I at least realized that there is some huge demand for having a better design because while we were evaluating how modern their teaming capabilities were, we found out that how their system was designed was somehow affecting how we were thinking how modern the system was. Like it was not a rational way of thinking about their system at all, but it was easy to realize after a while. And then of course, some re-evaluation had to be done. Also, these systems were only open source competitors. If you go look at the more systems that are funded, who are having corporations behind them, they usually have even well-built designs and they are able to demonstrate a whole bunch of different kind of use cases using their systems. Like Angie was giving presentation this morning and she was showing something built on wigs and other systems and it was like they could have like tens of different showcases built using their systems, which is pretty interesting. It's pretty convincing that their system is good for building something that is beautiful. But let's proceed for what is happening with this topic in Interpol trying to create a new design. So I'm going to quickly go through the proposed roadmap for the initiative. And then after that, we can discuss some of the topics that the people who has been working on the initiative think are blocking this initiative the most. So the first step that we have is choosing a designer since none of the people working on this initiative are really willing to do the design for this team. At this point, we would also create some kind of initial design, very, very rough, just with the minimum provided resources that we could. Just some kind of an idea that what could it be and then we could validate that. The second phase, the phase B, would be to create the initial design with the form team. At this point, we would create the design principles and values and some of the page concepts. And we would provide that for the public feedback for a couple of weeks, allowing the community to provide feedback. And this is a crucial part of the proposed roadmap that we would be working privately and we would be providing something that we will propose for the community. And they can provide feedback. And as part of the proposal is that the initiative team can either do something with the feedback or they don't have to do anything with the feedback if they decide to do so. So not all the feedback has to be addressed necessarily. That's obviously a risk always for the team to proceed if there is open concerns on something. But if the team thinks that something is not a valid concern at that stage, they could totally proceed without replying to some of the concerns. After that, we would start creating a prototype out of the detail as part of creating the detailed design. That would mean creating a style guide, deciding on the typography, the colors, and different kind of graphic elements. And then we would also get feedback on that for maybe two or four weeks. After creating all of these different resources and being able to validate them with the community, we would start to build the team. And this is the part where technical things would start to happen. Before that, everything is pretty much non-technical. So at this point, we would create integration for the design into a Drupal team. This would be the part where we create kind of like a minimum viable product, something that we can introduce as an experimental team. I don't know if that's even a thing, but maybe we could make it a thing. Where we would include form stylings, front page styling, probably note page, user, and taxonomy pages. And that would be all at that point. After making all of these things happen, these are the most common use cases. We could create support for the less common use cases, such as form, module, and orders. And the last pace of the initiative would be bringing the team into stable, not into stable team, but making it stable instead. And at this stage, we might have to make some changes for the installation profile because of some of the things related for the content as to be done in the installation profile instead of on the team. Clearly, there is another initiative happening same time about default content. So at this point, we would review what things do we have to do as part of this and what things would have to be done as part of the other initiative. Maybe there are some other things that we want to do as part of this thing, providing some views or something like that. It doesn't necessarily have to be content at this stage. And at this point, we would also mature that team into a stable front-end team that could be chosen as Drupal's default team. That's the current plan. But obviously, plans might change. So I think we could discuss what's happening. So the first serious topic that I have, this is what I actually realized today was that is one design going to be enough for us? Because if probably after we have made this design happen, also our fellow competitors has made some kind of moves. Looking at the proprietary CMSs at this moment, because all of them seem to be going to this direction, that they are demonstrating their systems using multiple different designs, I would expecting that other open source systems would go into that direction while we are trying to create our design. So would it be enough at that point to have only one design or should we have multiple? And now I'm expecting someone to come say, please make just one design first and then make another? Yeah, maybe that's a valid point also. But as I showed earlier that what verpers has, it doesn't always have to be very complicated. It can be starting from very simple things. We can demonstrate using very simple design principles. It doesn't necessarily mean that it's technically something complicated. So any thoughts about this topic? Is one design enough or can you use the mic? And if you could also introduce yourself first. I'm Christina Chimillas. I'm a designer and front-end developer. And I think that sometimes if that's open, sometimes if you give too many options, it's not the good choice. Because just remember color. You have a lot of opportunities to create great themes. But you actually give someone that maybe doesn't have enough design skills to create it. So I don't know. Maybe too much options is not the best. Of course, if there is enough hands for do it. Yeah, I think that is a very valid point that making more things might make it less attractive than making just the one thing. Like color module is a good example of something that probably easily makes things less attractive because it makes it multiple. I don't know if it's because of that or because of color module. Actually, I just want to comment one more thing. We discussed with a bunch of people earlier, will we be willing to decrease the level of expectation that we've set to Bartik that we will set for this new team? And there were at least the people that I talked at that point. It was Jess, Angie, Boyan. All we agreed that we would be willing to set the barrier lower. Like we wouldn't set all these expectations for this new team. That it has to work with color module. It has to be something that people can build their team on and all of these things. Go ahead. Yeah, Andy, my Pixelmort on Drupal.org. So I think it would be good to have at least a couple of options. I don't want to go crazy or anything. But if I read that sentence, I think there will be different default content versions to visualize different things. Otherwise it will be just bloated and you will not recognize the purpose that was intended with the content. And I think the same goes for the design. So that you see that Drupal is really versatile. You need to do something that is a little bit different. And maybe it also takes a little bit of the pressure of the theme initially. Because then one theme can be good with one type of content and the other one can be good at that point. And then maybe later on in the next step it can be both themes or all three themes or what we are envisioning can be good with both use cases and both contents then later on. But first it will be a good step that you show. Because that's one of the strong suits of Drupal that you can build almost anything. And if you show that only with one theme and only one set of content then yeah. So it's then a better theme but that's also. Yeah, just to summarize it's kind of like I guess what you were saying is is this a problem or is this a solution for a problem to have multiple designs kind of. Yeah. So I'm Gabor Hoichi and I have like 10 different things and it's hard to tell what kind of other questions you're going to have. So like it's hard to like position the feedback correctly. But I think you are already standing up to do a brand new thing in and of itself. So if you can concentrate on doing it in one way for now is a smaller battle to fight than trying to fight the much bigger battle initially. So I think even figuring out the process and how you do this for one thing, for one is good. And then we can move on. And for now we can assume that this is not going to be perfect. So the other thing for the lowering the barrier is what WordPress does well is that they psychologically tell you that they're going to expire their themes. So they name their theme after the year. And the next year it's outdated because it's the previous year's name. So they come up with another one for that year and another one for the next year. So they have the cycle of redoing it every year. And then they don't have this expectation that it needs to work five years ahead and it needs to support every magic technology on earth and it needs to support every use case. And they can work on one demonstration use case that it fits and the next year it's replaced anyway. So if you don't like it, you need to live with that for like five months after whatever release comes out with that but then it's going to be replaced anyway. Yeah. So I think the process you've outlined may or may not take a long time. And the shorter time we can figure out to go through this process, the shorter we can produce something new. And if it's not good, then we'll get that feedback anyway because we put it out there and we'll see and then we can do something new again. Yeah. That makes sense. You stole my point, Gabor. My name's David Eatings. Eatings is my handle, not my last name, sorry. David Huang, sorry. Like Gabor said, the timeliness of it, I think is the important part. If we can show to the community that there are more coming along the way and we can deliver this first one quickly and then there's going to be iterations or a completely new version if this first one doesn't do well, I think that's going to be more meaningful than capturing something really great at the first. Like we should, as a community, accept that the first one might even suck but we'll get it out quickly and we'll go through this process. And, oh, I'm stealing your point, okay, great. We'll just steal each other's points. If we can do this quickly and demonstrate that the process works and ship something, even if it's not good, it'll move the momentum so much further than, that all the crazy bike shedding that we could have for trying to do the mother of all themes. Yeah, that's a very interesting point because of, I guess, many of us would like to, do it just like you're saying, but for me, it sounds like it's something that is easier said than done in their real life because you see on the issue queue how things tend to go quite often. So I think one reason people bike shed a lot in the issue queue is they're worried that they're going to have to live with it forever, right? Bartek hasn't fundamentally changed for six years and everybody thinks, oh, shit, I got to live with this for another six years. I better get my two cents in now and if I don't get it, I'll die screaming, right? Yeah. But if they know it's going to be just one of many up to come, that leaves that pressure. Yeah, that makes sense now, even more. Hi, I'm Chris from Fligen. So my idea is, since we talked about we should have a design guy. So with one design guy, but maybe we can have different like a layout or different design following the same design guy, but different layout can be, can for different purpose. So we can demonstrate this layout or design is suitable for blogger and the other layout maybe for enterprise. So we can have one design, but have different layout. So if possible, they are not totally different design, but like different, for example, the Android, they have changed their design guy very often, but they always use the same design guy for the entire product line. Yeah, so that's a little bit like what Concrete Five is doing, little bit similar kind of mindset that they're using the same design to provide different experience on all these different pages. My name is Roy. Following up on that, the main point was like we should do one thing and then see how it works and then do it the right way for next themes or next ideas. I still think it would be good to have multiple designs or use cases so that we can show the range that we're aiming to fill to cater for. And then we can be very explicit and now we're starting with this case, say the farmer's market as it's used in the user guide, for example, with sample content. So, because if we don't make a specific choice in the use case we're catering for, we'll get the WordPress version, right? Yes. Which is a blank slate, a good looking blank slate with no character and no specifics. Well, blank is a character as well. So if we at least outline the possible design directions or use cases, portfolio, shop, whatever, small NGO, et cetera, and say, and we're focusing on this one first, then we have been clear about making that decision and trade off. We're clear about and we have others we can work on. But that's not this one we're working on. Yeah. Yeah. That was a very good point. Any other comments about this point anyone wanna make or I guess we can move to the next one. Which already was discussed by a few of us, which is like how often should the design be updated and what should trigger that to happen. And so there was a little bit of a conversation that part of the problem is that we didn't have a new design when we launched Drupal 8. But I'm not sure if that is the actual problem or if the actual problem is that the design is just outdated. So it would be good to discuss how often should these designs be updated and what should trigger that to happen. Any points for this one? Gabor brought up yearly, but as Roy also mentioned we should have several designs. I think we should just accept three or four designs and say, okay, this one's 2014 or I guess 2014 we'd have it done by now. This one's 2017, this one is 2018 and this one's slated for 2019 unless more people come and join. I mean, that'd be a great problem to have, to have multiple teams compete to finish theirs first. I mean, that would be amazing if we could have that, but lack of that, we should just say, oh yeah, these are all coming at three different times and you can look forward to seeing these at various states of completion in the coming year. So yeah, I don't think we should have one design to work with. I should just take them all and slate them. So I know this sounds like Donald Trump, but I've, some people say, a lot of, now some people say, I've heard people say that maybe it's too early to do this and we should do this for Drupal 9 instead. And Drupal 9 maybe around the corner, which I don't agree with anyway. So then maybe by the time we finish this whole process Drupal 9 will be here and then we'll have something new in Drupal 8 and then like a half year later we're gonna have Drupal 9 and we'll need to do something new we have again in Drupal 9. I don't think that, I think that, so I heard that said from a few people, but I don't think Drupal 9 is that close. I don't think it's a problem if we replace it in six months, like why not? I don't necessarily think that Drupal 9 needs a new one right away. Depends on how Drupal 9 folds out. And I don't think we should wait until Drupal 9 with this. I think we should have done this earlier. So like we should have already done this. So like it's better to do it sooner than later. I'm not sure if there is like a concrete trigger point that it needs to be changed. Yeah, so just like someone said very precise one year, that's a very, very concrete trigger for a new design. So that helps. So if you just had a deadline that helps, yes, that helps set things in motion because then it sets up the expectations as well as what's gonna happen, but they can do this because they have a vast source of people doing designs. And we could say like one year we're gonna replace it, but then if there's nobody working on it, then we're like, what happens now? So if we are in that lucky position that there's multiple people lined up to do something, then that sounds good. And there has been quite a few people working on the front end issues, but the effort has went to maintaining what we already have instead of building something new because building something new has been very difficult. It's a huge process. I'm not contesting that there's not a lot of hordes of people who are technically capable of doing this. I'm contesting that there's people just afraid of the core process and or just don't have the time to endure. Yeah, that makes sense. Makes total sense because it's not easy. And especially with something like team, the core process is horrible because you need to involve in this process the scariest people in the community. You need to have the total, everyone from the up till the down involved in this process. So it's as complicated as something could get. Yeah, so back to your point, if we set a schedule ahead of time, then that makes it explicit that there's not like a request from you, the person, the random community person that we should do something new, but it's kind of an expectation that we're gonna do something new. So if we agree on that ahead of time, that makes it easier to start off these new things. Yeah. Just a random-ish idea about what could be a trigger. What if media initiative has a well-rounded complete-ish solution in 8.4 or 8.5? Couldn't that be a trigger to update the portfolio theme design to showcase? It's not an admin theme, so. But to showcase those new specific capabilities. So that might be something that could help decide which one to evolve next because new features. Yeah. I think new feature is totally a valid trigger for something like this because that's usually what you wanna promote. Yeah. And new design is totally a good way to promote something like that. Then the second sentence, do we then need to repeat this entire process for Drupal 9? Sounds like you're already like, oh. And that's probably more like a culture shift. We're continuously re-architecting Drupal 8, at least, right? We're adding features. We're deprecating things and reworking things. I think the same idea, same mentality should be brought to design. We're constantly redesigning. The whole world is constantly redesigning. And how to do that is another thing, like lowering the barriers and having multiple options, et cetera. But I think if we can somehow get that point home by iterating on that idea of we're constantly redesigning, that would help getting more done faster. Yeah. Makes sense. Any more comments for this one? I guess not. We can proceed to the next one, which is a big issue, at least. So it's when we want to make these designs happen, how are we going to get designers involved in Drupal? Because Drupal is not a very designer-centric community. How could we attract designers to do something for us? So one of the ideas was that companies might be interested in sponsoring their designers to do something. But probably that's not the good way in terms if you wanna make it sustainable for a long time that we trust on one company or two companies to do it. Instead, we want to have healthy community around the design in Drupal. Like, I think we have a healthy community around usability right now in Drupal. Like, probably we could use some more hands. Always. Like, I guess any of us could agree with that. Yeah, like there is a process around it. There are some people that are working on it and yeah. So, does anyone have any ideas how could we get some designers involved? So, so I can tell one extra comment that our community is very scary for many designers. Like, we scare many of the designers out once they come inside our community. So that might be one of my personal opinions why designers don't come. But that doesn't answer the question why or how are we going to get them inside our community. One, have a very clear briefing. Two, with a very specific limited scope because we go on and on and on, right? And that's a scary bit, right? We don't stop, use 300 comments to redesign a single page if we want to. And it's not done, right? So, at the very least, one of the requirements would be to box in the assignment or the briefing what we ask people to give because that's what we're doing. And one of the other ways to do that is to think to be very clear in that that person creates an initial design and then is not be very clear. You're not, we're not asking you to do all the implementation details. We ask you to transition to kind of like an art director role where we maybe can have bi-weekly calls and get your question, get questions, answer it. How do it like this? What should the RSS feed icon look like? Wow, figure it out, guys. Yeah, limit the scope of what you're asking people to do. And then the team, T-E-A-M, the core team around this theme should be the protective layer, I guess. So that should be the main interface this person is working to probably shield him or her from the larger community, at least in some sense. Thank you. I was just gonna add that. I think a good way to encourage and show designers that we take them seriously and we want them to be around is to give them things like authority in when it comes to creative decisions and rather submit all their decisions for everybody's public approval, we're gonna just cut it off and suck it up and build what they design. And if it's not good, then we'll take care of it the next round, right? I'm getting real, I'm gonna buy a lottery ticket tonight because I'm really good at predicting these next person's comments. If we give people authority and show them that we'll take them seriously from the get go, there'll be more people who wanna come and contribute for themes B, C, and D after we get A out. And I saw what happened to Mark Bolton with seven when we paid Mark Bolton a ton of money to make really authoritative decisions about seven and he still got second-guest throughout the issue queue, like, oh, yeah, yeah, yeah, yeah. I mean, he was also pretty forceful in replying to people too, which is good, but there was still a lot of second-guessing going on. So for somebody who we're paying no money to or maybe nominal money, the situation would be much worse, right? Right, yeah, the least we could do is let them own the integrity of the design from beginning to end and treat that as the, treat that as authoritative. Yeah, I agree that we have the issue that every little Drupal developer thinks that there is their interior designer living inside them and they want to comment on all of the design related issues because of that. Yeah, the colors you're using totally off. So, so, yeah, so, so I think, so I think generally, even generally involving people in the community are better with the small, safe groups. So what we found with the usability team, for example, is once we set up a way for it, once we identified ourselves as, hey, we are the usability team and we set up a way for people to come in and share and work with us, then totally random people from everywhere showed up and they're working on from the smallest things to the biggest things. And they have this like safe space of feedback loop there that we can review things and we can provide feedback. And I'm not saying that we solve all the problems that a designer may face, but that kind of, it somehow shields them off from some of the problems and also provides the constant feedback loop that helps with moving forward. And the other thing that we are trying to launch now is the ideas queue, which is supposed to codify this difference of everybody shouting at you and or not. So basically there's the Drupal.org slash project slash ideas, which is supposed to be the first step of proposing big things like a new theme. And then the first step is actually broken down to I think three areas to have a hypothesis of what you want to do to have a prototype and then to make a plan, how to do that. And so you have this sealed off area in the ideas queue to figure out a high level plan and a high level prototype and you don't get the bitching of the technology and everything that would happen in the issue queue otherwise until people figure out the ideas queue. Yes, so, but once they figure out, we can say that's not the queue for talking about that. And there you can agree on high level goals and the idea is that the decisions there are authoritative. So when we move from there to the core queue, then you say we already decided this. And look at that issue, we discussed that it's done, we set it to done and now we moved it to implementation. So the idea is to support these kind of workflows. We've never done this before so I don't know how it's going to work, but yeah, that's the idea. Yep, sounds good. Any other comments, any ideas how we can get more designers involved? No? Oh, Roy has some ideas. Suggestion, we have to broadcast that the job is there. This is, we're now advertising the project here in this room, this is not our audience for this question. So we need to find places where we can advertise this opportunity. Yeah, yeah, behind four people. Yeah, that's good. I have to remember each of you. Did you take a photograph? Yeah, that was a serious commitment. It was signature on a contract. I guess a summary of what Gabor said is that we need to provide a safe space and provide a peer group basically so that the designer knows that she's talking with designers. Yeah, okay, I guess, do you have something to add for this one? Yeah, go ahead. And it's picking up on the mention of Mark Bolton. One of the things that Mark Bolton talks about is designers and developers need to work together. And I wonder if it's, I've no idea how this works, but how do we tackle that issue? We need to get designers actually understanding the world of the developers in Drupal Core and vice versa is really important. Yeah, I don't have any ideas how are we gonna do that? Yeah, it sounds like a difficult problem, at least for me. Maybe another thing to attract some designers will be giving them some exposure to them. I don't know, maybe it's because there are not so many designers and issues, so maybe just giving something that I don't know, maybe not exposure, but I don't know what else will get them there. Yeah, at least appreciation in terms of maintainership and all of these different things that we already have in place and we can give them. Yeah, I don't see why this couldn't be funded through a Drupal shop as core contribution. It's meaningful as writing any code. The only volunteer designer I know who's worked for Drupal voluntarily for multiple years is the designer for Bad Camp, who is an absolute madman and does a new design for Bad Camp every year and has for the last seven years. So if you've been to Bad Camp or seen like a Bad Camp hoodie, it looks completely different every year because Darius is an absolute madman, but it's also that we give complete design deference to him. It's like, Darius, you design it, we'll just build it. Just design it, right? Doesn't matter how hard, doesn't matter how crazy. We give him the authority and say so to run with it and he's in the end, he owns the creative and we acknowledge that and he gets to see his ideas brought to life again and again and again by others. So there is a given take there that we can, I don't wanna say exploit, that we can use to our mutual advantage if we're willing to have that kind of relationship versus give us deliverables and we'll take care of the rest which is probably not what you want. You want somebody who can be part of that process from the end to end and own that creative all the way through. Yeah, that's a good suggestion. Yeah, I think if there's somebody coming in as a designer and wanting to make a design for a Drupal theme, I think it would be good that he, she or he would have a buddy to pair up with. So somebody that is more from a front end developer perspective or developer perspective or, you know, and can, you know, give advice if this will work or, you know, protect a little bit or take care of, you know, all the issues that might pop up or, you know, bike shedding and what not, what can happen there. So, yeah, somebody like Lowry or, yeah, but that, because it's, I think it's a hard thing to, you know, take care of the design and own the design and make those decisions. And so if you have some companion that helps you get this push through or fight for that design, that would be great. And that will be already somebody that can do implementation and stuff and it wouldn't make it happen. Yeah, that's a very good suggestion. I think that is something that is very crucial in order to make this sustainable in long term. If we get designers involved in this process, we want them to tell other designers that it was awesome to work with these people instead of them telling that it was horrible to work with the Drupal community, I hate them. Like we don't want that kind of exposure at all. So I think it's necessary that we are able to provide like help for these people. And I don't mean in a sense, I trust the designers, they can do the design, but they might need some help with the community management and like things that they haven't had to figure out in their previous assignments that they've worked with. Yeah, we're a horrible client if we're not managed. Keith, to your point about designers and developers collaborating, it's a fair question. And I think you're maybe now really seeing us stressing the point of how to separate those concerns at first, because that's the scary part. I mean, historically, when we start discussing design, where quickly the discussion is quickly taken over or maybe even stampeded by technical details. And we want to, we want, we know there's technical details and we have to figure those out. But we want to establish the goal, the visual goal in this part, in this case, first. And I think in the ideas queue that we're going to try out, there's these three stages where there's an idea, hey, let's do a new theme. There's a prototype, it could look like this. And then there's the plan. And the plan needs to involve all expertise is that this initiative hits. It will have accessibility input. It will have performance input if it does weird JavaScripty things. It will have, et cetera, implementation feedback before we can even sign off on a plan in a way that we can say, hey, here's a spec. Let's build this. So we're postponing that. And we're trying to create the initial bubble where we won't get bogged down in those details. Hi, my name is Joel Patet, and I'm the theme, one of the theme system co-maintenors. Team API. Oh, they change it? Without asking us. Oh, OK, whatever. Anyways, I don't care. I just wanted to offer my support from the implementation side of things. I'm in former life, I went to design school, so I can help there. But I'm not an expert in doing it day-to-day like the actual designers. So when it comes to the point where you're actually trying to implement it, I can kind of smooth those edges a little bit. And I would love to offer my support for that. And I'm sure some theme system maintainers or whatever they're called now would probably do the same thing. But yeah, I'm showing off for my support. And I worked with Christina on a recent issue, and it's not done yet, but it seems to be going along pretty smooth. And back and forth on some design things that might not have worked or too hard to implement or something like that. And concessions are made on both sides to try to get it done. And so, yeah. So let's proceed to the next question, which is, are we ready to get a designer involved? This, we kind of discussed like, our community is not probably fully ready for having a designer. But what is our spec and what are our constraints when we get a designer involved in this process? So this is a difficult question. Also, is there something that we should change on the community side? Is there something that we can do to ease this process? So they say that design is not democracy? Okay, I say that. I don't quote it. I say that. Yeah. Yes, because the first time I mentioned that with some friends, they say, hey, I want to give my opinion about that. And it was like, wait, and if we want everybody, if everybody wants to say something about the design, we will end up with a pager in a Drupal issue. And that's horrible. So first step should be that people should understand that design is not being, is not that all the other stuff in. So how could we avoid this issue? So one of them was to work in the private issue queues, private something. Is there anything else that we can do because there's still gonna be at some form of the bike shed. So on the issue summary proposal, there is section which is avoiding bike shed section where we have written down that we try to make as many decisions privately as possible and suggest them as a solution instead of asking for feedback or asking them if this is good. So that's what we have written down from this so far. Is there anything else that we could add to this because it's a major concern on this issue? Go ahead. Hi, I'm Tobi. I teach design and front end and do front designing and implementing stuff. I think we need a clear design brief what this theme should work for. So I think we don't get away with one theme. You can't design a portfolio site and use it for a blog post, it won't work. So when you have this design goal, you can discuss does this design support this design goal or not. And so we need clear goals and constraints, what should be designed. I almost wanted to say the same thing. Is that once you have a spec, then you can check the feedback against the spec. It's like, if you're arguing with the spec, sure. Like, do you think that we forget about something? Like, if you forget about accessibility, sure, argue with us. But if that icon should be five pixels right, no, that's not. So if there's like a fundamental problem with the spec, that's a good argument, which may happen however many people discuss that. But if it's just like, if it's an opinion on how it's implemented or whatever, then it doesn't match into the realm of does this proposal match the spec or not? So I think if that's something that we need to consciously and probably constantly fight in the discussions because it will come up anyway, and it will take time for the community to adapt to some of these new normals and new approaches that we didn't do before. But if we don't do it, then it will never change. So we'll need to fight the fight. Yeah. Yeah, but we already discussed about this topic quite a lot earlier on. So I'm gonna move to the last question, which is just a generic question, if there's any other thoughts that you want to give about the process of the initiative or anything that we've done so far. So this is the part where you can just give all the comments. This might be totally on you, Larry, but we need a way to shut down diversions when people start bringing up their pet technologies. We're very good at suggesting technological solutions before the problem has been fully defined and then cast discussion in terms of, well, should we use blah, blah, blah technique when we don't even know what we're solving for to begin with? So I don't know if that means we're going to have to be really aggressive in the issue queue about this or spin off sand traps for other people to argue about it for a while. But the 50 reply digression in the bootstrap is gonna destroy the issue queue momentum. It's a very complicated issue because for me, it's also all of these people who I appreciate, but I couldn't really agree with their comment. And it's something that could be discussed at some point, but I just feel like it's in the wrong place at the wrong time. And so it's very difficult to find a reply for that without sounding rude and without shutting them down from that conversation. So probably when you ask, we should be more aggressive. I think that's the only way we can somewhat end that kind of conversation from happening. Yeah. So I was just going to say there's been a lot of design going on with outside in and with some of the admin layer and wondering how conscious people should be about mapping that design experience and interaction experience to a new base theme. I haven't been involved in the outside in at all myself. So I mean, there's, as a new experience for Drupalers, they're going to have that design experience of what's being designed for those areas. And if that contrasts with that new base theme, then that's going to be kind of jarring. We were discussing at one point, a few of us, probably at different events, I can't remember. The problems with the admin UI showing up on front themes, cause we're doing a lot of like editing in line and contextual links always breaks in Drupal 7 when you do a new theme and some of those kind of things. We don't have a solution for that, but it's going to become more and more prevalent as you see some of those inside out or outside in or whatever it's called. So yeah, there's no solution for it, but suggestions are welcome. How do you deal with like, we have two themes that we're running parallel and some of the interface is going to be shared between the two. So yeah, currently that is, now I understood the question and we discussed this in Barcelona and a bunch of other events I think. Yeah, I see it also. So there is some issues because it's a little bit of wild, wild west. Like some style sheet is currently coming from seven to style some of the things on the front end, but then some of the things are coming from the modules and some of the things are coming from the front end team. So we have styles basically coming from everywhere to team these admin components on the front end. Yeah. And that's definitely an issue itself that needs to be solved. I don't, yeah, it's a technical issue that I was just about to say that it's an issue that is not relevant for this new team to happen. It's not something that we need to solve in order to be able to create this team, but it should be solved itself in another context for sure. And it's an issue that I'm interested of myself also. Go ahead. I don't wanna talk for you, but I think you meant, I think you meant to the visual, taking it visually into account, not technically. The new theme should work with the toolbar and the setting stray and the contextual links visually. And whatever we do visually, we need to take into account what's happening visually with all of these other experiences on the page that may also change in the meantime, by the way. Oh, so it was about how the admin elements looks visually or how the team looks visually. How they play together. The place block feature, the setting stray, the toolbar. Yeah, that's definitely one of the things that needs to be taken care of. And it's definitely probably becoming more complicated all the time because of more features is being added. Okay. So unfortunately, I have another thing that I have no solution for, not even can think of one, but somehow we should incorporate how we really use Drupal because we're not WordPress. So it will, if we stop at making a pretty thing that works with core, that's cool. And I would appreciate that because it just shows off that we have a system that is modern and works well and looks good and it's not just, but we tend to use Drupal really totally different. And in so many ways, so we need to somehow, and this maybe also goes back to the default content thing that we have to figure out a way that we don't stop at having a theme that works well with something that is a blog or a corporate website or something like that. It's, I think it's a hard thing. It's not easy to see for me a solution because it's so different how we use that, but somehow it should show off that Drupal is not only a CMS, but a framework and that people use it in millions of ways. Yeah. And also allows them to build beautiful design on there. Because otherwise we have a real beautiful thing that has a couple of columns in the footer and things like that. Yeah. Somehow we need to work on how to go beyond that and show some of the strength that you can have with Drupal as a thing that you can build an application with. But that hits almost on like, should it be a base theme then or something? Because I think one of the directions we explored in this discussion is that we showed that wide range of possibilities by eventually releasing multiple themes. Because if we're going to require one theme to carry that whole burden, then we are, then we are... That's not what I meant. So I don't wanna have the one ring that rolls them all and stuff. But it would be, there is a lot of concept involved and a lot of thinking and the designer will run in one direction and some other designer will run into another direction. But in the concept phase, we also will talk about those directions and there should be some thought put in the fact that it's not only a static content driven website. So it shouldn't only be like aesthetics but also that's really showcase our content modeling expertise by having sample content with a few nice content types. Hey, look, if you build a view. I think the problem is two-fold or the solution should be two-fold. So the static point, yeah, that will be solved by the designer because she will have an idea how this will look great. But we should have something that is also usable. That's the one point, because if you have all those applications you can build or those different projects usable for somebody that... No, for somebody that's building a project together with a themeer and a designer or something because it's not only showing that it can work but it will get used. There have been times that somebody used Bartik for whatever reason. So it will get used and copied and modified and stuff. So it should kind of work for more than one homepage or for once the front page. This is an interesting constraint that we have to take a position on because I would maybe argue for the counter idea where this theme works only, works very well for this specific use case. And it's basically, in that sense, also like training wheels. And I mean your first Drupal site, it's what you learn, right? And then you go build a new one with Zen or with Poots. So yeah, good point. And I think it's one important thing part of the constraint or the vision for what this thing should do. Yeah, and I agree that you need to be able to modify, you need to be able to use the features that Drupal provides. But you don't have to be able to build a fully fledged site on top of that. That's like what I would, how I would vision. Go ahead. So when is this released? Hopefully, hopefully 8.2. Lower question is the plan supposed to come with some estimated timelines. Do you have estimated timelines? So the realistic plan is to have something released for the 8.3. That's realistic. That's cool. Yeah. Or not realistic. It's the optimistic plan. Yeah. That one. But that's not the point where we have something as a default theme, for sure. But something. Yay. Yeah. Well, like assuming that we have enough people help. So as people sitting here don't assume that this, what Laurie said means that somebody will do this for 8.3 because this involves getting people on board and making it happen. So if you can help. So when we state dates, it doesn't mean that there will be just magically done by that time. I guess it's in February. February, March? No, April. It is February and then the release is in April. Yeah. Have you coordinated that plan with the default content team? We are working on that. So my concerns here is that I have a dream and I dream with several profiles in core. So what I'm concerned is what people who is using the standard profile, what are they using it for and how we can provide a theme that actually fits with that content and provide. I mean, I don't think we can feed all the use cases. So are we defining what the standard profile should be used on? So we can then better provide better profiles or different profiles for different use cases with different themes for them. So we can create a new installation profile with all of these new features and people can keep using the standard standard installation profile for the use case it was used for before. And then we have this new installation profile called new users or demonstration or whatever. And then they will use that and it will be specifically designed for the one use case. Yeah, go ahead. Just another thought about process. Gabor and I, we basically rebooted UX meetings and it works to have predictable availability of the experts. Once or twice a week or once every two weeks. But if you establish some kind of rhythm, then people will show up and you didn't ask it, but you were available and you broadcast that availability. Yeah. And you might find out that we're more ready to go ahead than we may be thinking.