CHAOSS AI Detection Project Meeting, Feb 17

CHAOSS AI Detection Project Meeting, Feb 17 ![rw-book-cover](https://img.youtube.com/vi/lU2NKub8XwU/maxresdefault.jpg) 🔗 **Source:** [CHAOSS AI Detection Project Meeting, Feb 17](https://www.youtube.com/watch?v=lU2NKub8XwU) > [!note]+ Document Notes > tags: #ai-detection #open-source #metrics #chaoss #project-management > author: CHAOSS Community > source: YouTube > reference: https://www.youtube.com/watch?v=lU2NKub8XwU > date created: 2024-02-17 16:30 > > # 🏷️ Title: CHAOSS AI Detection Project Meeting - First Trial Meeting >  ## 🧰 Action Inbox - [H1] Merge confidence scoring PR and create follow-up issue for points-based system — Adrian/Andrew #ai-detection - [H2] Test MVP tool on actual repositories and collect feedback — Team #testing - [H3] Set up automated release builds with binary attachments — Andrew #automation ## 🧭 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 AI Detection Repository](https://github.com/chaoss/ai-detection) - [Research Dataset of AI Generated Pull Requests](https://github.com/example/ai-pr-dataset) ## 📝 Summary - First meeting of the CHAOSS AI Detection project, a cross-working group initiative - Team includes maintainers from Augur, Ecosystems, and academic researchers - Goal is to create standardized tooling for detecting and measuring AI contributions in open source - MVP tool is ready for testing with deterministic detection methods - Future plans include confidence scoring, automated releases, and broader community testing ## 📖 Main Content The CHAOSS AI Detection project emerged from conversations across multiple working groups about the need for standardized tooling to detect AI-generated contributions in open source projects. The initiative addresses the challenge that many projects want to allow AI assistance while requiring disclosure, similar to citing sources from Stack Overflow. The project aims to create an adapter layer between varying disclosure standards, from "co-authored-by" git commits to PR comments mentioning AI tools. This would enable projects to understand how AI is being used in their contributions and feed into analysis tools like Augur. The team has developed an MVP tool that can detect various signals of AI contribution through deterministic methods, avoiding the reliability issues of existing AI detectors. The approach focuses on explicit disclosure patterns rather than attempting to detect undisclosed AI usage. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/lU2NKub8XwU?t=0) — [H1] Meeting Introduction and Project Overview - Key idea: First trial meeting of CHAOSS AI detection working group/side project - Evidence: "assists like three other working groups" - cross-cutting initiative #### ⏱️ [01:15](https://youtu.be/lU2NKub8XwU?t=75) — [H2] Team Introductions - Adrian - Key idea: Adrian leads from Red Hat OSPO and Augur working group - Evidence: "one of the sort of most act more active maintainers of Augur" #### ⏱️ [02:45](https://youtu.be/lU2NKub8XwU?t=165) — [H2] Team Introductions - Schillo - Key idea: PhD researcher studying communication dynamics and security practices - Evidence: "how sort of communication dynamics within open source repositories affect the security practices" #### ⏱️ [03:30](https://youtu.be/lU2NKub8XwU?t=210) — [H2] Team Introductions - Andrew - Key idea: Works on ecosystems and package manager metadata - Evidence: "already been picking up a number of bits of signal in ecosystems" #### ⏱️ [05:45](https://youtu.be/lU2NKub8XwU?t=345) — [H3] Detection Signal Examples - Key idea: Multiple disclosure standards exist (co-authored-by, generated-by, PR labels) - Evidence: "people disclose it. Like people say, 'Oh, I used Gemini to do this'" #### ⏱️ [08:30](https://youtu.be/lU2NKub8XwU?t=510) — [H1] Data Back to AI Companies Use Case - Key idea: Aggregate detection data could inform AI tool evaluation - Evidence: "Claude has contributed to 10% of the top like most critical Python packages" #### ⏱️ [12:15](https://youtu.be/lU2NKub8XwU?t=735) — [H2] Git Refs as Detection Method - Key idea: Git refs can store metadata that travels with repository pushes - Evidence: "when you push to GitHub, that data goes with it" #### ⏱️ [15:00](https://youtu.be/lU2NKub8XwU?t=900) — [H1] Confidence Scoring Discussion - Key idea: Need to decide between pass/fail vs points-based confidence system - Evidence: "Some of them are very easy to be like, yes, definite or not, but others are going to be pretty fluffy" #### ⏱️ [17:30](https://youtu.be/lU2NKub8XwU?t=1050) — [H2] Points-Based Scoring Like Spam Filters - Key idea: Similar to SpamAssassin's heuristic point system - Evidence: "each of them like either adds or subtracts points" #### ⏱️ [22:00](https://youtu.be/lU2NKub8XwU?t=1320) — [H3] Avoiding User Reputation Scoring - Key idea: Focus on content signals rather than user characteristics - Evidence: "as soon as they know the metric exists it's going to get gamed" #### ⏱️ [25:45](https://youtu.be/lU2NKub8XwU?t=1545) — [H2] Future AI Model Integration - Key idea: Could train BERT model on detected data for additional signal - Evidence: "once you have enough detected data, right? And then we just embed the BERT model" #### ⏱️ [30:15](https://youtu.be/lU2NKub8XwU?t=1815) — [H1] Configurable Detection Approach - Key idea: Let maintainers choose deterministic vs probabilistic detection - Evidence: "if a maintainer is like i just want all the deterministic stuff" #### ⏱️ [35:00](https://youtu.be/lU2NKub8XwU?t=2100) — [H1] MVP Ready for Testing - Key idea: Current PR provides working MVP that can be merged - Evidence: "merge this as it is because it's kind of our MVP" #### ⏱️ [38:30](https://youtu.be/lU2NKub8XwU?t=2310) — [H2] Release Automation Plans - Key idea: Automated binary builds and release notes generation - Evidence: "whenever we tag a release then it will build and attach the binaries" ## 📚 References - [CHAOSS Augur Project](https://github.com/chaoss/augur) - [CHAOSS Ecosystems](https://github.com/ecosystems) - [Git Packages Project](https://github.com/andrew/git-packages) - [AI Attribution Specifications](https://github.com/example/ai-attribution-spec) ## 🗣️ Paraphrase - The project creates standardized tooling to detect AI contributions across different disclosure methods used in open source projects - The team includes maintainers from multiple CHAOSS working groups plus academic researchers studying open source security - They're building an MVP that uses deterministic detection rather than unreliable AI-detection algorithms, focusing on explicit disclosure patterns ## 📰 Newsletter The CHAOSS community is launching an AI Detection project to help open source maintainers understand and measure AI contributions in their repositories. This cross-working group initiative addresses the growing need for standardized detection of AI-assisted code as more projects adopt "disclose but don't ban" policies for AI tools. The project creates tooling that can detect various AI disclosure patterns - from git commit co-author tags to PR comments mentioning ChatGPT or Claude. Rather than trying to detect undisclosed AI usage, the focus is on aggregating explicit disclosures to provide insights for project health metrics. An MVP tool is ready for community testing, with plans for automated releases and broader integration with CHAOSS tools like Augur. Resources: [CHAOSS](https://chaoss.community/), [Augur Docs](https://oss-augur.readthedocs.io/), [AI Detection Repo](https://github.com/chaoss/ai-detection) ## ✅ Action Items #### DevRel - Developer advocacy: Present AI detection tooling at conferences, create demos showing detection capabilities - Education: Develop workshops on AI contribution policies, office hours for implementation questions - Developer experience: Improve documentation for different disclosure standards, create CLI guides - Developer marketing: Blog posts about ethical AI usage in open source, detection methodology content - Community management: Moderate discussions about AI detection policies, collect feedback from early adopters #### OSPO - Policy & Governance: Draft AI contribution policies for internal projects, review existing disclosure requirements - Software Inventory: Integrate AI detection into SBOM workflows, track AI-assisted components - Developer Support: Training on AI detection tools, consultation on detection policies - Community Engagement: Fund upstream development of detection tooling, establish contributor agreements - Strategic Alignment: Define KPIs for AI usage measurement, quarterly reporting on AI contributions #### Community - Maintainers: Governance templates for AI policies, roadmap support for detection integration - Contributors: Onboarding materials about disclosure requirements, first-issue programs for detection tools - Ecosystem: Cross-project coordination on disclosure standards, shared tooling development #### WordPress - Core: Evaluate AI detection needs for core contributions, establish disclosure policies - Meta: API integration for AI detection across .org properties - CLI: Command scaffolds for AI detection in development workflows - Plugins: Security liaisons for AI-generated plugin reviews, provenance verification ## 🧪 Hypotheses - Projects with explicit AI disclosure policies will have higher quality AI contributions than those without policies - Deterministic detection methods will be more reliable than probabilistic AI detection algorithms for measuring contributions - Cross-working group collaboration will produce more comprehensive tooling than individual project efforts - Standardized disclosure formats will emerge as detection tooling becomes widely adopted ### 📊 Methodology - Survey study comparing AI contribution quality across projects with different disclosure policies - Comparative analysis of detection accuracy between rule-based and ML-based approaches - Case study analysis of cross-functional team effectiveness in open source tooling development ### ❓ Questions - How will detection tooling affect contributor behavior around AI disclosure? - What confidence thresholds are appropriate for different project contexts? - How can detection tools balance accuracy with privacy concerns? ### 🔮 Future Research - Long-term impact of AI detection policies on project health metrics - Effectiveness of different AI disclosure standards across programming languages - Integration patterns between detection tools and existing project management workflows ### 💡 Implications - Practice: Projects need to develop clear AI contribution policies before implementing detection - Policy: Standard disclosure formats could improve cross-project measurement consistency - Security: AI-generated code may require additional review processes and provenance tracking - Education: Contributors need training on appropriate AI tool usage and disclosure methods - Funding: Detection tooling development requires sustained cross-organization collaboration ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade #### 👀 Visual learners - Present: Meeting format allows screen sharing of code and documentation - Improve: Architecture diagrams showing detection workflow, visual examples of different disclosure patterns #### 🔊 Aural learners - Present: Video meeting format with verbal discussion of concepts - Improve: Recorded follow-up summary, podcast-style explanation of detection methods #### 🗣️ Verbal learners - Present: Technical terminology explained in context, analogies to spam filtering - Improve: Glossary of detection terms, comparison tables of different approaches #### 🧩 Kinesthetic learners - Present: Working MVP that can be tested, hands-on CLI tool development - Improve: Step-by-step setup guides, interactive testing workflows #### 🧠 Logical learners - Present: Clear decision trees for confidence scoring, systematic approach to detection - Improve: Flowcharts showing detection logic, quantitative accuracy metrics #### 🧑‍🤝‍🧑 Social learners - Present: Cross-working group collaboration, community-driven development - Improve: Contribution guides for community input, structured feedback collection #### 🧘‍♀️ Solitary learners - Present: Individual testing of tools, self-directed exploration of codebase - Improve: Self-assessment checklists, independent learning paths for tool usage #### 🌿 Naturalistic learners - Present: Ecosystem thinking about project interdependencies - Improve: Sustainability considerations for long-term tool maintenance ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Meeting transcript provides text access to audio content - Improve: Structured headings in documentation, alt text for any diagrams #### Keyboard navigation - Present: CLI tool supports keyboard-only interaction - Improve: Ensure web interfaces have proper tab order, skip links for documentation #### Contrast and readability - Present: Terminal output uses standard contrast ratios - Improve: Documentation color choices, code syntax highlighting accessibility #### Text resizing and reflow - Present: Documentation should support browser zoom - Improve: Test at 200% zoom, ensure no horizontal scrolling #### Media and captions - Present: Meeting recording can be captioned - Improve: Provide transcripts for all video content, audio descriptions if needed #### Forms and interactions - Present: CLI interactions provide clear feedback - Improve: Error messages that explain how to fix issues, accessible form validation ### 🌍 DEIB Assessment #### Cultural breadth - Present: International team with UK, US, Nigeria representation - Improve: Consider global variations in AI tool usage patterns, multilingual documentation #### Inclusive language - Present: Technical discussion avoids exclusionary jargon - Improve: Define technical terms consistently, avoid assumptions about prior knowledge #### Neurodiversity support - Present: Meeting structure allows for different participation styles - Improve: Provide agenda in advance, allow async participation options #### Representation - Present: Academic and industry perspectives represented - Improve: Ensure contributor recognition reflects all contributions, diverse use case examples #### Psychological safety - Present: Collaborative tone in technical discussions - Improve: Clear contribution guidelines, respectful disagreement processes ### ✅ Logical Validity #### Strong reasoning - Deductive strength: If AI disclosure varies across projects, then standardized detection improves measurement consistency - Inductive strength: Multiple working groups expressing interest suggests broader community need for tooling - Causal reasoning: Explicit disclosure requirements should lead to better contribution quality through accountability - Analogical strength: Spam filtering comparison provides good model for confidence scoring approaches #### Fallacies - Appeal to novelty: Assuming newer AI detection methods are necessarily better than deterministic approaches - False dilemma: Presenting choice between perfect detection and no detection, ignoring partial solutions #### Tone of voice - Overall tone: Collaborative and technically focused, with appropriate uncertainty about complex challenges ### 🛡️ DARVO Analysis - Deny: No patterns of denial identified in technical discussion - Attack: No attacks on participants or positions observed - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Professional, collaborative tone throughout ## 🎯 Conclusion The CHAOSS AI Detection project represents a practical, community-driven approach to measuring AI contributions in open source. By focusing on explicit disclosure patterns rather than attempting to detect undisclosed AI usage, the project provides maintainers with actionable insights while respecting contributor privacy. The cross-working group collaboration model demonstrates how specialized tooling can emerge from shared community needs, with immediate applications in project health metrics and longer-term research potential. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Detection tooling improves contribution transparency > [!quote] [CHAOSS AI Detection Project Meeting](https://youtu.be/lU2NKub8XwU) by [[CHAOSS Community]] via [[YouTube]]. Published 2024- --- ## Full Transcript [00:00] do that. [00:02] Sweet. So, welcome to the first sort of [00:04] trial meeting of I guess the chaos AI [00:08] detection action. I don't know if you [00:10] want to call it a working group because [00:12] it's probably not that big, but it's [00:13] like side side projects that sort of [00:16] assists like three other working groups. [00:18] I don't know. Um, [00:21] yeah, it seems like I think this effort [00:23] essentially came together just from like [00:25] this idea. I mean, it seems like this [00:27] idea I've kind of had this idea for a [00:29] little while, but I think having talked [00:31] about it in Chaos, it seemed like it [00:32] piqu peaked various people's interests [00:34] from from Andrew with ecosystems and [00:36] Schllo's PhD research and just chaos [00:40] augur grimmore lab like being able to [00:42] use it. So, I think I think this is a [00:44] kind of neat little like example of [00:46] working upstream and working together. [00:48] Um, do we want to kind of go around and [00:50] do some introductions [00:53] briefly? [00:54] >> Yeah, sounds good. Wait, I I can start. [00:56] So, I'm I'm Adrian. I'm I my most of my [00:59] work up until now has been I mean, even [01:01] still now uh in the Augur working group. [01:04] I'm one of the sort of most act more [01:06] active maintainers of Augur. Work [01:07] closely with Sean and mostly other augur [01:10] core team. I'm pretty active in that [01:12] channel. Um just helping kind of unteify [01:15] and and improve the Augur codebase. Um [01:18] my day job is working at Red Hat's open [01:20] source programs office. Um, I'm I'm kind [01:22] of on the data team with with Cali and [01:24] and Kaio and some of the other people [01:26] helping kind of we run an auger instance [01:28] internally for for Red Hat stuff, but [01:31] the majority of my work is all just [01:32] upstream community in chaos basically. [01:35] Um, and obviously every every company [01:38] under the sun is now interested in AI [01:40] and like how do we measure how do we [01:42] evaluate how do we you like use more of [01:45] it or evaluate how it's being used. And [01:47] I think there's also been a lot of stuff [01:49] going on in the the open source [01:50] community that scared people in terms of [01:52] AI. So seems like there's a lot of [01:54] interest here. [01:56] Anyone else want to go up? [01:59] >> I think I can go next. So yeah. Hi, I'm [02:00] Schllo. I'm a PhD candidate at the [02:02] University of Florida. Uh my research [02:05] mainly uh work revolves around how sort [02:09] of communication dynamics within open [02:11] source repositories [02:13] affect the security practices and [02:16] repositories. Uh and yeah I've I've been [02:20] involved with Augair recently. I think [02:23] it's been what four months now. uh uh so [02:27] yeah it's been it's been a good [02:29] experience and uh yeah Adrian and I were [02:32] discussing about uh you know AI [02:34] guidelines and stuff like that for augur [02:36] and that's also sort of uh ran into the [02:40] so can we you know sort of built a [02:43] heristic based detection tool or [02:44] something for AI detection and uh that's [02:47] how uh I got involved in this mouthful [02:52] group that we are now calling data AI [02:54] detection [02:55] I completely forgot the name. [02:57] >> Yeah, but [03:00] >> I already had a repo called AI detection [03:02] in the same code folder as well. So, [03:04] it's like I have to kind of like force [03:06] tab my way through to get to it. [03:08] >> The data AI detection. Yeah. [03:12] Yeah. So, that's me. [03:16] >> Hi everyone. I'm Andrew. Uh I'm in the [03:18] UK. I work on ecosystems primarily [03:22] uh and hang out in various chaos working [03:26] groups. Uh the main one I'm involved in [03:29] is the package manager metadata group. [03:33] Um I had kind of already been picking up [03:36] a number of bits of signal in [03:38] ecosystems. [03:40] uh before Christmas I added in the [03:42] detection for the kind of like [03:44] co-authors and signed off um messages in [03:48] uh commit messages and then also went [03:52] through and pulled out a load of like [03:54] labels that show up a lot that are [03:56] created by you know like if you make a [03:59] PR from the [04:02] I guess it's called codec now but it [04:04] used to be called chat GBT [04:06] like code uh that would leave a label [04:10] that said basically was it indication [04:12] that it was made by that thing rather [04:15] than using, you know, the bot account. [04:17] There all kinds of different ways that [04:19] these things work. Um, but all of them [04:22] were just kind of like desperately built [04:24] into different pieces of ecosystems. [04:26] There's not like a nice standalone [04:29] piece. Uh, I also got a project I've [04:31] been working on this year called Git [04:33] Packages, which basically is like [04:34] ecosystems, but you run it locally and [04:36] it analyzes the history of your [04:38] dependencies for a given repo. And that [04:42] is much more interesting to be able to [04:44] go like, oh, I can run this analysis on [04:47] a given repo locally. Well, this plugs [04:50] straight into this detection thing. Um [04:52] but also then if you want to do analysis [04:54] of lots of packages locally then it's [04:56] also very helpful to be able to go [04:58] through and clone all of those the repos [05:01] of each package and say okay well let's [05:03] do local detection I don't need to to go [05:05] anywhere else and then ecosystems [05:08] naturally ends up being a place where [05:09] it's like oh we can do some shared [05:12] public good analysis where we run this [05:14] code against public repos and then [05:16] record the results so that people can [05:18] just do a quick lookup rather than [05:20] needing to wait for say a CI job to run [05:23] on every on everything. If we're going [05:25] to be analyzing it anyway, then just [05:27] fling the um the results to a S3 bucket [05:32] or similar and then cache them in [05:33] Cloudflare. [05:38] >> Awesome. [05:40] >> Anyone else want to introduce [05:42] themselves? [05:45] >> Um hello everyone. [05:48] I don't know. Okay. [05:51] So, my name is Emanuel. I stay in [05:53] Nigeria. I'm a junior software developer [05:56] with um a Canadian startup, an IoT based [05:59] Canadian startup. I'm a full stack web [06:01] developer. So, I'm totally new to open [06:04] source. I just joined the ARA group [06:07] recently. So, I I just you know saw the [06:10] meeting link. So, I decided to join and [06:12] just get conversant with the ecosystem [06:14] of the project. So yeah, it's been [06:17] really nice getting to know everyone and [06:19] understand what's really happening. [06:21] Thank you. [06:23] >> Awesome. We You were in the augur auger [06:25] call just now, right? [06:27] >> Yes, but I came quite late. [06:29] >> Yeah, no worries. All the all the chaos [06:31] meetings are generally kind of recorded [06:32] and on YouTube if you want to go back [06:34] and watch the last couple of them. I [06:36] think it usually takes about a week or [06:38] half a week for for I think Elizabeth to [06:40] upload them. Um, but yeah, I'm happy to [06:44] help help you navigate your way around [06:45] chaos if [06:46] >> if there's something in particular [06:48] you're looking for. But glad to have you [06:50] here. [06:51] >> Thank you very much. I I'll [06:58] thank you. I I'll check the videos out. [06:59] Thank you very much. [07:01] >> Yeah, no problem. Sorry, I wasn't sure [07:02] if you sound like you're breaking up, [07:04] but I got it. Yep. All right. So, yeah, [07:08] I mean, I kind of mentioned earlier kind [07:09] of what this is and how it came [07:10] together. like it's kind of just like [07:12] every everyone here kind of has at least [07:14] one if not more than one sort of project [07:17] that there there's sort of interest in [07:19] there's kind of interest in this kind of [07:21] like having a tool that kind of just is [07:23] a effectively I guess an adapter layer [07:26] between all the different sort of [07:28] varying standardsish that are out there [07:31] as far as how how to disclose like [07:34] shared authorship or AI authorship of of [07:37] code or other contributions. I think [07:39] this this is sort of mostly focused on [07:41] code, I guess, but like [07:43] there's always all the like you could [07:45] have like a a co-authored by on on a git [07:49] commit. You could I think I feel like I [07:51] saw a standard at one point or standard [07:53] like people using like generated by or [07:55] assisted by um to sort of [07:58] >> in the description of the PR or the or [08:00] sometimes in the commit message as well. [08:04] >> There's like a commit flag like a extra [08:07] sign off or something. Yeah. But [08:09] >> yeah, I mean like people people disclose [08:11] it. Like people say, "Oh, I used Gemini [08:13] to do this in in PR comments or like [08:16] there's so many different ways that [08:17] people sort of site their sources as far [08:20] as like, hey, I used AI for this." U and [08:22] I think especially for the projects that [08:25] don't outright ban it, but are maybe [08:26] like, "Hey, we should we want you to [08:28] just like Augur, I think the direction [08:30] that I think the Augur policy is going [08:32] is like we're not going to ban it. We [08:33] just want to make sure that all the [08:35] contributions AI or not are held to a [08:37] certain standard of of quality and if [08:39] you're using AI, you should be [08:40] disclosing that like just like you would [08:42] site your sources if you're copying code [08:44] from Stack Overflow or whatever. Um just [08:48] and also just to help us understand how [08:49] AI is being used. So I think I think [08:50] that's valuable too is like helping [08:52] projects understand how AI is being used [08:54] in their contributions and feeding into [08:56] tools like Augur. [08:59] Am I missing anything? as other people [09:00] have. Oh, I mean the like the use case [09:04] that I kind of thought might be [09:06] interesting but also most people [09:08] wouldn't look to it is once you're [09:11] collecting it on mass then you can also [09:13] go back to the AI tools and go like here [09:16] is a large collection of data of stuff [09:20] that has been produced by your tool uh [09:23] for you know more and kind of quantitive [09:27] analysis. uh but obviously that requires [09:31] mining a lot of things uh to be able to [09:34] to to give that over effectively. [09:38] >> So like kind of providing data back to [09:39] these these AI companies. [09:41] >> Yeah. Like I mean they're probably doing [09:43] it already. Um but you can also then be [09:46] able to say like oh look here's Claude [09:49] has contributed to 10% of the top like [09:54] most critical Python packages or [09:55] something like that. uh that like kind [09:58] of ability to detect it uh is helpful [10:03] and that's a good and or bad thing like [10:06] depends on your like [10:09] >> your stances but it's a fact that can be [10:12] or at least you know like for the ones [10:14] that we can detect because obviously you [10:15] don't have to put any kind of indication [10:17] in that you're using any so uh it's [10:21] basically going on like whatever the [10:22] signals are available. Yeah, that's [10:24] actually really interesting because I I [10:26] saw so one of the I don't know this [10:28] probably wasn't super inspiring for this [10:29] project, but I I've seen before other [10:32] open source communities using [10:34] tools mostly sort of more for like I [10:36] guess social metrics, but they like uh I [10:38] think I think it was the Universal Blue [10:40] community who built Bazite, the sort of [10:41] gaming Fedora based operating system. Um [10:45] they were using a tool to kind of keep [10:47] track of like their Discord and I think [10:48] Reddit and stuff too, but I think mostly [10:50] Discord for this. And that I guess that [10:52] that metric was basically like it looked [10:55] for people asking questions and then [10:57] somebody responds to the question and [10:59] then the question asker responds with [11:01] like a thank you and it sort of track it [11:02] like counted that and so it's like hey [11:05] how many how many sort of positive like [11:06] help interactions are we getting in this [11:08] community. I almost wonder if that could [11:10] be interesting to kind of tie into like [11:12] providing that data back to AI companies [11:13] as far as like hey yeah maybe Claude was [11:16] used in these top repos or like but then [11:18] maybe that could tie into some of like [11:20] Schllo's sentiment [11:21] >> you could definitely feed that into like [11:23] sentiment analysis around the [11:25] conversation as well and go like oh it [11:27] turns out in these in this ecosystem [11:29] everyone hates this so probably your [11:32] like your PRs are bad uh for you know [11:36] they train and test a lot more on Python [11:38] than they do on Erlang for example uh to [11:41] be able to go here's more quantitive [11:43] data that suggests that no one is [11:45] merging Claude Erlang uh contributions [11:49] in open source at least you know [11:50] ecosystems only picks up stuff on public [11:53] projects [11:55] >> yeah or you could even like hey we're [11:57] like these PRs like we're responsible [12:01] for the largest share of the bugs or the [12:03] smallest share of the bugs or like so [12:05] imagine I imagine a lot like in the [12:06] self-driving car world it's always like [12:08] how good is it compared to a human [12:10] driver? And it's like [12:13] it's sort of maybe harder maybe not hard [12:15] to measure, but like I imagine you could [12:16] use something similar with open source [12:18] is like does does this code have more or [12:20] less bugs than the human authored code [12:22] before it? Like there's there's a ton of [12:24] room for interesting analysis. I mean [12:26] that's probably more like data science [12:27] working group territory but like [12:30] >> yeah just having the raw data though to [12:32] be able to then pass over to other [12:34] groups like right now and it we can end [12:38] up with just almost like a dictionary of [12:40] here are the different ways that you can [12:43] do some level of detection because [12:45] obviously if you're like oh actually [12:47] like I only care about this bot and this [12:49] bot only writes in this method I don't [12:52] need to use the whole tool I just need [12:54] to like troll through in a certain kind [12:57] of way or I can use this API to do this [13:00] rather than like I mean in some cases [13:02] you might see it in the GitHub archive [13:04] data and then you're like great I don't [13:06] need to fetch anything other than I just [13:09] troll through the GitHub archive data to [13:11] find this particular string one [13:14] brilliant but in other cases you're like [13:16] oh I can't get there's no git ref data [13:18] in GitHub archive so uh I have to go and [13:23] you know fetch every repo to go and look [13:26] inside its ref's database. [13:29] >> Yeah, that's a really interesting angle [13:31] that I'm excited to kind of explore [13:33] more. I I didn't know really much about [13:35] git refs until now, but there's been [13:37] some interesting issue. I think the the [13:38] issue you found was issue number two on [13:40] the repo like that. There's some cool [13:41] links in there. [13:42] >> Yeah, that basically came from where I [13:44] was spelunking around over Christmas in [13:46] the ways that you can store extra data [13:49] in inside of Git. Uh, and yeah, it turns [13:53] out that other people use that as well. [13:55] JJ uses it as well. If you're using JJ, [13:58] it makes like a JJ name space in the [14:01] refs folder and stores extra stuff there [14:03] because when you push to GitHub, that [14:05] data goes with it. So, it's actually [14:07] then everyone pulls it back down. It [14:09] moves around rather than like a hook [14:12] which is only installed locally on your [14:14] repo that you've checked out. [14:18] >> Yeah. [14:19] Uh, I did open and update that PR. [14:23] Thanks for the review. Um, I fixed three [14:28] of the four comments. The fourth one [14:31] being like the confidence levels and I'm [14:35] basically like I I don't know. We we up [14:39] for us to decide what we want to do. [14:41] Like for a CI check, you want a pass or [14:44] a fail kind of thing. So then the [14:46] configuration is like right. Well, how [14:49] do we decide? Some of them are very easy [14:51] to be like, yes, definite or not, but [14:54] others are going to be pretty fluffy. [14:57] Um, so maybe we need more data to be [15:00] able to give us a bit of a test case or, [15:03] you know, you started a thread of like [15:05] here are some examples. Maybe we should [15:07] put some more together that we can turn [15:09] into like here's the JSON you would get [15:12] from the GitHub API. [15:15] uh [15:16] can't well yeah can't even do it with [15:18] that necessarily because you need to [15:19] also check against the git repo but some [15:22] test harness that we can then go like [15:24] okay well we can make sure that we're [15:27] covering all of these things and also [15:29] we're not sure about this one like or [15:32] it's like very difficult to test against [15:36] >> yeah I almost I almost wonder like [15:38] because it seems like right now we sort [15:40] of just have like a high medium low sort [15:42] of like I guess enum whatever whatever [15:45] the structure is called um for like [15:48] confidence scoring. Like I almost wonder [15:49] if it'd be better. Like I feel like I've [15:51] heard of more pointsbased things being [15:54] used for like email filtering like spam [15:56] assassin and stuff where it's like oh [15:57] there's all these different heristics we [15:59] look at to try and determine if this [16:00] email is legit or spam and like each of [16:03] them like either adds or subtracts [16:05] points and like [16:06] >> yeah did in liio was you would you would [16:09] gain things for good behavior and lose [16:12] points for bad behavior. you know, if [16:14] your if your version numbers weren't [16:17] exactly SER, then you're going to lose a [16:19] point. Uh, for example, um, so we could [16:23] definitely do that. It's basically just [16:24] a case of coming up with what, you know, [16:27] some decision on how we like what things [16:31] we are going to score good and bad. Uh, [16:35] I also maybe would against going like [16:38] into the reputation of the user a little [16:40] bit because that data can be huge. Uh [16:44] but also some people might get very uh [16:47] funny about having like oh this script [16:50] then goes and you know analyzes how long [16:52] has this person been on GitHub for for [16:55] example is it's also kind of losy [16:58] because I could sell a GitHub account to [17:00] someone else uh if they were really [17:03] trying to hide that [17:03] >> as soon as they know the metric exists [17:05] it's going to get gained. [17:06] >> Yes. Yeah. Exactly. [17:07] >> And I I also want to try and maybe move [17:09] a little bit away from calling it good [17:10] and bad. Like I think we could maybe [17:12] still do the numeric scoring and just [17:13] have it be like here is sort of how how [17:16] likely this is to be AI. We're like hey [17:18] positive points are like more likely to [17:20] be AI [17:22] and negative points are like hey here's [17:23] more indicators of it being human. Um, [17:26] like even maybe we could even do like [17:28] run a spell check on the like [17:32] any one metric, but like [17:35] >> maybe run a spell check on the frequency [17:37] of like known unusual words that [17:41] >> chatbots like to say a lot dashes like [17:46] >> like used a lot of headings in your uh [17:50] in your issue. I mean, we joke, but [17:54] there are definitely some huristics like [17:56] that that like people get that kind of [17:58] feel for it, even if it's not explicit. [18:01] They're like this, it says some things [18:04] that just setting off my trigger alerts. [18:06] Of course, the problem is that uh a lot [18:09] of these bots are trained on all the [18:12] existing content. So, they do end up [18:14] like all the emojis in readmes would [18:16] just come from the JavaScript community [18:18] uh having emojis in all their readmes. [18:21] So it kind of you know you towards the [18:24] average I guess of all open source if [18:27] you if you go too far into the like the [18:30] feels of a issue. I mean you could [18:33] literally do embeddings and say like how [18:36] close is this to the embeddings of all [18:39] known [18:41] uh AI generated PR descriptions for [18:43] example and you can say oh this looks a [18:46] lot like it except for that you know the [18:48] shorter your PR description is the worse [18:50] your embedding is going to be. [18:52] Yeah, that was one of the ideas I sort [18:54] of had part of the kind of original idea [18:56] for this was like as sort of a side [18:59] project. I almost wonder if it would be [19:00] interesting to create because I know [19:01] like there's all these AI detectors on [19:03] the internet and they're varying degrees [19:04] of not great um as far as like hey put [19:08] an image or put put a paragraph in here [19:10] like academic in the academic world like [19:12] hey upload an essay and see if a [19:14] student's been using AI right um and [19:17] like we sort of have like virus total [19:19] for like the security world where like [19:21] you upload a binary and it will just [19:23] scan it with every antivirus tool and [19:25] it'll let you know like oh only one or [19:28] two of these flagged it might be fine or [19:31] like all of them are flagging it, then [19:33] it's probably malicious. Um, and so like [19:36] even if you've got a whole pile of [19:37] unreliable tools, I almost wonder if you [19:39] could kind of build something like that [19:41] and then we could kind of use that as [19:43] part of this to like [19:44] >> maybe as maybe as like a sort of future. [19:48] >> Yeah. I mean, you could [19:50] using AI and not disclosing it. [19:52] >> We could train a little BERT model uh [19:55] once you have enough detected data, [19:57] right? And then we just embed the BERT [19:59] model in the um in the binary and it [20:04] would be like oh yeah high confidence [20:05] low confidence. Obviously, it's much [20:08] harder then to kind of reverse engineer [20:10] that and go like, "Oh, this is exactly [20:13] why this is low confidence because it's [20:15] like, well, we we smooshed like a [20:18] million uh PR descriptions and titles [20:21] and things into this uh into this model [20:26] and came out with a a tiny binary on the [20:28] other side. compared to the very like [20:31] discrete steps of like oh yeah we did [20:34] these reaxes and uh you matched on three [20:37] of them like the debug there is much [20:39] easier and like we could even have like [20:42] if it's going to leave a PR comment it [20:45] could put like a a hidden block of YAML [20:49] that's like here is the very like [20:52] verbose description of all the different [20:54] checks that it did [20:56] >> uh so that you can see once you get into [20:59] the kind of like, oh, we we have a spam [21:01] model essentially. Uh, it's like, well, [21:04] for one thing, maybe some people are [21:07] going to be like, I want my own custom [21:09] hidden spam model. Uh, or it's going to [21:13] be like, well, this is entirely opaque [21:15] and we can't tell you why exactly this [21:19] uh isn't working. Of course, I guess the [21:23] further down that you go, you also end [21:24] up in a place where you're like, do we [21:26] we could use AI to try and detect if [21:28] it's AI, but [21:30] >> that's a very expensive way to do it. [21:33] >> Yeah. And I think one of the things I [21:34] like about this too is like I want to [21:36] make sure that whatever we're doing like [21:37] if we're going to be doing the B model [21:38] or things like that, like [21:40] >> make sure it's configurable. So like if [21:41] if a maintainer is like I just want all [21:44] the deterministic stuff. I don't I don't [21:46] want any variability in whether or not [21:48] this is AI. just like show me the [21:50] deterministic ones. Maybe there's a flag [21:52] like we pick a sensible default and then [21:54] just let them customize it. Um because [21:57] then like everyone's going to have [21:58] probably a different label they apply or [22:00] whatever. But I think even just having [22:03] that be explicitly defined like you you [22:06] you set up this action on GitHub or [22:08] wherever and you you say, "Hey, I want [22:10] AI things to be labeled with this [22:11] label." I'm sure we could write a a [22:13] small piece of code in Augur to check if [22:15] this action is installed, read that [22:17] config line and then we'll just [22:19] dynamically use that [22:21] detect like [22:23] >> even just the existence of the config. [22:24] But maybe maybe [22:26] >> there's other ways to do it too as far [22:28] like I've seen [22:30] >> I think there's like the AI there's like [22:31] some AI attribution spec I think I [22:32] linked in one of my issues like maybe [22:35] maybe it could post a comment with like [22:36] a string that meets that spec and so we [22:39] can just scan for that or what like [22:40] whatever. I don't quite know exactly how [22:42] we'd be making this data available to [22:44] like other analysis like broader [22:46] analysis tools like Augur that would [22:48] look across whole orgs or whole sets of [22:50] repos. [22:51] >> But there there's options and I think I [22:54] think that'll sort of solidify as we [22:56] play with this. [23:02] >> Uh so what's the next steps then? [23:06] >> I'm not sure. I know um I mean it seems [23:08] like we've got that PR. I think that's a [23:10] really good like I mean I wasn't [23:12] expecting such a big PR but like I mean [23:13] it's new project I guess I guess that's [23:15] fine for now. Yeah, I just took a lot of [23:17] what I'd learned um on [23:20] get working on git packages and took all [23:22] the CLI stuff like you can do some cool [23:25] stuff with Cobra to basically go like oh [23:28] I can generate you a markdown contents [23:30] for a website like if you wanted a [23:31] >> oh wow [23:32] >> a Hugo generated website out of this um [23:35] like I show you the example uh in git [23:39] dash packages where's the website gone [23:44] Um [23:46] this has a command reference which is [23:49] entirely generated [23:51] from um from the CLI as like it just [23:57] goes and vomits out uh markdown files [24:00] into the correct location and then Hugo [24:03] just goes oh here's here's that whole [24:06] thing uh as like individual commands [24:08] with all the flags. Obviously like what [24:10] we have right now is much smaller than [24:12] the amount of different commands in git [24:14] packages, but the it also [24:18] gives you like in easy to generate man [24:22] pages and the automatic help flags as [24:25] well. Um, which is quite nice to just be [24:28] able to kind of like keep all of that [24:31] working as people would expect. So the [24:33] tool is easy to use. Um, and then I also [24:37] cut it up into different pieces rather [24:40] than trying to have one big detector [24:41] file. It's just like, oh, we'll just [24:43] have lots of different ones so it's easy [24:45] for someone to add in one without having [24:47] to kind of just stare at a honking crate [24:49] file of like every different possible [24:52] thing in one place. [24:55] >> Yeah. It seems like the one the last [24:57] thing on this PR is the confidence [25:00] scoring then, right? I think everything [25:01] else has been addressed. [25:03] >> Yes. Yes. [25:04] >> Do we want to maybe just kick that and [25:05] just say like merge this as it is [25:07] because it's kind of our MVP and then [25:09] make a new issue of like hey [25:12] >> scoring based system and sort of discuss [25:14] that further. [25:15] >> Okay, [25:15] >> that would be a good idea. Yeah. Uh I [25:18] can also [25:19] take the same um go release builder uh [25:24] and plug that in if we like so that it [25:26] just starts whenever we tag a release [25:29] then it will build and attach the [25:31] binaries to the release if you will then [25:34] >> that sounds it will make the action [25:37] faster as well because it's like oh I [25:39] just download this from this release [25:43] >> yeah I don't have to do the like go [25:45] install you can do. Obviously, it [25:48] depends on how much you trust. But the [25:50] at least with Go, there's no package [25:52] manager in the middle. It just like is [25:56] all pulled straight from um the Go proxy [26:01] and then built back into GitHub [26:03] releases. It's all pretty transparent. [26:07] Uh I can Yeah, if we make an issue for [26:09] that, I can just basically copy what I [26:13] did before fairly easily. That also [26:17] makes the release notes basically [26:19] automatic as well. [26:21] >> Yeah, I mean I'm I'm like Yeah, I think [26:23] definitely like once now that we've got [26:25] kind of MVP, I think maybe give people a [26:26] little bit of time to kind of test it, [26:28] make sure it works, and make sure this [26:29] is like, hey, this is something we're [26:30] kind of confident releasing as like a [26:32] V0. [26:33] >> We can turn it on for the repo itself [26:36] and see if it labels [26:39] AI contributions as well. [26:51] I need to jump in a couple minutes. Um [26:55] but uh yeah, once we got the project to [26:58] a good starting place, we can definitely [27:00] share this a bit wider, I think, cuz [27:02] people will be interested in [27:06] and maybe even just as a call to um like [27:09] give us more examples of things that we [27:12] could do with uh [27:16] flagging or testing against even if some [27:18] of them we're going to be like, "Oh [27:19] yeah, we're like we've already got good [27:21] tests for that." But just getting like a [27:23] people dumping some examples in would be [27:27] very helpful. And then obviously anyone [27:28] kicking the tires, people are going to [27:30] try and run it in forjo and be like, [27:33] "Oh, it doesn't quite work like this." [27:34] And [27:35] >> yeah, [27:35] >> we can try and shake out some of those [27:37] bits. Some of them might be might be [27:39] difficult. I don't know. We'll see. Uh [27:41] but at least the binary itself would be [27:44] like, "Oh, you can you can download this [27:46] and you can run it in as long as you [27:49] have access to the git repo. [27:54] Yeah, I just I merged your PR by the [27:56] way. I I think I just made a new issue [27:57] from that one comment I had on system. [28:00] And [28:00] >> that's cool. [28:02] >> So yeah, I think we're I think people [28:03] can start testing. I think we can yeah [28:04] start doing some release maybe release [28:07] automation or some of the some of the [28:08] docs automation that I think you were [28:10] talking about. um just get get some [28:12] stuff there so that like as we sort of [28:14] develop this and as we start writing [28:16] content we can kind of give people [28:18] >> Adrian by the way I shared a GitHub link [28:21] uh it's an open source project it's a [28:23] research study that a couple of [28:24] researchers published last year where [28:26] they developed their own data set of AI [28:28] generated pull requests I think it has [28:30] some minor [28:34] >> I'll put that in the meeting notes thank [28:36] thanks for that Um, [28:53] yeah. And I think I think just generally [28:54] if we've got ideas of like, hey, we [28:56] should we should be like if there if [28:59] there's an idea someone has of like, we [29:00] don't know when we're going to do this, [29:01] but let's put on the [29:03] >> Yeah. Get it in the issue tracker. [29:04] People can see it. [29:05] >> Yeah. Yeah. Yeah, there's I think [29:06] there's already I made a project board [29:08] for it. Um, so as long as you just put [29:10] in an issue or or something like that [29:11] and we can kind of track it and start [29:14] kind of labeling stuff. So at least the [29:17] road map is kind of clear and like I [29:19] don't know if we want to start doing [29:20] more like a sprint style like assign [29:21] people stuff or not. But I guess we'll [29:24] see how this how this shakes out. [29:27] >> Uh yeah, sorry. I don't know what [29:28] happened. I don't know. I just [29:29] automatically disconnected. But yeah, I [29:31] think that data I I'll try to take a [29:34] look at the data set sometime soon to [29:36] see if we can you know get some insights [29:38] from there. If we can get some more sort [29:39] of markers or something um some more [29:42] deterministic thing rather than you know [29:44] just some non-deterministic LLM calling [29:47] an LLM to see whether this was written [29:48] by an LM that just doesn't make much [29:50] sense. [29:53] I'm gonna make a detection signal label [29:55] so that we can kind of like if there's [29:56] an issue like oh we should add this as a [29:57] signal or that as a signal we can we can [29:59] kind of label those and just [30:01] >> Y that sounds awesome perfect yeah [30:04] >> great are we going to do another call at [30:07] some point I guess we can just arrange [30:09] that in the Slack [30:11] see how we go [30:12] >> I'm my plan is sort of just to you re [30:14] like do this like so the the Augur 8 not [30:16] call is every other week it sort of [30:17] alternates with the data science working [30:19] group um different link but same time [30:21] slot I think. Um so I think maybe we [30:24] just like do like same thing as this [30:26] every other week. Is that [30:27] >> Yeah, that works. Um and if we can do it [30:30] async and without any like if everything [30:32] seems to be already in the issue tracker [30:34] then that's good too. [30:37] >> Yeah. Sound good? [30:40] >> Thanks everyone. Have a good week. Yeah. [30:42] Have a good day. Thanks guys. [30:45] Cheers. Bye.  📄 **Full text:** ![[Full Document Contents/Articles/CHAOSS AI Detection Project Meeting, Feb 17.md|CHAOSS AI Detection Project Meeting, Feb 17 by YouTube]] ## Highlights - do that. Sweet. So, welcome to the first sort of trial meeting of I guess the chaos AI detection action. I don't know if you want to call it a working group because it's probably not that big, but it's like side side projects that sort of assists like three other working groups. I don't know. Um, yeah, it seems like I think this effort essentially came together just from like this idea. I mean, it seems like this idea I've kind of had this idea for a little while, but I think having talked ([View Highlight](https://read.readwise.io/read/01kpb462qj0pjdcm1dcyjhjs2s)) - Tags: 👻 ai highlighted - been working on this year called Git Packages, which basically is like ecosystems, but you run it locally and it analyzes the history of your dependencies for a given repo. And that is much more interesting to be able to go like, oh, I can run this analysis on a given repo locally. Well, this plugs straight into this detection thing. Um but also then if you want to do analysis of lots of packages locally then it's also very helpful to be able to go through and clone all of those the repos ([View Highlight](https://read.readwise.io/read/01kpb462rcjh6qpy0gyn0a35p6)) - Tags: 👻 ai highlighted - whatever. But I think even just having that be explicitly defined like you you you set up this action on GitHub or wherever and you you say, "Hey, I want AI things to be labeled with this label." I'm sure we could write a a small piece of code in Augur to check if this action is installed, read that config line and then we'll just dynamically use that detect like >> even just the existence of the config. But maybe maybe >> there's other ways to do it too as far like I've seen >> I think there's like the AI there's like ([View Highlight](https://read.readwise.io/read/01kpb462v47tahfd1qpgrdn38b)) - Tags: 👻 ai highlighted - some AI attribution spec I think I linked in one of my issues like maybe maybe it could post a comment with like a string that meets that spec and so we can just scan for that or what like whatever. I don't quite know exactly how we'd be making this data available to like other analysis like broader analysis tools like Augur that would look across whole orgs or whole sets of repos. >> But there there's options and I think I think that'll sort of solidify as we play with this. ([View Highlight](https://read.readwise.io/read/01kpb462zpaybjyng9zp2bekhk)) - Tags: 👻 ai highlighted - kind of confident releasing as like a V0. >> We can turn it on for the repo itself and see if it labels AI contributions as well. I need to jump in a couple minutes. Um but uh yeah, once we got the project to a good starting place, we can definitely ([View Highlight](https://read.readwise.io/read/01kpb46334a9jbsdbbtqjvrwha)) - Tags: 👻 ai highlighted