Meta Team Goals 2024  ## Metadata - Author: [[Courtney Robertson]] - Full Title: Meta Team Goals 2024 - Category: #articles - Document Note: --- tags: [#wordpress, #opensource, #governance, #meta, #community, #2024goals] Author: Meta Team Contributors Source: Meta Team Goals 2024 Zoom Meeting Reference: [YouTube Recording](https://www.youtube.com/watch?v=lzuRXk0DGt8) date created: 2025-08-22 18:30 --- # Title: Meta Team Goals 2024 – Transcript & Analysis ## Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary The Meta team’s 2024 planning session tackled foundational governance issues for WordPress.org infrastructure. The team explored gaps in contributor onboarding, outdated “components” and “projects” dashboards, lack of clarity on maintainer roles, and the disconnect between Track and GitHub repositories. Discussions emphasized: - Updating handbooks with contributor pathways. - Strengthening transparency between community volunteers and sponsored contributors. - Standardizing dashboards, tagging, and team practices. - Coordinating with marketing to refresh WordPress.tv and other user-facing sites. - Scoping Q2–Q4 2024 goals with clearer project tracking, contributor roles, and inter-team collaboration. --- ## 📖 Main Content ### 🗒️ Notes - **00:04 Goal-setting kickoff** First Zoom planning meeting for Meta. Highlighted lack of centralized board for tracking goals across GitHub, Track, and other sources. - **02:22 Components confusion** Discovery of “components” tab on meta team site. Lack of awareness underscores poor documentation and contributor usability barriers. - **07:10 WordPress.tv** Marketing team introduced new leads, including one focused on redesigning WordPress.tv. Noted cross-team collaboration opportunities. - **09:31 Alignment** Need to avoid wasted contributor effort (past work rejected). Push for earlier alignment and approval stages. - **14:35 Dashboard decision** Should org site list GitHub issues directly, or serve as an explainer linking outward? Proposal for hybrid dashboards. - **17:09 Component maintainers** Emphasis on recruiting and documenting maintainers for each area (e.g., WPTV, Learn, WordCamp.org). Confusion over where roles are described. - **21:29 Component dashboards** Each component could become a dashboard pulling in tagged make posts, descriptions, and GitHub repo links. - **27:50 Contributor guidance** Contributor onboarding currently ends at environment setup. Suggestion to create contributor markdown files per repo, plus clear next-step pathways. - **34:19 Access levels** Advocated “protected” or “intermediate” labels for GitHub repos to prevent contributor discouragement when denied access. - **36:25 Projects page confusion** Duplicate, outdated “projects” pages on meta site. Some suggested deletion, others embedding GitHub projects for transparency. - **40:53 Transparency & trust** Discussion on bridging volunteers and sponsored contributors. Calls for more clarity in priorities and timelines. - **47:54 Updating posts** Outdated blog posts confuse contributors. Proposal for custom post types or standardized templates with revision dates. - **54:33 Q2–Q4 goals** Roadmap scoping: handbook revision, component maintainers, team site redesign timeline, marketing/Meta survey for feature requests. - **1:01:09 State of the Word follow-up** Addressed implications of new repos (e.g., migration tools). Marketing to support mapping connectors and clarifying repo responsibilities. - **1:03:16 Team reps** Meta currently lacks team reps. Proposal for facilitators rather than “leaders” to align with other teams’ governance. --- ## 📖 References - [Meta Team Site](https://make.wordpress.org/meta/) - [WordPress.tv](https://wordpress.tv/) - [Learn WordPress](https://learn.wordpress.org/) - WordPress.org Handbooks - GitHub WordPress.org repos --- ## 🗣️ Paraphrase - Original: *“Let’s not do a bunch of work that gets rejected. That’s my WordPress resolution—work we’re all on board with at each stage.”* Paraphrase: The goal is to prevent wasted contributor effort by aligning early. All stages of work should have shared approval before deeper investment. - Original: *“Meta is unique compared to other teams because of security. Some contributors simply won’t get access. We need to spell that out.”* Paraphrase: Meta differs from other WordPress teams due to security restrictions. Expectations about contributor permissions must be clearly documented. --- ## 📰 Newsletter 🎉 **Meta Team 2024: Building Bridges & Better Dashboards** The WordPress Meta team kicked off 2024 with its first-ever Zoom planning session. Big themes: clarifying component maintainers, redesigning WordPress.tv, and improving contributor journeys. Expect new dashboards that pull GitHub activity into make.wordpress.org, better handbook documentation, and inter-team surveys to guide the team site redesign. Marketing will play a key role in user-facing improvements, while Meta works to define Q2–Q4 priorities. Transparency, sustainability, and smoother onboarding are at the heart of these goals. --- ## ✅ Action Items - Update **Meta Handbook**: contributor journeys, access levels, maintainer responsibilities. - Build **component dashboards** with GitHub + make post integration. - Launch **survey for team site needs** (via marketing). - Define **roles for component maintainers** and display them on contributor profiles. - Clarify **security tiers** for GitHub repos to guide contributors. - Scope **Q2–Q4 roadmap** for redesign and governance alignment. - Formalize **Meta team reps** focused on facilitation, not leadership. Alignment with professional focus: - Strengthens governance → ties to OSPO leadership goals. - Improves contributor journeys → supports education & onboarding. - Emphasizes sustainability & transparency → aligns with open-source advocacy mission. --- ## 🧪 Hypotheses - Clear dashboards increase contributor retention. - Documenting access levels reduces contributor churn. - Early alignment between Meta and Marketing improves project acceptance rates. ### 📊 Methodology - **Surveys** of contributors (to measure onboarding friction). - **Analytics** on GitHub PR rejection rates pre/post-guidelines. - **Content analysis** of updated handbook vs. legacy guidance. ### ❓ Questions - Should GitHub issues replace Track entirely for Meta? - How can dashboards remain accurate without duplicating effort? - What incentives will attract maintainers for under-supported components? ### 🔮 Future Research - Testing impact of “protected/intermediate” repo labels on contributor behavior. - Studying inter-team survey results for design needs. - Analyzing correlation between updated contributor docs and PR success rate. ### 💡 Implications - Stronger contributor pipelines → long-term project sustainability. - Transparent dashboards → better cross-team collaboration. - Governance standardization → healthier open-source ecosystem. --- ## 🧠 Learning Styles Assessment - **Visual**: Weak. Needs infographics/flowcharts of contributor journey. - **Aural**: None. Suggest adding recorded audio summaries of handbooks. - **Verbal**: Present (discussion-based, but scattered). Could use clearer analogies. - **Kinesthetic**: Absent. Add “first contribution tasks” for hands-on learners. - **Logical**: Strong in diagnosing Track/GitHub disconnects. Could improve with structure - Summary: The content discusses the need for component maintainers and better organization of projects and information on GitHub. It suggests creating dashboards on the organization's website to centralize information and provide clear links to GitHub repositories. It also mentions the need for better documentation and a clear contributor journey to help new contributors. - URL: https://www.youtube.com/watch?v=lzuRXk0DGt8 All right, whatever that AI companion part means, we'll figure that out to give people some notes. Say yes, this might be the first ever Zoom meeting that Meta has had. Um, and also it might be the first goal planning that any of us at least know about. Well, at least on the, just on the, on the, at least on the community side. Yeah, yeah. I don't have my glasses. I really, did you see, I like wanted to pull down my glasses and do that, but I'm not wearing them, so I couldn't. I could imagine. You could get some AI ones. Go into the settings and like, get the, Just so I could do this. The fake hat and the glasses so you could have them. Although Bernard's here to make sure that you don't feel left out with the lack of glasses. Oh good. Yeah, yeah. That's funny. I was just talking about how I need new glasses, and I was looking at all their glasses for ideas. Yep. So, we'll try to keep the Zoom meeting parts, uh, specific to just the goal setting. And, I've done some goal setting work with other teams, like training and things, and we were fairly advanced in our approaches. Uh, whereas, Meta is, uh, no. Meta, Meta has A couple of inboxes that it checks on the regular and it's sort of hard to have a cohesive like, here is one board that we could go to for all of meta. And I don't know that we'll ever have that because we have track and we have the site GitHub repos and we have this and we have that. But I think it makes sense from the meta management perspective. Yep. So that GitHub project board that we saw from Steve. Looks pretty cool. In a way, do I feel like I am actually, I I'm here to, to set a space for us today. Um, I would love to hear ideas on how we could do this. One of the things that I know, um, kind of came to my mind in terms of meta management and Bernard, you, you helped sort of bring this back up was this idea of component maintainers, because that's going to be needed, whether it's our GitHub repos or our meta track tickets or whatever, it's like, who is overseeing those. Those realms of organization. I think, and even backing that up further, before we have a list of who is taking care of those things, we might need a list of the components themselves. To refresh that list, you mean? I don't know where it is. I mean, put it somewhere. Okay. So go to meta team site. This is a good exercise and look at the top. I'm actually going to, I'll screen share. Uh, but I'm making sure that I have my notifications all off. So at the very top of the meta team site, near where there's the link to things like the handbook on every team site, it says components. Um, and up here, components. Am I hallucinating? Oh, wow. Holy components in the blue. Why was I looking like I have never looked up there one time in my life. What the heck? I thought you were talking about, like, the text. Um, does anyone know how we manage those tabs? Uh, On a menu? Yeah, so usually there's a bit of a menu area when you log in on team sites. Like, wherever the handbook is listed, that's usually in there. Although, I will say, Kelly, for some reason, strikes me as someone that might have more of an idea. It's the, it's the menu. Yeah. It's a menu. I didn't even look at the menus for marketing. My, my computer is stalling at the moment. So pardon the beach ball while I'm screen sharing. Um, it's amazing how like that was so obvious and it like didn't occur to me. It didn't occur. Yeah. That's not on other sites as much. Like I didn't even think it was an op. Like I didn't go look, I didn't even look at the menu. Right. And the site. That's so funny. Yeah, so, um, I'm sorry that I'm stuck on screen sharing at the moment. We'll see if I can get out of that. But, uh, yeah, somehow Zoom is wanting to beach ball on me and that's not cool. So, in the meantime, um, uh, components that those are kind of the areas that sort of oversee some things. I am wide open for how we want to tackle this, but I think say to your point, um, Oh gosh, it's going to frustrate me that I can't get it to stop sharing. If we want to jump over to the GitHub board, which I can't, um, because beach ball. Uh, if we want to jump over to that and then sort of add on to the meta project backlog, you can see I've got it open on the bottom left of my screen. Um, and start making some notes. Like if we're going to recruit component maintainers, then we need to figure out this and make some notes kind of in that direction. Does that seem reasonable? Uh, yeah, I think it would also make sense to have a components project, uh, board. Yeah, uh, like, cause, like, uh, where we could manage, those components could be, is that, does that exist? Um. That's kind of what that page is. Uh, well, I mean, that's the list of stuff. Oh, it's like tickets and whatnot. Yeah. Yeah, if you, excuse me, if you click into it, you get like the track view, because I think those are all track components. Yeah. Which, of course, is not actually that reflective of how we're doing things these days. So that also needs to be. Um, yeah, I was thinking more in terms of, um, I guess it is. Wow, that's complicated. I don't know. Why are there so many errors? That's really funny. There's like a lot of errors. I'm like, what is what are we doing here? Uh, should there be a maintainer for each of these components? And there's not? Probably would. Yeah, originally there would have been. Like, is this just not current? Or is this? Accurate reflection of who is maintaining it is left to guess because when it came up during, uh, I want to say it was like end of November. Bernard brought up about WPTV and I was thinking, well, that would be a component maintainer. And I remember reading this once years ago, and, uh, I don't know that it's been thought of maintained really sense as a, an approach to how we view the team. I mean, even under components, I try to reach out to, um, the org, uh, WordCamp. org maintainer and team is, team is not responding at all. Oh. And he's the only one. Um, sorry. Recording in progress. Oh, who showed up? The other me, because I'm trying to let go of, yeah, I'm going to try and like, use this. If I have to close on my computer, if I have to close zoom to get a screen share unstuck, that's what I will do. Hello, Adam. Good to have you. Um, my, uh, so I just wanted to flag when we're, since we were talking about WordPress. tv, the marketing team has, uh, three new, uh, leads. And one of them also named Bernard. Um, I don't know how to pronounce his name. Bernard, Bernard. Not sure. That's fine. You know, but the other Bernard, there's two of you, uh, but he, uh, also just expressed to me, I was trying to schedule a meeting to do a onboarding for the new team reps. And he's like, my goal is just to redo wordpress. tv. So that's. You know, obviously, I think marketing is important from for the presentation user focus stuff. So that's pretty exciting that We're bringing it up. But also that marketing is so that's something I think we could definitely work together on and I can connect you through here or directly or however, we want to to I think marketing can help in a lot of these components. Well, not well, maybe in the components, but with a lot of the the user side Both the user side of someone, you know, the public looking at it, but also the user side of, um, contributors finding it. So that's something that I know that is, you know, that I'm going to be able to work on a lot more, uh, actual projects instead of team management this year. It's one bonus of not, uh, moving into doing the second. Team rep here. So I'm hopeful that we can have more check ins with marketing for site redevelopment to make sure that we're really looking at, you know, all the different UI components that we need and answering everyone's needs. So that works well for WordPress TV. By the way, that other Bernard. I somehow brought in because he was attending the Contributor Day at WordCamp Germany and I introduced him to the WordPress TV site and he was like, I want to redo the theme. That's amazing. Well, uh, well, you introduced him to it and he wants to do it. So, uh, Bernard times two is going to be about, and I guess you're both German? He's not German. No, he was just at the German webcam. No, but I think he's in Germany because he's in Germany. Yes. Yes. So yeah. Oh, this adds to the confusion, folks. Two Bernards. Two. Yes, and is German. And the other one doesn't have an H and isn't German, but is in Germany. But that is useful for you two. If you're both working on, you know, you're working coming from the meta side and he's coming from the marketing side. Honestly, and you're in the same time zone ish. Yeah. I also explained to him how, how it's usually working when you set up something like this and you project, you cannot just like, go ahead, do it. And then ask later, because I did a campsite 2017 theme for WordCamp Europe 2017, and I know how the process usually works. So you propose an idea and you get some mock ups and all of that. So don't waste hundreds of hours making a new theme. And then you end up saying we don't like it. Yeah. Let's not do a bunch of work that gets rejected. That's that, that that's my 2024 goal. It's my WordPress resolution. Let's do work that we are all on board with at each stage. Oh, that's a really cute emoji. So WordPress TV is definitely on the list. That's good. It is rightfully redesigned. Now we only need a maintainer who can actually merge and deploy things. Can we, do we have, uh, and this is maybe my ignorance showing again, since I didn't even realize there was a components page. Do we have a description of A, components, and B, the maintainer responsibilities, roles and responsibilities in general or per component? We do. I did not expect you to say that. I don't, I don't know if that's true. Um, looking like we have these components, right? We have this list of components. Um, but the one we're looking at on the components page. Yeah. Yeah. But like, for example, like global header and footer, that is part of the must use plugin that we use across all. org, which is a GitHub repo. And all the work is happening in that GitHub repo. Yeah, is that a component? Well, it's listed as global header and footer component. Well, I know, but is it, does that meet whatever definition of component is that we're working with? That's my point. I, I, I don't know. Um. Oh. Go for it. Okay, I'll just like quickly answer what you're asking. Um, the list is coming from track. This like that list. So there is a global header and footer component in track. And when people try to open a ticket there, we say go to GitHub. So this is actually, this list, as far as I can tell, is disconnected from any of the GitHub work. We've had that problem, right, Courtney, that the GitHub connection to the site, you've had that problem with, like, the last, the, the latest page? You're muted. Yeah, so. So, uh, I'm not sure on the latest, sorry, I switched over to iPad. Um, so that I could reboot the computer and get the screen unfrozen. Hopefully you all aren't still stuck on that. Um, so, I, I, As far as the disconnects say, I'm not understanding. Uh, because I know on your latest page, you've got feeds coming in from GitHub, and I think you've been No, no, no, no. You don't have the feeds coming in from GitHub, is what I'm saying. That's not, not relevant at the time. Oh, okay. Well, I mean, I'm talking about having GitHub information show up on this page. So I kind of feel like Oh, right. Yeah, no. So I'm doing some tricky RSS stuff. That's just a That's a content issue. There's no integration of how to get GitHub issues to show up there. And I was trying a method. So that's not connected to at the time when we're discussing component maintainers overseeing things that's not related. Uh, yeah, I just meant in terms of having, for example, you said that Kelly, the global header is, is being handled in GitHub, but none of that information about that appears here, right? If you were to look at this list, there's no, there's nothing, there's zero, right? So somehow either we need to connect the GitHub into here, feed it in, or, you know, make another table. Field, you know, make another column or scrap this in a different way, make more of a dashboard. Like, here's a track. Here's the GitHub like, but at the end of the day. This is not accurate, right? That is, this is currently not accurate because it's not tracking GitHub stuff at all. So anything that's happening in GitHub is not on here. Right, and it will probably only become more out of date as we continue working on GitHub. So that, to that end, it makes more sense to me to say let's try to figure out, like, okay, well I guess the question I would ask is do we want to continue to display this type of project information on the org website, or do we want to have it be like, here's an explanation, here's where you go to get that information via GitHub. Like, so, you know, either this is like an explainer that links to something, or it's a little dashboard of its own. I think that's, it's kind of trying to be a little dashboard right now. Which is helpful, right? So a good example would be, for example, like the, um, uh, how about learn the learn. wordpress. org. So if you click on that, um, Instead of we could, there could be a ticket related to learn that we would want to make sure that it's surfaced here, but I think we should also have information of like, here's the GitHub repo for learn, like, you know, like just have that information so that people know where else to go. Maybe it was like a low hanging fruit thing. Um, because that I think is the biggest thing, because when we were doing like the developer resources. Redesign. We kept having to, I mean, you, we had to actively tell people to go to the GitHub repo, you know, to, to follow the make posts. Because if they were trying to come here and they went to click on developer hub, it's just going to direct them to track tickets that are not relevant. Um, so that's not helpful. I mean, your comment was helpful, but that redirection is not helpful. Yeah. So then it sounds like what we need to do is sort of rethink. I mean, this is team organization at the the reason I honed in on component is solely from a team organization who's overseeing and answering to what things, even if they don't know all of the answers, who do we go to about WPTV, or who do we go to about learn or, you know, who's who's overseeing which areas. And then we can revise the content certainly on those pages so that it is more reflective of where the, uh, perhaps new to us contributor would be going. How do they, how do they see that info? So at the heart of it, it's about the contributor journey to get to the info to help, um, and what Meta can do kind of organizationally to make that a little bit better. So it sounds to me like Um, I'm just sort of noting there. Thank you on the meeting note, say. I just needed to write this stuff down because I was like, I feel it leaving my brain already. Yeah, yeah, no, no, no. So, so there, that's where I will say, I don't, if you all clicked on that link that, uh, that we had earlier, that Steve started to this GitHub project, I'm reluctant to share my screen now, but we'll see. Um, so, so, um, in the process of that, I'm thinking that we need to start putting some of this stuff into, you see, it says quarter one, two, three, four, and Steve had started kind of organizing through that I dropped in, let's see if it, I, I dropped in number six, where it says assigned component maintainers, I'm thinking that we can, at the very least, these might be really rough kind of notes for, um, issues in GitHub, but we could start as we're having this meeting now of jotting down the ideas. Within each of the GitHub topics so that they're in the place and we can clean up what the actual GitHub issue says it to be more polished if we would like later. Um, but under that draft for assigned component maintainers, I'll actually switch that to a proper issue if I can. Edit, does it let me? Who said, when I asked if there was a description of maintainer needs and of the people, someone said yes and then someone said no. Uh, the person who said yes. Can you explain yourself? Uh, nicely, I mean, I don't know who said yes. Did I imagine that? I don't, I don't know that I officially said yes or no. I think when I look at all of the teams in org, and a good bit of us here have hopped around on many teams for some time, they have different roles within the teams. And it's mostly clear what those roles are or mean or what it takes to do those roles. And while component maintainers might reference terminology, tied to track. This idea of who is the person to go to that makes the decisions or can get answers about the decision for these various buckets that Meta works in is more the way to think of it. So whether or not we're taking people off to track or GitHub or wherever we have to go for that source, having a person that is Um, going to watch GitHub track for those areas and or point people to the right direction for answers about those things I think is pretty important. Other folks? Uh, I just added onto that list. I'm just kind of adding all the things that I think we at least need for the components. Yeah. But, um, oh look, there's a something. Let's link that up. You can just put that in there. Uh, I noted that, um, uh, we, I, I don't think, doesn't look like it from my very marginal view. That's, that's a core component maintainer to be correct. Not a meta component maintainer. What are we talking about? What? What? Yeah, I said so. The role for core component. Yeah, yeah, yeah. Well, it's just a good reference. Yeah, perfect. But, uh, so something that we might want to do that is not currently happening is have the maintainer role show up on the profile, because right now that's not on there at all, and I think that'd be a you know, it's not necessarily like, ooh, I'm you know, a boon or whatever, but along the lines of badges, it is nice to show that there is, you know, you at least, I mean, otherwise really the only any sort of highlighting you get for that at all is your little on this components page, your little profile. So it might be nice to, you know, at some point, if we can tie that back in so that the maintainer role also shows on their profile. So I just wrote that on there. I don't know how, you know, that while that is one thing I'm noticing here is that I'm just clicking through all these components, I'm noticing that The individual component page pulls in make posts that are tagged in a certain way. Oh, really? Yeah. Wait, as a ticket? Or no, it's on their page. It's a recent post on make. metablog. And then like if someone posted about it and tagged, for example, Learn WordPress. org, it pulls it in, which is pretty sweet. I mean, so that really speaks to the idea that these are intended to be dashboards for each of these components. And so, to that end, I think we could definitely kind of dig into that. I think having dashboards on the org site makes a lot of sense. Even if they're directing to various different places, then at least it's a very solid You know, go to this page to learn more about that. Sort of like the teams, but the teams are just blogs anyway. So, you know, I like, I like this concept a lot. I'm going to do a test here because one of the things I'm thinking about, cause if we're doing, let's say someone does a proposal of a make post and it's about. an enhancement to one of these components, let's say learn, for example. If we're making sure that it's tagged appropriately, then that hopefully will show up on that component page. I mean, it's a minor thing, but like, it helps make that, those individual pages a bit more usable, because at least there's, you know, all the posts related to that component are pulled into one place. I would love to see proposals clearly labeled across all the teams. It might be interesting to implement a new tag for these particular pages that was like learn component or, uh, you know, whatever else component specific, I don't know, or, or just have it be more specific so that. I know sometimes tags can get, you know, sort of misused. I don't think that's the problem here, because I think people are not using tags enough. Um, but if we knew that it's, like if people knew more, that things that got tagged that way would have, would, like, that it matters. I don't think people really know that it matters where they're putting the tags, or what tags they use. Like, what are people really using that for? So if this has, um, If it's clearer that a specific tag will have it show up here or on its individual dashboard, um, I think that would. You know, and we have a clear, this is the tag, like a list somewhere. This is the tag that shows up here. Um, I think that would be really useful. I just did a test with one of my recent posts and now it shows up by adding developer hub to it. So. Oh, cool. Let me, so we need a list. I'm gonna add this too. I know you're doing stuff in the, um, GitHub, but I'm not gonna do it in there for now. I'm just gonna do it on this doc and then we can process it in. Anyone feel free, by the way. Um, yeah, but I'm gonna add the, uh, that we need a list of tags. Okay. It's the slug of the, oh, it's, it's a slug of the component. Okay. So we still need . Nick, which one did you say it was? It was for. I did the developer hub. Dev hub. Yeah. There's dev hub. And wish I would've you called component dashboard just to, if you click on developer hub Yeah. Yeah. List of components and slugs will show up in dashboard. Um, the reason I think how, oh, let, we dig in and then it tells us at the top it, we'll give you the posts. Okay. That's pretty great. I love that it's super low key too, like it's not like the whole post or whatever, just the title and the date. And I think you can actually add a description to that component, like in the editor, and it will appear in that white area right there where your cursor is. Yeah. So in theory, we could also add better descriptions to each one of these components, include links to like the GitHub repo or whatever. It doesn't solve the problem that we're just pulling in track tickets here, but it might be a temporary step. But it also, it also, um, allows, you know, This happened the other day with this. What is, what is my thing that I have made? It's a gesture that you're doing on, uh, on your computer because of your, your version of, okay. Everyone see my balloons? We're celebrating. Go ahead. Kelly said something too. Oh, I was just gonna say, I think that that, uh, having those hubs, having the description, that will really, um, That will really make this a dashboard for each individual component that people could actually use as a reference like that would be an easy way to go see what's happening all the news. Like I mean, all the pieces are there. It's just we're not using it. We're not implementing it on the post side or on obviously the GitHub. And then I don't think people know that that exists to the for is if evidenced. There should be a lot more maintainers there if people knew that it exists. They're like, look at all these empty spots like That brings us next step to handbook revision, and I'm just gonna log that one as a whole thing for its own, um, revise meta handbook, um, and in, that's just a note for now, that would become its own whole series of Tasks, but in there, you want to say something real quick before we're sorry. Yeah. Uh, yeah. So what I was, all I was going to say was the components. I was a bit wrong. There are, they are defined in WP admin. So we probably could iterate on that enough to add in some kind of GitHub integration too, so that we could then add our, um, GitHub projects as well. And we're not like totally stuck with track. I haven't looked at the code the rest of the way, so I don't know, but at least I think we can build on this. I love your thinking. That's fantastic. Um, say when you were saying about some of these other things. Well, one, all the stuff that we're all talking about today, some meta people built this thing, didn't document it, and now we're discovering while we're playing. Right? Documentation. Documentation is, you know. Yeah. Yeah. So it's, it's a bit of, um, document. The tags for components, right? That's an obvious, but there's other things that are in here too. Like I, when I'm looking at this handbook, it's, it's got a good bit of how to start being a contributor overall, but it doesn't address the, um, some of the areas like. I'm new to contributing and also new to meta, but maybe not new to DevOps. And so I could ramp up fast or I'm new to open source and contributing and I don't know any DevOps or dev, so it might take me a bit to figure out what to do, right? So I think the contributor, something that indicates some more contributor journeys rather than just a get started. In the handbook, um, if you are a, if you have X, if you have Y, no, yeah, I love that. But I also think that a lot of the times I've heard feedback from all the contributor days. And I know this has been trying to, this has been addressed different ways at different contributor days. Uh, but a lot of any of the meta stuff and core stuff is usually like, let's just get you set up. And then after that, it's like no man's land. Um, it's just like, oh, go to town now. So I think having, um, uh, from what I have seen and in the handbook as well, it's not super clear. I think people, you know, people don't like to just submit things. They don't know if it's appropriate. So we need to say somewhere. Okay. When. outline, like, once you're ready, what do you do, right? Once you've got your install set up, and once you're looking at the track, and it's like, how do you take that next step into action to, you know, do you have to talk to somebody to tackle something? Can you just jump right in? You know, I think that just needs to be spelled out better. Yeah, one of the things too that we could in this vein is, because a lot of the work being done, especially for the website, Is being done in GitHub and there's individual GitHub repos for the relevant relevant individual themes. It's actually easier for people to contribute in many ways because you don't have to deal with tracking like you find a spelling error or something. You can quickly create a PR that sort of thing. I think that it might be a good idea to create contributor. Info like, uh, contributor, uh, whatever, uh, contributor markdown files for the GitHub repos that kind of just an outline for each one. So if you're, cause we had that for like Gutenberg and stuff, just give you an overview of how to contribute to the repo itself, the GitHub repo. Um, that might be helpful. Uh, and we actually have a ticket open for that in marketing. So to that end, let's centralize things on learn. And if any of the how to do it with GitHub works in learn, then we can repurpose the same video in a, in a page on the site. And then say, um, just adjust for which repo you need to be in. Here's the ticket for that. And it was made by our very own Courtney. Oh, did I? You thought I forgot, but no, I remember every single one of these get up tickets. I'm going to chomp through them now that I'm not team rep anymore. Delightful. Delightful. Um, uh, document how the, the P2 works with the tags and the, um, dashboard. I, my stuff erased on me. I'm sorry. Uh, the dashboard tour, dashboard tour. That's that new current. Yeah. Current. Um, content and how to update should be public. Um, info for other teams. Info for other teams, right? Like a lot of teams assigned someone from docs to be the buddy with that team or something to that effect. Um, so just kind of some info along those lines and then I'm going to jump back. That did say, that's actually something that I was hoping more last year to introduce with marketing, but definitely this year, um, again, it's not team repping. I, you know, I will be able to bridge. Uh, for marketing and meta and then we'll probably have Bernard like doing the WordPress TV stuff, but and you're a good bridge for learn. So I think we should identify some places that some teams that don't have a good meta bridge and, you know, maybe just reach out and say, you know. Uh, here's what we're doing. Here's our thing. So let us know just so we have someone letting us know like what they're looking for, what they're asking for, um, because then they can at least get on our radar. I think that it happens that all the teams sort of get very insular, um, and don't think they can develop anything, you know, or do much. So they're like this. So I think it'd be great to have just a, um, sort of at least know which teams, like, who, who is the sort of the meta contact on each team. That's, that's what I was thinking. Yeah. I do want to call out, and I, we all know this, most of us know this, is that, um, I think meta is a little bit unique. Compared to a lot of the other teams in the sense that there are security issues related to deploying to the site and whatnot. So inherently there are certain contributors that have far more access than others. Um, you know, through their time in the project and so on and so forth. And so I think that as part of like updating contributor docs is just. Outlining that as a new contributor or something, you're, you're, I don't know, there are some expectations. Don't get your hopes up. Or direct them to things that they can do, you know, that can't be done. I think that's really important. That's, that's exactly what I meant about at the contributor days, like, what's the next step? Because if, if it's sort of like go to town, here's all this stuff, what ends up happening is people go into something and then they're like, oh, no, you can't do that. And then it's like. They don't come back because they, they're not empowered or they're told, Oh, I'm interested in this. It's like, Oh, actually you can't touch that. So having, I know we have good first issue as a tag. It's kind of, I don't know that it's really well used, but at least focusing on that for like, here, I think it makes more sense with the get hubs to be like, here's a get hub that is like pretty much open to different pull requests and whatnot, as opposed to this one, which is much more protected. So, um, I think. Having that. And maybe that comes down to in the get hubs, defining them, like this one is a protected GitHub, like right now it's sort of like, if someone asks, and then you kind of ask around, can this person, you know, and so I think there should be, you know, we're always looking for more standardization and I'm not saying that we should have other levels. I mean, obviously there's levels and roles anyway, but at least some sort of like, even if we just call it protected, you know, or, um, You know, intermediate or, you know, whatever it is, like, for your different levels. I think that then people aren't going to go work on something or be like, Oh, I could work on this and then have that, that wall thing happen. So I need to download the parts of Otto's brain that I want, is what we're after. How do you get the keys? How do we get the keys? Yeah, I was making a couple notes just in, uh, in case my screen share is wonky at all, um, in revising the handbook, um, we oftentimes will see people swing in close to a contributor day, um, or certain now that we have the kids camps, some of those types of things, um, where We'll get requests in. Hey, make sure this IP is not blocked or some details like that. So there's some other documentation to just have recorded somewhere. Because what happens is we get a lot of chatter in the meta channel. This is people swinging by to ask questions, which is great, but there could be some more self service and or, um, advanced information so that they're not. At contributor day and the people with the access are asleep or in the wrong time zone or Exactly, yeah, and like, go to this page and find your, you know, like an S eq. But yeah, I'll, well, some of this also then will overlap with like community does tell their their organizers things, but I'll look into more specifics. What is it that the organizers are receiving? How much notice are they told to give? Do that, are they doing that adequately or not? Like the usual. Stuff that we bump into. Um, and I think that we could have a whole section that goes over like security information. Um, some of the, like, I'm seeing a couple of, of themes happening there. Contributor journey would be like, get started, uh, up through, you're running a, you're the meta person now running a contributor day. What do you do? We could kind of clump some of that information together. Um, we could clump, we could have a section that's just about security. We can have a section that is about what are components according to meta and what does that mean? And then where do you find them? Um, and then there's this, what does the maintainer do? Yeah, and then there's this other section we haven't addressed yet today, which is at the top as well, and it says projects, so we have track components and handbook, um, so projects, I don't know how this page works. I don't know what I last looked at it. I don't know if this is what the board should be like. What's this? And we need to care about it. And where does it come from? We have a second project page as well. In the handbook there's a second project page. Oh no. I have the link in the chat. Oh my goodness, Bernard. Folks, can I say how thankful I am to contribute alongside all of you. Um, yeah. This is good. Where's the other project? I don't see the link in the chat. Oh, it's not. I'll say that this one. Sorry. Kelly, if you have an idea on the one that was there, I was just saying that that first one, the, um, the one that's the table with the idea and whatnot. Yeah, was last updated 3 years ago. Okay, just a page on the site. I can actually edit this page. I have, I have, you have edit access. Oh, I also have Tours access. Oh, good God, it's literally just a table. Yeah. Okay, so then maybe this can be swapped over to the GitHub projects that Steve made. Or, I mean, can we embed that? Or, you know, I'm a big fan of explainers and text, so if you go to this page and it's like, here's how the projects works, here are the projects listed, you know. Yeah. For this, like, I, I would like, is this, this isn't something that's replicated across other teams. This is just meta, right? Yeah, I'm wondering, I'm wondering if that's a page where we can, I don't know, I'm tempted to just want to delete it, honestly. Um, yeah, until something, until we don't even know what it's doing, though, is the problem here, like, what is it doing? It's spreading misinformation. Keep deleting something until you know what it's doing. Yeah. Um, it was written by We can take it out of the menu though. It was It was written by Take it out of the menu. That's a org solution. Take it out of the menu. It's also linked in the header. It's Wait, no, no These fine projects. This is this, but not that. Those aren't the same. They're not the same. No, because those are totally different. Oh, wait, this and this are the same. These, these two are the same. They're not. But this is not. Okay, got it. So then, um, yeah, that looks like something that we can do in there. Published in 2013. Um, so there was no automation available for it. Uh, but I can't see any data of like when it was. Revised or any of that fun stuff. Um, but I mean, the page ever, uh, especially if it's something that we need, uh, not something that we need, but like, like in theory, it would be nice to look at projects, right? It would be nice to have an overview of like what is happening currently. So it, if it, you know, components are track, then projects could be GitHub. Um, and it could, you know, sort of display, you know, the latest stuff that's happening with that. I, I mean, I think projects is such a generic term that, like, it would need to be better defined. But, I don't know. This is specifically projectsfor. org. Right? Like that's specifically what we're talking about here. Right. Not like any other projects, but ideally, this would be a page that exists for all the different teams, and does have an automatic, you know, maybe it shows just GitHub issues, maybe it's literally just a GitHub issue embed, if those are like projects or something, because that could be, um, that could be useful for surfacing the GitHub stuff. Mm hmm. And, you know, seeing sort of the latest updates, you know, I don't know what, I haven't looked at GitHub embeds and how, how those are, if those are any good, um, rather than try to make it something that's automated, like API based or whatever, just literally doing an embed or linking to it with some explanations. Nope. So, um, as I'm looking, um, I do have a little time if we go past the top of the hour, but I don't want to. We don't have to. Um, what I'm kind of seeing, we focused a bit on, these all are things that we need to address before we could do the other meta type of goals, at least those of us that are not full time to meta. Right, but we need to create some organization for the other people that will come along. Um, as I'm looking a little longer, Adam, you are one of our full time official META folks. I know you don't speak for all the rest, and I'm hoping to get this replay out for those that are the rest of our full time folks. Um, and at least we'll get, uh, like an outline of it. But I would love to know, um, how we can continue to foster. The back and forth between the community will say and the full time folks, um, really strengthening that so that we have contributors coming in that we are, uh, continuing to train more people in the work that this team does and that we do it in a transparent way that. Fosters more open source, great ethics. Um, I understand as a sponsored contributor myself, that my schedule, um, and perhaps sometimes my purview of what I need to go work on, even in org, might be subject to my employer. Often that is not the case, but I don't know if that is true for others. Like, I don't have my manager telling me go work on this issue right now in org. Um, But I want to give space for those that might have different ways of how they organize their day to day jobs, too, as we're looking at all of this and understand how can we, how can we help bridge that connection even more and make it a stronger connection between the community and the contributors that are sponsored, especially, um, that there is that, that real great level of transparency and an understanding of people are doing stuff without feeling like you're beholden to reporting. I know that was kind of a question for Adam, but I just kind of wanted to tag on to that, that I think Ideally, it would also be helpful for the more full time people to have, like, right now, the, the, the, you know, sort of non sponsored volunteer people, those sort of, like, smaller contributor people, in terms of amount of contributor time, uh, struggle to contribute, effectively, and it is a kind of a burden to the more full time people to, to contribute. Like it's like a burden to have that help in general. So I feel like there's got to be a way that we can have it. Like we want not just the contributors to contribute for the sake of contributing. We also want that to be useful for the people, like to take some of the burden off of the full time people who are having to. Do all of the steps of their stuff, but also with all this reporting. So, you know, how can we find a way, like, and I feel like the dashboards could be useful for that. Like here's an ever changing list of the things that someone could just pop in and do that would move your projects along, but then aren't requiring like a ton of security access and more like kind of grunty work or, you know, stuff like that, that at least could get people involved in the process. Go for it, Nick. I don't know. Adam, go for it. If you want to go for it, I have some ideas too. I'm not sure exactly what the question was, to be honest. I think the work is so varied. Yeah. Sometimes it's little issues that people can jump on and maybe like having that GitHub project board so they can see what projects are running and they can just pick up a low priority ticket. Surfacing that is helpful, but yeah, all the little quirky things that we have to deal with day to day. New contributors aren't really going to be able to pick that up. Yeah. That's why I think it'd be so good to distinguish between those in a way that it's, you know, you really have to know what you're talking about and be involved to do this one, but here's some stuff where you can just kind of turn through and make things move faster. And they might not even be good first bugs. Like I'm thinking about what Bernard, the Bernard's want to do with WPTV. Right. And, and so that might not be on the goal list for. Adam or for Nick or for Kelly or for anyone else, right? That might not be the goal list, but that might be the goal list that the Bernard's have with the time that they have available. And so how do we, um, I don't want to position things always as good first bugs because then it's like, we've got. baby contributors and we've got the opposite end and we don't have the in between where there could be considerable growth of, oh gosh, WPTV really needs a refresh and shouldn't it also be an app? Sorry Bernard, I don't mean to dump ideas, but I want it on my Apple TV, darn it. Yeah, so I've been thinking about this because I was been working with Meta on some of this redesign work and. It's been a little challenging because, you know, we have a channel in Slack, which is growing, which is great. Um, but when it comes to like the management of one of these redesigns, it's, it hasn't been, hasn't been as transparent as it could be. And we have a lot of different links. We have Figma, we have GitHub. And I think that there's a lot of opportunity in those two venues for folks who only have a certain amount of time in a week to contribute meaningfully to these projects. And so one of the things I was thinking about was, I mean we use this a lot internally at Automatic Project Threads, and I'm going to put one in the chat that the Learn team did for the Learning Pathways, which is basically it's just a post, um, but like it outlines kind of the goals of the project, all the, all the necessary links, you know, everything in one place. So like, whenever a project is Initiated, there's a dedicated project thread that people can follow. And then it gives people a place to point people. Um, it linked properly. It will link to the component pages. And then that kind of, I don't know. It kind of gives people like a central location to say, Hey, I'm interested in learn. It will learn redesign. It gives them one place to go. And then all the conversations happening there. So they know who's involved. The post has who's involved. I don't know. What do you all think about those ideas for some of these projects? I mean, I definitely, in general, that makes sense. I think the disconnect comes from the fact that this, at the end of the day, feels like a blog post. And so if the date is older, it's hard for ongoing project management because you don't know what is current and what isn't. You don't know what's being updated. Like, is it just, this is the, this was posted in July. Are there subsequent posts with new updates? Like what's the what's the most up to date place for this? I don't know that even just looking at this post right like I would be like, well, this is from July. This was the plan. Who's been, has someone been updating it? Has someone been changing the next steps or is that all in the comments? The comments become, um, you know, I think that in the concept of blog comments, no matter what, even if it's for feedback, people still feel that it's a comment versus a. Uh, something in a GitHub comment, which is essentially the same, but that feels more like it's doing work that is linear versus a comment, which is more like, you know, commentary or feedback that may be more sporadic. Someone's replying to a thread, and it goes up there. There's the, for tracking the, the, the, the, kind of the, the, what's it called, like the snapshot of where it's at now. This to me is not clear. It be, I feel like it's out there and it's, it's dated. Like it is a, not an evergreen shifting dashboard, which is kind of, I think what we're talking about in a way. So I think that's my issue with the posts. There's no way to understand that there's no revisions even. So we can't even see. Although that is a collaborator thing, so maybe that will help bring that into, like, this was last updated on. To follow on Say's ideas, tags are useful, and we've seen Quor go back, you know, they'll put out a post of, um, Gosh, our, our, the times when we have the beta releases and where we are in the release cycle, Core makes it really clear on the release post schedule when they're having all of their meetings and they update it consistently. They tag their stuff better than any other team, frankly. It could be, but, but so, so we all know how tags work. I think, um, we know how to edit. Posts and to say how something was last edited and we have experienced when our predecessors that have contributed before us didn't leave us good directions or whatever about coming back and doing the thing. So I hear your points say, I do think that if there was something that indicated that. This post has been revised, make it really clear, and then pin it, like a lot of the teams do, at that box at the top of the top comment, do the blue box thing on the top of the team sites for now. I think that that would probably also be a good way to go about that. Hear me out. What if we made a custom post type? Sorry, did I say that out loud? Let's not over engineer. I know this is wild, but it would make sense to have a little like last updated field that shows on everyone's thing. And like, uh, you know, I, this is what I do with this client. I'd be, you know, all up in my little custom fields. Uh, and I would have a custom, like, it would be nice to have, you know, it would, as opposed to posts, you know, in theory we could have proposals or. Wild, I know, but same process. And then that to me would sort of solve that problem of it's just a blog post that is from the past because it'd be clear that this is a project page that is, you know, constantly being updated and could even have like the component. Dashboards that we're talking about, here's the list of all the posts that have been related to this project, which that's what we're all kind of looking for here. Right? So this, I mean, that would be amazing, really, for every team, because then you would really, it wouldn't just be the components that have a dashboard, like, you know, for marketing, it'd be like, You know, WordPress TV redesign and it could have its own little, you know, sort of like it'd be almost exactly like this. It doesn't have to, you know, go outside the box wildly, but just instead of, you know, title and Bach, you know, content that is then there's no template. There's no, you know, that kills me constantly, but, uh, I'm sure we can make a block template for something like this too. If we didn't want to make a CPT, we could. make a block that is a project block. That's just for you guys. Just FYI. I can't do that for us. I don't have that access. Just putting it out there. Even, even if not the CPT, just a block so that the information was standardized. Because the blue pin, first of all, it's hideous. Yes. But like, other than the fact that it's hideous, you can only have one. And then like, you, you, then, or you've got a bunch of things stacked. Yeah. Still, that's not useful. Well, it is without, until Redesign hits the, the team sites. We don't want to engineer much in the current team sites until Redesign is deployed to team sites. Oh, well, where do I go say we need CPTs in the current team sites Redesign? Can I just tell you that, Nick? We've got to create the project first. Wait, chicken, egg. I don't know. Yeah. Yep. Yep. Yep. Okay. So how very meta of you. And then there's, then there's the meta component of being a. Of, of maintaining all the components. That's a meta, meta component. Maintainer? Yeah. Like the, the maintainer of components is, uh, now meta. Meta, I don't know. Um, okay. So I'm keeping an eye on time. We are definitely at a little over an hour here. Uh, I think a good next step is I will certainly get the, as soon as this is done and Zoom sends me the link, I could post that in the channel right away. Um, I'll work on getting that embedded into a post. So that people see what we discussed today, I'm going to cheat and use AI to help me make the outline of our conversation. Um, yes, say your computer is so fancy. Um, and then for anyone that might be listening to say is doing gestures like a thumbs up and it made a bubble on her screen that said thumbs up. Um, then after I'm done with some of this, Adam, I don't know if you have a regular sync with some of your other full time. co workers that are just meta people. Um, if such a thing exists, I'm still kind of noodling on like. We're looking at some pretty foundational stuff today, and how do we figure out what goals should look like in Q2 4. Some of that will be, of course, time dependent on like, how long does it take to do the handbook? How long does it take to get the people, like, revise the components, then start recruiting people to the components? That's something that, like, those are areas I'm certainly here to help shoulder some of that work. I would love to have more help, obviously, and appreciate all of those that are along for that. But if we could sort of think through this, like, how do we even scope what's Q2 through four, that's not that that's the goals, but are not just hobby interests that a contributor might just come along with, right? Like, how do we actually define as a whole team, what Qs two through four might look like and document that in a way that the community would appreciate. Yeah, absolutely. Um, just a quick note. I'm going to put together some ideas in the website redesign channel. Just start because, you know, we, we did showcase last year. developer resources, developer blog, the new events page. We did, a lot was done, but then if you look at like the rest of the site, it's massive, right? And so it's like, um, what is 20 foot 24 look like? And there's a lot of, it's all making a sitemap. There's also a lot of work to do on the sites that were launched. Like we have post launch follow up issues that Matt is working on and stuff like that. So, um, That's definitely this conversation that In that little vein of meta needs to happen in the next few weeks as well, so. Is the team, are the team metasites, the team sites on the P2s, are they on the docket for redesign? No timeline, but yeah. Because they have been in the background for a long time. So then the goal is to get a timeline. In prioritization. Yeah, right. And it's because it's like, it's also, if you look at the number of folks working in meta, it's actually, it's not that many. And it takes a while to build. So here's my request for that. And this is something that I could, uh, you know, again, not team rep, so I could do more active work on, uh, in marketing is maybe putting together a survey. for the teams to have one comprehensive place where the teams can put their ideas and needs for what they want for their sites that then we would be able to look at, you know, this isn't everybody in the community request. This is literally like teams, like active teams. What would you, you know, when you're posting your updates when you're posting your P2 posts, like, you know, we could get that get that information from them so that when the meta team is doing that, having that conversation, you wouldn't just be, you know, you wouldn't have to be like, here's our idea. And then now you give your feedback, like, you'd be able to incorporate that feedback from the survey initially, which would maybe move it along further so that you would have a much better project View of all the different features everyone's looking for in the initial step. I think that would cut down on some. Yeah. Especially for the make, especially for the make sites. Cause every team operates differently. I mean, there are some sites like the developer resources, which is relatively straightforward. And it was pretty new. Right. And, and the same thing with documentation. It's relatively straightforward, but like the make teams is, is challenging because every team is using it differently. They all have different links and different sidebars and different, you know, so that that's a great idea. Yeah, cool. That's something I will, I will do. Um, if we're cool with that, that's something I can put together via marketing and flag that like marketing can help with those, uh, survey questions and everything. We'll get something together and then I can bring it at our next meta meeting for us to look at and everyone, you know, then you all can put in your. your meta view. Uh, and then we could get that out to the community, not to the community, to the teams. Um, and you know, give them time to do it and remind them, but then, you know, sort of feeding, getting ready for that push, hopefully. And, and cause they really do, ideally they would be standardized, right? So that people could move from team to team without having to learn a whole different. Set up like right now. It is literally like everyone is using their stuff differently. And like you said polyglots, especially but And then performance doesn't really even use their polyglots team does something very unique with their p2 They have people do a lot of submission on the front of site on their team p2. Yeah Update Screen they have yeah, all the plug in maintainers go write a request. Hey, please approve me for whatever. And so polyglots is going to be your weirdest edge case one. Toby will be fantastic and having ideas for that one. I'm sure. Um, but then I think also, uh, Publicizing, when, when we know what the dependencies are, like, what are the dependencies we have to cross off before we can open up a date for team sites? Like, how do we, how do we assess which part of org is getting the work done now? And then, what is next? Not so much date dependent, but this idea of like, how do we prioritize which part of org? Why are we prioritizing that? And then what do we gotta do? To close out that and open up the next. I think that those are things that would, um, that would do well for the, for our contributors that are bopping all over the dot work and. net jobs. net jobs that WordPress. net by the way, was, uh, had a hiccup and auto set. It's a big spike of traffic. Technically I'm a maintainer on that and I don't even, I'm not even listed, so I'll fix that. Um, but anyway, that's part of the whole redesign too. tv. There's, so there's a lot of sites I know. Yeah. I mean, even with the, the redesign, like that's literally like you have been linking to so many different repos. Like I am like good lo and I have an, an issue open in marketing, which I hope to be able to get to, which is like, where are all of these things a little, you know, connector map. That's going to become really important with some of the things Matt announced at State of the Word, by the way, like opening up new repos that aren't really adjacent or directly tied to Meta, like the, the, uh, what are we calling it? Migration. Yeah. Data migration. Yeah. So, so having methods of, uh, drawing the journey for users through all of this is, yeah, this is why I think marketing can really help because we can help. outline it and scope it, and then Meta can come in and do the implementation as needed. Sounds good. I will get a retro on this posted before the end of the week. Um, and then I guess in two weeks we can resume a mixture, I think is what we need to do, a mixture of looking at the, the bigger pictures and then the, the daily stuff. Some of the like, day to days that are just falling through the cracks. I could let go of announcing that in meetings. It doesn't have to be. I like to tag people in just so they feel heard, um, and acknowledged and build some community through that. But some of that can just be done maybe like before the main gist of the meeting or something like that to it. Spare our meeting time. Let's see. I'll play with it. Thank you folks so much. It was great to see you. I have one question. Uh, Meta Team doesn't technically have team reps, uh, and has not done any sort of thing with that at all. And in terms of standardization, I know Courtney's obviously facilitating. I'm trying not to like take any leadership roles right now for a variety of reasons. Um, but, uh. That is still something that should we have a team technical perspective like we, we should have that happening so that at least there's someone who is a team repping so I know that's, that's kind of a complicated thing for for meta, but I do think. that's something that we should talk about. I don't know who is, who would, you know, it's hard to even really know fully on my end who is on the team. Uh, so I don't know where that conversation should happen, but I do think it would be nice to get in a line with everybody else. Fair point. And especially emphasizing that the team rep role for Meta particularly should facilitation and less about Well, like with all of that, it's really, they're all supposed to be about facilitation and not like the lead core person or whatever. That doesn't have to be the same thing as, as Courtney has so clearly demonstrated. So like, um, I just wanted to flag that for people because. I think it'd be nice if we followed the rules, especially if we want to show up in the, uh, new contributor matrix. If we want to have that meta team be like, uh, uh, a result, obviously all the work we're doing here is important for that. But I still think you need to have a team rep so you can be like, talk to this person if you have a problem. So even just that, you know, team rep connecting to new people or someone who's in charge when a Contributor day needs to happen like or not happen. I think that is really just a really basic kind of role We need to fill so if everyone wants to kind of think about i'm not going to do that But I just want to bring it up happy to run the election if we need one or we could just appoint somebody or whatever We'll bring it up for the start of next team meeting, too. Thank you On the radar. Thank you. Bye friends. Okay. Bye, Meta Team Goals 2024, Courtney Robertson, 01hkx8m7wf00pe24qrwn7nmv23.