 Okay, everyone, welcome to another session. This session is being done by Alex Mathews. Alex organizes the Wellington Drupal Meetups, going back to 2012, and also helps oversee development and ongoing support of New Zealand's Drupal Community Science, which is Drupal.org.nz. He's also the CEO and co-founder of Xequals, a digital agency, and also a CEO of Frost Plain Games, a game design company. Can I request all the attendees to please ask their questions using the live Q&A button at the top, and we will be picking up those questions at the end of the session and answering them. Thank you, over to Alex. Hi there, everybody. It's lovely to be with you all here today. I'm speaking to you from the gorgeously sunny blue sky Wellington. Not that many of us would know that at the moment. I'm given that New Zealand obviously is in a rapid lockdown. So I join you from the comfort of my living room. Fortunately, I was able to snab these signs just in time to give you the illusion that I'm calling in from a professional environment. Anyways, I'm here today to talk to you about one of our favorite Drupal projects. We've been working with Drupal since Drupal 5, way back in the day when my co-founder and Irox Flame were building nonprofit community-driven sites using Drupal. Since then, we've came in leaps and bounds, and I'm using this policy project not only as an example of a case study that we're already proud of, but also as a case study of a project that sort of doesn't fit perfectly into the Drupal 9 upgrade path. Or rather, it could be a good candidate for legacy support. It could be a good candidate for an upgrade or for a rebuild. And I figured that many of you, especially those of you who are on the technical side or on the high level business end will be in similar positions right now, whereby you've got code bases that you've got to make these calls on and give your clients or your stakeholders good information to work with in terms of what the best future for their Drupal code bases. So I assume you can all see my slides, and I am just gonna start going through them. And... Pardon me. Cool, thank you everybody, is it? All right, so policy.nz. Now the best thing that you can do to understand policy is to go there. So I encourage you all right now in a new tab, just pop over to policy.nz so you can see what the most recent iteration of the website looks like. So what is it? Policy is a platform for recording and communicating policy information. And sorry, I've just got a bit ahead of myself because I'll quickly tell you about who X equals is and who I am. Co-founded with Rocks Flame about 11 years ago. We're based in Wellington and based in Melbourne. We have a large portfolio of non-profits and social good clients. We tend to prioritize projects that we like to work on. We're passionate about good governance and politics. We're proud Kiwis and we often campaign for better public services and open data, as many of us in the digital communities tend to do. And we love a good Drupal challenge. Which this certainly is. So more about sort of the background of policy here. Every presentation I've ever given has always had pixelated memes. And I didn't want to stop now. So I can't hear any of you all, but hopefully there's some giggles happening somewhere. The due policy they said, it'll be easy, they said. I think that's the one that the team relates the most to. Given the turnaround on the various policy projects we've done and how technically difficult they've actually been. And here's the meme that really makes it for me. And this is why we're so passionate about the project. We are really, really interested in there being an educated voting community. The electorate needs to know what's up in order to make good decisions. We are loathe to look at sort of personality politics and the rise of populism across the world. And we really feel as a policy communication and informed voters is actually the solution. And frankly it's low hanging fruit, given that there is so little on the way of good policy communication out there. Okay, so just a quick overview of sort of what we've used it for. And then we'll start getting into more detail about what this platform actually is. So we first built it for the 2017 election for a group of young lawyers who are our clients that we work in collaboration with. It was subsequently forked and repurposed for the 2019 federal Belgian election, which was one of the most complicated projects we've ever done in terms of data modeling because in Belgium they have English, French and Dutch. They've got political parties that have the same name in those different languages, but different policies, if you can believe that, because technically they're different parties, or within a MMP structure that I believe has something like 17 different MMP parties. So sometimes New Zealand, we think our elections are pretty complicated, but Belgium really takes the cake. And so that was a very difficult project. And I was hoping that Dries would actually be in the audience, maybe he is. Because he'd probably understand our pain. So we're going to look at demos of these in just a moment so you can see what they look like a bit better. So as I mentioned, it was led by a team of young lawyers deeply aligned with X equals values, which is why we pounced on this one. Privately owned, but supported with sponsorship, including from X equals. We were quite happy to put our time into this one. Some really good editors, the editor of New Zealand's largest newspaper, the Herald, famously wrote that the real winner of the 2020, pardon me, sorry, 2020 election was the policy website. And we have been finalist just recently for the upcoming New Zealand best awards in the social good category. So that's a real boon for us and our team, and we'll be flying up to Auckland in a minute. So we're going to look at some of these so that's a real boon for us and our team, and we'll be flying up to Auckland to COVID permitting later this year to attend that. Cool. So just before we jump into some technical stuff, I would like to quickly show you what the sites look like. So for those of you who haven't already jumped over to policy.nz, this is what it looks like. You can explore the parties, the candidates, the policies, the referendums. We'll have a quick look at some policies. I was warned to not tempt the demo gods by trying any live demos. But as a few of my colleagues know, I have a highly healthy appetite for risk. So here we are on firearms. Now all of these are categorized by the political party. We can jump through and we can see what the various different parties are saying about these things. We can expand policies and read more about them. We can share them. We can look at the sources and citations. Now we also down here have this amazing option to turn off all party names. And this will allow you to navigate policy categories or policy domains within a larger subset and do so without actually knowing which political party you're looking at. This is quite interesting and I encourage everyone to go and do this because you may end up finding that you support policies that aren't from your typical tribe. To support them, you can obviously heart them. And this adds them to your cart, which you can then go and check out at the end. I've only added a few policies here, so it's going to be pretty basic. But you get the idea. It'll generate a graph of the policies that you've liked and you can share those to social media should you wish. So that's policy.nz. Now I'm going to really quickly show you another version of the code base that we developed called Policy Local. That was for the local body elections in 2019. So here we are. Now this is the same Drupal 7 code base but has had some new features introduced. It's more about geolocating you to certain electorates and then allowing you to view policies and candidates within those electorates. So I don't mind you knowing my home address at all. It's not public anyway. So we're going to just bring this up to Watson Street is what I want. There we are. And so what this is going to do, it's going to return a mesh block from the address finding API. And then Drupal is going to use that to determine what elections I'm eligible for. So the Mayor of Wellington, the Wellington City Council, the Wellington Regional Council, the Capital Coast, the HBs. And then we can see a summary here. Jump into any one of these and then see all of the candidates and all of the policies within those elections. Now this is non-trivial as I'm sure some architects in the crowd are thinking right now. And you can imagine how much content we actually have. There's about 3,500 candidate profiles in the back end here. So an enormous amount of content loading, which is also why our content loading tools are so sophisticated for the site. Cool. So I won't tempt fate too much further with that. But what I will do is show you another fork of the project called COVID-19 Policy Watch. Now this has been offline for a couple of months now. So I'm just showing you a testing environment. But again, same Drupal 7 code base repurposed to track the world's COVID-19 responses and policy changes. This is all done as a non-for-profit engagement. X equals donated its labor to this one because we were all just trying to do something useful during the outbreak last year. So this isn't public, but I just wanted to show it briefly so you can see how versatile this code base is and how many different things it's been doing. So just looking at New Zealand here, since the stop being updated, which I guess was 15th of May 2020, we were tracking all of this data in real time and the changes in policies that the countries that we were tracking were doing. This ended up being a repository of some pretty useful information for researchers. And I'm not sure if it has a future or not given it was really just a once-off project. But we were pretty proud of what we were able to turn around in a matter of weeks to get this online. So moving on. Great. So these were the main principles that really drove the development of the site. It really was about journalistic integrity. This is information for information's sake but delivered in the most easy to interact way possible with columns supporting that with privacy and speed and the ability for users to personalize their shopping carts of policies. And every web experience is meant to be unique. We hope that every user is able to have their own policy experience. So we worked with a team of lawyers to provide all the content which was essential. Fortunately as the developers we weren't liable for the content but obviously the content side of it was just as intense as the actual technical development itself. Blinker's mode for turning on all of the political names of the parties that was a big undertaking than randomizing the actual data in terms of how it was ordered so that we weren't perceived as favoring any particular party. So for personalization we had a goal to create an intrusive personalization with users never needing to create an account on the site but retaining their favorites. And again, non-trivial. Doing all this customization without any user system. So we used adi which is an address lookup service to help users find their electorate and candidates. This allowed us to sort of enable users to create lists of their own preferred policies and share them with others. And how do we achieve this without user accounts? We stored as much data as possible on the user's end and only collected non-personalized information. So that meant that their cookies and their session browsing data was doing most of the heavy lifting in terms of personalizing the web experience. Privacy and speed were super important to us. I don't think we've ever done as thorough sort of stress testing and using automated testing tools as we did on policy. The site actually did go offline once or twice during the election which we considered a huge success given that it basically pushed the system as hard as it possibly could go before we had to sort of look at those bottlenecks and addressing them. But again, it was a sign of success. It was a high quality problem because we had a significant percentage of New Zealand's eligible voters interact with our website. I don't know the exact figure so I don't want to be quoted on that. But I do believe it was a presubstantial amount of people in New Zealand saw the site or interacted with it in some way. So for those of you who are technical, the way that this worked with geolocation was that when the user enters an address we send a query to the ADDI API and receive a mesh block back for the addresses. A mesh block is the smallest non-person identifiable location metric we had available for then personalizing their data. Now we added that mesh block to the user's cookie along with their matching electorate so that we didn't need to store all this data server-side which would have ballooned into an impossibly large amount of data eventually. So we keep it in client-side where if we can until such point that the set is meaningful from a statistical perspective, we decided that this would be when the user decided to view a summary of all their policies that they've collected and at that point we collect a list of policies mapped just to the mesh block and generate a graph for the user from their cookie. When the user shares their set on social media it is shared via a URL that contains only the ID for each policy and this allows us to create shares that are not tied to a person and rather generate the cache on the fly based upon the URL shared and viewed. So that's relatively sophisticated as a solution and the reason for doing it was just to reduce the possibility of users and their preferred political policies being stored on the server. So the privacy policy is available on all pages and really, really clear human-readable breakdown of what's collected and what's not because for us being really clear if the user about that was essential to this whole thing working. Cool, so just looking at some core Drupal entities I won't spend too much time on this but it's important for those of you who are interested in the upgrade. So our policy content type was reused across all five policy implementations. The fields that were used were a little bit different but it turned out to be very, very dexterous and reusable and that was down to the strength of how the data model had been built in the first place. Significant usage of taxonomies as you can imagine given how much data needs to be tagged. I'm not gonna tap the demo gods too much further but I will just show you what it looks like to enter in a COVID-19 policy. So here's the backend. Pretty simple. Policy ID, the name of the policy, the details, the country it's connected to, the issues that it relates to, the date it's announced, the date that it expires, if it's been superseded by another policy and then citations. This was one of the simpler data models. The national elections I believe were a bit more complicated but you can see how simple it really is for someone just to go in and load a policy. Sorry, just coming back here. So there's not too much more to say about this other than that the policy local body has quite a significantly different data model in terms of the candidate profiles given how many candidates we needed to actually cover. All right, contra modules. We didn't use that many but the ones that we did use we made heavy usage of. So I'm sure developers in the audience will be very, very familiar with us. Flag's module is handling the hearts on the cards. Views is powering most of the screens on the website. Better exposed filters is allowing us to filter down those views in real-time. Colour box for popping up the policies when you click on them. Display suite goes without saying. I'm not sure anyone built sites without Display Suite these days. High charts for generating the charts and the rest of these modules were sort of managing the data on the back end and getting it in there. Do we have any custom modules? Do we have any custom code? The answer is yes but not if we can avoid it. X equals is quite capable when it comes to developing modules and writing PHP but for us that is a last case scenario. It always makes a lot more sense to find a heavily supported community project and give back to that or use it for what it was built for rather than reinventing the wheel. I know I'm preaching to the choir here but it does need to be said because to this day we still see people using Drupal for the wrong reasons but we feel as though we did well by only needing custom codes for retrieving the mesh blocks and geolocation data and the party colours and blinkers mode for turning on and off the party information the swiper.js and the theme layer so that this all works in a tablet swiping left and right queuing, oh pardon me let's jump back here queuing user policy data submission for performance that was really important because otherwise the site would fall over and moving flags client side for performance as well which was something that we learnt from the 2017 implementation. Cool, so what is the future here? Because there is another NZElection coming up. Well this site is a really good candidate for upgrading to Drupal 9. It would be a substantial undertaking but that said it also isn't broke it works great as it is there's actually nothing wrong with it. If Drupal 7 was maintained infinitely then there may not be any need to upgrade this at all it would probably be totally appropriate for the next election. However we live in reality code bases need to be upgraded and therefore we need to make a decision on what to do here. So I know that everyone always prefers through a fresh build I certainly do it would be great if we could rebuild this from scratch and migrate to the know-how and logic rather than migrate the code I think that's a really important point here because as many of you I'm sure are aware you've all had the experience where you sit down you write let's say a document and then you accidentally have the power cut you lose all your work and you've got to start from scratch. Doing it a second time round you often do it in half the amount of time and you do it better and web rebuilds aren't particularly different I don't think so I would love to rebuild this from scratch if we could but it would also be the most expensive and time-consuming option and naturally if you're the client and you've invested all this time and money in developing a product you want to make the most of it and that's something that we fully support because that is the promise of Drupal as well. So as legacy support support an option well absolutely it is some suppliers Acquia predominantly are going to be supporting Drupal 7 well into 2025 is the pricing public or available easy to understand no it's not and that's not unique to Acquia that's all the various different people around the world saying that they'll provide Drupal 7 support it's actually really hard to find out what you should expect to pay which means that you should expect to pay a lot we've got the next New Zealand election in 2023 we hope to be covering it with the system so something needs to be done before then with the kill date for D7 at least in terms of community support being November 2022 so the chronology here does force us into needing to be quite strategic now it's going to be a losing battle long-term to support this on Drupal 7 because we won't be receiving all the benefits of Drupal 9 it'll become less and less secure over time it'll become less stable and we will just be really swimming upstream rather than just taking advantage of modern technology so we're not in the business that equals of maintaining Drupal Core we'll honest with ourselves about that and we'll be advising the client that this solution might be cost-effective for a year or two it might get us 2023 but if they want the product to have any continuity beyond that then they should consider a rebuild or a fresh build really soon for an upgrade I should say so this here I think is the favourite option a D7 to Drupal 9 upgrade we've done a few of these at Xequals most of them have gone more or less to plan there's a little bit of friction broken views front-end tweaks that's to be expected as I'm sure we're all aware so I put down here probably the best option but like all sites in the situation does require an investment I'm sure many of you have been in the situation especially those of you who are client-facing where the client just doesn't understand why they need to pay to upgrade a bit of software especially if they've been using it without errors for years and you know a good argument needs to be made for why at least while technology is still evolving we need to constantly be rebuilding it to stay up to the play and I think our client understands that but the cost savings here aren't dramatic maybe 25% maximum cost savings in terms of doing the upgrade versus a fresh build pros and cons a fresh build in some ways would allow us to move faster but the Drupal 9 upgrade will give us hopefully most of that work out of the box it's actually quite hard to tell but my guess would be that the upgrade will be 25% more cost-effective and more time efficient with a fresh rebuild so brace yourself a new policy is coming one way or the other we feel like the site is too good not to hold onto it the site is relevant way beyond New Zealand in fact any MMP democracy can benefit from this ultimately these are always client decisions they need to do their cost benefit analysis and decide on what's going to be most appropriate for them but I was really hoping to use the last part of this presentation to ask you all what you think and get your active feedback on this because I think as is often the case with Drupal there's a million ways to skin a cat and sometimes there isn't one particularly right answer there's just a complicated set of pros and cons I think that's the beauty of Drupal is that there's so many different ways of doing things but I also understand the tyranny of having too many options available sometimes it's nice when decisions get made for us so I'm really keen to know from those of you in the audience what do you think let's share our knowledge about this what do you think about policy do you think it has applicability outside New Zealand can you imagine this working in Australia what do you think about the idea of us investing as societies and educating our voters and working backwards from people being being motivated by understanding policy rather than tribalism or personality politics or just going along with what the people around them are saying versus taking intellectual responsibility for understanding what you're actually voting on and how it impacts you I know it's something that long-term we hope continues to be a focus of democracies globally but watching the world as it is now it also seems a little bit utopian in some ways so I would really love to know what you all think and with that I believe we are heading just into our last couple of slides here yeah questions and answers Alex I do see a few questions do you want me to go through them yes please if you can speed them out we'll just take them as they come so Karina De Leon is asking what is the API that you used what is the API that's used yes there's at least one API the first one is to the ADDI address API which is returning the geolocation information based upon street addresses that's basically what you can see on the policy local site when you type in your street address and then it returns that based upon the postcode finder I don't think we're using any other APIs than that to be honest our main solution architect and co-founder of xEquals rocksflame we don't have any other person to answer that but to my knowledge it's just that one API that we're using of course sorry google analytics API is always in there somewhere as well of course the next question is by Griffin this is fantastic thanks for sharing Alex yes I certainly see this having a place slash value in Australia I know that ABC does something similar close to states cash federal elections so this is not a question specifically it's more of a compliment for you Alex well that's lovely to hear well thanks for that mate and to be honest that is what we've heard from pretty much everyone we've shown this to I've shown this to people in Europe in the states I've got friends in Canada who are wild about it and a lot of people want to sort of take this back to their countries and make it real I think the burden for a lot of people is finding someone who's motivated to actually get all the policy content together to vet it legally and be willing to stand by it and I also have to be clear that this is owned by our friends at policy limited who paid us to build this and they would be the gatekeepers to the code base but I'd be happy to put anyone in touch with them if they're interested because they are motivated by a social entrepreneurial approach and really it's not about making money it's about educating voters about policies so if anyone in the audience is actually serious about doing this in their respected country which I imagine would only be Australia given the audience of people but if anyone is interested let me know Alright the next question is who did the design slash illustration Ah yes that wasn't my speaker notes and I'm really glad that was asked because I didn't quite get to it so thank you to whomever asked that Rachel Reeves is a really good friend of X equals she was a contractor for us in our very early days she's worked for a lot of places around Wellington and she was one of the founders of policy limited and that's part of the reason why the project came to X equals was because we had that social connection with her she's a really incredible UI UXer she does freelance work occasionally and if you Google Rachel Reeves UI UX you'll probably find her I think her website is rachel.works or something like that and we foresee future collaborations with her as well but I also just want to mention that I'm finding a really good senior UI UXer is very very hard but you can see from the policy side the benefits that you get from doing it and I think that has been nominated for the New Zealand Best Design Award I've had a lot to do with her work That's awesome and my question is how have you done the content is it manual if you could improve this process how would you do it Yeah right to be honest this was one of the biggest parts of the project it was building all of the feeds and porters so we used the Drupal 7 feeds module in fact the feeds module being stable for Drupal 7 was one of the big drivers for us using Drupal 7 when we started this project Drupal 8 had just came out but it was unstable there weren't many modules ported and the modules that we really needed like feeds just weren't working the way that we'd hoped so going for Drupal 7 was actually about making the project feasible within the time frame and the budget that was available because things like feeds would take us more time to code from scratch than the whole rest of the project and we are talking about bringing in thousands of content objects including content objects that are constantly changing so we built a whole bunch of different feeds the client was putting together a spreadsheet based upon a spreadsheet template or spreadsheet templates I should say because there are multiple different feeds and then those were being sucked in and aggregated into Drupal 7 content quite a bit of fine tuning and trial and error was needed on that I know that my co-director Rox was up late many many nights working on that but obviously it saved hundreds if not thousands of hours of what would have been an extremely tenuous manual content loading process so the answer to the question is that we turned CSV files or spreadsheets into Drupal 7 content by maybe half a dozen quite sophisticated battle-tested feeds that not only sucked the new content but also updated existing nodes cool thank you for that the next question is by Nicholas Santa Maria and he's asking what are the specific challenges of policy? Oh wow there were many I think in most cases it came down to the timeline we were often sort of prepared to do the project but told to hold off until certain sponsor support was secured we needed confirmation that the Electoral Commission or Sponsor A or Sponsor B was going to come to the party and so by the time that we were given the green light to proceed we often only had maybe a couple of months before said election was coming up and turning around this kind of product in that amount of time with a relatively small team because x-equals isn't huge I mean we're only maybe a dozen people that was significant but in every case we delivered we always do I think that's just down to the strength of our team and the seniority and the skills that we have as a really high capacity team but the timeline was one of the biggest challenges. I think scaling the site to deal with ever-increasing traffic was definitely a big challenge as well I know that especially in 2017 there were some performance issues that we had to really address in subsequent implementations I think originally we were storing a lot of that personalization data on the server and so the server just got bigger and bigger and bigger and bigger until I believe we had gigabytes and gigabytes of data relating to various different user sessions now not only was that an issue in terms of storage capacity and performance but we were very aware of privacy considerations and not wanting to hold any data from users even where it was anonymized so rebuilding that to work client side rather than server side that was quite difficult but ROX and the various different developers he was working with was able to achieve that so yeah the big challenge was scaling to ever-increasing traffic to addressing bottlenecks in the performance like certain views would fall over unless they were cached really carefully and the biggest challenge right now is dealing with the fact that it works fine as it is but for it to have a future we're going to have to rebuild this in Drupal 9 and that's going to be a lot of work Alrighty so the next one is by Nathan Dobbin and he's asking great site I'm pretty sure I used it when it first came out do you keep track of policies across elections might be interesting to see how policy has changed over time Sorry the last bit of that question you said do we keep track of every New Zealand election do you keep track of policies across elections and it might be interesting to see how policy has changed over time Sure thank you we don't it's not our place through that but the client policy limited certainly does and I think if they keep doing this long term which I suspect they will then they'll have one of the best data repositories in New Zealand or in the world rather with the political policy data and how it's changed over time because if you think about it it's kind of remarkable that every democracy especially western democracies aren't doing this already there's certainly no one else in New Zealand who's doing this the government itself doesn't do this at least not to our knowledge so we are building an arc of information here which will only become more valuable over time and again it totally blows my mind democracy doesn't just have this as a public service and the Ministry of Statistics or the Ministry of something or other doesn't take this on as a responsibility the fact that private citizens have had to come together in order to be able to communicate to the public what they're voting for I think that reveals a lot about the areas of our democracies that are yet to mature so for now yes all that data will be held by a private company but my hope is that one day it doesn't need to be that way all right the next question is by Nicholas Santamaria it's not a question more of our information in Australia the ABC have VOTE campus which is a similar concept to the turn of party names feature of this project and then he's also given us a URL which is votecampus.abc.net.a I would say quickly I will go and have another look at that because I've certainly seen it in the past but there were several other competing sites with us that were trying to do similar things I think we had VOTEWISE.co.nz and there was at least one other where they massively differed is that they were sort of question wizards that would then tell you how to vote at the end you know you'd answer a few questions you'd hit a few checkboxes you'd say how you feel about certain issues and at the end it would say congratulations or it would say you're a conservative that's who you are go and be conservative and I'm being a bit reductionist here but the truth is that that's how we saw most of them working on the high level and fundamentally we wanted to do something different which was be impartial be journalistic let people just consume the data and for us being able to turn off the ability to see which political parties represented which policies that was really important to us was the point of differentiation from those other services so I'll certainly go and check out VOTEWISE.co.nz and re-familiarise myself with that in Australia but I suspect it's going to be closer to a tool that tells you how to vote rather than a service like Wikipedia or policy but I'm happy to be wrong about that so I'll go refresh myself on it thanks thanks Alex the next question is by Sean Hamlin he's asking do you store any data from the number of policy hearts or was this all tracked through Google Analytics? Sean always nice to get a question from you that's honestly going to be a better question for Roxx so I'll ask him to give you the lowdown on that next time you talk to him I'm tempted to say that it doesn't include any service side data about the user I'm just conscious of the fact that certainly IP addresses would be recorded there could be a little bit of other stuff but it would certainly all be anonymised and we worked really hard wherever possible to store data in the browser rather than on the server especially in the later implementations of it so if there is any data server side it'll be extremely minimal it's probably just session data but I will take a note of Roxx getting back to you because I know the two of you are very technical we'll have lots to talk about there and the next question is by Karina and Karina is asking did you do any custom development for the FEEDS module to work or was it a matter of mapping fields to various different quantum types you have do you know if FEEDS is still a stable module to use in D9 or is there any other alternatives that can use similar implementation of importing content wow that's several great questions again I'm just going to speak to that sort of most high level knowledge just so most of you know I'm not the most technical person that it equals I'm more of the business guy but I know enough technically to be dangerous as we say so I'll do my best to answer that I don't think we did any active development of FEEDS I'm sure we were on the issues queue and we may have written a patch or two that wouldn't be uncommon but I don't think we did any significant contribution back to the FEEDS module is the FEEDS module stable in D9 I'm not sure I'd have to have a look last time I checked in the sort of the back end part of FEEDS what was largely there but there was no UI for it and it wasn't particularly stable and there was a big sort of rift in the community between using FEEDS or using Migrate API and I think that the D9 Migrate API is preferred by many people in D9 in terms of sort of moving data around and again that's all command line driven and isn't quite the same as FEEDS FEEDS had a great user interface in D7 it was really easy for someone who's only semi-technical like me to use it the client was able to use it which was great but I'd never expect the client to go and use a command line for sort of mapping fields across which I think is the more accepted way of doing it in D9 which is the other answer to your question what are the other competing solutions to FEEDS and look there's actually quite a few if you google import export tools for Drupal you'll find that there's many many dozens of solutions I think for getting data out various plugins for views are considered the best practice it's certainly what we typically use so there's the views export module there's the views rest module and there's others which will perform very specific kinds of exports and they're already really good for particular use cases and then the migrate API I believe can be used for typically migrating entire Drupal projects but can also be used to sort of map data from one system to another and I think that depending upon the developer and depending upon the particular data input or output challenge you'd find the best module for that by just evaluating the available ecosystem so I'd be googling Drupal 9 import export modules and then I'd do a comparison table of what they can do and then choose the best of breed based upon the particular challenge I'm sorry I can't give a more quicker answer there but like a lot of things in Drupal you've got to get out there in search you've got to evaluate the ecosystem and you've got to make an informed decision based upon the particular technical challenge you're facing yep and the last question here is from Dallas Ramstone and Dallas is asking Empowering Talk Alex, thanks how much data needs to be brought over into the new site if there is not much custom code and if there is minimal difference between a fresh build and migrated site in my opinion have you considered leveraging migrate API to bring over the data instead of feeds gotcha Dallas I've heard from you from ages but great to hear that you're there yeah great question I suspect that would be the next step we'd look at as part of evaluating a Drupal 7 to Drupal 9 upgrade it may make sense just to lift and shift the data and use the migrate API for doing that into a fresh Drupal 9 build that would be again one of the many options we've got available and again this comes under the the tyranny of decision making because even under the D7 to D9 option within that there's three different flavors of how we can do it and using the migrate API for the data and then otherwise rebuilding the config that could be a perfectly good way of doing it what I will say to that though is that I think most of the secret source in the code base is down to how it's configured the features that it's doing and how it's doing it the data itself is almost negligible given that the policy data for the next election will be completely different from the policy data for the previous election so moving the data is less important than sort of migrating the features if that makes sense alrighty thanks a lot Alex for this great talk just a reminder for everybody who's attending that the lightning talks in the round table session starts at 2pm AST slash 4pm INZ and yep thanks a lot see you there thank you everyone and check out policy.inz again if you if you want to keep it in mind cheers bye