 So this is background for our compatibility challenge in country models This is a core conversation So thanks for coming everyone and I hope that I will give some context of the topic and some personal experience We had but I invite everyone to to get them to the mic and share your thoughts So my name is Christian Lopez. I'm penia skid on Drupal.or. I've been contributing to Drupal for some time mainly in the multilingual initiative That helped me to get a new job at Lingotec where we help people translate and localize their sites so This is not about multilingual or Lingotec, but I will give a bit of context So do you know what we do and why we face the challenge that we had So my main job there is building a Drupalite module Which connects Drupal to a translation management system and this means using Drupal APIs for extracting content Uploading somewhere downloading it And in this journey we had some challenge and this is why we are here So in Baltimore, Beamleast talk about backwards compatibility already and this slide is from him Doing the Drupalite cycle Dries announced that we will have backward compatibility and we will have semantic versioning for that which means that People is supposed to be able to break their sites to the latest version Which is of course a huge benefit Without any any issues But sometimes things happen Things don't go as expected So being came with three different types of APIs in Baltimore Explicit APIs, which are like hooks plug-in tax services Implicit APIs, which is the markup structure render a right structure and the wakes and priorities for the order of calling different models and Some accidental APIs which are main interfaces. So when we Introduce object-oriented code in Drupal most of the classes there were were came with an interface and People assume that these interface are part of the API so in the case of explicit APIs the way of Maintaining backward compatibility is not trying to change them But in the case of implicit APIs sometimes we avoid to change it But if it's needed we We will we will change it in core and one example we had is For in lingo take a test code for saving a note we we had different in Drupal 8.4 it changed How we Saved like the button level for saving content now for the status if it's published or not We have a checkbox so We need to call different Buttons for submitting the form and in the case we have content moderation enabled in 8.3 or 8.4 This also change So one example for implicit API change what we did is like trying to abstract these changes in a method so We can control which things we will need to clean up later another Issue we had is for great tests in our case we have like a lot of tests and This give us some random failures with the test bots These will come later and one thing that we we see is in Drupal ecosystem is really important to Have different integration so When we develop our country models We need some way of saying which models we are compatible with and with versions of these models and One way we currently can use aside of having The text of the project description is The list of dependencies in our releases it's quite hidden But if you go to the release page you have there all the dependencies and the current versions that are used In this case these are extracted from the test so these these are the optional dependencies that we have for our tests And this is like We are recoursing this depends that silly so we we have some Some dependencies there which are not really useful for end users that want to see What models this model is compatible with or which integrations do we have? So we should probably figure out Better ways of explaining this to to to users What and when we talk with When we talk about the integrations that we support with different country models we find another challenge which is Which versions of those models we are compatible with There's an issue About adding semantic versioning in country Like in core it was really helpful And I guess when when country still evolves some more this will be really useful for explicit for making explicit with versions you are compatible with When we talk about backward and forward compatibility one thing that we have is How we test against different versions of different models and There are multiple combinations, so this The number of tests that we should actually run for ensuring that we are compatible with those versions of those country models grows quite in a factorial way So One thing we could do for improving the situation is using some research this was presented in Barcelona It was a call called smart test proposal accelerating detection faults in Drupal this come from research from a Woman who works for the University of Seville and she presented this work in in Barcelona so what they used was a software problem research approach for for doing prioritization Techniques to a scheduling test So they ended up developing a module which is called a smart test Which changed how simple tests? Tests are running which order depending on which are more Which have been which tests have been failing failing more often So you run these tests first and you can see more quickly Which tests are failing So using something like this in in Drupal or or and or test bots Could be useful for when you have so many combinations for running tests. This could be a useful approach for for getting feedback as soon as possible But this will be quite costly in terms of development like we know how hard is to Push change to Drupal.org infrastructure and the test bots So another way could be gathering Data from users. So this is something that WordPress used to do. I couldn't find it anymore So maybe I don't know why they stop using it, but they used to in every module page or Plug-in page as they call them. They had a compatibility box and if you were registered on the system you could Say which setup are you using and if it work or not for you? But this could be like for Supporting core minor releases or or minor releases. This could be quite helpful but We should really look how how to make this scalable when you have like a lot of Country models that you also want to to check which ones are compatible. You are comfortable with I Want also to show some issues that we find on on the way of grading our module and making it compatible with other stuff so First I should start like in the lingo tech model started Quite before Drupal 8 was actually released so we didn't have a lot of examples to look at and And one one decision we take is we we need to store data About every entity so we know if we have uploaded it yet to our platform or not and some kind of metadata that we save and For that what we use is that we we added fields Altering the entities we added fields to To any entity that we mark that we want to to integrate with lingo tech And at the end this wasn't a good solution especially when you When you start supporting revisions and then where Ben's moderation appears Your data is storing different revisions. So this wasn't a good solution and we use this in the 8.x 1x branch So we created an 8.x 2x branch which use a different entity for storing this kind of metadata We took this approach for for actually from from the content moderation module, which is now in core as an experimental module And what they did is that they have a different entity and they load this entity Dynamically so you don't really need to store anything in the original entity And it makes everything easy easier But then when we wrote our great path we wanted to remove The the fields that we added in the previous version and we found that that it wasn't possible So there's an issue for that and I'm really happy that some work going on in the sprints this week about Bargain based fields data. So when you have a data in these fields, you cannot delete it Which actually means that if you had lingo tech before and you want to uninstall it you cannot Because there's data existing in the system and you cannot really push it So So yeah, so this is something that affect affected us and it may happen to you if you are Creating country models Another thing This is one that I didn't face myself, but Fabian Bircher sent it to me There's an issue about updating models with new service dependencies So if you are updating a model which have a service dependency That comes from a new model that it's not in the system when you try to install this model The container is rebuilt and this service doesn't exist yet. So Drupal will crash And this is something that people is working on in this screen too So these are most of the issues we have about back work compatibility another one. It's for work compatibility so one thing we wanted to do is a is Making our module compatible with With content moderation, but we had clients that were using were events moderation already Then we had clients on 8.2, which may be using the content moderation experimental model People who are going to to grade to 8.4 with a content moderation And we want to so once the release comes out We want to support it So in this case what we had to do is like creating a facet a facet layer where we Where we can provide a common API for all of these and using Using the service service collector we can Inject different services Even from different country models is there's another moderation solution that comes afterwards So in this case what what we use for for work compatibility is trying to extract these features into Into our code Which I don't think it makes sense to to abstract it to a different model because I'm not sure if some people will have this kind of situation but This is what it worked for us So I tried to give you some context So summarizing situation. It's much better than Drupal 7 but there are still some challenges. I highlighted some issues with contour in the way Some of the problems we had will require change to Drupal.org and and to the test box and This could be quite hard to do One thing that we usually found is we need better communication even better communication like When people see something in code they assume that it will work and Experimental means experimental so in in case of content moderation Some clients Were expecting that we work with them and and we didn't support them yet The importance of dating to to the last releases Most of these problems wouldn't happen if every client Were using the last release of every module and and core But at the end they they usually are slower to catch up After this I would love to have a conversation and see which actions we could take for For improving the current situation So I invite everyone which wants to share His or her thoughts to the mic There's some bibliography. I Got content from making Drupal a great CC forever the article from this where they announced This the do the semantic versioning Backwards compatibility burden and benefit from being leaders Which was made in Baltimore and Seville and the smartest Talk from Barcelona, and there are some research papers about the subject link from there if you are interested of knowing more so Everyone wants to share Hi, I'm Jess. I'm one of the Drupal a core release managers I did want to highlight on your previous slide where you had your summary and then you asked What are some actions we can take around the communication the better communication for experimental means experimental and Trying to Navigate the problem of content moderation in a 2x being totally a huge BC break with content moderation in a 3x and a 4x We actually have changed the experimental module process so that won't ever happen again So in the future in we will not release alpha level experimental modules in core And what that means is that if you if any code is added to core it must provide Backwards compatibility and an upgrade path within within a major release So in the future what we would do is if a module an experimental module has only alpha stability And they're not ready to support the API yet We will remove the module from core Before the next minor release is released. So let's say we add the workspaces module in triple eight five x If if it turns out that workspaces is not ready to support backwards compatibility and an upgrade path By the time eight fives alpha is going to be released in January We will remove it from the eight five X branch of Drupal core put it in eight six X only And then continue to do that until workspaces is ready to support a data module So that that one thing we have addressed already And then I also wanted to highlight One thing related to you had the first line about Explicit API's implicit API's and quote accidental API's We actually have a slightly different way of framing this in the core Definition of what the API's are if you go to Drupal org slash core slash D eight hyphen allowed hyphen changes Yeah, yeah, yeah that page that has a very very long textual list that explains For each type of thing in Drupal Whether we consider it a public API an internal API or not an API. So for example, um, a Hook is considered a public API. So we will provide backward compatibility for hooks within a minor version But a render array in the implicit API example, that's considered an internal API So that page has a very long text definition of what the API's are But that's obviously not very useful for developers like you're not going to every time say, okay I have This base class and I there's this method on it. That's public. Is that API or not? I don't know if you go to that page it says in text what we're doing now is in the process we're in the process of Adding an internal tag to everything in Drupal core that is actually not considered public API So for example a hook implementation would not be public API You should never call a procedural function that happens to be a hook it Implementation directly and what we're going to do is label all of the hook implementations in court with at internal If you want to help out with that we're sprinting on it this week Tomorrow, it'll actually be in the mentored sprint room There will probably be a table that says like at internal and big labels come find us and help and then you Can help make it so that I'm in the future. It's more clear to developers whether or not they can rely on that API I was wondering if there's anything Core could do or maybe individual can trip modules to make it harder To either turn on experimental modules like maybe you had to go into settings dot php and put a thing to say I'm gonna run experimental or if can trip modules Potentially especially for something that you know Could potentially mess with your storage To say to actually check to see if content moderation is on and say Yeah, there's also an issue for that. I'll find it and give you the note ID but but potentially Without forward doing that you could still say hey content moderation is on let's on every lingo tech administration page say You know, we know this is a this could be a problem. You know, have you do you know that you're running experimental module? Do you guys put any warnings or? that We are not doing that. Okay, so we actually do that like for adding settings like This experimental module is supported. So these are the settings related to that one. Yeah But we are not doing something like that. And I guess with what Xgm said About this won't happen again. Yeah, okay, maybe it's not that relevant anymore. So So if somebody is making a project with composer though, are they gonna Have that same not like if I'm making a if I'm making a project And I think it's gonna be a year out. So I do composer and I require like a next branch of Drupal If I was like developing against 8.5 now, I would still have that problem, right? Also one way Experimental models are actually in core is to increase visibility. So hiding them. It's probably not a good idea from a different country model Thank you The core issue to add a flag and the implementation It suggests in the core issue is a settings dot php flag That's triple dot org slash node slash two nine zero seven one six two This is something that came out of the experimental module policy change I was talking about as an additional suggestion. So what it would be is on a site-by-site basis Administrators could opt in to showing experimental modules or not So that you know if it's in a developments like and we have there's the settings that local dot php for That's since you can set up differently like as a development environment So we would probably include it so that that enables the flag to allow you to try experimental modules So people who can use it on a development site, but then on a production site It would be off by default or on the default installation of Drupal. So So Drupal core tends to add new features in minor releases, especially like for the entity API So what I'm doing is I'm still in the process of writing the group module and I want to make use of that so Every time there's a new minor release I you're looking for the change records for what's new and I'm like, oh shit We've got a default HTML route provider now. I want to use that instead of you know Having my own routes in there so I can reduce the module size But that means that from that point on my module requires core eight point in that case it was one I believe point zero and Then in eight point three point whatever something new comes along and I'm like, oh shit I want to use this so I do and what I find myself doing so far is just updating my Project page every time with like big ass letters at the top saying Requires core whatever whatever whatever just to make it real clear to people that if the module worked for you on Drupal 8.2 and I added in new features that Have only landed in core 8.3 It will no longer work properly in 8.2 Or it will be missing stuff that I had in place that now core has so I can toss it out of my own module So how do you fix that problem where I mean? I don't want to keep having to update my project page saying you know use this core version or use this Use that core version. So how you how would you? Go about that So one way is you can in your info jammel file. You can say the minimal core version You support. Yeah, or your compose a json. So this can prevent people to actually install it. Yeah, I know that it's just That's not intuitive enough. Yeah, and especially yeah, this is the problem. I had like here like How can we make easier for users to see these in especially because it's like it's an upgrade path So it used to support eight point two and then because eight point three has new features It now requires eight point three So I'm basically telling people like as long as you'll keep up to date with core the module will keep working Which I guess is a good thing to tell people but some people are you know afraid of that because they're still afraid of doing core updates Yeah, so Every time so soon as a four comes out eight three is no longer supported at all So they shouldn't be as Jess said they should be afraid of continuing to use old versions Like I agree there could be a usability improvement and maybe a confidence booster, but they're as a contrib author you should Only be worried about supporting the latest one Yeah, you're just you're just it as you said factorially in increasing the number of the amount of work you have to do so, yeah, the Dependencies way is the safest way to protect yourself against it. I agree. It's not the most easy to You know, it's not the most helpful way of Explain to them that like it's broken now, but eventually everyone will figure it out Maybe I don't know or we can help them along the way, but it's it's it's good for them to not be able to use old versions of Court because it's not supported at all Yeah, I was just gonna add a comment about Composer so Talking about like what your composer minimum requirements after core I mean it would be good to be able to expose that information on the project page You know rather than have to go in there and say, you know, you need this particular version if we're able to expose that on the project page I mean That kind of ongoing issue. I guess of the fact that people want to click a download button versus composer install things But it's just an idea I'm just going to share one of these kind of update to latest core problems with backwards Compability I was in the sessions about drush 9 and the problem now is drush 8 supports Drupal 8.3 it will not Fully support 8.4 because symphony is upgraded from version 2 to version 3 and So they have a developed drush 9 but the problems we manage our site using agar and it's reliant very much on drush commands and I got this kind of panic because in a week our Hosting environment will not be supported at all kind of how do we do because I need to upgrade core And I don't want to be in a older version and the problem there. I found a solution how to fix the Provision part of agar so it can install 8.4 pages because it couldn't But we're using a drush version that is not supported so I don't have a good solution How to solve this because drush 9 is not in stable mode and drush 8 is not supporting the new one. So it's a problem So I'd like to reassure you a little bit about that. It's it. That's what that's what was the case for a while But thanks to some work that Greg Anderson who's one of the drush maintainers did you can use so The what it actually is is that you can't Global installations of drush 9 are not supported And so if you use a global installation of drush and Drupal 8 there was a situation where Or you wouldn't you wouldn't be a or sorry and drush 8 you you were sort of like stuck But Greg Anderson did do some work. So it is actually possible to update core From 8 3 to 8 4 using drush In in drush 8.1 point 12. So if you use drush in a global workflow On your host be sure be sure be sure to update drush to 8.1 point 12 Before the release of Drupal 8 4 before you use it up to update to Drupal 8 4 and you should be okay They said they they don't want to say that they're supporting it, but it actually works just fine So it's it's not quite as dire as all that so but I think a lot of people went through the same panic because at first They're saying that we they weren't going to support it at all. It's actually okay What might actually just happen is that? new feature development might not You know be available and so what you want to do in the longer term is is try to switch to like a local composer based Set up for your sites for for future compatibility But in the immediate future for the next month and then six months later for 8-5 you should be okay But the most problem for us is agar is reliant on multi sites so we have like 40 sites on one core and To kind of split that in to have separate Composers So for us is kind of we need to figure out either agar and needs to be fixed or we need to change our hosting Philosophy about it. So yeah So I have one maybe suggestion you mentioned one of the problems maybe the order where you That you run the test of with the all the optional dependencies and For that specific problem if if the test is a php unit test There is one dark that is depends and I have just grab it core and they are There is already like 10 or 15 instances of depends in the test So that's a way to actually enforce that the order of dependencies without needing to To you change test bots Because they will be unit would be the one actually doing the the order of the test Yeah, that works when you are testing One version but the thing is that what I was talking about is maybe trying to to test Run your test with different environments too, but yeah, I think that can be helpful too. Yeah Like a long while ago. I was following the issue about having some version it's not a semantic versioning for a country modules and There was a discussion back then and I haven't really followed it since so I wanted to see whether there was like an update on it But the whole idea was that Modules need to support a certain Drupal version. So you have a module for Drupal 7 you have a module for Drupal 8 So this is why we have like 7.x dash 1.1.x So How how how far along have we come With trying to find a solution for that So when you want to have like a module 1.0.0 for Drupal 7 and you also want to have that 1.0.0 for Drupal 8 So, how will we handle that because basically you'll just have like Especially for a composer like Drupal slash let's say group dash 1.0.0 And you don't really know whether that's like Drupal 7 or Drupal 8 So has there been a solution for that yet or is that still a little bit up in the air? So there's still a discussion about it. So sorry so there are still ongoing discussions about it and so the the last proposed thing I saw is composing the major version with the 8 prefix in case of 8 or 7 in case of 7 This is like a very long discussion. Yeah, so I kind of like unsubscribed from that discussion because it kept going back and forth and Everyone like every 50 comments the same solutions would come up again Like people weren't you know bothering reading everything before that. So, yeah, I kind of just like zoned out and it was like, okay, never mind This isn't moving anywhere I Was just saying that I think that really the only long-term solution to the problem is is for the for the Drupal ecosystem to just actually adopt composer to manage dependencies but Because like Drupal core doesn't include some expectation in its own version number of what symphony versions it uses for example But that's that's my that's just my personal opinion. That's not actually a direction that we've necessarily chosen So what you just said I agree with that like we need to use composer from now on One of the comments I remember reading is that Say I have a 1.0.0, which is for Drupal 7 and then I can list Drupal 7 as a dependency in composer But then I release a new version for Drupal 8 and I'm sort of forced to call it 2.0.0 Because I need to list Drupal 8 as a dependency and then you get like this weird versioning because then I may use that version 2 To backboard all of the cool stuff I wrote for that to Drupal 7 But that would be version 3 and then if I wanted to update like for Drupal 8 or Drupal 9 that would be version 9 Version 4 and then you'd get this weird scenario where in true semantic versioning like the first number is like This is a new major release So you'd have two releases for Drupal 8 one being 2.0.0 and one being 4.0.0 There's something and that doesn't really make sense because everyone's going to be wondering like what happened to number one and three Yeah, okay, so I just call that being part of the discussion And I wonder whether like because like prefixing it with an 8 seems like introducing just another Drupal isn't to me because there's going to be someone who's got like 21 version of his module and then he's jumping from like 89 to 810 which is like very weird The the question I was going to ask though is if you're back porting new functionality to Drupal 7 Why wouldn't wouldn't why would that be a new major version number? So if you're making backwards compatible API additions that's that's allowable within a minor version So you can add new APIs to the minor version. So why wouldn't it be like in 1.1.0 for example? Generally because when I want to back port some stuff from Drupal 8 to Drupal 7 it means I realize I fucked up and So it's definitely not back. Yeah. Yeah, so it's definitely not BC Anyways, yeah, so I guess it's still ongoing, but I Mean, I just wanted to like have my concerns on the recording like you know prefixing 8 seems something weird And then jumping from version 2 to 4 seems weird as well But as the guy in the back of the room said maybe that is like the right approach Yeah, I mean I think the way that we solved that problem in in Drupal was to have completely separate Packages repository for 7 and 8 so again, it's the what we're doing in composers different from What you're seeing on on project pages like that stuff's not not surfaced And the other thing I was just going to mention was as a comment is that you know a lot of this a lot of the times We're we're kind of putting more burden on The maintainers of Drupal.org to say oh, we need this feature in that feature and they've got a massive massive backlog of work So when I think if we can think of solutions, maybe we can think of ways that we can solve this without Adding more burden on them, you know like to do it because in reality a lot of this stuff We asked where it's probably not going to get done for a long time This there is a Drupal.org battle where we may learn about what is What is possible and what the time frame would be? I will also add that if people saw the Dries note on Tuesday, you might not have picked up on it, but Dries is proposing and and automatic updates initiative, but Some work around composer might actually end up as part of that so there we might see better Practices and better more complete Drupal.org support For using composer for dependency management as a whole come out of the automatic updates initiative because it's the work is sort of coupled So that's something to keep an eye on if you're interested is that the automatic update initiative whatever it becomes That's just starting to get started with discussions with the DA this week though They haven't even raised funding or anything, but there might be funding campaigns where like Drupal shops and hosting providers are so forth are invited to invest in this initiative So if it's something it's important for your business keep an eye out for that and you know Maybe you mark some of your 2018 budget for that initiative There's also the Drupal.org Projects on Drupal.org and they have which I guess is the Model that runs on Drupal.org and they have a path forward for compose a meta issue And they have at least a couple Issues seems like one is take the list there How to require the project, but I don't know if it doesn't look like I haven't seen one that says you know List the dependencies from the composer json, but that's potentially something we could suggest and provide patches for So, you know, you could potentially look at a project and say like I think you were saying that you update and say if this needs Then the latest version of Drupal But you know if we thought if we provided a patch to that project that could potentially something just be automatic So that you wouldn't and other people who aren't doing it wouldn't have to do it That would just be like this requires a free So I think even if we're encouraging people to use composer a lot of people are still at least going to the project page To read about it before they actually download it. So That could maybe like flag them to say, okay, you know, I should you know, all of these projects are on the latest version So I should be or I'm not so I Severely restricted on the number of projects I can use So the dependencies is there and I think also if we just if there was something it says this is the you know suggested way to require a project, but I think the document like sort of the auto documentation would be pretty big as far as like Could also tell you automatically which modules it requires just in general, but the versions of I'm actually gonna ask a question this time instead of spouting information off the top of my head so earlier you I didn't quite under follow on a slide where you You have the list of the optional dependencies the integrations that lingo tech provides I didn't quite follow what you were saying about How how those are Surfaced that you're doing are you doing it automatically from tests like I didn't like that the right sidebar there This comes from the release page. Oh really in the sidebar where it has that list Yeah, so I make core releases So I don't ever see what this looks like for contrib and in for core It's this huge long list. That's not even valid information. So but it did you say that it does it? from It discovers it based on the tests that are provided with the module or did I misunderstand that no The thing is that we have optional Dependencies for the modules we are compatible with and we have test coverage for it So we have like an optional dependence for Are those declared in the info yaml file or info yaml file and they can be in the composer Yes, I obviously don't ever like there's no such thing as optional dependencies for course I'm not familiar with it, but um, I guess I can just look on the lingo tech project page to and see What look in the code base? Okay. Thank you. Thank you So if there are not any more comments Yeah, so as I said, this is some of the bibliography I used and I want to thank Some people which gave feedback on On this topic or created content that I could based on this talk and thank you all for coming and sharing your thoughts So thank you I highlighted some issues that will make Forward and backward compatibility better. So it's a good way to contribute in the sprint tomorrow also the at internal Table so join us and remember to give feedback of This is actually something that interests me like When I want to contribute to core or country modules I do that in a in a way that I'm familiar with like providing patches But how do you do that for Drupal the door because like you don't have the code base. So all you can do is What a theme? Okay, and a sandbox environment. I don't remember the exact details But basically you can get a sandbox with even a database them, right? And so yeah sanitize database them so you can't access passwords and whatnot. I'm imagining hoping So it's actually totally empty one so you you get to be Dries in your sandbox of Drupal at arc But yeah, there's a there's an issue queue where you can like I don't remember if it's Which did you cute is but if you post an issue in the webmasters project? They'll get you to the right place And you can just say I want to use a triple org sandbox to work on developing feature X And they have an automated toolchain by which they can spin up a sandbox for you and and it has It used to be what Tim was saying where you don't have a theme, but now it's actually Like there's they don't do a local version anymore. It's just actually a full sandbox on their sub-domain So that's good. Although I will say it is like if you find Drupal core contribution trying Contributing to Drupal org is an order of magnitude more frustrating in my personal experience. Um, it's there's because there's just so much You know so much more going on and the Drupal Association has limited resources So like just you know be be ready for that Because it can take a very long time to get a small change in But in in a situation where it's like important ecosystem changes like this in some ways. It's actually more It will probably go faster than contributing yourself to just you know be constructive and supportive in the issues discussing the issue because Like the people who do work for the Drupal Association when something becomes a priority can actually get changes done really fast So that's the people to look for on Friday are Neil Drum, Ryan Astlett aka mixologic They'll they can sort of like orient you to what's going on, but also come to the panel That's right after this. I think I'm saying yeah, the Drupal org panel. I'm making Yeah, I think you definitely should come to the panel that is right after this then Okay, well in any case I think what Jess said is all true But then on top of that I think perhaps for this particular area. It may be a little bit easier To contribute to triple the door because it is like one specific tiny area that doesn't integrate with lots of external services Usually the integrations with the entire infrastructure is what makes it trickier to contribute because you don't have them locally So I think this particular area composer information to the project page should be easier I just wanted to add for that specific problem. You want to look at the project release model that is inside the project project and and also Based on that you probably that is actually the place where you probably can add the information to the to the project page and Yeah, I also want to say that yeah, it's maybe it takes some time to actually contribute to to do though But yeah, I wanted to say that yeah, it is possible and it's really Rewarding because it is it is a change that you can actually see and all people use so so I would say that people around you Like Neil and Ryan they would be really happy to help you put you in the right path to actually do the change And so please do that on Friday Thank you