CHAOSS OSPO WG, Feb 19 2026 - CourtneyR.dev's 2nd Brain

CHAOSS OSPO WG, Feb 19 2026 ![rw-book-cover](https://img.youtube.com/vi/isE_p-eDzhM/maxresdefault.jpg) 🔗 **Source:** [CHAOSS OSPO WG, Feb 19 2026](https://www.youtube.com/watch?v=isE_p-eDzhM) > [!note]+ Document Notes > tags: #ospo #chaos #repository-lifecycle #archival #sunsetting #open-source #cms #government #github-actions #automation > author: CHAOSS OSPO Working Group > source: YouTube > reference: https://www.youtube.com/watch?v=isE_p-eDzhM > date created: 2025-01-27 10:30 > > # 🏷️ Title: CHAOSS OSPO Working Group: Repository Archival and Sunsetting Practices >  ## 🧰 Action Inbox - [H1] Review CMS archival checklist for your organization — consider implementing repo-sunsetter tool #automation - [H2] Explore creating "path of growth" vs "path of archival" framework — identify stale repos quarterly #strategy - [H3] Set up repository metadata standards using code.json or similar — improve discoverability #inventory ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [CHAOSS Practitioner Guide on Sunsetting](https://chaoss.community/wp-content/uploads/2023/07/CHAOSS-Practitioner-Guide-Sunsetting-Open-Source-Projects-v1.0.pdf) - [Repo Sunsetter GitHub Action](https://github.com/CMSgov/repo-sunsetter) - [Stale Repo Identifier](https://github.com/github/stale-repo-identifier) ## 📝 Summary - CMS OSPO presented their repository archival practices and tools, including an automated GitHub Action called "repo-sunsetter" - They developed comprehensive checklists for preparing repositories for archival based on CHAOSS sunsetting guidance - The team created both "path of growth" and "path of archival" frameworks to help projects either revitalize or properly sunset - Discussion covered best practices from VMware, government-specific considerations, and repository inventory management - Key insight: Making archival reversible reduces resistance and no one has ever asked to un-archive ## 📖 Main Content The Centers for Medicare and Medicaid Services (CMS) Open Source Program Office has developed a systematic approach to repository lifecycle management, focusing specifically on the archival process. Their work builds upon the CHAOSS Practitioner Guide on Sunsetting and addresses the practical challenge of managing repositories that have reached end-of-life. CMS created two complementary frameworks: a "path of growth" for revitalizing dormant projects and a "path of archival" for properly sunsetting repositories. Their approach recognizes that not all inactive repositories should be archived - some may benefit from renewed development efforts. The team developed an automated GitHub Action called "repo-sunsetter" that streamlines the archival preparation process. This tool creates comprehensive checklists, updates repository metadata, and adds archival notices to documentation. The automation reduces manual effort while ensuring consistent practices across their organization. Key technical considerations include reviewing metadata files (code.json), conducting security assessments, managing access permissions, and handling community communications. The process also addresses issues, pull requests, wikis, and external communication channels. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/isE_p-eDzhM?t=0) — [H1] Meeting Introduction and Participant Introductions - Key idea: CHAOSS OSPO working group meeting with new participant Diego Mastraani from Cloudera - Evidence: "Diego Mastraani. I work as the OSPO head of OSPO for Cloudera" #### ⏱️ [03:25](https://youtu.be/isE_p-eDzhM?t=205) — [H1] Repository Lifecycle Focus at CMS OSPO - Key idea: CMS OSPO has been focusing on complete repository lifecycle including growth and archival paths - Evidence: "Our OSPO has been focused on the repository lifecycle... one path which we call the path of growth... the other side of it the path of archival" #### ⏱️ [05:47](https://youtu.be/isE_p-eDzhM?t=347) — [H2] CHAOSS Sunsetting Guide as Foundation - Key idea: CMS based their archival practices on the CHAOSS practitioner guide on sunsetting - Evidence: "We turned towards CHAOSS's practitioner guide on sunsetting which was written by Dawn" #### ⏱️ [08:12](https://youtu.be/isE_p-eDzhM?t=492) — [H1] Comprehensive Archival Checklist Development - Key idea: CMS developed detailed checklist covering metadata, documentation, access, security, and community communication - Evidence: "Review the metadata of the project... update the documentation... assess who has access... perform lightweight security review" #### ⏱️ [12:35](https://youtu.be/isE_p-eDzhM?t=755) — [H1] Repo Sunsetter GitHub Action Demo - Key idea: Automated GitHub Action creates issues with checklists and updates repository metadata and README - Evidence: "This is essentially a GitHub action that prepares a repository for archival by creating an issue that posts all these action items" #### ⏱️ [18:20](https://youtu.be/isE_p-eDzhM?t=1100) — [H2] Audience Discussion on Organizational Practices - Key idea: Most organizations don't have formal archival practices, making this work timely and valuable - Evidence: "It's actually very timely because we are talking about archiving one project right now" #### ⏱️ [20:45](https://youtu.be/isE_p-eDzhM?t=1245) — [H2] Metrics for Repository Diagnosis - Key idea: Key metrics include open/closed change requests, new issues, and technical forks to assess activity - Evidence: "Number of open and closed change requests... new issues... technical forks... indicates whether a project is still maintained" #### ⏱️ [23:15](https://youtu.be/isE_p-eDzhM?t=1395) — [H1] Action Results Demonstration - Key idea: The GitHub Action successfully created checklist issue and two pull requests for metadata and README updates - Evidence: "It should have created a new issue with the archival checklist... two pull requests up in this repository" #### ⏱️ [26:30](https://youtu.be/isE_p-eDzhM?t=1590) — [H2] Future Conference Presentation Plans - Key idea: CMS team accepted to present at George Washington University OSCON conference - Evidence: "Our talk at the GWU OSCON conference has been approved... March 23rd or 24th at George Washington University" #### ⏱️ [29:42](https://youtu.be/isE_p-eDzhM?t=1782) — [H2] Path of Growth vs Path of Archival Framework - Key idea: Two-pronged approach gives projects choice between revitalization or proper sunsetting - Evidence: "If you want to try and not go to the path of archival here's how you can get your project back on track" #### ⏱️ [35:18](https://youtu.be/isE_p-eDzhM?t=2118) — [H1] VMware Experience with Reversible Archival - Key idea: Making archival process reversible significantly reduced resistance, though no one ever requested reversal - Evidence: "She put together a process for this is what happens if you say that you want it archived and then you change your mind later... No one ever changed their mind" #### ⏱️ [38:45](https://youtu.be/isE_p-eDzhM?t=2325) — [H2] Drivers for Repository Archival Focus - Key idea: Reduced team sizes and security concerns drive urgency for proper repository stewardship - Evidence: "Teams are getting smaller... contracts are being renegotiated or canceled... cyber security concerns" #### ⏱️ [42:30](https://youtu.be/isE_p-eDzhM?t=2550) — [H1] Security and Trust Implications - Key idea: Abandoned repositories from trusted organizations create security risks due to brand trust - Evidence: "People tend to trust big companies like VMware... these abandoned repositories... got all kinds of security vulnerabilities" #### ⏱️ [47:20](https://youtu.be/isE_p-eDzhM?t=2840) — [H2] Repository Inventory Management Solutions - Key idea: Metadata standards like code.json enable better repository discovery and management - Evidence: "Code.json which is the metadata file that gathers up information about what a project is... supposed to go to an inventory on code.gov" ## 📚 References - [CHAOSS Practitioner Guide on Sunsetting](https://chaoss.community/wp-content/uploads/2023/07/CHAOSS-Practitioner-Guide-Sunsetting-Open-Source-Projects-v1.0.pdf) - [Repo Sunsetter GitHub Action](https://github.com/CMSgov/repo-sunsetter) - [Stale Repo Identifier by GitHub](https://github.com/github/stale-repo-identifier) - [CMS Maturity Model Framework](https://github.com/CMSgov/cms-open-source-policy) ## 🗣️ Paraphrase - CMS OSPO developed systematic repository lifecycle management with both growth and archival pathways, recognizing that inactive doesn't always mean ready for retirement - They created automated tooling that generates comprehensive checklists and handles routine archival preparation tasks while still allowing human oversight and customization - Making the archival process reversible dramatically reduced organizational resistance, even though no projects have ever requested restoration from archived status ## 📰 Newsletter **Repository Lifecycle Management: Beyond "Set It and Forget It"** The CMS team shared their thoughtful approach to repository stewardship that goes beyond just creating projects. Their "repo-sunsetter" GitHub Action automates archival preparation while their dual-path framework gives projects clear options for either revitalization or proper sunsetting. Key takeaway: Making archival reversible removes psychological barriers to proper repository hygiene. The automation handles routine tasks like updating metadata and documentation, while comprehensive checklists ensure nothing falls through the cracks. This work builds on CHAOSS community research and will contribute improvements back upstream - a great example of collaborative open source tooling development. Resources: [CHAOSS Guides](https://chaoss.community/), [GitHub Actions Marketplace](https://github.com/marketplace), [CMS Open Source](https://github.com/CMSgov) ## ✅ Action Items #### OSPO - Repository lifecycle: implement dual-path framework for growth vs archival decisions - Automation tools: evaluate repo-sunsetter for organizational archival processes - Inventory management: establish metadata standards using code.json or equivalent - Security stewardship: regular audits of inactive repositories for vulnerability exposure - Community guidelines: develop reversible archival policies to reduce resistance #### Community - Maintainers: contribute archival best practices back to CHAOSS sunsetting guide - Contributors: test and provide feedback on automated archival tooling - Ecosystem: share repository lifecycle frameworks across OSPO community ## 🧪 Hypotheses - Automated archival preparation reduces manual effort while maintaining quality and consistency - Offering both growth and archival pathways increases organizational buy-in for repository lifecycle management - Making archival processes reversible significantly reduces resistance without increasing actual reversal requests - Regular quarterly assessment of repository activity enables proactive lifecycle management ### 📊 Methodology - Comparative analysis: measure archival completion rates before and after automation implementation - Survey research: assess organizational resistance to archival policies with and without reversibility options - Longitudinal study: track actual reversal requests over time across different organizational contexts ### ❓ Questions - How can repository maturity models be integrated with automated archival assessment tools? - What role should community input play in organizational decisions about repository archival? - How do government-specific compliance requirements affect repository lifecycle management practices? ### 🔮 Future Research - Integration patterns between repository lifecycle tools and existing OSPO workflows - Cross-organizational standards for repository metadata and archival practices - Impact measurement frameworks for repository stewardship and security risk reduction ### 💡 Implications - Practice: OSPOs need systematic approaches to repository lifecycle management beyond initial creation - Policy: Reversible archival policies may be key to organizational adoption of proper repository hygiene - Security: Abandoned repositories from trusted organizations pose significant supply chain risks - Education: Repository stewardship training should cover complete lifecycle including proper sunsetting ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Screen sharing of GitHub Action workflow, repository interface demonstrations - Improve: Architecture diagrams showing repository lifecycle flows, visual checklists #### 🔊 Aural learners - Present: Full audio discussion with multiple speakers sharing experiences - Improve: Structured presentation segments, clearer speaker transitions #### 🗣️ Verbal learners - Present: Detailed explanations of processes, terminology definitions, analogies to familiar concepts - Improve: Glossary of OSPO and archival terms, more explicit comparisons between approaches #### 🧩 Kinesthetic learners - Present: Live demonstration of GitHub Action, step-by-step workflow walkthroughs - Improve: Hands-on workshop format, downloadable templates and checklists #### 🧠 Logical learners - Present: Clear decision trees for growth vs archival, structured checklists, metrics-based assessment - Improve: Flowcharts showing decision points, quantified success criteria #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion, shared experiences from multiple organizations - Improve: Breakout discussions, collaborative tool development sessions #### 🧘‍♀️ Solitary learners - Present: Detailed documentation links, individual tool exploration time - Improve: Self-assessment worksheets, independent study materials #### 🌿 Naturalistic learners - Present: Repository ecosystem analogies, organic growth vs planned sunsetting concepts - Improve: Lifecycle metaphors, sustainability framework connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Spoken descriptions of visual demonstrations, clear heading structure in shared documents - Improve: Alt text for screenshots, structured navigation of shared materials #### Keyboard navigation - Present: Tools demonstrated are keyboard accessible GitHub interfaces - Improve: Ensure all shared links and resources support keyboard navigation #### Contrast and readability - Present: Standard video conferencing interface with good text contrast - Improve: High-contrast presentation materials, larger font sizes for code examples #### Text resizing and reflow - Present: Responsive GitHub interface shown in demonstrations - Improve: Documentation that reflows properly at high zoom levels #### Media and captions - Present: Video meeting format with clear audio - Improve: Live captions, post-meeting transcripts, audio descriptions of visual elements #### Forms and interactions - Present: GitHub Action configuration shown with clear labels - Improve: Form validation examples, accessible error handling patterns ### 🌍 DEIB Assessment #### Cultural breadth - Present: Government (CMS), enterprise (VMware, Cloudera), international standards discussion - Improve: More diverse organizational contexts, global archival practice examples #### Inclusive language - Present: Professional technical language, defined jargon, respectful discussion - Improve: Plain language summaries, cultural context for government-specific terms #### Neurodiversity support - Present: Well-structured agenda, clear topic transitions, detailed documentation links - Improve: More frequent breaks, visual agenda tracking, reduced cognitive load #### Representation - Present: Mix of presenters and participants, various organizational roles - Improve: Broader geographic representation, more diverse speaker perspectives #### Psychological safety - Present: Respectful discussion climate, optional participation, acknowledgment of different approaches - Improve: Explicit community guidelines, multiple ways to contribute feedback ### ✅ Logical Validity #### Strong reasoning - Deductive strength: CMS team logically built specific practices from general CHAOSS principles - Inductive strength: VMware experience generalized to broader organizational patterns - Causal reasoning: Clear links between automation tools and reduced manual effort - Analogical strength: Repository lifecycle compared to --- ## Full Transcript [00:00] Okay. So, welcome everyone to the Chaos [00:04] OSPO working group meeting for Thursday, [00:07] February 19th. Um, as always, this [00:10] meeting falls under the chaos code of [00:12] conduct. So, uh, please be kind to each [00:15] other. Um, as you can see, we are [00:17] recording this one. So, we've that's the [00:19] first item on the agenda. So, we've [00:21] decided to record it. We can stop the [00:22] recording at any point if somebody wants [00:24] to have a more more frank discussion off [00:26] the off the record, so to speak. [00:29] Um before I turn it over to um Natalyia, [00:33] we have we have a couple of people that [00:35] I don't know that I've seen before in [00:37] this meeting. Um I don't know if you [00:40] want if you want to introduce yourself. [00:41] It is totally optional. You don't have [00:43] to. Um but we'd be happy to have you do [00:46] some introductions if you'd like. [00:49] >> Sure. I can can go first. I just joined. [00:52] So my name is Diego Mastraani. I uh work [00:54] as the uh OSPO head of Ospo for [00:57] Cloudera. Uh I was um we actually met [01:02] last year in Napa. Don I was the OSPO [01:06] for Moody's at the time so I changed in [01:09] between and um it's my first time [01:10] attending the meeting. So yes um [01:13] >> yeah very good. [01:14] >> Happy to be here. [01:15] >> Welcome welcome. Uh anybody else? [01:21] Okay. Uh so we'll we'll go ahead and get [01:24] started. I will stop sharing so that I [01:27] can uh turn it over to uh Natalia to get [01:31] started with our agenda item. [01:33] >> Yes, thank you. And I will be taking [01:35] over the screen share. Okay. Actually [01:39] before that um I'm Natalia Luzeryaga. [01:42] I'm a software engineer as part of the [01:45] open source program office at the [01:46] Centers for Medicare and Medicaid [01:48] Services. And today we'll be talking [01:50] about um our organization's practices [01:53] with archiving repositories. This has [01:55] been one of my main projects um starting [01:58] the beginning of this year. Um so lately [02:04] um our OSO has been kind of focused on [02:07] the repository life cycle where um first [02:11] our major focus was establishing our [02:13] baseline tools which started out with um [02:17] creating repository templates for our [02:20] organizations and uh thus forward [02:23] assisting those development teams with [02:26] maintaining those repositories. And then [02:29] um we've been [02:31] thinking of uh the rest of the life [02:33] cycle one path which we call the path of [02:36] growth. So as a open source project [02:40] matures further in their journey how [02:42] best can we assist them as an ospo and [02:45] the other side of it the path of [02:47] archival. So how do we assist [02:49] repositories that have reached the end [02:51] of life? So today I'll be focusing [02:54] specifically on the path of archival um [02:57] and how exactly we go about sunsetting [02:59] repositories in our organization. Okay. [03:02] And then I will share screen. [03:07] So um to kind of start off with um [03:12] brainstorming and trying to figure out [03:14] what are the best practices to go along [03:16] with this um we actually turned towards [03:19] Chaos's uh practitioner guide on suns [03:22] setting which was written by Dawn and [03:25] here this is a very um comprehensive and [03:29] wonderful guide about how exactly you go [03:31] about um archiving repositories. So [03:35] first she talks about identifying trends [03:37] using um metrics that um using chaos [03:41] metrics and then from there based on um [03:45] those trends and metrics that's when you [03:47] can diagnose a repository as ready to be [03:50] archived or or identify its candidacy [03:53] for archived. And there's also some [03:56] other recommended metrics and data that [03:58] you can use along with your [03:59] consideration. And then finally is [04:02] actually making um the actual change of [04:05] archiving the repository. And so here um [04:10] we have some action items that are [04:12] listed out such as updating the readme, [04:15] updating communication channels and [04:17] documentation accordingly and notifying [04:19] users. And then um you can also do an [04:23] additional step of adding your code to [04:25] software heritage to ensure that it is [04:28] preserved over time. [04:31] and some cautions and considerations. So [04:33] after reading this guide, we decided to [04:37] um focus on this step over here. What [04:40] exactly does our organization need to do [04:43] in order to um what we should do when we [04:46] archive a repository? And so based on [04:49] this guide, we came up with our own [04:51] checklist [04:53] based on this of how we want to prepare [04:56] a repository for archive. So for [04:58] instance, first we want to review the [05:00] metadata of the project. We have a file [05:03] called code.json which includes all [05:06] metadata about a repository. So we want [05:09] to be able to mark the status of the [05:11] repository as archival in that metadata [05:14] so it reflects its new um status. And [05:18] then from there we go through a um [05:21] thorough repository review where we [05:23] update the documentation such as the [05:25] readme. We look through the repositories [05:28] issues, close what has been fixed, [05:31] comment on what has been unresolved, [05:33] label the issues accordingly, and for [05:36] those that won't be fixed, label that [05:38] too. [05:39] Then we assess um who has access to the [05:42] repository. Then we perform a [05:45] lightweight security review, review for [05:47] secrets, keys, PII, and then we do some [05:50] minor housekeeping like deleting some [05:52] branches. And then for repositories that [05:56] are a bit more mature in their journey [05:59] um such as they accept contributions [06:02] from the external community that's when [06:05] we review the pull requests make sure [06:07] that um we merge those that are ready to [06:10] be merged merge any dependabot PR so [06:13] that our dependencies can be up to date [06:16] um comment on open PRs and close won't [06:19] fix PRs [06:21] and for those repositories that um have [06:25] a wiki or slack channel or just more [06:29] means of communications outside a [06:31] regular GitHub repository. We also note [06:34] to review that and to notify um parties [06:38] in uh in those spaces. [06:41] And then finally, we have a little more [06:43] thorough um security review where we [06:47] review the code quality, the commit [06:48] history, um run some code scanning and [06:52] security alert tools. We check out the [06:55] change log and then re-review the [06:57] release and tags. So just doing a [06:59] thorough review of the repository to [07:01] make sure that all of our bases are [07:03] covered before we mark the repository as [07:05] read me as uh archived. Okay, cool. And [07:09] then so based on um all this information [07:12] I just shared with you um our team we [07:15] created a tool to kind of automate some [07:17] of that work called repo sunsetter. And [07:20] this is essentially a GitHub action that [07:23] um prepares a repository for archival by [07:26] um creating an issue that posts all [07:30] these action items from this checklist I [07:33] shared. and it automates some of that [07:35] work such as adding a adding some text [07:38] to the readme to inform users about the [07:42] repository being archived and updating [07:44] the project metadata accordingly. Okay, [07:48] cool. And then I'm going to do a little [07:49] demo. So I'm going to I have this test [07:54] repository over here and then I'm going [07:56] to um run this GitHub action on this [08:01] repository by first creating a new [08:05] workflow file. [08:12] Cool. Okay, this is the workflow file [08:15] over here. You want to make sure that [08:17] the GitHub action has permissions to [08:20] write pull requests and to write issues [08:23] and to also write uh contents within the [08:26] files of the repository. And then here [08:29] we just have uh this one step over here [08:32] where we actually run the repo sunsetter [08:35] tool. Okay, I'm going to switch this [08:37] over to [08:40] another branch [08:42] that I have that's that has a little bit [08:45] more features than what's currently on [08:46] main right now. I'm just going to do [08:48] this over here. Okay, cool. [08:53] Okay. And then I'm going to name the [08:54] file archive [08:56] repo.ml. [09:03] Okay, cool. So now that we have the [09:04] workflow file, we can easily run this [09:07] action [09:10] in the UI. [09:12] This is it over here. And then we run [09:15] the workflow. [09:19] Cool. [09:21] Okay. And then we're going to wait a [09:22] minute or two um to let this finish. [09:26] Okay. Cool. In the meantime, I wanted to [09:29] ask the audience um does your [09:32] organization have uh their own archival [09:36] practices? Um just curious to see like [09:39] how exactly you guys go about it. [09:44] >> No, no. Okay, cool. [09:47] >> Yeah, it's it's actually very timely [09:50] because we are talking about archiving [09:52] one project right now. So I was I was [09:57] kind of doing this checklist. I mean I [09:59] never been it's serendipity. So thank [10:01] you so much. [10:02] >> Okay cool. That's really good to hear. [10:04] Yes. I hope this uh we decided to make [10:07] this a GitHub action because we know [10:08] this is a shared challenge that ospos go [10:11] through. So we hope that you can also [10:12] make use of it too. Yes. [10:16] >> Okay. [10:16] >> Very thoughtful. Thanks for sharing all [10:18] this. [10:19] >> Yes. Of course. Of course. [10:22] Okay. Um let's see. while she's building [10:26] let's see I think I can talk a little [10:28] bit more about diagnosing repositories [10:32] um let's see feel free to step in Don [10:35] too but um another my team and I were [10:40] also creating another tool to to assist [10:43] with diagnosing repositories as um being [10:46] candidates for archival um and some of [10:49] the interesting metrics that uh we've [10:51] been looking at mostly in this guide is [10:54] the number of open and closed change [10:57] requests that a repository has since [10:59] that indicates whether a project is [11:02] still maintained or if um [11:06] other people have been making pull [11:07] requests to it. It just indicates [11:09] activity. [11:10] We also have new issues. So that [11:13] indicates whether the external community [11:16] is uh still looking at the repository [11:18] since users can um post bugs um ask [11:22] questions or request for new features [11:24] through through new issues. [11:27] Um [11:29] and then technical forks. This is a big [11:31] one. So people that fork your project, [11:33] um we want to kind of assess usage [11:37] within that fork to actually see if [11:39] people are uh [11:42] to see if people are building a uh on [11:44] top of the upstream stuff that you did. [11:49] Yeah. So um we've been looking at these [11:51] metrics and kind of just been [11:53] experimenting with um using these [11:55] metrics to identify repost for archival [11:57] and I hope to share that work in a next [12:01] uh chaos ospo working group. Okay cool [12:06] and then we're going to look to the [12:07] actions over here. Okay cool. It looks [12:11] like our GitHub action repossitter has [12:13] run successfully. And so as a result it [12:16] should have done three things. Let's [12:19] see. [12:21] It should have created a new issue with [12:25] the archival checklist that I went over. [12:27] So, the idea is we post this as an issue [12:30] so that the repository um the [12:33] development team can um go through this [12:36] checklist now that they know how exactly [12:39] they should prepare their repository for [12:40] archival. Yeah. Cool. And then notice [12:44] that we have two items that have already [12:47] been checked over here. And that's [12:48] because we actually automated that work. [12:51] So we should have two pull requests up [12:54] in this repository. Okay, cool. One is [12:58] updating the project metadata. And for [13:00] our organization, our repository [13:02] metadata lives in a code.json file. So [13:05] we indicate its archival status. And I [13:08] think we add it as a tag. Yep. [13:12] And then the last thing is we add a [13:14] archive notice to the readme. So this is [13:17] how that PR looks like and this is the [13:20] text that we provided. [13:24] Cool. And this is how it looks like. We [13:26] use the warning banner as part of uh [13:28] GitHub's uh markdown rendering. Yeah. [13:33] Okay. Cool. And that's pretty much it [13:35] for our repo sunsetter tool. Yeah. I [13:39] think that's all I have to demo for [13:41] today. Yes. Uh but any um Yeah. any [13:45] thoughts, any questions, and I'll share [13:47] some links in chat. [13:50] >> And just to add to this, I think the [13:51] team is actually planning on [13:53] contributing some of this back to the [13:56] sunsetting guide. Um, which I'm super [13:58] excited about because if you're So, [14:00] Diego, if you're looking at this right [14:02] now, I would have a look at their [14:04] checklist because uh the the [14:07] practitioner guide is missing a few [14:09] things that um we just didn't think of. [14:12] So, I'm really looking forward to [14:14] getting some some contributions to the [14:16] sunsetting guide uh from the the CMS [14:18] team. I think that's really exciting. [14:25] >> Cool. And then um we have Remy DSMaker [14:27] who's on the call. Um he's the open [14:29] source lead uh at our OSO. Yes. [14:34] >> Yeah. And we just got word yesterday [14:36] that uh our talk at the GWU OSCON [14:39] conference uh has been approved. So, we [14:41] were accepted to present and our agency [14:43] has approved that. So, we're going to be [14:45] presenting about Repo Sunsetter and the [14:48] Chaos Practitioner Guide uh on March [14:51] 23rd or 24th at George Washington [14:54] University here in DC. And I believe [14:56] they're going to record it. So, um [14:58] should be uh a good moment. Uh you folks [15:02] are the first to hear about it though. [15:03] Uh the working group here uh as you [15:06] fellow practitioners uh Nat shipped this [15:09] yesterday I think. Uh, so this is fresh, [15:12] brand new, off the press. Uh, we wanted [15:14] to make sure to engage with the OSO [15:17] community. We definitely appreciate the [15:18] feedback here. We couldn't have put this [15:20] together without the chaos practitioner [15:22] guide. We leaned on it heavily. So, we [15:24] really look forward to contributing back [15:25] up. And that's going to be one of the [15:27] key elements of the presentation is, you [15:30] know, making sure that these upstream [15:31] contributions are made back and that we [15:33] can share those out with the GW OSCOM. [15:37] >> That's great. Great. Congrats on getting [15:39] that talk accepted. That's awesome. [15:43] Um, other other questions for Natalyia [15:45] or thoughts that people have on [15:48] sunsetting and archiving repositories. [15:58] Natalya, I'm not all that familiar with [16:00] GitHub actions, so I'm just trying I'm [16:03] looking at it on your repo. I'm just [16:05] trying to figure out how would I I saw [16:09] how you would use it. How would I [16:13] graph that into a flow that I might try [16:16] to do? [16:17] >> Yeah, for sure. Um, let's see. So to [16:20] actually use the action, okay, I'm going [16:22] to steal the screen share again, [16:26] you can simply copy and paste this text [16:29] over here [16:31] >> and add it to a okay. So first you [16:35] identify the repository that you'd like [16:37] to prepare for archival and um from [16:41] there we will run the GitHub action on. [16:43] And so to run GitHub actions, you have [16:46] to go to the workflows directory in the [16:50] git within the GitHub directory. And [16:53] here is where your GitHub action files [16:55] live. [16:57] And then from there you can create a [16:59] file with those contents within that [17:02] folder and then name it accordingly. [17:05] Archive repo 2.l. [17:08] Oh, and GitHub action files are written [17:11] as YAML files. Yeah. Okay. Cool. And [17:15] then um you have this actions tab over [17:18] here where you can run the GitHub [17:21] actions that live in this file over [17:23] here. [17:26] And then so here are the actions that [17:28] you can run on the side. And so I'm [17:31] going to click on archive repository. [17:33] Cool. And then from there there's a [17:34] button that says run workflow. And then [17:36] you can run the workflow. [17:39] >> Yeah. [17:40] >> Nice. Thank you. [17:42] >> Yeah. It's super easy. [17:44] >> I saw another one that you had in that [17:46] list stale repo identifier. [17:49] >> Oh, that one's a cool one actually. Um, [17:52] so that um GitHub action was created by [17:55] the GitHub Ospo and it basically [17:58] identifies repositories that have been [18:00] inactive within 6 months. So um you give [18:04] it your GitHub organization name and [18:08] then uh you run it as a GitHub action [18:11] and then it identifies all the [18:13] repositories in your organization that [18:15] have been inactive for that period of [18:16] time. Yeah. So we were kind of doing [18:18] some experimenting with what's currently [18:20] in the landscape and we thought that was [18:23] a super helpful one that will assist us [18:25] with diagnosing repositories to be [18:27] archived. So, [18:29] >> so prioritize which ones to put at the [18:32] top of the list. [18:34] >> Oh, for sure. Yes. Okay, cool. And then [18:37] it's this one over here. Okay, I'm [18:39] dropping it in chat. Cool. [18:42] >> Thank you. That's really helpful. [18:45] >> And David, you have a question. [18:47] >> Yeah. When when you saw the banner, like [18:50] when the action create a banners on the [18:52] top, is that what does it say? the [18:54] banner says this has been archived or [18:56] there's a kind of a way of I don't know [18:59] adding some kind of reasoning of why [19:00] this archive or showing like [19:03] alternatives of what to use if like is [19:06] there [19:08] is does the action provides [19:11] more things to do or does one of the [19:13] checklist to say oh by the way add more [19:15] information of what you expect the users [19:18] to use now [19:19] >> I see okay I'm going to share screen. [19:25] Okay, cool. So, um the GitHub action, it [19:29] does these three things, but um actually [19:32] I have a PR up where we kind of want to [19:35] generalize the action so that it's more [19:37] configurable. So, speaking to um let me [19:41] bring up the archive text. [19:47] Okay. So, speaking to your point about [19:49] um this archad text over here. So, um [19:54] let's see. Yeah. So, I added a feature [19:58] where you can add your own custom [20:01] archive text text um which will be [20:04] appended right over here. Um, so this is [20:09] personally the um archival text that our [20:12] organization decided to use, but there's [20:14] also some best practices where you point [20:16] other people to other repositories that [20:18] users can um use that instead of the one [20:22] that is about to be archived. Um, but [20:25] here you can essentially just provide [20:27] guidance on um to users on how you want [20:30] to uh approach things. Go ahead, Remy. [20:35] And one of the patterns that we've used [20:37] in the past too, David, is that PRs are [20:40] editable. So even if we have an [20:42] automated tool that will generate the [20:44] PR, the OSBO can go back in and then add [20:47] custom text to it on a case- by case [20:50] basis. Um along with that same like [20:54] questions of like where you want to go, [20:56] I don't know if Nat covered this, but um [20:59] there's sort of two parts to repo [21:01] sunset, right? This is the part that [21:03] says we know we want to archive this [21:05] repository. This is called what we refer [21:07] to as the path of archive. We also have [21:10] this concept of the path of growth which [21:13] during the archival process like maybe [21:16] we can say like hey it looks like your [21:18] project is a little bit stale and coming [21:20] up with like if you'd like it to not be [21:23] stale here's a checklist of things you [21:25] can do like adding pull requests [21:27] templates or adding better contributor [21:29] documentation or adding new issues that [21:31] are labeled in a certain way to draw [21:33] people towards your project or you know [21:36] coming up with uh a little bit of like a [21:40] you know a fork in the road to say like [21:42] if you want to try and not go to the [21:44] path of archival here's how you can get [21:46] your project back on track and then we [21:49] want to use that also as a as a leading [21:51] indicator as well. So like maybe the the [21:54] sun seting process starts by running the [21:57] identification script identification [21:58] script says here are the stale repos. So [22:00] we file our first issue on our [22:02] repository that says, "Hey, looks like [22:04] you're stale. If you want to go down the [22:06] path of growth, here's some things we [22:07] suggest you do." And then if that issue [22:09] sits idle for a quarter and we run it [22:14] again, we can say, "Okay, we told them [22:16] about the path of growth. They didn't go [22:18] down the path of growth. Let's now [22:21] change courses and and suggest that they [22:23] go down the path of archive." And then [22:25] if that one sits unattended, the OSPO [22:29] can come in and we can burn down through [22:30] the tickets and we want to keep track of [22:34] all the tickets that we have filed so [22:36] that we can show progress and [22:38] demonstrate value to the organization [22:40] and say like we've identified this many [22:42] inactive repos, we've converted this [22:44] many to active repos, or we've archived [22:46] this many. And that's part of our source [22:48] code stewardship task force strategy to [22:51] go through with our inventory work and [22:54] make more sense of what's going on uh [22:56] across our footprint in the ecosystem. [22:59] Uh we are still early on in this [23:00] journey. You know, we just shipped this [23:02] tool, so we're not running it regularly. [23:04] I saw a question in the chat from Travis [23:06] says, "How often uh do you run this?" Uh [23:09] ideally, I think we're going to be [23:10] running it probably on a quarterly [23:12] basis. uh maybe a monthly basis if we [23:15] wanted to, but quarterly is probably the [23:17] right cadence. Um so this is something [23:20] that's kind of new. Uh I think we'll [23:22] like as soon as we're happy with it, [23:24] we'll start rolling it out across our [23:26] own GitHub organization and then testing [23:28] it in other GitHub organizations. [23:30] There's probably about [23:32] at least half a dozen GitHub orgs that [23:34] are part of our footprint, plus a bunch [23:37] of others that we don't know about yet, [23:38] too. So, I think it's it's going to be a [23:41] little bit of a patchwork uh process [23:44] because each org will have different uh [23:48] cycles that we go through. So, a lot of [23:50] this, you know, we're still early on in [23:51] the in the inventory process, but we're [23:54] we're feeling better as we're starting [23:55] to put some concrete code that actually [23:57] runs and actions that we can enable. [24:03] >> Yeah. And one of one of the things we [24:05] did at at VMware, so we did we did that [24:08] audit about quarterly. So we had a [24:10] Python script that looked for inactive [24:11] repos. Um, and we ran it on a whole [24:13] bunch of GitHub orgs because I think [24:15] VMware had over a hundred GitHub orgs [24:17] that had come in through acquisitions [24:19] and various various things. It was it [24:21] was a lot. Um, and so we ran it on a [24:24] whole bunch of a bunch of different [24:25] orgs. But the other thing um the other [24:27] thing we did and this wasn't my idea. [24:30] This was Stefka who worked on my team. [24:31] this she ran the whole sunsetting [24:33] process. Um she put together a really [24:36] detailed process for unariving. So um [24:40] she put together a process for this is [24:41] what happens if you say that you want it [24:43] archived and then you change your mind [24:45] later. This is what we'll do. And it's [24:47] it's fairly easy. We'll just bring it [24:49] back. It's not a big deal. And that [24:51] really that was a real turning point in [24:54] convincing people to archive their [24:56] repositories because I think a lot of [24:58] people when you say they're going to [24:59] archive it, they're like, "Oh, it's [25:00] forever. I can never get it back. You [25:02] know what? What if I change my mind? Um, [25:04] here's the funny thing. No one ever [25:06] changed their mind, but um but knowing [25:08] that they could made all the difference. [25:15] >> Don, it seems like you were ahead of the [25:17] curve at VMware just even addressing [25:20] this issue. [25:22] And compliments Remy and Natalyia to [25:26] your team because this is really [25:28] thoughtful and well thought well well [25:30] worked out. But I'm curious if there's [25:34] maybe urgency is the wrong word, but [25:37] some push to get on with focusing on [25:41] this either because of the EUR and not [25:44] wanting to have [25:46] stewardship assigned to these things or [25:50] just because people file pull requests [25:52] and you just don't want to deal with it. [25:57] >> Yeah. [25:57] >> Or something. [25:58] >> Uh, no, great question. I think that um [26:01] there's definitely value like so we we [26:04] think about the layers of stakeholders [26:06] in our hospital right so the immediate [26:09] stakeholders of the people within our [26:10] community they just developers need more [26:13] support uh you might have noticed you [26:15] know across tech and in the public [26:18] sector there have been a lot of [26:20] reductions in force over the last year u [26:23] maybe four years so teams are getting [26:25] smaller uh contracts are being uh [26:28] renegotiated or canceled. So, a lot of [26:31] that brings a a more urgency to this [26:34] type of an issue. And so, uh that is an [26:38] immediate concern. Um with the the CRA, [26:41] which I just I went to FOSD them in a [26:43] personal capacity over the past uh month [26:46] and got to hear a lot more about the [26:48] CRA. Um in the world of the United [26:51] States federal government, I think that [26:52] that's less of a concern um because, you [26:55] know, we're in the United States. Not to [26:59] say that we're not a member of the [27:00] global open source community, but um I [27:02] don't I think that um we're the first [27:04] federal OSO, right? So I don't think [27:06] that that's as much on the radar of um [27:10] there's no specific open source program [27:12] offices thinking about that at other [27:14] agencies. Uh that being said, I know [27:16] there's cyber security concerns being [27:19] upheld. That is the place where the [27:20] federal government is actually really on [27:22] top of the ball. So maybe there are [27:24] other source code uh analysis uh and [27:28] like cyber security functions for supply [27:30] chain security that are that's more on [27:33] their radar. Um, but I think that, you [27:37] know, generally as like a steward of the [27:39] code, like we just want to reduce our [27:44] footprint and we want to be more [27:46] intentional about saying like these are [27:48] the active projects and these are the [27:50] inactive projects so that we can, you [27:53] know, direct the limited resources that [27:56] we do have towards the projects that are [27:58] in the best place to receive them and [28:01] also to provide like another layer of [28:03] nuance. Um it's been really helpful back [28:06] at um Nadia's book working in public uh [28:09] where she talks about the the project uh [28:12] classifications of like toy federation [28:15] club stadium where you talk about like [28:17] your composition of upstream uh [28:20] developers and your users and using that [28:22] to describe more uh more clearly or more [28:27] like [28:29] you know more specifically like what [28:31] your open source project is. It's not [28:33] it's not just an open source project. [28:34] It's a open source project of a certain [28:37] size with a certain user base and a [28:38] certain downstream and an upstream. So [28:40] taking that same kind of classification [28:42] and bringing it into the archival space [28:44] where we can say like it's not just a if [28:47] it's a inactive project, it's a stable [28:51] project or it has an inactive downstream [28:53] or a dormant upstream or a dormant [28:56] downstream. you can say, you know, this [28:58] project is being used by lots of places [29:00] inside the federal government, but the [29:02] upstream community is dormant now. Like [29:05] that is a different thing versus we have [29:07] an active upstream community, but [29:09] there's not a lot of down, you know, not [29:10] a lot of downstream users of it. And I [29:12] think that helps us to figure out like [29:14] in a more clear way how to prioritize [29:16] those kinds of projects. Then we are [29:18] helping to advise some other projects [29:20] inside and outside the agency that have [29:23] been impacted by reductions in force and [29:26] open source is a succession strategy. Uh [29:28] it really is important when you look at [29:31] um inner source style models that are [29:33] totally driven by internal teams and [29:35] salaried people when those communities [29:38] lose their core contributors. Uh how do [29:41] you then provide succession? And an [29:44] open- source strategy is one of the ways [29:46] to help with that. It doesn't come [29:48] without resource load or a lot of [29:50] upfront work potentially, but uh it is a [29:53] strategy to help to to secure succession [29:56] when there's a big change in the [29:57] composition of the contributor community [29:59] in a project. [30:02] >> Yeah. And to just to add to that a [30:04] little bit, you know, one of the reasons [30:06] that we started doing this so early at [30:07] VMware was um was frankly the pivotal [30:11] acquisition. So I came into VMware [30:12] through the Pivotal acquisition and [30:14] Pivotal didn't have an OSPO but we did [30:17] have an open- source everything by [30:19] default strategy um which meant that [30:22] this is partly how ended how GitHub or [30:24] how VMware ended up with over 100 GitHub [30:27] orgs. Um and so we just had we had so [30:30] much open source and nobody looking [30:32] after it. And so so much of it was was [30:34] in need of being being sunset and being [30:37] archived because VMware's big concern [30:39] was, you know, hey, we we've acquired [30:41] this this smaller company and people [30:44] tend to trust big companies like VMware. [30:47] They're like, oh well, you know, it's a [30:48] VMware open source project, so it's [30:51] probably, you know, secure. Um, and and [30:54] these these abandoned repositories [30:56] aren't right. They've got all kinds of [30:58] security vulnerabilities that have not [31:00] been looked after. And so our concern [31:01] was leaving these sit around is uh you [31:04] know potentially creating security [31:07] problems for the people who trust the [31:10] the brand of the organization. So that [31:13] was that was kind of why we started [31:15] doing it. So we we started this it might [31:17] have started a little bit before um [31:19] Pivotal was acquired. I can't remember [31:21] exactly but so this was around 2000 or [31:24] so that we we really started uh sorry [31:27] not 2000 uh 2020. It was right before [31:29] the um you know people started being [31:32] locked down. So it was about 2020 that [31:34] we really started doing a lot of this [31:35] stuff. [31:36] >> You'd be really ahead of the curve if [31:38] you were doing this in 2000. [31:39] >> Yeah, exactly. This is that was back in [31:42] the days where all of the Yeah. All the [31:44] stuff was [31:46] hosted hosted um in other places there, [31:50] you know, Git didn't even exist. [31:52] >> Yeah. [31:57] Any other comments, questions, thoughts [32:01] on this topic? [32:05] We also don't have any other agenda [32:07] items, so we're free to keep talking [32:09] about this if it's if it's interesting [32:11] to people. Um, if you have something [32:12] else you want to talk about, we have a [32:14] few more minutes, so we could always [32:15] talk about something else. Um, that [32:18] >> I have a sideline and but if other [32:22] people want to talk about this, I I'll [32:23] hold on it because it's changing the [32:25] subject a little bit. [32:30] I just have a question on uh when we [32:32] were talking about tagging and giving [32:34] the opportunity to grow. So this is kind [32:35] of for the contributors reminding them [32:39] you have opened this repo here. You were [32:41] maintaining it and now it's kind of [32:43] inactive. [32:44] Do you want to bring it back? So or or [32:47] this to let's say the for the internal [32:51] contributors or or open source in [32:53] general like if somebody else picks it [32:56] up you would remain keep it open [33:00] what because [33:03] yeah if if you I saw you nodding [33:06] >> you want to take a stab at that and I'll [33:08] follow up [33:12] >> you can do like me. [33:16] >> Yeah. So, um, one of the key pieces of [33:20] guidance that our ospo is like there are [33:23] many layers to the the repository life [33:26] cycle and the key one is our maturity [33:28] models. So, one of the things we're [33:31] coming up with right now is, you know, [33:34] getting people from we don't know what [33:36] our maturity model is to, okay, we think [33:39] you're a one-time release or we think [33:41] you're an inner source project or we [33:43] think you're working a public project. [33:45] >> And then knowing what maturity model [33:48] you're in, then we can say, okay, what [33:50] are the actions that can take you from [33:53] base tier two to like advanced tier two? [33:58] from advanced tier two to base tier [34:00] three. So mapping the different pieces [34:03] of guidance and now if you want to grab [34:06] a link to the maturity model the table [34:10] with all the like the documentation [34:11] guidance. So it's a little bit rigid but [34:16] structure is good. Uh we found that our [34:18] users really like to have more [34:20] structure. So we can tell them things [34:21] like hey you're a tier 2 project. Tier 2 [34:25] project is an inner source style [34:26] project. we notice that you don't have [34:28] your agency mission. You don't have a [34:30] code owners file. You don't have like [34:32] pull request templates. You don't have [34:34] issue templates. If you wanted to go [34:37] through the checklist and add those [34:39] kinds of things, then it would make it [34:41] easier for people to make contributions. [34:44] And we also have this sense of um we [34:49] gave a talk recently internally about [34:51] like is your project really open source [34:53] if you don't accept poll requests from [34:54] the outside world? And that's a really [34:57] interesting question. Uh in the OSBO, [35:00] our guidance is sort of like open source [35:02] is a journey, right? So it starts with [35:05] making your repository public, right? So [35:08] if you have a public repo and you're [35:09] working in the open, then yes, you are [35:11] open source. Then you should start to [35:14] accept issues and take feedback from the [35:16] community. And then once you start [35:17] accepting feedback from the community, [35:19] then you can start accept contributions [35:20] from the community. And then once you [35:22] start accepting contributions from the [35:23] community, you can start to accept [35:25] maintainers from the community. And then [35:27] once you start accepting maintainers, [35:28] eventually you can accept people into [35:30] your governance process. So we see that [35:32] as sort of a a longitudinal journey at [35:35] each layer of maturity. And we think we [35:37] can help people depending on what their [35:39] goal is to get to each of those hubs [35:42] along the contributor's path. And we [35:45] have made it more clear with the [35:48] maturity model framework like what parts [35:50] of what docs need to be where. Um it has [35:53] been relatively straightforward to do [35:56] the the tier zero through tier 2 because [35:59] it's like that is a lot less [36:02] specialized. It's like hey you should [36:05] have issue templates, you should have [36:06] pull request templates. You should have [36:07] a contributor process. Like it's easy to [36:10] say like and here are some that we [36:12] recommend. But when you get into the [36:14] higher tiers of like shared community [36:16] governance or working in public, that's [36:18] where the like one-sizefits-all uh [36:21] guidance doesn't necessarily work as [36:24] well. And you need the communities to [36:27] opt in with their own things. So some [36:29] communities are very like inner source [36:32] style driven where they have timed [36:34] releases and they go through like [36:36] specific kinds of backlog grooming and [36:38] like all that stuff is very particular [36:40] to their project and should be reflected [36:42] in their path of growth versus like [36:44] something that's more of like a classic [36:46] open source project that goes off of [36:48] feature releases or doesn't have a very [36:50] formal dev team or is very widely [36:52] distributed would look very different. [36:54] So, we don't have as much tier 4 [36:57] guidance as we do for like tier one or [37:00] tier 2. So, we're filling in some of [37:02] those gaps now, too. Um but all of this [37:05] stuff is um you know NAT has been [37:08] incredible and driving so much of it and [37:10] putting together so much of the tools [37:11] and they all build on the layers of [37:13] documentation from the maturity models [37:15] and the the repository scaffolder work [37:17] and it's sort of putting it into place [37:19] and we're starting to consider you know [37:22] getting that back up into the Cass [37:23] community because we've been leaning on [37:24] so much of the metrics work here. [37:29] >> Awesome. Thank you. [37:30] >> That's great. Thank you. There was a [37:32] side topic. I know we're getting close [37:34] to the end, but [37:35] >> yeah, Ria, what's your side topic? [37:38] >> So, you had mentioned that part of your [37:41] motivation, Don, for doing this was all [37:43] of the GitHub repos that you were [37:46] managing as part of VMware back in the [37:49] day that there's a hundred GitHub repos [37:51] from various acquisitions and projects [37:53] and spin-offs and everything else. And I [37:55] have a similar situation now. I've been [37:57] just trying to figure out how to corral [38:00] all of those. and I have index files and [38:03] traffic cop files that you know so I can [38:05] just have a one-stop shop to know where [38:07] everything is. But I'm wondering if this [38:10] group has [38:12] experience or suggestions about doing [38:16] that type of coraling to give a better [38:19] face to the public so they know where to [38:22] find stuff. [38:29] Is that a yes, you do have advice or [38:31] yes, you resemble that comment that you [38:34] would like advice, Remy? [38:36] >> I've been doing a lot of talking, so I [38:38] was going to give somebody else a chance [38:39] before I started again, but I definitely [38:41] have answered for this. [38:45] >> Um, so [38:48] >> in government land, we have code.json, [38:51] JSON, which is the metadata file that [38:54] gathers up a lot of the information [38:56] about what a project is and and what it [38:59] does and what its purpose is and where [39:01] it is in its development life cycle. And [39:03] then that is supposed to go to an [39:06] inventory on code.gov where people can [39:10] search through and find pre-existing [39:12] repositories while they're doing their [39:14] market analysis before they build or buy [39:16] something. [39:17] >> That was the intention. Oh, [39:19] >> it's still uneven amounts of adoption is [39:22] uh how I would describe it. [39:24] >> But um that's how it is in the federal [39:26] landscape. [39:27] >> In the international landscape, in the [39:28] national landscape, um you have like [39:31] code inventories from Germany and the [39:34] Netherlands and France where they are [39:37] using a similar metadata file to [39:39] code.json, but it's probably like public [39:42] code.yamel or code meta.json. [39:45] So if you can go through, [39:48] >> add a metadata file for each repository [39:51] and then get it uploaded into an [39:52] inventory. That's how the national [39:54] governments are doing it and that's how [39:56] uh the international project for [39:57] software heritage foundation where [39:59] they're cataloging all of Earth's source [40:02] code [40:02] >> as a UNESCO cultural heritage project. [40:05] Uh they use code meta JSON to do that [40:08] and they have forms for generating it [40:10] and they have some other tools around it [40:12] too. So, you know, we're hoping that [40:15] part of our archival process on our road [40:17] map is to create a converter that will [40:20] take our federal standard metadata, [40:22] convert it to the international [40:23] standard, and ideally deposit it into [40:26] the software heritage. But that's [40:28] perspective future work. Shouldn't talk [40:30] too much about that until we've shipped [40:32] it. But those are some of the ways that [40:34] we're thinking about uh that to your [40:36] question like how do we keep track of [40:38] all this stuff? If you add metadata to [40:40] every repository at least then you can [40:43] compare apples to apples and you can use [40:45] that to update your inventory and then [40:46] provide an inventory [40:48] >> even if it's just like [40:50] >> you know a simple web page that just [40:52] puts everything together which is you [40:54] know what we've done with our fork of [40:58] >> it sounds like that could also be really [41:00] helpful from an inner source perspective [41:01] for the stuff that you're not [41:03] necessarily putting out in the public [41:04] but just to help your own organization [41:06] find all the [41:10] Oh, 100%. And like even just simple [41:12] keyword and labeling stuff is great if [41:14] you're like this is a data science thing [41:15] or this is a Python thing or this is a [41:17] Java thing. Like [41:19] >> that alone really helps out especially [41:21] in like the government space where we [41:23] have different programs like Medicare or [41:25] Medicaid. People will ask like hey does [41:28] anyone have a Python project that will [41:29] crunch this stat for this state? And [41:33] being able to say, "Yeah, I think [41:34] there's a repo over here that does that [41:36] can really helps to save a lot of time." [41:38] Uh, and ideally, if you have like [41:41] example scripts or, you know, libraries [41:44] inside the the firewall is just as [41:46] important because, you know, we have all [41:49] these tools that are common, the the R [41:52] and the CCW and, you know, random [41:55] acronym, but they're just like data [41:58] sources where you can run scripts that [42:00] are shared. And I know that those folks [42:02] are looking to say, "Hey, I want to [42:05] provide an inventory to other people so [42:06] that they can run their scripts." It's [42:08] not even necessarily like a whole [42:10] projects. It's just like playbooks and [42:12] and um run books and stuff like that. [42:15] That is super helpful in the inner [42:16] source context. [42:19] >> Yeah. And the other thing the other [42:20] thing we had within within VMware was we [42:22] had some internal tooling that we would [42:24] onboard at least the most important [42:26] organizations to so that we could better [42:29] manage things like access so people [42:31] could request access to things. And so [42:33] there was there was a bunch of internal [42:36] tooling that did various bits of [42:37] maintenance around some of the um GitHub [42:40] or so. So I don't I don't know that's [42:42] necessarily the best solution, but it is [42:45] it is a another another way to do it. [42:50] All right, we are we have one more [42:52] minute. So, I'm just going to mention a [42:54] couple of things. So, the next meeting [42:56] which is on the 5th. Um, so there's that [43:01] uh working group within the to-do group [43:03] that's focused on basically business of [43:05] open source. Um, and they're going to [43:08] come in and talk to us a little bit [43:09] about what they've been doing and some [43:11] of the uh metrics that they've been [43:13] talking about and maybe get some [43:15] suggestions from us about uh metrics as [43:18] well from a kind of a business value [43:20] standpoint. Um, and Cornelius Schumacher [43:23] is going to give that presentation. So, [43:25] that'll be on the 5th. We will also [43:27] schedule a what do I supposas need to be [43:29] thinking about for AI? So, I've talked [43:31] to Emma, she's happy to do that. We just [43:32] need to get it to get it scheduled. And [43:35] then the other things I wanted to [43:36] mention, we have two conferences that [43:38] have just opened their CFPs. One is uh [43:41] the ASF's community over code. Um all [43:45] things open also opened their CFP. [43:47] They've got kind of a different format [43:48] this year. So I would encourage you to [43:49] have a look at that. And then there's [43:51] also I think you talked about it uh at [43:53] the last meeting that I missed, but [43:54] there's an OSPO virtual conference that [43:56] uh folks at Punch Tape are organizing. [43:58] So that might also be interesting for [44:00] folks. [44:02] And with that, I think we are I think [44:04] we're out of time. So, thank you [44:06] everybody so much for coming. Uh, I [44:08] really appreciate it. This was a really [44:09] really interesting discussion. So, [44:11] thanks to folks at the the CMS group, [44:13] Natalyia and Remy, for for coming along [44:15] and showing us some cool stuff. [44:19] >> Thank you. [44:20] >> Thanks everybody. Bye. [44:22] >> Bye. [44:23] >> Bye. [44:24] >> Bye.  📄 **Full text:** ![[Full Document Contents/Articles/CHAOSS OSPO WG, Feb 19 2026.md|CHAOSS OSPO WG, Feb 19 2026 by YouTube]] ## Highlights - started with our agenda item. >> Yes, thank you. And I will be taking over the screen share. Okay. Actually before that um I'm Natalia Luzeryaga. I'm a software engineer as part of the open source program office at the Centers for Medicare and Medicaid Services. And today we'll be talking about um our organization's practices with archiving repositories. This has been one of my main projects um starting the beginning of this year. Um so lately ([View Highlight](https://read.readwise.io/read/01kpb4e0sq0fhx44ra320g6dcy)) - Tags: 👻 ai highlighted - thinking of uh the rest of the life cycle one path which we call the path of growth. So as a open source project matures further in their journey how best can we assist them as an ospo and the other side of it the path of archival. So how do we assist repositories that have reached the end of life? So today I'll be focusing specifically on the path of archival um and how exactly we go about sunsetting repositories in our organization. Okay. ([View Highlight](https://read.readwise.io/read/01kpb4e0sy1dwxq0rz9gdd7nyt)) - Tags: 👻 ai highlighted - comment on what has been unresolved, label the issues accordingly, and for those that won't be fixed, label that too. Then we assess um who has access to the repository. Then we perform a lightweight security review, review for secrets, keys, PII, and then we do some minor housekeeping like deleting some branches. And then for repositories that are a bit more mature in their journey um such as they accept contributions ([View Highlight](https://read.readwise.io/read/01kpb4e0tc8zhjbrd39f52fy1t)) - Tags: 👻 ai highlighted - make sure that all of our bases are covered before we mark the repository as read me as uh archived. Okay, cool. And then so based on um all this information I just shared with you um our team we created a tool to kind of automate some of that work called repo sunsetter. And this is essentially a GitHub action that um prepares a repository for archival by um creating an issue that posts all ([View Highlight](https://read.readwise.io/read/01kpb4e0tx6ntmn5k1qaa6c75k)) - Tags: 👻 ai highlighted - you so much. >> Okay cool. That's really good to hear. Yes. I hope this uh we decided to make this a GitHub action because we know this is a shared challenge that ospos go through. So we hope that you can also make use of it too. Yes. >> Okay. >> Very thoughtful. Thanks for sharing all this. >> Yes. Of course. Of course. Okay. Um let's see. while she's building let's see I think I can talk a little bit more about diagnosing repositories ([View Highlight](https://read.readwise.io/read/01kpb4e0vjnggpwbw6x3wkj6md)) - Tags: 👻 ai highlighted - so that the repository um the development team can um go through this checklist now that they know how exactly they should prepare their repository for archival. Yeah. Cool. And then notice that we have two items that have already been checked over here. And that's because we actually automated that work. So we should have two pull requests up in this repository. Okay, cool. One is updating the project metadata. And for ([View Highlight](https://read.readwise.io/read/01kpb4e0wsc5tt7rjgdqsjrz9d)) - Tags: 👻 ai highlighted - sunset, right? This is the part that says we know we want to archive this repository. This is called what we refer to as the path of archive. We also have this concept of the path of growth which during the archival process like maybe we can say like hey it looks like your project is a little bit stale and coming up with like if you'd like it to not be stale here's a checklist of things you can do like adding pull requests templates or adding better contributor documentation or adding new issues that ([View Highlight](https://read.readwise.io/read/01kpb4e0zhz5vvgbafqty656ab)) - Tags: 👻 ai highlighted - There's probably about at least half a dozen GitHub orgs that are part of our footprint, plus a bunch of others that we don't know about yet, too. So, I think it's it's going to be a little bit of a patchwork uh process because each org will have different uh cycles that we go through. So, a lot of this, you know, we're still early on in the in the inventory process, but we're we're feeling better as we're starting to put some concrete code that actually runs and actions that we can enable. ([View Highlight](https://read.readwise.io/read/01kpb4e111snazssfrpnhe2bp3)) - Tags: 👻 ai highlighted