Hello, thanks for coming to our session, aspirations versus realities, where we're going to be talking about the results of a survey of nonprofit organizations in regards to how they are prioritizing their investments across the different components of their marketing stack, including their website. So I'd love to get a quick show of hands. Who here is from a nonprofit? Great, it's a little over half, so this hopefully will be relevant. We are from Blue State, an agency that focuses primarily on working with nonprofits, and I am the SVP of Platform Partnerships. It just means I work on the things that we build, like websites, so I help establish new relationships with clients, and I also build relationships with other partner agencies that we use to build Drupal sites in particular. Hello, I'm Jack Steadman, I'm Chief Technology Strategist at Blue State. So I head up all of our technology and data work, and spent a lot of my time consulting with nonprofits on this very topic. So for a little bit of background on the research that we're going to present here today, we asked to hear from organizations who use Drupal or WordPress for their websites. There are obviously a lot of other CMS platforms and use by nonprofits, but these are the two that we most commonly work in, and we were looking for insights that were most relevant to this community, but also to our core business. So to set the stage, first we'll talk about the role of the website in the ever-expanding MarTech ecosystem used by nonprofits. So 10 years ago, this is what a typical Blue State client looked like. We built a lot of websites in Expression Engine. A lot of our clients were locked into long-term contracts with BlackBod, which was and still is a big name in non-profit tech. And because BlackBod's digital tools were pretty clunky, we built and often added in our own platform, the Blue State Tools, so that we could be a bit more nimble in our email segmentation, data collection, and fundraising work. But around 2015, the landscape began to change. Most of our clients outgrew Expression Engine and started moving toward more sophisticated open-source content management systems like WordPress and Drupal, and obviously much larger developer communities and so on. And at the same time, Salesforce started to make a massive push into the non-profit space and we started to see a lot of our clients migrating to Salesforce and to a lesser extent HubSpot. This point we started to see a split. Some organizations stuck with the non-profit specific all-in-one platforms like EveryAction and Engaging Networks where CRM, email, fundraising, advocacy, and so on are all rolled into the same platform, whereas others started to take a more composable approach. Adding in separate tools for email and donations and so on built around Salesforce or HubSpot. And so the result was that there's a lot more fragmentation. There's a lot more systems, a lot more tools that come into play. Some of these tools are more sophisticated than the ones they're replacing, but it creates a lot of fragmentation and it means that every single one of our clients is running a unique combination of these tools. But if we zoom out even further, we can see that the bigger picture is even more complicated. CRM, fundraising, and email are pretty common to most of our clients, but depending on the organization, there could be a number of other tools in place. Some organizations do political work or advocacy work and have tools for that. Many non-profits rely on in-person or virtual events or peer-to-peer fundraising. Some offer online communities or online courses and some are even leaning into new tools like A.V. testing, personalization, machine learning, data warehousing, and so on. So nobody's doing all of this, but our typical client will have some number of these five, six, seven of these different platforms in place. So we're primarily interested in what these changes in the technology landscape mean for websites, particularly because we build a lot of websites and we respond to a lot of website RFPs and we see there are changes in what's being asked for in terms of skill sets and the size of projects and the types of relationships. And we really want to understand where these trends are heading so we can think about multi-year planning for nonprofit websites. So something that's easy to spot from this slide alone is that today the website is competing with many more systems for an organization's attention and investment. In a given year, there's only so much a team can accomplish and so much budget to go around. So this might mean that decisions are delayed on when to make a website redesign happen or even when to do sort of essential technical upgrade. So we want to learn how organizations are navigating these decisions and which parts of the stack are highest in priority and what are the expected benefits of the year investments. So to learn about this, we conducted a survey. We ran the survey between February and May this year and we invited around 300 organizations and of which about 58 responded and completed the survey. So we started by asking this question if they agreed or disagreed with this statement, our website is our most important asset for marketing and supporter engagement. So I'd love a raise of hands for people here. Do you agree or disagree? If you agree raise your hand. So about 45, 50%. We actually got a higher response in our survey, about 72 respondents either agreed or strongly agreed but that left about a third, 28% who think that other systems are as important or more important than the website. So with so many other systems in play now, this isn't entirely surprising but we wanted to learn more about which systems are on the rise in importance. So the importance of the website to the website is influenced by what the organization thinks of as the website's primary jobs. So we asked what are the most important jobs your website has to do. And here you can see the responses grouped in three buckets by the size of the organization by their operating budget. So brand awareness and general education is a consistent answer across all three groups but after these two the results diverged a bit depending on the size of the organization. For smaller nonprofits providing community resources and enabling community connections were highly important but as the nonprofit grows in size from possibly a local organization to a regional or national one then fundraising and donor acquisition really starts to become important and event promotion becomes very important along with building their email list and mobilizing for advocacy depending on the focus of the organization. So these are the most important jobs that the websites need to perform but next let's look at what components are used to power the website to accomplish these ends. Right so the website isn't just the core site running on the CMS. So all these other platforms in place serve up front ends of their own. So forms, landing pages, event registration pages and so on. So we asked what platforms made up the front-facing user experience and we can see that email, the CMS marketing automation tools were used by 84% of respondents. Event management systems are closely behind the 71% followed by fundraising platforms at 67% which is actually to me surprisingly just a little bit low. But then advocacy, social media, job recruitment systems all came in in the 30 to 40% range. So what that means is that maintaining consistency of user experience and creating content on the part of staff can be a difficult and fragmented experience. And in fact, we hear from our clients that all these systems aren't working all that well together. Of course, the proliferation of specialized marketing tools creates a new challenge, data fragmentation on the backend. And in fact, we're frequently hearing from our clients these days that their systems aren't talking to each other. So there's a lot of data integration work that needs to happen to make the platform as a whole function as well as it can. Given all this increasing complexity to get a sense of where nonprofits are heading, we asked how priorities are changing across a range of tools and capabilities. You can see here in the top right that there are four that stand out as increasing in priority. So marketing personalization, CRM, primary website and email. So we're gonna set the website aside for just a minute and take a closer look at why CRM personalization and email are rising in priority. Nonprofits know from other sectors, particularly retail and e-commerce that personalization works. It works to increase engagement, drive additional revenue, and they're trying to get there, right? They're trying to figure out how to apply these technologies and tactics to their own work. That may be part of what's driving the adoption of a wider range of tools and more sophisticated platforms, but getting all those tools to work together is hard. And I think organizations are really struggling to unify the experience and the data. We heard a lot of respondents saying we wanna make better use of the tools that we already have. So let's look at the CRM. We asked why the CRM is increasing in importance and here we have some responses that are representative of the reasons we've heard so far. Our CRM has always been a high priority for our organization but is only growing more so as we try to better integrate it with the site and build out user journeys. We have tech debt left over in our CRM due to a staff turnover and issues with our CRM software provider that are now we're investing and correcting that. We need more tailored interactions with our audience and that's increased substantially. We want to be able to personalize user journeys and content and our first step is capturing users info and engage in history. And then lastly, data just feels more important than ever. So we have a range here of it's, we're trying to do new things and better integrate. We are trying to correct technical debt and just sort of upgrade our stack. We are trying to create tailored experiences and we're trying to work with data more holistically. CRMs are now designed to integrate with many other systems and so by nature they gravitate to a very central position in an organization and non-profits adopt these systems because they have a vision of unifying supported data in hopes that it'll create more targeted communication and personalization. But CRMs aren't necessarily great at making data useful and actionable in real time. Often we see the data sinks happen on 24 hour cycles, there may be additional expenses to pull data out and do things with it depending on the product. And so we see that many of our customers are adding additional systems for marketing personalization or CDP to hook it up to the CRM which is more nimble and they can do things in real time. And that leads us to the next set of tools that non-profits are prioritizing. So why is personalization such a high priority for half of respondents? As we saw in the previous slide, the ability to support personalization strategy is a key driver for investment in the CRM. But as the quotes on this slide illustrate, marketing automation is typically the next level goal once an organization is in a good place with a CRM. So we adopted a marketing CRM and automation platform to deliver personalized email content. We're looking at personalization to deliver engagement opportunities based on what they're interested in. We're optimizing donor acquisition with appropriate cultivations, asks and CTAs and by tailoring messaging. You can see here that organizations are looking to lean into personalization to respond to softening responses to older and less sophisticated tactics like light boxes. Supporters have grown accustomed to personalized messages in their other activity on the internet. And so they don't respond as well to generalized content or messaging that doesn't speak to their interests. So the expectation is that if we can tailor messaging and calls to action better, make them reflect where a person is in their journey with the organization, they'll drive a stronger response and ultimately lead to more revenue. So at Blue State, a big focus of our work is email campaigns for large non-profits. And we were particularly curious to learn the reasons why organizations continue to email as a priority for greater investment. And the quotes here show some of the key drivers. Email enables highly personalized communications. It provides a channel to very specific audience segments. And email has been seen as a safe constant in a shifting landscape, particularly as Facebook and Twitter fade as reliable channels. So the respondents talked about why email is important from a strategic perspective in their communications. But we think there's another reason at play here, which is that it's simply less complex to implement. Typically the non-profits we work with see tighter integration between the CRM and the email tools to create marketing personalization. It's that the email tools are in the CRM are already sort of pre-built to connect together. Sometimes they've even sold as a package suite. And so there's relatively little work to get that functionality up and running and show results. Conversely, we see very little integration for personalization between the CRM and the website CMS, Drupal or otherwise. And this sort of sets up a three-on-one competition among these four priorities because more progress can be made faster between the CRM and email. So rounding out our questions on priorities for the near future, we asked what organizations planned up with you this year and next. Two highest priorities were take better advantage of the tools that are already in place and better integration of data across the current stack. And these are, I think these are pretty interrelated. The first point is something we hear often from clients that they've invested in sophisticated technology but aren't able to take full advantage of it. Often they say their teams are stretched too thin or the tool ended up being too complicated for their staff to learn or use efficiently. The second point, addressing data fragmentation is a major area of focus for us and our clients right now. All this says that organizations do believe that they have the right tools in place. They just need help making it all work together. We also asked respondents to look back to their most recent big technology investment. And most said their most recent big move was to a new CRM. Most added that it had been a long and bumpy road with a lot of pushback deadlines and many were still struggling to make use of the new platform long after the project officially completed. Which is why this work continues to be a top priority. Getting to a good place with CRM is seen as a prerequisite for unlocking a lot of other capabilities. Many organizations also reported that they recently updated their website but in at least half of those cases that was driven less by a strategic priority than the need to do a major version upgrade or just needing to upgrade the technology for the site, particularly in many cases moving from Drupal 7 to Drupal 8, 9, 10. So what do these findings tell us? 2022 year-end saw revenue decline across non-profits digital programs in our work and reported by some of our peers in the space. And this continued a year-long trend of lower-gift volume as people have worried about the state of the economy. So less revenue combined with more digital marketing tools means organizations are making tough choices between platforms for attention and investments. And the survey suggests to us these takeaways. First, organizations take on a change to the CRM when it's seen as a strategic imperative and then once started, it becomes a consuming priority for several years. Following a CRM implementation or migration and organizations need to better integrate data comes into sharper focus and then that drives a new set of priorities in that direction. And then conversely, or perhaps because of prioritized investments in the CRM, organizations are currently making big changes to the website less frequently. And when they do, it's often not driven by strategy but it's in reaction to required updates or technical debt, as Jack mentioned. So to put this in another way, organizations know that their website could be improved but they choose to get by with what they have for another year because upgrades to the CRM are seen as more crucial. So for everyone here, I'd love to get a raise of hands if this resonates with what you're seeing. So about six or seven people raise a hand. So obviously this isn't a trend for everyone but we think that this is sort of becoming a real concern in our space and that there's only so much you can do and there's a sort of a sense of capture by the CRM providers of budgets. Like it's sort of once we step on this path, we have trouble doing the other things that we thought we'd be able to do because it's bigger and more expensive than we were led to believe, for example, is a concern that we're seeing. So we've talked so far about how the survey suggests that the website has been losing a bit of ground in competition for investment with other parts of the stack but in the last few slides, we'll look to turn back at the website and say what the survey revealed about the challenges and opportunities there. So we asked, what are your most significant website challenges? And the two most common responses were integrating external systems with the site and measuring and optimizing performance. These resonate with what we heard about making systems work well together. It's a priority to incorporate the website into the broader MarTech stack to unlock things like website personalization and behavioral data collection. There's a lot of eagerness I think to get more sophisticated in how websites engage visitors if we can only get the various data systems working well together to enable it. But despite those challenges, we have seen recently that the website has been outperforming other channels like email as we'll see on the next slide. Yeah, so fundraising is obviously a key job for the website for nonprofits in general. And so we wanted to share what Blue State has been seeing outside of the survey in this area. And so overall in 2022, it was a down year for fundraising, which shouldn't be surprising given the overall concerns about the economy and waves of layoffs that we saw at the end of the year in particular. So 2022 year end results saw a decline about 5% in general. But email in particular is sagged by about 15% compared to the previous year. However, while revenue was down generally, more than half of our clients saw increases in revenue attributed solely to the website. So meaning finding the site organically, not driven from a media buy, email or social, coming in through the front door, getting inspired and deciding to make a donation. So someone on that particular journey, we're seeing actually a raise in the results at the end of the year. And that was remarkable given the overall decline. So helping to make improvements to the website to optimize those journeys actually can move the needle and raise more. So in our work with clients, we're focusing more efforts on SEO, increasing the top of funnel on A.V. testing to optimize journeys once people arrive at the site and remove friction in the donation paths and ultimately raise conversions. In particular, mobile journeys are something that we're realizing you can really make a lot of gains in. So on average, close to 60% of all traffic coming to the website is from mobile, but only 36% of donations are from mobile. So you get many more visitors, but many fewer donations. And so, and also the average donation size is about half when given from mobile. So under $96 versus 94 is some of the data from last year. So digging in to optimize the journey on mobile really is an opportunity to move the needle. And it's something that we're starting to do with more of our clients and sort of evangelizing this idea. So while we recognize the practical challenges that organizations face as they seek to incorporate new tools and unify their data, we're encouraged that most organizations still see the website as their most important asset for marketing and engagement. And for half, the website's only increasing in priority. I'm gonna call out two of these quotes. Is our main engine for driving engagement with the core audience we serve and diminishing returns and attribution challenges make upper funnel even more important to Sam's point on the last slide. So to end, I'll share some advice we've been giving our nonprofit clients for how to maximize their limited time and budget. Don't think about updates to the website in terms of a three or five year cycle of major rebuilds. It's a shift of thinking about frequent incremental improvements. Think about the website as a revenue generating digital product with an ongoing roadmap. Especially since we know that many orgs have recently done a major website redesign or upgrade. It's likely that the site is in good shape to sort of grow incrementally now as opposed to needing a full rebuild or upgrade. And that gives an organization the flexibility to focus on whatever is the most pressing issue of the moment, whether it be website performance, SEO, mobile user experience, or even adding in some level of personalization as the rest of the stack catches up. So it's not revolutionary. It's also not how most of our clients work. For those who haven't made the transition, we're able to be a lot more agile and make more consistent progress on the website. So we wanted to round up by giving a shout to a few partners who helped us recruit survey participants. So thanks to Kenobi Studios, to Forum One, to Calamuna, to Think Shout, WDG, Capellic, Corner Shop Creative, and Pantheon. And with that, we'd be really happy to answer questions. And also, if anyone wants to take shot of our email addresses, we'd be happy to share this deck with you. We intend to publish this more formally in the coming weeks. And so are there any questions? Michelle? So the question is, what was surprising? What did we go in? What did we go in not expecting and that we saw from the results? I would say the statement that we think we already have all the tools we need, but we're not taking best advantage of them. And then that's the pain point, is that we don't need something new. We just need to use everything that we've already invested in better. Any insights that stuck out to you? No, I think that's right. It does resonate with some of our clients. I think that there's a range of feeling on technology adoption, I think. Some clients have invested in sophisticated marketing cloud platforms and are now frustrated in questioning that investment, because they're not taking full advantage of it. Others are just looking to invest more, looking to figure out how to get past those complexities, the staff limitations, the things that are getting in the way of taking that next step. So the question is, what is the next step if you are struggling with integrating the website into the broader stack? And this is an existential thing for us in our work, because we're eager to make progress. And we see strategies that should be achievable. But year after year, they get deep prioritized. And even when we have an ongoing relationship where we're helping plan the roadmap, some of these things just end up getting set aside year after year. And so it's frustrating to us. The one thing that we really would love to see and should be simple to achieve is the personalization of a CTA and a website to resemble somewhat what we were able to do on the email side. So it's very typical for the email journey to get someone to sign up to the email list. And then once they're there, start asking them for donations, tailoring the ask to their donation history and what we know about their interests. And why don't we do that on the website side? It should be very simple for the CTA to say, if you're not signed up already, sign up for email list. And if we know you've given something in the past, ask for the first donation if they've never given. And if they've given before, ask them to become a monthly donor or ask them to give more. And those three states are pretty simple. And we have the data on the CRM side. We know all of those things. But we don't actually have a single client that has succeeded even the largest organizations that have the most sophisticated tools are doing this on their website and Drupal websites included. And so why is that? And it's just there's a lot of friction getting the data over to the website. And so I don't know if anyone saw Elevated Third's presentation of their personalization tool. They've presented it in a number of Drupal cons this time, smart content. We are looking to use that in conjunction with the CDP with some of our clients where we can actually get the data over to make that very simple journey happen. And the question is, if an organization doesn't want to invest in the CDP, how can we still get things going like that? I don't know if you have any thoughts to add. Yeah, I think CDPs are really promising for this. So adopting a tool like Segment or Buconic or there's a whole wide range of them that can be much more nimble in terms of what data it's collecting, how it's storing that data, how it's making it available directly to the website, and being able to connect to a wider range of systems more easily, I think there's just a lot of promise there. But it is an investment. In the meantime, I did a webinar a couple of years ago actually about how to just, if you have specific tactics like the Lightbox example that Sam was giving, that you think can move the needle and you want to experiment with, just go at the problem of getting that specific piece of data, like someone's last donation, get that either in a cookie or into the content management system somehow, whether even if it's manual, it's not a sustainable solution. But if you could make that some specific piece of data available to the website in some timely way, then you can start to experiment incrementally with some of those tactics. Again, it's not sustainable and it's not necessarily simple. But we do think that not asking somebody for their email after you've already gotten it or not recognizing that someone is a donor to your site when you pop up that Lightbox or whatever ask you're making, not recognizing their history with you, is detrimental. That's something that is worth trying to address and trying to get the person to deepen the relationship by recognizing where they are with you and making sure that you're always making the right next ask. One of the things that we've seen, if anyone here uses the platform Neon, is that they've recently reintroduced a CMS product going back in the direction that Blackbot originally was pursuing just because they want their customers to be able to create these effects, to have this integration. And I was very surprised to see them launch that last year sort of a step back in the direction that we had been going for a number of years in the space. Any question over here? Yeah. The question is, how are data warehousing is relatively low on the importance list? And the question is, how are organizations pulling all this data together and doing personalization if they're not prioritizing data warehousing? And from what we've seen, there's a lot of variation in our clients in how much they've invested in data and data warehousing. Some of our clients have full data teams. They're running Snowflake or Redshift warehouses, and they have invested in this. And then others just haven't. And so we sort of see our role as sort of helping to bridge that gap in a couple of different ways. One is just helping with whether it's point-to-point data integration or helping to sort of solve some of the CRM challenges, even if there's not a data warehouse, if you can get as much as possible connected to CRM and then use that as a jumping point to push it into the marketing tools from there. And we are also, like as Blue State, we're investing in not necessarily, I wouldn't call it a data warehousing platform, but investing in a reporting platform that we can sort of hand to our clients who don't have sophisticated data teams of their own. What we're doing is we're building something that is relatively easy to deploy that can collect data from all of these different sources for the purposes of reporting. We haven't necessarily taken the leap yet to say, OK, we're actually going to build you a data warehouse that we can then push back audiences into all these different tools, but that's potentially a next step. Again, that's not necessarily answering your question about what organizations can do. But as an agency, we are trying to help our clients by providing them with reasonable cost, templated solutions that can help to fill some of those gaps. Thanks again for attending. And looking forward to sharing this with you.


Should we do it? Yeah, let's get started. I think them, we have forums, so we're good anyway. Go for it. All right, welcome everyone. I've got, I guess, who's got the slides? Is somebody, shh, bleh, can't speak. Engaged for mouth, right. Who's got the slides and can share them? Should be Taylor one second. Yeah, it's Taylor here. I thought they were there a moment ago. Yeah, we just had them up. What happened? Is Taylor still on the call? Because I'm also not saying being recorded yet. Yeah, one second. She's restarting. Ah, OK. God, she's hosed one second. Let's give her a minute. I guess it would be good to wait for Taylor, partly for the slides, but also for the record button. Yeah, no, she's got admin access. She should be back any second now. Looks like she's back. So, hey, Taylor. Hey there, I'm going to share one second. No worries. Great. I'm sure the recording is going to, because that's looked like it killed that. Oh, there it is. It's recording now. OK, cool. Share away. Let's get to the agenda and we'll get started. Yeah, all right. So while the slides come up, welcome everyone. We've got a few things to come through. There we go. I think we could move straight on to talking about KubeCon and ClanNativeCon, which, Chris, I imagine you have a couple of things to say about that. I'll just quickly, CFP closes for KubeCon North America on July 2nd. So if you're interested, please get your talks in. We're doing pretty well in sponsorship. So if you're interested in sponsoring, please reach out to us. We've had a huge influx in interest in co-located events. So we're doing our best to kind of accommodate, but please get your request sooner than later. Other than that, yeah, go ahead. July 12, 10 days from now, not the second. Sorry. Yeah, I'm still jet lagged from China. July 12. The link is there for the CFP. Next up is we've been doing these conference transparency reports for all of our events moving forward after the TSE requested them. So if you go to the next slide, Taylor, it's online available. There's a PDF and website that basically kind of breaks down number of tendons, number of companies, attendees, percentage of end users versus vendors, et cetera, et cetera. So it's fairly detailed. So feel free to comb through it. But a lot of data is available for you to kind of poke out there. We'll be getting the one done for China, hopefully by the end of this month also. So if you have any questions on KubeCon or the transparency port, let me know. Just give a couple of seconds in case anyone's got any questions right now. I have a quick question for the call for proposals. Are we only allowed to submit one? Is that right? Or is there a mechanism for submitting more than one? I believe you're capped to two talks per person that you could submit. If I recall, Dan, you may remember the rules offhand. That's correct. You can submit. You can be a speaker or a panelist for up to two talks. It doesn't matter who actually submits it. But you'll only be accepted for one. Right. OK. And you can do this from the same account. Maybe I missed something. But it seemed like you wouldn't let me add another one. But it was perhaps just me. It could be a bug if that's the case. You certainly should be able to submit two from the same account. And you can reach out on Slack or by email if you're having trouble doing that. But just as an FYI, we don't actually care whether you submit it or a co-speaker submits it. We're not tracking by who submitted it. It's who the speakers are. Got it. Yeah. I thought, Dan, that it limited to if the marketing people were submitting, the marketing person could only submit to regardless of whether if it was the same speaker or not. That was my experience last year. That sounds like a bug. So I'll take that up with Nancy, and we'll see if we can adjust the center. OK. I'll try and confirm that and let you know. Thanks. Thank you. Any other questions on this? All right. Six. OK. Let's make on to the six. So we'll be hearing from Six Security in a very short moment. Six Storage. I think the last meeting, or roughly the last meeting, we had a discussion about the co-chair and tech leads for Six Storage. And we're talking about two existing co-chairs. And we're looking for approval for Erin as the third. Is that how that works? That's right. We have two co-chairs right now, and we're looking to have Erin as the third. And we already have a couple of tech leads. Actually, we have three tech leads, and we're looking to add Brad and Louise as tech leads too for the various projects that we're looking to engage on next. OK. Any comments or queries or concerns from TSC folks about those people? I'm going to take that as everybody seemingly happy. Chris, do we need to formally have a vote, or are we just able to say? I mean, if there's no objections here, we have quorum. I'm happy to have it pass. I would also accept if anybody said they wanted to push off the decision. That's also something you can say. Otherwise, I think we should just approve. Just a comment. I think we pushed off the decision about a month ago to give people more time to consider it. So I think we can consider it now, unless there are specific objections. I think that's right, unless anyone has any new concerns to raise today. I think, all right. Well, they have my support. Any objections? Consider it approved. Thank you. Brilliant. Thank you, everyone. Great. SIGAP delivery. I know there's been some activity on drafting the, what do you call it, like the? Charter. Charter. That's the word I'm looking for. Thank you. Alexis, I know you're here. Do you think we are exactly in a good state to be discussed, to be approved? It's been shared with everybody who's on the app delivery SIG mailing list, which was everybody who responded to say they were interested in being in the conversation when we advertised it a few weeks ago. That's about 40 people, I think.  And if you're not on it, email Amy and me. And Michelle, but if you look at it, you'll see references to the draft charter. And we're looking for feedback at the moment so we can start the process of getting potential chairs to nominate themselves. We're essentially trying to bootstrap the charter and the chairs at the same time. So we did an initial cut of the charter to give people a sense of the direction. And now we're sharing it with the community to help finish the charter. While we're doing that, we're asking the most enthusiastic members of the community to self nominate as possible chairs. I hope that makes sense. Any questions about that process? All right, so I think the conclusion there is it's not ready for a vote yet. It's still in progress, but, you know, it sounds like good progress is being made there. There is at least progress being made. I wouldn't quite guess as far as to say good. We have delays mostly due to things like KubeCon. But it is now in the hands of the right people together. And I think it'll be ready for a vote in probably four to six weeks time, I would hope. Great. I know there was also a discussion of a networking related SIG that I believe someone was interested in actually forming. Yeah, yeah. Yeah, hey, this is Lee. Yes, this is the answer. And soon, there's a proposal written that is, I would say, 90% draft complete and should be shared on the networking, working group mailing list shortly. Feedback and insight from Matt and Ken are forthcoming on that as well. So I think it's just still just an in-flight proposal. Okay, great. I think if you start following the model that SIG security, SIG storage and SIG app delivery have started putting in place, that seems to be working. So is there a form in your chart? Or is it just an informal group that's pulling to that stuff together right now? Joe, actually, I think I missed the first part of your question. Oh, is there a mailing list or anything sort of formal that folks can get involved with the SIG networking? Sort of. There is. That's still very informal. There is, we'll drop it into the chat, the mailing. Okay, and do we have any other folks interested in forming any other SIGs right now? Yeah, I volunteered to help set up the applied architecture SIG if there's demand. I just bit backlogged at the moment. I was intending to have started it by now, but I have not yet. I can't do it in the next few weeks if there's demand for that. So what's SIG I missed that one? It's called Core and Applied Architecture. So it's basically Kubernetes and applied architectures of Kubernetes. And I was just to be clear, I was just offering to kind of kickstart the process of drafting the charter and goals, et cetera, and trying to solicit some interesting people to serve on it. Now, that's an interesting name for it, but okay. I'll wait to see Mr. Omen. Yeah, and that's certainly the name is up for debate if you like it. It was kind of debated in the original SIG stuff, but it would be up to this new SIG to clarify the charter and if they decide it's necessary to rename it. Okay, great. It does look like a very large set of technologies there covering orchestration, scheduling, and runtimes, et cetera, so there we go. Okay, I think the one that stands out we don't currently have in flight is probably observability. So if there are folks out there interested or thinking about setting up a SIG for observability, that is open. For those of you who missed the last 18 months of discussion on Twitter, observability is monitoring, logging, tracing, and debugging. Okay, so I think we can probably, unless anyone wants to say anything else about SIGs, let's move on to SIG Security and Justin Kappos, I believe, is going to be telling us about SIG Security Assessment process that they've put in place. Great, well, thanks Liz. Yeah, so what we've done is we've set up a process by which we take a project for the moment. We've really looked at a few security projects and gone and provided a lot of security information and context at a high level. This is not meant to take the place of an audit but is meant to tell you things like what is the system designed to do? Where are the gotchas at? Where are the things that if you can figure it, you should think about it. What sort of protection should you expect to get when this is used? Is the project developed in a way that makes sense or are you likely to find a lot of problems with it? Things like this. So this is meant to be helpful for anyone who might sort of adopt it and also meant to let the TOC and others go and look at this and try to decide is this the kind of project that from a security standpoint, we want to have, you know, be admitted into this ENCF. And we're not trying to go through and actually go through and say, aha, we found a buffer overflow here or we found this issue there. There would be a later assessment by Cure53 trail of bits or whomever else the TOC contracts out to find those types of issues. Next slide, please. And really, as I said before, there's two main audiences here. We're really trying to answer these sorts of questions, from the CNCF end user standpoint to help you figure out what security properties you'll get by using your project and how to set it up correctly. And then the TOC to understand things about where maybe gaps are at in the TOC's landscape, how do we improve existing projects and so on. To this point, we've gone through and done several assessments. There's a very long and painful assessment that the Intodo project that went through as it was the first project to be assessed. So we kind of rewrote the rules, I don't know, three or four times as it went through the process. OPA is mostly through the process, we just need to do a little bit of sync up and declare them final. Key Cloak and Falco have expressed a lot of interest and I know Spiffy, Aspire and others are also, I think, ready for a refresher for this. Our plan is to conduct an initial set of about five assessments and then go through and sort of revise and formalize some of the steps that we're doing in a way so that we can make sure that things are much more uniform. I'd like to thank a lot of the people that have gone and participated in this, Sarah Allen, Justin Cormack, Brandon and Brandon Lomb and a bunch of other people that I'm gonna be embarrassed that I've forgotten that have started with it so far. And if you're interested in participating, please come join us and join our meeting on Wednesday at 11 a.m. Eastern time, whatever that is in your time zone and we'd love to have you participate. So I'm confused, are we just doing CNCF projects or non-CNCF projects? But we're doing projects that effectively from our standpoint, it's what's being recommended to us by the TOC. Okay, so what's the process for recommending that? Cause I don't think we discussed it. Not, I mean, maybe I missed the meeting or the email list, but where did that list come from? Projects. We had some initial conversation and Liz and others who know this should really step in but we had some initial conversation and we were told these seem like good projects. Like I think when the SIG was formed, there's like, these are these five projects that should be part of it. And that was tough, Spiffy Spire, Falco, Opa and something else, Istia or something else. I forget what, but something else that I'm forgetting. And then the Spiffy Spire assessment that I did before any of this was set up was kind of used as the model. So we said, we don't need to do them first. Toph has had a lot of assessment, thank you. And so then we went and said, Opa would be a good thing. And in total, when in total was going to come up for vote in the TOC, there was a discussion about why don't you be the first one for this process. So we would expect there to be a more formal way to do this in the future. And we're also need to have a discussion about should these be things that are refreshed annually? Is every project supposed to go through this so that we would look at Prometheus, which are other projects like that or what the process should be? Yeah, I just wanna make sure that we put effort into the things that are CNCF projects first or are well on their way towards a vote. And so I think definitely there's been discussions about some of the other projects you mentioned, but they're not really on their way to a vote right now. So that's the, and I heard T-Club there specifically. And I know that we've seen presentations from T-Club, but I don't know of any formal submission of T-Club to the CNCF. I know there's been a lot of discussion, but it's been happening one-on-one. And I wanna kind of bring that stuff into the public. Yeah, so this is exactly the conversation we wanna have. The process is that I just put a link to our new issues. We have an issue template. So any project or the TOC can initiate that and anybody can put out a request. And then the prioritization is something that we want, like the TOC influences, yet we weren't going to wait for the TOC to pick a project if we have bandwidth. So the idea is we queue these things up. The TOC influences the order, but then we have a team ready to be doing a security assessment at any one time. And so yeah, so we wanna refine that project. At the beginning we had these two queued up in total on request of the TOC and then OPA because it was the one in this list that hadn't had an audit or some kind of prior review. And they were involved in the group. And so basically we're a little ad-hoc'ing it right now so that we have some in the queue and completely welcome whatever process is appropriate for that prioritization. I mean, one of the things that I think we've been talking about across the TOC is getting a more sort of structured sort of flow chart in terms of how projects come in different stages. And I think it'd be interesting to look at this through that lens. And so again, so that we move from this sort of ad-hoc lot of one-on-one conversations and then something comes up to a vote. There's a bunch of stuff that gets started beforehand to more like, okay, this is in a sort of this stage. And so let's activate some of the gears to make sure we get a closer look across the various groups there. So yeah, definitely something we should take into consideration as we do that. So, all right, thank you. Yeah, and also the other thing I wanted to mention is that we thought we would start with the security-focused projects because one, they need an assessment. And the other thing is the people from the project really know their stuff. And then we wanted in this first five to have one project that is not security-focused but then of course has some security. So we're looking for kind of guidance on what that project should be, either by a project raising their hand and saying we really want to participate or the TOC identifying one that the TOC is particularly. Things would be a good candidate for like, this is a template for a project that has security but isn't for security. Okay. Yeah, I think it's worth having the conversation in terms of what that sort of non-security-focused but security-impacting project might be. I have some ideas but I don't wanna start that discussion now. Super, yeah, so just for people to start thinking about because it'll be probably after we get through the next couple. I think one thing that's quite interesting in the discussion of the flow chart here, the flow for projects in general is that security makes sense to review security-related projects and also makes sense to review non-security-related projects that may need to be operated in a secure way where I think other seeks, there's a more kind of clear, you know, if we had an observability seek and we were asking for the observability seeks opinion on an observability project, we might also want to get seek security's opinion of the security implications of that observability project. And I'd also argue that really for any project, you at least want to know that you shouldn't operate it in context X or context Y. And so I think there's at least some argument to be made that pretty much every project should go through this if for no other reason to say, like this is wildly insecure if you use it in situations A, B and C, so don't do that. Yeah, a lot of what we're finding is that the assessment process is a matter of saying, oh, maybe you want to put this high up in your documentation that things that the project maintainers might think are clear and obvious to everyone are actually a well-kept secret from a user's perspective because projects aren't aware of how users perceive them versus how they think of themselves. I think it might be useful to just circulate an example assessment so that people on the TOC can see the kind of recommendations that you're making. Well, coming up is the Intodo presentation which includes its security assessment. So this was very much like right before you're about to hear a sample assessment. So that's the first one we anticipate that it is like we've been through and like four to six iterations on it so and it is not perfect by any means. So that is the first of five that you will hear and then we welcome feedback on the format, the content, all the things. Justin, do you want to take this question about overlap with the independent security audits? Yeah, I was, yeah. So I think that the way to look at it is when you get an actual security audit and you read it, it's typically a very dense document where they've gone and they've pinpointed particular things that they say are vulnerabilities in a project. A lot of times the assessment is more meant to provide high level guidance about how to use something and the way to do it in the way the system is intended to be done. So an assessment will do things like help to guide the auditors about what to look at and talk about scoping and resources, whereas the audits that you go through typically try to pinpoint vulnerabilities. And so there's a few examples of that. You can see this if you look at, for instance, a lot of the audits that Tough Project has had by different groups or audits that other CNCF projects have had, there's a focus on, there is vulnerability X with severity Y and then that's probably been fixed three weeks later, but that doesn't tell you, when you deploy it, you should think about doing it way X, way Y, this is the secure way to do it, which is more of the assessment process. So I just wanna call it in the chat, somebody's saying overlap between, okay, so that's what you just answered, but then Quinten also had his hand up, I wanna make sure that. Yeah, I just had a quick question about, so there was originally a request from the TOC to produce like a white paper, and I think there was some debate about whether that was a good idea or not, but either way, it seems useful before going and doing a bunch of assessments to at least agree on some basic ground rules, terminology, these are the general approaches to the following categories of cloud native security. There's key rotation, this is what it means, it's typically done in the following ways, et cetera, those kinds of things. Do we have such a general framework before we go diving into specific assessments of specific projects? So just as a, before we, the SIG ever got in place, audits were happening, so a lot of this is, there's activities that are happening and that are needed for projects, you know, kind of for the projects to meet needs of the projects. And so the process that we're following is to do the activities that the experts within the group know how to do and have that informed the vocabulary. So one of the reasons that this INTODO project took so long was getting to alignment on what this assessment is, how is it different from the audit? How are these volunteers from various companies, what's an appropriate role for them to take given that this isn't their full-time job and how is that different? And with the knowledge sharing and education aspect of the SIG, how does that color this process? And so it might be appropriate. Do we have something that the TOC and end users can consume that says this is the scope of cloud-native security and these are the terminologies that we use and everything else should be read in that context.  So as I was about to say, the scope of SIG security, which was just formed two months ago is specified in the charter and we're working on a roadmap, which we anticipate will include the white paper that was much discussed many moons ago. And this security assessment was just prioritized ahead of the completion of that white paper. And so it might be appropriate for us to schedule a presentation of the roadmap as that gets put together so that the TOC can give feedback on that. But yes, we do want to do that and we're taking a bottoms up approach. And so you can see the security assessments. There's a lot of vocabulary that is being used there but security also includes policy and compliance and a number of aspects that need more discussion in order to get to alignment about what the group is comfortable putting forth. Yeah, and I would also like to jump in and say that in these first five assessments, we are trying to be quite clear about defining things that we think are unexpected for readers. There's a stupid question phase that the person leading the security audit does where they expressly try to make sure that there's meaningful definitions for any terms that they think a reader might not understand. So, but we haven't formalized this process. This would I think make sense for us to talk about once we've been through the five assessments and we have a better idea of the right scope and fits into something like what Sarah was saying throughout the map. It is in the charter that one of the things that security will do is educational resources which include things like common vocabulary to talk about and understand cloud native security. So I think it's documented as part of the charter but I don't think it has to be done in, you know, the precise order that is laid out in the charter. And I think the fact that there are people volunteering to do security assessments is really, really valuable. There's a follow-up question about security and audits. So I think that that's still in process. Like we, so Justin Cormack reviewed all of the audits and we're trying to figure out what is our role with that and, you know, but I think that I think it would fall under sick security to coordinate with the auditors, but that isn't a separate CNCF process. So we'd love to see feedback about, you know, how to engage. I assumed it that it was a matter of logistics and that it would fall under our, you know, sort of broad. Because the auditing process started before sick security existed and has kind of got its own process going. Like many of the audits have happened already. We haven't been as directly involved, but some questions have come out of it which we're following up on. Okay. Any other questions? Oh, no. Any other questions or comments about the security assessments? I would definitely say it'll be really useful to see the example as we go through in Toto and we can see the kind of value out that comes through that. Okay. And a comment there from Sarah about some common vocabulary for use cases and personas. Quintin, did that cover your question? I don't expect that the use cases and personas covers the questions. It's just I'm trying to illustrate the bottoms up approach. So I'll drop in a few links. We've developed some resources and then, you know, and I'll point to some, and then we'll come back with a timeline on the white paper and the other things mentioned in the charter. Quintin, does that address your concern? It does answer the question which it sounds like the answer is there is not a complete body of information that I was requesting and I just wanted to point out this has been requested over and over from that group which previously was called a working group and is now called a SIG for over a year now. Actually, I'd like to correct you. We were not, we proposed to be a working group and the request was not clearly presented to the whole group and the priorities were not clear. So I think there was some miscommunication between JJ who was one of my co-chairs and myself. I don't know if he's on the call. And so there were things were prioritized differently because we got many different requests from the TOC and we weren't formally involved with the CNCF until a couple of months ago. So we've been doing work that the community that we felt was the community valued in, you know, I think a white paper is a grand idea and it's just not done yet. So to answer your question, this is JJ Quinton. I think in terms of the first problem that we had with security was the scope was too large to just to make sure that what's in scope and what's out of scope took a lot of iterations and that's specified in charter. And then the second stage of like what are the categories and then all the projects that are associated with the categories that needed some form of definition which I think we took care of. White paper is an in progress thing. There's a lot of different ways in which we can actually slice security. If you wanna layer security in terms of functionally, it's gonna look a lot different. If you're gonna layer it structurally, it's gonna look a lot different. If you wanna layer it based off of associated project, it's gonna look a lot different. But to even basically to address what makes sense and how we can actually make sense of this to the end users, a lot of use cases needed to be understood. And I think we spent a lot of time collecting and gathering use cases. This coming up with a white paper that's like functionally narrow will be easier. But for something like security, it's gonna take some time. And once you have something, then I'd want it to be a little bit more meaningful in terms of like how we can trade on it. So that's a long-winded answer, short-winded answer. Short answer is like we are working in steps to gather enough information so that the white paper is meaningful. Would it make sense to think about carving up rather than doing a single white paper, doing smaller, more focused white papers? I'd be open for, yeah. In fact, the policy working group, subgroup is working on a much more implementation focused policy white paper, whereas the white paper that JJ is referring to and Quinton's referring to is more the security landscape and the terms and all the different parts of security. So it'll be more of an overview, like one of the things that we struggled with is who's the audience for the white paper? And that we didn't get a lot of input from the TOC on that. And so we talked amongst the different members and people in the community and found that, and I had an interview with Quinton and it was really felt that it's the deciders who need this white paper of like, how do I reason about security in the cloud? And how do I know what, how to make these choices and what things should I be worried about one of the categories? And so that's where I think we could still use some participation of the TOC in validating our assumptions about who is that audience. And one thing we've talked about is could we get a few people who are from the end user community who are representative of the audience to validate the white paper so that they, you know, we could have reviewers who are outside of our group who could say, yes, this is useful content because we want to produce something that is valuable to the audience. Okay, so Joe and I are the kind of liaisons to sick security. So I think I would make a request to the other members of the TOC that if you have particular concerns about what sick security is focusing on, you know, let's discuss that and try and come up with a coherent message to the team there. Or show up to the meetings. That also. All right, any other questions on sick security? Or shall we move on? Thank you very much, Justin and Sarah. Thank you. All right, moving on to the question of archiving rocket. We brought this up a month or two ago already so I don't think it's a surprise to anybody but Chris has now created the formal request to do the archiving process. Do you want us to say something about that, Chris? Yeah, sure.  So, you know, I've had some private conversations with the rocket team. I filed a public issue kind of notifying them publicly that we intend to do this, you know, per our process, they're supposed to have essentially two weeks, you know, to discuss or come up with anything before we formally do the vote. So that's kind of where we are right now. I just kind of wanted to kind of bring this up to see if there's any other further thoughts or discussions. I think we're just kind of being slow and careful here, notifying all the respective parties and community that this is gonna potentially happen. So from a process perspective, we'll formally call a vote in about two weeks if there are no strong objections from anyone. Okay, and then we're gonna help the team move documentation and project, you know, website or the rest of it. I'll figure that out. There's some other complicated things where I think they're also participating in summary code, but they're happy to do that. You know, still they're an open source project. We'll figure it out and kind of document everything. Okay. Just giving a moment for any other comments on that. Hey, this is Jay Pipes. Just a quick question on this. Is there a plan to have like official messaging from CNCF with regards to this archiving? We like CNCF blog or something, like explain the ramifications of it and that kind of thing. We haven't decided yet. I think I'll kind of lean on the TOC, but if they wanted to put forth a statement or something, we're happy to syndicate it on the blog. I personally, I think overcommunication is not a bad thing in this case, but I'll think, you know, I don't know what the TOC thinks about this. It's our first archiving. So we need to explain what it means to archive a project. Yeah. That's an area where I think the executive staff, Chris could help actually because it's not just about the TOC. I mean, this is a long-term decision. Correct. Like that is no problem, but I think from like a TOC perspective, like we archived it because this project is maybe inactive or doesn't reflect the value, blah, blah, blah. There's that that I'd rather see come from the TOC than necessarily staff, if that makes sense. So the technical commentary, what format would you like that in? Statement and paragraph? Yeah. Statement, blog, like Google Doc. Okay. Why don't we suggest, I'm gonna float an idea that maybe staff could like come up with a blog post with a space for us to comment. Like. Cool. Consider that done, not a problem. I might have missed it. Is there, is part of our communication sort of like talking about how projects can get unarchived or adopted elsewhere or what have you? Because I think that that'll help it feel sort of less final in case somebody makes the wrong call. And I know like in the past, we've said, oh, well, the TOC or, you know, the LF can decide to do this stuff, but maybe having something that's clear there will help soften this a little bit for folks. Going into the LF is not the end of the road for the project. It just means that it's no longer part of the cloud native tent for the time being. And I think what we talked about before was the idea that a project could be revived. I mean, there are many people who use Rocket who may not have noticed this and might come in. There's also people who've spoken on Twitter. I see Chris here from Kinvoke talking about it on the slide, for example. Right. I think, you know, I know that's what we've talked about. I'm just wondering if that's part of the communication plan. Do we have that written down anywhere or has that just been informal conversations? We have the reactivation archival process. OK. So that is part of the, you know, I'm just, yeah, just soften the blow a bit, you know. Yeah, we're sure. Au revoir, not. Go ahead, Alexis. I said au revoir, not idea. All right, so we'll share a post with the TOC and then we'll do our best to kind of fill it in. Great. Any other comments about Rocket or archiving in general? OK. Right. Ten minutes for Backlog. OK, so, Chris, I think this is to try and keep us honest and make sure we're working through the Backlog, right? Yeah, so, I mean, basically outside of the schedule for the community presentations, I think the important question to ask is, I think it's hard to say no always, right, and trying to find projects that you may want to say no to here and do it at some time in the coming weeks would be good. You know, we seem to have an uptick of interest now of projects wanting to come in. I don't know whether it's a seasonal thing, but, you know, we have quite a lot of projects in the Backlog right now, so I don't know if there's any thoughts of, you know, how you want to go about this, but I just wanted to kind of raise awareness and make sure everyone's kind of on the same page of what's on the Backlog right now. My understanding is that Longhorn is actually ready to present next week, is that not the case? We shuffled them around. They're presenting to the storage SIG first, and then in August they will present to the TOC and wider community. There's other ones floating around for a while, like CNI, Genie, I believe, and others that I think just basically need a kind of an answer of what we want to do with them. And I think also just referring to Joe's comment earlier, this is one of the reasons why we need a clearer sort of flow chart on what the process is. This is something that as the TOC we've discussed privately, and we have some volunteers. I can't remember who those volunteers are. I think it was Brendan and Matt to draw up a flow chart, because we need to get on top of this process and make it very clear not only what order things happen in, but also the etiquette of approaching C members, just so that everyone knows we are all now communicating with each other if we are approached about a sandbox project, because I think there were concerns that a bit like if you're a kid and you don't get the answer you want from dad, you go to mum, right? So, while it's totally fine to talk to TOC members we are now trying to over communicate with each other about conversations we're having around a project, particularly sandbox. Okay, so I don't know if anyone has any particular strong feelings about any of those backlog. I mean, I think Longhorn is going to be presented. Do we know about dates or prospective dates for any of the other proposals in that list? Some of the shift to August, I'm still trying to track down folks availability and so on. Chris, this is Erin and I joined late, so maybe I missed it, but do we have clarification of what we want for sandbox projects? Are we going to require a formal proposal and a presentation when the charter doesn't necessarily reflect that? Generally, I think the legwork of doing a formal proposal to PR and starting from there and kind of deferring to the TOC whether, you know, hey, maybe there's two immediate sponsors or they want to see a presentation and so on is, I think is a better path than just asking for a presentation to put us a little bit more legwork on the project. So we should probably update that in as part of the sandbox requirements so it's more succinct and then I'd be happy to put together an example. PR, what we expect is part of that, if that would be helpful. I just, I seem to kind of get a lot of these questions and it's not necessarily intuitive if you're a brand new project to come to want to present. I think that would be very helpful, Erin, thank you. And I think actually as part of that, that can help us as the TOC figure out, you know, whether there are other questions that we should be asking before we accept a project in at Sandbox or any other level, having a template for all those questions. Right, because we did that. Sorry, I didn't mean to cut you off, I have a lag in my network. It's, and I think we did a really good job at that with the due diligence and we couldn't put that together but I don't think we ever stepped back and did the same thing for Sandbox. Yeah, I think I completely agree. Great. Yeah, that due diligence is a bit vague with respect to the different categories. So it gives general guidelines about how to look at a project and how to evaluate it but it doesn't, it's not very good at distinguishing between these things have to be there for a graduated project, these things for a Sandbox, these things for a incubation, et cetera. Perhaps it's worth refreshing that document in that context. Well, and I think it changed Quentin, if you remember right, because we did used to do due diligence even on Sandbox and then we had so many projects it just wasn't scalable. So then we said, well, we're not gonna do due diligence, we're just gonna do presentations. So yeah, I think if we split it out into the categories and kind of loose requirements at least for each, it would give a better set of guidelines for the TOC that's consistent for every project coming in. Yeah, that makes sense. Right, that's all I had, thanks. All right, I think we can all take this as a bit of a kick to take a look at the backlog issues, see whether there are, and I think TSC members, let's all try to over communicate with each other whether there are some projects here that we do or don't, you know, if we have objections to a particular or concerns about any of these backlog projects, let's share those concerns so that we can start saying no, because I think this is one of the problems here we need to say no to some projects. Liz, as part of saying no to some, does there need to be a reevaluation then after we're finally done with the backlog to go back and based on some new set of standards, say no or say you have to come up to this next level? I just, I fear there's an inconsistency just based on the number of projects coming in, the changing of the TOC, the changing of the policies, that someone who did it a year ago compared to now isn't judged by the same, you know, set of rules. Yeah, I think that's completely fair, completely fair criticism. I think maybe having that kind of set of questions and the documented flow of how the project should work and perhaps if we are clear, something we talked about was the idea that when we say no to a project, in the hypothetical situation where we say no to a project, we should be trying to document why we've said no, but with a certain level of discretion that, you know, if we, you know, if somebody submits a project and it's just in terrible, terrible shape, and really what we're saying is this project is in terrible, terrible shape, we may not wanna say that publicly, we might wanna communicate that privately, but I think if we're having more general guidelines on, for example, this project, well, you know, we're saying no to it because you're not prepared to move it to a license that the CNC would, you know, that would be a very clear reason why we'd say no, and we should probably come up with a few more of those reasons why we would say no and why we do say no when we do, yeah. Also, I'm seeing, yeah, okay, so a couple of comments coming up here. So Lee was pointing out that the requirement to present is listed in the Sandbox process. And to my mind, we should have that presentation before TIC sponsors actually commit to sponsorship because otherwise, how do we hear about objections? Yeah, I think that's all right. Yeah, in my mind, the redirection of Longhorn to the storage, SIG is in part where I think those working groups in those SIGs are four. And so, yeah, that as a general, I don't know that we necessarily state that in there, that can be a way of ensuring some diligence, offloading the TOC sum, allowing the TOC contributors to enter in and assist. So I don't know if there are two places where that requirement, that presentation requirement is called out. And yeah, I don't know if refinement there is necessary or not in terms of funneling through a SIG first. One thing that I think is worth of taking. Sorry, go ahead. So one thing that I think it's worth updating the larger community on is the TOC got together and one of the things we talked about is just creating more communication about as projects start engaging with the TOC across different TOC members. So one of the things that we're doing is that if you talk to any of us about a project becoming a sandbox or incubating project, we just want, we're gonna share that information across the TOC as soon as possible, just to make sure everybody's on the same page. Because I think that, you know, things can get pretty confusing when there's a lot of one-on-one conversations. And we don't want somebody in the TOC having a concern and then somebody else committing to a sandbox project without having a chance to really have these things talked through. Thanks, John. Sarah, also your comments about having a clearer communication to the SIGs about how to prioritize requests and roadmaps. I think that does also make sense. Yeah, and we're kind of making up the SIG processes as we go along, but we'd actually anticipated that we would present our roadmap before presenting the security assessments and things because Intodo's been waiting for like six months to actually do their presentation and proposal to this TOC. We kind of did things out of order and probably should have acknowledged that. I really like the idea you just posted there about labeling in the backlog when a project proposal is related to a SIG. I think that could be a useful part of the process. Well, cool, yeah. I'm happy to do it. We're running up on time, so... Yeah, we are. Was that the end? Have we got anything else? Nope. Cool, see you everyone next week. Awesome, great. See you all next week.


Awa kwa blooming ibu kwa kaziwa muna wa kwenha in Afrika, which may be the basis of the tents. We've not seen it as a serious crime in the past but we think, over the past decades, that we have seen a lot of those cases emerging in areas specifically in the trade market and so on. I should say, Interpol has really been very instrumental in the support it offered to Namibia. First, you can't solve any problem without capacity. Namibia was one of the accoded countries to have undergone first mentoring program of IPSIC, organized by Interpol. We have had the opportunity to spend some time as a Namibian delegation in Lyon where we were trained for two weeks. After that, we went back home, tried to put what we learned in two breaks. Two days, three days workshop, organized by Interpol, which was attended by a number of African countries. After the three days conferences and training, then we did the operation at Tosha, which was very, very significant and yielded quite a number of satisfactory results.


More than half a million concrete bridges carry our nation's highways over watercourses, canyons, bays, and other roads and structures. A significant percentage of these have deteriorated or will begin to deteriorate in the near future. Much of this deterioration is due to the action of de-icing salt, which penetrates the concrete cover and initiates corrosion of the reinforcing steel. The resulting rust causes the concrete to delaminate and spall, leading eventually to severe deterioration of the riding surface. Many of the most severely damaged bridge decks require total replacement because they're no longer capable of safely carrying today's heavy traffic loads. Other decks may have to be replaced because they're too narrow or are otherwise obsolete in terms of their function. Fortunately, though, many bridge decks can be cost-effectively rehabilitated through the use of concrete overlays, and that's the focus of this video program. We'll begin with an examination of deck condition, then we'll move on to materials, surface preparation, and overlay placement. So let's get started. Deck condition. Excessive deterioration may indicate that only total replacement would be cost-effective. Although a visual survey is the first and most important test, including a close examination underneath, this is especially important if there's been an asphalt overlay. After a visual survey is completed, the deck should be sounded to locate any subsurface delaminations. Extensive delamination may indicate the need for deck replacement. Delaminations may also be detected with more sophisticated techniques, such as infrared thermography, impact echo measurements, and ground penetrating radar. Half-cell potential measurements are often used as part of the deck survey when bridges are chosen for rehabilitation and overlays. The electrical potential measured between the copper-copper sulfate half-cell and the rebar steel is an indication of the probability that the rebar steel is corroding at any given location. Large areas of potential values that are more negative than 350 millivolts indicate that the deck is a good candidate for rehabilitation. Sampling for chloride analysis is another widely used measurement in deck surveys. Powder samples are obtained using an impact hammer and are then analyzed in a laboratory. Samples can also be analyzed in the field using a new technique developed by Sharp. Chloride contents in excess of one to two pounds per cubic yard of concrete are usually sufficient to initiate corrosion of rebar steel. Some agencies may require removal of all chloride-contaminated concrete prior to installation of an overlay. This will prolong the life of the overlay because corrosion will not continue in the absence of chloride. All of these measurements can be used in a decision model to determine the most cost-effective strategy for deck rehabilitation. This computer-based model is available from Sharp. Now let's look at materials. There are various types and systems of materials which have been used to overlay reinforced concrete bridge decks. These include latex-modified concrete or LMC, silica-fume concrete or SFC, low-slumped dense concrete, LSDC, low-water cement ratio concrete, LW slash C, and polymer concretes, PC. Conventional Portland cement concrete has also been used to overlay bridge decks. Because LMC and SFC are the most widely used, we'll concentrate on these two types. Latex-modified concretes contain a latex emulsion generally based on styrene-butadiene polymer, which is added to the concrete mix. A typical mix might contain 658 pounds of cement per cubic yard, 15% latex solids by weight of cement, fine and coarse aggregates, and enough water to reach a slump of 4 to 6 inches. The water-to-cement ratio should be no greater than 4-tenths. Air entrainment is not required. The LMC is mixed in mobile concrete mixers and placed at a nominal minimum thickness of one and one-quarter inches. Silica-fume concretes contain a very finely divided material which is a byproduct of silicon or ferro-silicon alloy production. Silica-fume is available in slurry and densified powder forms. These concretes normally contain from 600 to 700 pounds of cement per cubic yard, 7 to 10% silica-fume by weight of cement, fine and coarse aggregates, and air entraining and water-reducing admixtures. The water-to-cement plus silica-fume ratio should be no greater than 3600s. Super-plasticizer must be added to obtain the desired slump in the range of 4 to 8 inches. SFC is produced using conventional ready-mix truck operations. After the deck has been selected for overlay, the next step is surface preparation. All deteriorated, delaminated and spalled concrete must be removed and the surface must be properly cleaned prior to placing the overlay. Most often the process begins by scarifying the top surface of the deck to a depth of at least one-quarter inch. Scarification using automatic rhodomilling equipment must be done carefully so as not to damage any steel lying close to the surface of the deck. Also, because the equipment is not capable of reaching all areas of the deck, considerable handwork may be needed near curbs and joints. In lieu of mechanical scarification, a process known as hydrodemolition can be used to prepare the deck surface. This technique involves applying water at pressures up to 20,000 psi to cut grooves at regular intervals across the concrete surface. The high pressure of the water also breaks off the concrete remaining between the grooves, removing all concrete to a preset depth. The unit is robot-controlled and can process up to 100 square feet of surface per hour. The equipment can be used to selectively remove only deteriorated concrete. However, in preparation for rigid overlays, it's simpler to remove concrete to the depth anticipated for the overlay. This allows the contractor to place the overlay up to the grade of the original deck. That way, existing drains and joints can remain at their original elevations. One of the major advantages of hydrodemolition is that all deteriorated concrete surrounding reinforcing bars is removed during the process. So, chipping hammers are needed only to obtain minimum clearances. This results in labor savings and prevents damage to the bars. After the top layer of concrete is removed, the deck should again be sounded to identify any deeper delaminated areas. These areas are then marked with paint, and the concrete is removed using small chipping hammers. The hammers should weigh no more than 30 pounds, and the angle of the hammer should be less than 45 degrees to the surface. The contractor has to be very careful not to damage any exposed steel. If the bond between concrete and steel has been destroyed, or if more than half of the bar has been exposed, the concrete should be chipped away from the steel to a clearance of at least three-quarters of an inch. After all of the deteriorated concrete has been removed, the remaining concrete and exposed steel should be blast cleaned. All contaminants, dirt and loose rust must be removed so that a good bond between the overlay and the substrate may be obtained. High-pressure water blasting can also be used. This final cleaning must be done no earlier than 48 hours before placing the overlay. The surface should now be thoroughly checked for the presence of any material which could interfere with bonding. A good way to check for loose material is to use black electrical tape. Just press the tape onto the surface, and then examine the sticky side. If the tape picks up any particles, the surface should be cleaned again with dry compressed air. During the cleaning process, the contractor will begin setting the rails for the paper. The rails are positioned outside the width to be paved on a curved sidewalk or medium barrier. They should be supported by adjustable rail supports. No discernible deflections of the rails should be permitted. The next step is to dry-run the finishing machine across the full length of the lane to be paved. The minimum overlay thickness should be verified by numerous clearance checks during the run. Also, the vibration frequency of the screed should be checked with the vibratory tachometer during the run. After all corrections are carried out, a final test run should be made. On the schedule day of placement, you should check the ambient conditions to see that they comply with agency specifications. Many agencies use this chart to determine the evaporation rate from the concrete. Determining the evaporation rate involves measuring the ambient air and concrete temperatures, wind speed, and relative humidity. Concrete temperature can be measured in the shade using concrete thermometers or thermal probes. Wind speed can be measured with a small portable anemometer. Relative humidity can be measured with a traditional sling psychrometer or with new digital units. Suggested maximum limits on evaporation rate range from 1 tenth to 1,500 pounds of water per square foot per hour for LMC and SFC overlays. If the actual rate exceeds these limits, considerations should be given to placement at night when temperatures are lower or taking precautions such as using windscreens or fog sprays. Normally, there are also limits on minimum air temperatures for placement. Generally, overlays should not be placed when ambient temperatures are expected to fall below 45 degrees Fahrenheit during the period of placement and curing. The final step of preparation is to saturate the deck and then allow it to come to a surface dry condition. Wetting is normally done from 2 to 3 hours before placement. Once the surface is dry, the deck is ready for placement of the overlay. Latex modified concretes are generally produced using mobile concrete mixers. These are essentially mobile concrete mixing plants with output capacities of from 3 to 12 cubic yards. The dry materials are stored separately in hoppers on the mobile mixer. The water and liquid admixtures are stored in tanks. The materials are then fed through vibrating gates onto a conveyor belt that transports the material to an auger mixer at the front of the unit. The mobile mixer must be calibrated prior to use. This is done by discharging materials and measuring the amount of time needed to discharge the desired weights. All discharge rates are based on the rate of cement discharge. Now we're ready for the LMC overlay placement. A bonding grout should be broomed into the deck immediately in front of the area to be overlaid. The grout can be composed of sand and cement paste broomed out of the actual LMC, or it may be prepared separately. In any case, it must not be allowed to dry out before the LMC is placed on top of it. LMC is then discharged from the mobile mixer and placed in front of the paver. A roll of concrete should be maintained in front of the screen. You should check the vibration frequency of the screen again now that the screen is under load. In variable depth areas, more than 3 inches deep, internal vibrators should be used in advance of the screen. The paver cannot finish the entire width of the deck, so areas near curbs and joints must be carefully hand-finished. Throughout the placement operation, a 10-foot straight edge should be used to check the plainness of the surface. Thickness check should also be made frequently. After the overlay is consolidated and screened, the surface must be textured. This is normally done with a turf drag or a large wire broom that produces transverse tines ranging from 1 eighth to 3 sixteenths of an inch in depth and spaced at about three-quarters of an inch. The areas near the curbs are usually left un-textured. Problems can result when too much time is allowed between placement of concrete and curing. Ideally, a lapse time should be no longer than 10 minutes, so all work should be done rapidly, but with great care. Timely and proper curing is essential for construction of durable LMC overlays. Wet burlap kept continuously moist with soaker hoses and covered with thick poly film is the preferred method of cure. After the first 24 hours, the burlap is removed and the overlay is allowed to air-cure for three additional days. Construction of bridge-deck overlays using silica-fume concrete is virtually identical to that of LMC overlays, with the exception that mobile mixers are not generally used. Instead, conventional ready-mixed trucks are used to transport either central or truck-mixed silica-fume concrete to the job. Since the ready-mixed trucks will deposit concrete immediately in front of the painter, it's important that the deck surface be protected from any contaminants that may drip off them. This can be done with plastic sheeting or dry burlap mats placed on the deck or cloths may be attached underneath trucks to catch any drippings. SFC overlays are also very susceptible to rapid drying and cracking. Curing must be initiated immediately after the timing operation so that exposure of the surface to the dry air is minimized. SFC must be moist-cured for the full curing period. This should consist of at least three days of wet cure under soaked burlap covered with poly film. Provisions must be made to keep the burlap continuously wet. Longer wet cure periods are desirable. We have seen how decks are selected and prepared for concrete overlays. By closely controlling the quality throughout preparation, placement and curing, these overlays will add many years of life to the bridge and allow vital transportation functions to be maintained.


Shave everyone 1000 here today. I got something different. This is not what I was going to post That's what I had to show you I Was originally going to talk about some of the inconsistencies in this story You know, well, if you guys don't know I'm I'm I'm certified mechanic. I've been a mechanic all my life So I you know whether whether this internal combustion Engine is on a plane in a car on a boat. It doesn't matter. It's still an engine but What I want to show you guys is if you look down here second one down right there now Look at the time. It's supposed to be 16 minutes and 42 seconds, right? Now this is from him. This is his channel Trevor Jacob. All right now. Let's click on this and see what happens, okay? first of all it comes up as a Two-minute 12-second video now as you can see up here Right hand corner up there. I do have my head blocker on and for some reason it's still giving me the sad In the run-up and we'll be on our way soon now if I click that to skip the ad it starts into the video But if you look at the time now The video the video is only 12 minutes and 53 seconds long We'll be doing the run-up and we'll be on our way soon. So that's how it starts in the air Now if you if you look down here where it says show more nothing and Yesterday when you show more it just talked about the Ridge wallet did did they drop his sponsorship and he cut that out? So but he left the whole name video up. So it's still like there's there's some things I want to talk about like right here Okay, this is an auxiliary this for an auxiliary tank on this wing.  It's not even hooked up. There's a GoPro here and it appears to me that it's turned on later on in the video It's not What's this over here? Is this the? because I believe I Believe this thing had was capable of carrying 12 gallons of fuel But what what I found was in the I'm not sure where it is now under the fuel on this that that plane now it said the fuel was It had six gallons over this right wing, which is on our left, but it's considered the right wing and It was a six gallon auxiliary and it said that in the manual For this plane that if when you got down to half a tank of fuel You would open that up and drain that into the fuel tank the fuel tank was supposed to be under here somewhere But I'm looking over here on this wing the left wing which is on the right side of the screen here. Well for me there is a tube coming out of here and There is a it looks to be I'll tell you what it is I mean, this is copper line used for fuel lines. This is definitely a fuel line and like I said this You know this valve here. I'm not sure but it looks like it's any off position Like I said, I got to do some more research on that that'll be in an upcoming video, but if you look here Okay, like You got your copper line going up It seems to me like there will be a fuel tank here under this wing too And it looks to me like there is a hollow tube coming out of this wing right here. Let's make this bigger Okay, coming out of this wing right here. See that too Right there and then we've got this copper what I believe to be a fuel line coming up into Rubber which that's you know kind of normal if you got flaxing and stuff You want to have a rubber piece there for something to give see your line don't crack It looks to me like this Right here this rubber line should be connected to that shouldn't it This should be connected right here See where my arrow is This part should be seeing see screw holes here and there's a screw hole there. This should be mounted here This is a fuel line This should be connected here. It's unconnected This is unconnected. I believe this to be a fuel tank up here. I believe this this one here to be the auxiliary I believe this to be a fuel tank, and it's not hooked up So what's going on? I mean do you purposely run this thing out of fuel or what but anyway today? what What what I wanted to talk about was just that what who who removed it mean because I'll show you something here That on mine yesterday if you saw my video yesterday, and I'll go back check it out. It's video right before this one There'll be a card up here at the end somewhere here But this is what originally how it originally started out, okay Go happening. How's it going? My name is chamber Jacob. We are here at the end of the runway gonna go fly the 1940 Taylor craft up to mammoth and Do some paragliding do some snowboarding. It's gonna be a super good time I got my best friend Johnny strangers ashes with me. We are going to Go paraglide off of one of his favorite mountains up in this year in avatars and spread some of those So I'm super grateful. He'll be joining us.  This is all all that is gone. Let's get out of there all that is gone Let's take this and like I said now. It's now. It's a 12 minute 53 second video So he cut that whole that whole section out somebody did We'll be doing the run-up and we'll be on our way soon. So much love see that's where it starts That's where it starts now Okay, so I mean right there You go to his channel.  All right, let's go under videos There it is now it it has also changed to 12 minutes and 54 seconds and Again, it just starts out Just abruptly after his little ad his little sponsorship thing, you know, and it just it's ridiculous I mean this guy is A piece of work. He left everything else in there.  I mean Okay, I don't want to stray too far off of this, but yes someone did I don't know if Ridgewall it made him do it if Ridgewall it has the capability of doing it theirselves But as you can see right there show more show less nothing Comments have been turned off now. I read somewhere where a Ridgewall it turned them off. I don't know if If you can give them permission to do that But anyway, they were on for a little while and then they got shut off and now like right here show less See let's hit show more. There's no description whatsoever Nothing when there was a Ridgewall it thing here and uh, you know a link to it How you could get it and stuff like that so anyway guys I just want to show it to you things are just getting stranger and stranger. I mean did he really Him and his friend really Charter a helicopter and go remove that plane.  So what was he doing at the plane? You know, I mean in my book once and cameras are mounted, you know Once these cameras are mounted on here to me. That's kind of like a black box Why wouldn't why wouldn't you leave him there to be no he took him and edited? You know To make this video This guy's a real piece of work man.  Okay, so I don't hear well You have no proof to back up.  There's nothing he can say a damn thing He can say or do about it and if he was right here. I told to his face. So anyway All right Well guys, thanks for watching stay tuned for more of this because trust me I'm gonna hit some more topics on this thing Anyway guys again, she bears a myth man alleged.  Have a great week. Be safe


At Audiology Associates of Prestonsburg, you can live your life the way you want and find the freedom of better hearing. You'll experience patient care that is specific to you with exceptional follow-up care that ensures your hearing and balance needs are being met. Audiology Associates at 1428 Northlake Drive in Prestonsburg. On Monday, September 26, the city of Pico named Lieutenant Johnny Lee Cole as its new fire chief. Cole was sworn in at the city commission meeting and is fully supported by the rest of the fire department and over 20 years of experience. I feel great as a very mixed emotions. We've been a great fire chief.  I'm going to thank you every day as a blessing from God. You know, thank my family, thank the support of my men.  After being recognized, Cole showed his gratitude towards the fire department, the city and his family. With his new title, he plans to give back to the community as much as possible. I just want to thank everybody for the support and the love that they've shown me. Chief Bentley, you know, he is retired. We just want to thank him for his usual service and everybody in prior to this.  It's truly an honor. I love this town dearly. I just want to make sure that everybody knows that we're there for them. I just want to make sure that at any point in the day that they may need us and that we're going to respond with the grant strategy that we can and show the families and loved ones with as much of a respect as possible. Thank you, Cole.


This study shows that machine learning models based on the one electron reduced density matrix can be used to generate surrogate electronic structure methods for systems ranging from small molecules to complex compounds. These surrogates can predict molecular observables, energies and atomic forces using standard quantum chemistry or a second machine learning model without the need for computationally expensive algorithms such as self-consistent field theory. The algorithms are packaged in an efficient and easy to use Python code, QM learn, accessible on popular platforms. This article was authored by Shu Etching Xiao, Lucas Payto, Mark E. Tuckerman and others.