Augur/8-Knot WG, March 3 2026

๐ **Source:** [Augur/8-Knot WG, March 3 2026](https://www.youtube.com/watch?v=qc000j4r-Ho)
> [!note]+ Document Notes
> tags: #augur #data-pipeline #contributor-resolution #debugging #open-source-analytics
> author: [MISSING]
> source: Zoom Recording
> reference: https://www.youtube.com/watch?v=qc000j4r-Ho
> date created: 2026-03-05 10:30
>
> # ๐ท๏ธ Title: Augur/8-Knot Working Group Meeting - Debugging Contributor Resolution Issues
>
<!-- deep-read:sections start -->
## ๐งฐ Action Inbox
- [H1] Disable affiliations page on production instance โ data accuracy issues #augur
- [H2] Implement keyboard navigation for search functionality โ improve UX #eight-knot
- [H3] Fix contributor profile data collection pipeline โ critical bug #data-pipeline
## ๐งญ 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
- [Augur Repository](https://github.com/chaoss/augur)
- [8-Knot Repository](https://github.com/8-knot/8-knot)
## ๐ Summary
- What happened: Working group meeting focused on debugging critical contributor resolution issues in Augur's data pipeline, plus 8-Knot UX improvements
- Why it matters: Inaccurate contributor data affects research validity and public-facing analytics dashboards
- Key stakeholders: CHAOSS developers, researchers using open source analytics, grant funding prospects
- Risks and tradeoffs: Data quality vs. collection speed; user experience vs. system complexity
- Bottom line: Multiple critical bugs identified in contributor profile data collection requiring immediate fixes
## ๐ Main Content
The meeting addressed two primary technical challenges in open source analytics tooling. First, Augur's contributor resolution system has been failing to collect GitHub profile information despite successfully creating contributor records. This creates a situation where the system has contributor login information but lacks essential profile data like emails, which significantly impacts research quality. The issue appears to stem from timing problems in the data collection pipeline where contributor records are created early but profile information collection happens later and may be failing silently.
Second, 8-Knot's search interface lacks intuitive keyboard navigation, particularly affecting accessibility for keyboard-heavy users. The current design requires mouse clicks to execute searches after selecting repositories, which violates common UX expectations where Enter key should trigger search actions.
## ๐๏ธ Notes
#### โฑ๏ธ [00:00](https://youtu.be/qc000j4r-Ho?t=0) โ [H1] Contributor Resolution Debugging Overview
- Key idea: Team has spent two weeks debugging contributor data collection issues
- Evidence: "We've been doing with contributor resolution for basically the past two weeks since the last meeting"
#### โฑ๏ธ [02:15](https://youtu.be/qc000j4r-Ho?t=135) โ [H2] Data Collection Pipeline Architecture
- Key idea: Contributor events collection happens before profile resolution in separate tasks
- Evidence: "Collect contributor events...that happens after the commits get analyzed and the committers get inserted"
#### โฑ๏ธ [04:30](https://youtu.be/qc000j4r-Ho?t=270) โ [H3] Affiliations Page Accuracy Crisis
- Key idea: Public-facing affiliations data is grossly inaccurate and needs immediate removal
- Evidence: "It is grossly inaccurate and I don't think that until this contributor resolution issue is resolved that page should not be public"
#### โฑ๏ธ [07:45](https://youtu.be/qc000j4r-Ho?t=465) โ [H2] Silent User Discovery
- Key idea: Many more people are using the tools than the team realizes
- Evidence: "I feel like every week learn of more people who are using it relatively regularly and we aren't really aware of them"
#### โฑ๏ธ [11:20](https://youtu.be/qc000j4r-Ho?t=680) โ [H1] Profile Data Collection Failure
- Key idea: System creates contributor records but fails to populate profile information
- Evidence: "You can click the link to their profile and you can see directly in their profile that the information is there and we are not collecting it"
#### โฑ๏ธ [15:10](https://youtu.be/qc000j4r-Ho?t=910) โ [H2] Hourly Profile Update Task Discovery
- Key idea: System runs hourly contributor updates but only updates timestamps, not profile data
- Evidence: "We're making an entire GitHub API call...and we're adding we're populating that data hourly but not using it"
#### โฑ๏ธ [18:30](https://youtu.be/qc000j4r-Ho?t=1110) โ [H3] Coverage Impact Analysis
- Key idea: Fixing profile collection could increase email coverage from 2% to 30-50%
- Evidence: "I'd confidently say 70% of people have an email...I would expect that to go up to 30 to 50"
#### โฑ๏ธ [25:45](https://youtu.be/qc000j4r-Ho?t=1545) โ [H2] Contributor Record Creation Timing
- Key idea: Empty contributor records created early with only username, profile data added later
- Evidence: "We just make a basically empty contributor row entry with just the username and everything else is basically null"
#### โฑ๏ธ [32:00](https://youtu.be/qc000j4r-Ho?t=1920) โ [H3] 8-Knot Search UX Issues
- Key idea: Search interface lacks keyboard navigation support, particularly Enter key functionality
- Evidence: "He didn't know that he was supposed to be clicking on the search icon"
#### โฑ๏ธ [35:20](https://youtu.be/qc000j4r-Ho?t=2120) โ [H2] Multi-Repository Search Complexity
- Key idea: Current design supports multiple repository selection before search execution
- Evidence: "People can want to select multiple things and if you right now pressing enter adds a repository to the search list"
#### โฑ๏ธ [38:15](https://youtu.be/qc000j4r-Ho?t=2295) โ [H3] Proposed Keyboard Navigation Solution
- Key idea: Use dropdown state to determine Enter key behavior - add repo when open, search when closed
- Evidence: "If the dropdown's open enter is going to add the new item. if the dropdown's closed, it's just going to trigger the search"
#### โฑ๏ธ [42:30](https://youtu.be/qc000j4r-Ho?t=2550) โ [H2] Large Repository Performance Fix
- Key idea: Worker callback timeout issues resolved by increasing soft limit timeouts
- Evidence: "The worker's query we had like on the docker compose we had updated before to 10 minutes but then the worker call back it was still like 240 seconds"
#### โฑ๏ธ [45:00](https://youtu.be/qc000j4r-Ho?t=2700) โ [H3] UK Grant Application Update
- Key idea: University College London submitted grant application for Augur development funding
- Evidence: "They just submitted an application for that UK grant research grant thing"
## ๐ References
- [CHAOSS Augur](https://github.com/chaoss/augur)
- [8-Knot Analytics Platform](https://github.com/8-knot/8-knot)
- [GitHub API Documentation](https://docs.github.com/en/rest)
## ๐ฃ๏ธ Paraphrase
- Augur's data collection pipeline has critical bugs where contributor profile information isn't being populated despite successful API calls and record creation
- The affiliations dashboard contains inaccurate data and should be disabled until contributor resolution issues are fixed
- 8-Knot needs better keyboard navigation support to improve accessibility and user experience for search functionality
## ๐ฐ Newsletter
๐ง **Critical Data Pipeline Issues Identified in Open Source Analytics Tools**
The CHAOSS community is addressing significant data quality issues in Augur that affect contributor analytics accuracy. While the system successfully collects commit data, a bug in the contributor resolution pipeline means essential profile information like emails and affiliations isn't being populated.
**Key Impact**: This could improve email coverage from 2% to 30-50% once fixed, dramatically enhancing research capabilities for open source community analysis.
**What's Being Done**: The team is refactoring the contributor resolution system and has temporarily disabled inaccurate public dashboards until fixes are deployed.
Resources: [CHAOSS Metrics](https://chaoss.community/metrics/), [Augur Documentation](https://oss-augur.readthedocs.io/), [8-Knot Platform](https://github.com/8-knot/8-knot)
## โ
Action Items
#### DevRel
- Documentation: Create troubleshooting guide for contributor resolution debugging
- Developer experience: Improve error reporting and logging for data collection failures
- Community engagement: Communicate data quality issues transparently to users
#### OSPO
- Software Inventory: Audit data quality across analytics platforms and dashboards
- Developer Support: Provide training on debugging distributed data collection systems
- Strategic Alignment: Establish data quality KPIs and monitoring for research tools
#### Community
- Contributors: Prioritize data pipeline stability and accuracy over new features
- Maintainers: Implement comprehensive testing for multi-step data collection workflows
#### WordPress
- This content primarily relates to general open source analytics rather than WordPress-specific tooling
#### The WPCC
- Programs: Consider how data quality issues might affect research grant applications
#### FAIR
- Technical independence: Ensure analytics platforms provide accurate, verifiable data
- Governance artifacts: Document data collection methodologies and known limitations
## ๐งช Hypotheses
- Contributor profile data collection fails due to timing issues between record creation and profile resolution tasks
- Multiple silent data collection failures occur due to insufficient error handling and monitoring
- Keyboard navigation improvements will significantly increase accessibility for analytics platform users
- Database contention during heavy collection periods causes rollbacks and missing data
### ๐ Methodology
- Code review of contributor resolution pipeline to identify failure points
- Database analysis comparing contributor records with null profile data against GitHub API availability
- User testing of proposed keyboard navigation improvements with accessibility-focused users
### โ Questions
- How many other data collection pipelines have similar silent failure modes?
- What percentage of current contributor data is actually missing profile information?
- How can the system better handle API rate limits and failure recovery?
### ๐ฎ Future Research
- Comprehensive audit of data quality across all CHAOSS metrics and collection systems
- Development of automated data validation and quality monitoring systems
- Investigation into distributed system reliability patterns for research data collection
### ๐ก Implications
- Practice: Data collection systems need comprehensive error handling and monitoring
- Policy: Public dashboards should include data quality disclaimers and known limitations
- Security: Silent data failures can compromise research integrity and decision-making
- Education: Developers need training on debugging complex data collection pipelines
- Funding: Grant applications may be affected by demonstrable data quality issues
### ๐ง Learning Styles Assessment
Reading level estimate: Grade 12-14 (technical documentation level)
#### ๐ Visual learners
- Present: None mentioned in transcript
- Improve: Architecture diagrams showing data collection pipeline flow, database schema visualization
#### ๐ Aural learners
- Present: Audio meeting format available
- Improve: Recorded debugging walkthroughs with narrated code review
#### ๐ฃ๏ธ Verbal learners
- Present: Technical terminology explained through discussion context
- Improve: Glossary of terms like "facade," "contributor resolution," "upsert"
#### ๐งฉ Kinesthetic learners
- Present: Debugging process involves hands-on code investigation
- Improve: Step-by-step debugging checklist, reproducible test cases
#### ๐ง Logical learners
- Present: Sequential problem analysis and pipeline flow discussion
- Improve: Decision trees for troubleshooting, clear causal relationship diagrams
#### ๐งโ๐คโ๐ง Social learners
- Present: Collaborative debugging discussion format
- Improve: Code review sessions, pair programming for complex pipeline issues
#### ๐งโโ๏ธ Solitary learners
- Present: Individual investigation and analysis components
- Improve: Self-guided debugging worksheets, independent testing scenarios
#### ๐ฟ Naturalistic learners
- Present: Ecosystem thinking about interconnected data collection components
- Improve: Analogies comparing data pipelines to natural systems and flows
### ๐ Accessibility Assessment
#### Screen reader semantics
- Present: Meeting transcript provides text-based access to audio content
- Improve: Structured headings and landmarks for navigation, code snippet alt text
#### Keyboard navigation
- Present: Discussion of keyboard navigation improvements for 8-Knot
- Improve: Ensure all debugging tools and interfaces support keyboard-only operation
#### Contrast and readability
- Present: Plain text meeting transcript with good contrast
- Improve: Syntax highlighting with sufficient contrast ratios for code examples
#### Text resizing and reflow
- Present: Text-based format supports resizing
- Improve: Ensure technical diagrams and interfaces scale appropriately
#### Media and captions
- Present: Full transcript available for audio content
- Improve: Time-synced captions for recorded technical demonstrations
#### Forms and interactions
- Present: Not applicable to this content format
- Improve: Ensure debugging interfaces have proper form labels and error handling
#### Standards reference
- Meets WCAG 2.2 AA for text-based content, improvements needed for technical interfaces
### ๐ DEIB Assessment
#### Cultural breadth
- Present: Discussion of grant funding from UK institution shows international scope
- Improve: Consider how data collection issues might affect global research applications
#### Inclusive language
- Present: Technical discussion uses accessible terminology and explanations
- Improve: Avoid assuming familiarity with specific development environments or tools
#### Neurodiversity support
- Present: Structured meeting format with clear topic transitions
- Improve: Provide meeting agendas in advance, summarize action items clearly
#### Representation
- Present: Collaborative problem-solving approach with multiple perspectives
- Improve: Ensure debugging processes accommodate different cognitive approaches
#### Psychological safety
- Present: Supportive tone when discussing complex technical challenges
- Improve: Acknowledge that debugging distributed systems is inherently difficult
### โ
Logical Validity
#### Strong reasoning
- Deductive strength: Clear logical flow from symptoms (missing data) to potential causes (timing issues)
- Inductive strength: Pattern recognition across multiple repositories and data points
- Causal reasoning: Systematic elimination of potential failure points in pipeline
- Analogical strength: Comparison to known database contention patterns
#### Fallacies
- Hasty generalization: Assuming all missing data has same root cause without comprehensive analysis
- False dilemma: Presenting scheduler changes as either necessary or unnecessary without considering partial solutions
#### Tone of voice
- Overall tone: Collaborative problem-solving with appropriate technical focus and urgency for data quality issues
### ๐ก๏ธ DARVO Analysis
- Deny: No denial patterns observed - team acknowledges data quality issues transparently
- Attack: No attacks on users reporting issues - constructive response to feedback
- Reverse victim/offender: No victim/offender dynamics present in technical discussion
- Emotional cues and rhetoric: Professional, solution-focused language throughout
## ๐ฏ Conclusion
The meeting revealed critical data quality issues in Augur's contributor resolution pipeline that require immediate attention. The team demonstrated strong collaborative problem-solving by immediately disabling inaccurate public dashboards and systematically debugging the collection process. The parallel work on 8-Knot's accessibility improvements shows commitment to inclusive design. Success will require both short-term fixes for data collection and longer-term improvements to system monitoring and error handling.
## ๐งฑ Refactor Appendix
### ๐ Literature Split Pad
Purpose: Stage CEE units that become Literature notes.
Split level: H3
### [H1] Distributed data collection systems require comprehensive error monitoring
> [!quote] Augur/8-Knot WG Meeting by [MISSING] via Zoom Recording. Published 2026-03-03. Accessed 2026-03-05.
> "We're making an entire GitHub API call...and we're adding we're populating that data hourly but not using it."
Demonstrates how complex data pipelines can have silent failures where API calls succeed but data isn't properly utilized.
[view highlight](https://youtu.be/qc000j4r-Ho?t=910#H1) #
---
## Full Transcript
[00:00] We are recording now.<br>[00:02] >> Sweet. So yeah, we're just talking about<br>[00:03] the uh some of the debugging we've been<br>[00:05] doing with contributor resolution for<br>[00:06] basically the past two weeks since the<br>[00:08] last meeting. Um but yeah, I think I<br>[00:12] think generally the overall sequence of<br>[00:13] facade is basically like one of the<br>[00:16] first tasks is it's named deceptively.<br>[00:20] Its function is basically to collect<br>[00:22] contributor events. So that's querying<br>[00:25] the GitHub events API which is not<br>[00:26] really relevant to what we're doing.<br>[00:29] Um, other than the fact that that task<br>[00:31] is named such that I thought it was<br>[00:32] collecting contributors and I think that<br>[00:34] task does insert contributors because I<br>[00:37] imagine it would need something to<br>[00:38] reference the events to but I don't<br>[00:42] think it's it's not gathering it's its<br>[00:43] purpose is not to gather the profile<br>[00:45] information because that happens after<br>[00:48] that happens the commits get analyzed<br>[00:51] and the committers uh get like inserted<br>[00:54] and then we do the contributor<br>[00:55] resolution where we look at the commit<br>[00:57] like the commits table and we try and<br>[01:01] find either using using the various a<br>[01:03] couple of couple different GitHub APIs<br>[01:06] to try and get a GitHub username to get<br>[01:07] their profile to get the rest of the<br>[01:09] information. Um, and it's that that sort<br>[01:12] of after the commits are being<br>[01:14] processed. That's sort of the part I've<br>[01:15] been focusing on for the last probably<br>[01:18] week or so. Um, and that's that's I<br>[01:21] think I've been we've been running a bit<br>[01:23] of a a sort of hot fix branch um to with<br>[01:27] some just sort of quick changes to try<br>[01:29] and get things up and running again. And<br>[01:31] then also in parallel, I've been doing<br>[01:34] some more reworking of like trying to<br>[01:36] just organize the process a little bit<br>[01:38] better for contributor resolution anyway<br>[01:40] so that we can so that it's it's easier<br>[01:44] to sort of have a known like hey we need<br>[01:47] to make these calls to GitHub and like<br>[01:50] it's it's you don't have to jump between<br>[01:52] three different files to read it and<br>[01:54] also I'm going to need to rework it<br>[01:56] anyway if if we're going to be adding<br>[01:58] more PL like making the contributor<br>[01:59] resolution work for Git. lab, work for<br>[02:01] 4G, work for any new platforms we want<br>[02:03] to add in the future. Um,<br>[02:07] I think that's largely been what I've<br>[02:08] been focusing on. Like a like how do we<br>[02:11] how do I make sure that Callie's not<br>[02:13] blocked on the analysis she needs to<br>[02:14] deliver, but also like how do we sort of<br>[02:19] make learn from this and figure out<br>[02:22] like, okay, how do we make Augur more<br>[02:24] resilient to like, hey, we found a data<br>[02:27] collection error. Like I've been<br>[02:30] starting to think about like backups and<br>[02:33] other things, other tools that are going<br>[02:34] to help us have things like this that<br>[02:36] happen in the future not be as bad.<br>[02:39] >> Um yeah, a quick question for um Tom.<br>[02:42] Have you taken down the affiliations<br>[02:45] page for the um for y'all's instance of<br>[02:49] of 8 yet?<br>[02:51] >> No. you I I would appreciate if you did<br>[02:56] >> because it is grossly inaccurate and I<br>[02:58] don't and yeah I think that until this<br>[03:01] contributor resolution issue is resolved<br>[03:03] that page should not be public.<br>[03:08] Yeah, I put a patch in the in one of our<br>[03:10] uh Slack channels, Sean, for it's like a<br>[03:12] it's like a small git patch you can like<br>[03:15] just throw up and rebuild the container<br>[03:17] or how I don't know how.<br>[03:19] >> Oh, okay. So,<br>[03:20] >> like you just I just removed it from the<br>[03:21] navbar. Like the page is still there.<br>[03:23] It's just not visible in the navbar. So,<br>[03:25] it's it's<br>[03:26] >> which branch which branch would I pull<br>[03:28] because that's how I do it. Uh it's I<br>[03:31] think I think I did make a PR on 8 knot<br>[03:33] that never got merged. Um let me go find<br>[03:36] it.<br>[03:38] Yeah, I I don't have time to go through<br>[03:40] eight not and do an edit, but I can pull<br>[03:42] a new branch down and run it.<br>[03:45] >> You How up to date is your<br>[03:48] I think this branch might be based on de<br>[03:51] our dev branch. So, I'm not sure.<br>[03:54] >> I mean, I think that's a good thing. I<br>[03:56] mean,<br>[03:58] >> that it's based on dev.<br>[03:59] >> Yeah.<br>[04:00] >> Yeah, I think it is. And I was it was<br>[04:03] this year that I updated it last I want<br>[04:06] to say toward the end of January cuz I<br>[04:09] was making sure it was up to date before<br>[04:10] Chaos Con.<br>[04:12] >> Yeah. So there's probably not very many<br>[04:13] changes since then.<br>[04:14] >> I put it in Zoom chat. It's the disabled<br>[04:16] affiliations branch.<br>[04:18] >> Um yeah because I but sorry to derail<br>[04:22] from what you were saying Adrian. I just<br>[04:24] really wanted to make sure this is um<br>[04:27] because this is interrelated. Um,<br>[04:31] I think if anything I'm realizing that<br>[04:34] we have more silent users that I think<br>[04:37] we realize. Um, and<br>[04:42] >> what's leading you to that? Like are you<br>[04:43] seeing people kind of talk about this<br>[04:45] data stuff?<br>[04:46] >> Yeah. I mean there's like I'm just I<br>[04:48] feel like I'm on calls or oh you found<br>[04:51] that one person that's a super user and<br>[04:53] then I'm on another call and somebody's<br>[04:54] mentioning using eight non a combination<br>[04:57] to claude. like it just seems like every<br>[04:59] week learn of more people who are using<br>[05:04] it relatively regularly and we aren't<br>[05:07] really aware of them and so I think it's<br>[05:10] worth like I that's why<br>[05:13] >> people looking at eight not<br>[05:14] >> yes<br>[05:17] um and so I just think that's why I<br>[05:19] think that it is important um for us to<br>[05:22] take take this down<br>[05:24] >> wrong data yeah<br>[05:25] >> yeah because then like realistically<br>[05:27] We're no better uh no better than LFX<br>[05:30] insights right now like whenever it<br>[05:33] comes to this stuff.<br>[05:35] >> Yeah. I mean affiliation data has always<br>[05:38] been something that needs to be you need<br>[05:41] to have a map of what the affiliations<br>[05:44] are<br>[05:46] for people.<br>[05:48] So what we<br>[05:50] >> I guess for us we're just we're not we<br>[05:53] are not holding up to the stand to the<br>[05:56] what we say the data is right now and so<br>[05:58] I don't think that those visualizations<br>[06:00] should be up. I think it's kind of as<br>[06:01] simple as that. Um but kind of going<br>[06:05] back to to the collection<br>[06:08] um yeah that makes sense Adrian. I guess<br>[06:10] we can just wait it out. It does sound<br>[06:13] like that there are API calls in that<br>[06:15] chain and so it might still be<br>[06:18] beneficial for you like there are a lot<br>[06:20] of API keys that are not being used<br>[06:22] right now. Um, so something to consider,<br>[06:27] um, especially when we're going it's<br>[06:29] going through and doing all the<br>[06:30] contributor resolution because I<br>[06:32] remember um, Sean mentioning that there<br>[06:35] is a different API rate limit for this<br>[06:39] and so having one API key is going I<br>[06:42] would<br>[06:43] >> limits the search API that that's um<br>[06:46] that is true but that that is our second<br>[06:49] and less reliable anyway method of<br>[06:51] trying to find a username. So,<br>[06:54] >> I'm not talking about username. I'm<br>[06:55] talking about GitHub profile<br>[06:57] information.<br>[06:58] >> The GitHub profile information that<br>[07:00] that's just the that's what the regular<br>[07:02] I don't I don't think that has a<br>[07:03] separate API limit because that's just<br>[07:05] users endpoint, right?<br>[07:06] >> Uh um so<br>[07:11] yeah, I don't I I'd have to look at what<br>[07:13] API we're using<br>[07:14] >> commits API and everything else.<br>[07:15] >> I do want to Yeah,<br>[07:17] >> sorry. I do want to understand a little<br>[07:19] bit better about missing profile<br>[07:22] information. So the contributor is it<br>[07:26] that the contributor wrote does not<br>[07:27] exist, Kelly?<br>[07:29] >> No, it said that the that I go through<br>[07:31] and I can look through any of the<br>[07:33] entries of the login. You can click the<br>[07:35] link to their profile and you can see<br>[07:38] directly in their profile that the<br>[07:40] information is there and we are not<br>[07:42] collecting it.<br>[07:46] So it just hasn't made it from GitHub's<br>[07:48] API to our database yet.<br>[07:49] >> Yeah.<br>[07:50] >> Yeah.<br>[07:50] >> So you're talking about like the URLs,<br>[07:53] the gravitars,<br>[07:55] the<br>[07:55] >> Yeah. I mean, or look at their login.<br>[07:58] It's just that it's quick to get to it.<br>[07:59] I'm just saying that if you look at the<br>[08:01] at the profile for the login for any<br>[08:04] contributor row, I can send over a<br>[08:07] couple of different examples that I've<br>[08:09] I've seen, but it doesn't really you<br>[08:12] could click, at least from what I've<br>[08:13] seen, it doesn't take very long to to<br>[08:16] find an example. It usually takes me<br>[08:18] looking at one or usually yeah, one,<br>[08:21] two, maybe three entries and then I can<br>[08:23] find an instance of what I'm talking<br>[08:25] about. Um, if you give me a second, I<br>[08:27] can switch to my computer and just show<br>[08:29] examples.<br>[08:29] >> Yeah, I've got I've got my contributors<br>[08:31] table open right now and I see, you<br>[08:34] know, obviously different levels of the<br>[08:36] profile being filled out.<br>[08:39] >> Start clicking on somewhere there's no<br>[08:41] basically no profile information. Like<br>[08:43] it's all null. If you go to one of the<br>[08:45] links, like I think what Callie's saying<br>[08:46] is that she's gone to three or four of<br>[08:48] them and within that she'll she's been<br>[08:51] able to find like<br>[08:53] >> fairly consistently. Just give me a<br>[08:54] quick second. I'm going to switch<br>[08:56] devices.<br>[08:57] >> Okay.<br>[09:00] One thing I also noticed too when I was<br>[09:02] kind of looking through this, I I might<br>[09:04] maybe I should repeat this when Kelly<br>[09:05] gets back, but um in trying to just sort<br>[09:07] of double check my understanding of that<br>[09:09] sort of earlier sort of pre-commit<br>[09:10] processing step of facade um or I don't<br>[09:14] know what it I was looking into<br>[09:15] something and I found a a task that we<br>[09:18] are running on an hourly basis that<br>[09:19] looks through contributors and fetches<br>[09:21] profile information. Like we're updating<br>[09:23] contributors supposedly hourly, but<br>[09:26] we're only doing it for the created at<br>[09:28] and last used time stamp fields.<br>[09:32] >> So we're making an entire GitHub API<br>[09:34] call to that same endpoint we're getting<br>[09:37] the profile data from. and we're we're<br>[09:40] in we're we're adding we're populating<br>[09:41] that data hourly but not using it like<br>[09:44] we're not we're fetching the data and<br>[09:46] then throwing it away.<br>[09:48] So that might be another cool place to<br>[09:50] try like to potentially fix that task.<br>[09:53] I'm currently working on that um to fix<br>[09:56] that task so that we can get like maybe<br>[10:02] it's it's not necessarily directly from<br>[10:04] the Jupiter resolution but it's that<br>[10:06] other process that we already have for<br>[10:08] populating that data.<br>[10:10] >> All right.<br>[10:11] So in my my understanding of theuler is<br>[10:15] that it does not have like tasks running<br>[10:19] hourly that everything is run as a as a<br>[10:22] sequence.<br>[10:25] >> We do have a couple I mean we have<br>[10:27] there's the tasks that like refresh the<br>[10:28] materialized views and stuff that do get<br>[10:30] run<br>[10:31] >> yeah more fixed time schedules. So this<br>[10:34] this is another one of those like it's<br>[10:35] sort of a separate<br>[10:37] >> class of tasks<br>[10:39] >> but there is one that populates this<br>[10:41] data that we are not using like to the<br>[10:44] fullest extent that we I think should<br>[10:46] be.<br>[10:47] >> And you're sure it's getting run?<br>[10:49] >> Uh I have not 100% checked. I need to<br>[10:53] see if I've even I'm really hesitant to<br>[10:56] I don't want to touch my local instance<br>[10:58] because that's what's trying to populate<br>[10:59] our little backup DB right now. Um, if I<br>[11:03] forgot to start flower, then I won't.<br>[11:05] Yeah, I don't think I started flower.<br>[11:08] Um,<br>[11:12] I don't know if there's a way to see<br>[11:14] which tasks have run without flower.<br>[11:16] Okay, I might I might do some spelunking<br>[11:20] through rabbit MQ commands in a bit to<br>[11:23] try and find that. But<br>[11:25] um it's if if someone's got a instance<br>[11:27] that's got collection running, which I<br>[11:29] sort of doubt at this point, um it is<br>[11:33] the<br>[11:36] process contributors task.<br>[11:40] Um<br>[11:44] I'll see if I can double check that's<br>[11:45] what it's actually going to show up as,<br>[11:50] but it's it's referenced in celery<br>[11:51] app.py.<br>[11:53] um as a as a periodic task.<br>[12:03] >> Yeah, this I mean I think I think a lot<br>[12:06] of this will become easier to manage and<br>[12:08] a little bit a lot more clear when we<br>[12:10] have a the job scheduler<br>[12:12] um as a bit more transparent. Like from<br>[12:16] my perspective, a lot of what we're<br>[12:18] talking about could be fixed much more<br>[12:20] quickly and deterministically if we<br>[12:23] dealt with the job scheduler.<br>[12:25] >> I mean, yes, but I don't think we should<br>[12:27] wait for that cuz this this is this has<br>[12:30] been actively<br>[12:32] >> putting bad data into augur databases<br>[12:34] for months.<br>[12:37] >> I'm not suggesting that we wait for it.<br>[12:39] I'm suggesting that a lot of the<br>[12:41] conversation that we're having about the<br>[12:42] full population of contributor data and<br>[12:46] periodic tasks and how they run and when<br>[12:48] they run, if we go and deal with the job<br>[12:51] scheduler, I think that we will be able<br>[12:53] to speak more authoritatively.<br>[12:56] >> Uh maybe maybe as far as the scheduler<br>[12:58] goes, I think the the tasks themselves<br>[13:00] seem to be getting run. So I'm not<br>[13:03] >> like<br>[13:04] >> I'm not worried about<br>[13:06] >> the dual source of truth thing with<br>[13:07] celery. Yeah, sorry for interrupting<br>[13:10] Andrew, but yeah, like I guess the as<br>[13:12] this debugging process has been going<br>[13:14] through, I don't think we've hit a<br>[13:16] single point where the problem is<br>[13:19] because of scheduling. There's always<br>[13:21] been an actual bug in the code that has<br>[13:26] caused these data issues. So, I'm not<br>[13:29] the scheduler is not really the um or at<br>[13:32] least up until this point has not been<br>[13:34] the source of the problem.<br>[13:37] Well, part of me wonders too like like<br>[13:39] if like if it is largely largely sort of<br>[13:43] just various bugs or tech debt or<br>[13:46] whatever with our tasks like if we even<br>[13:48] if we did have theuler thing ready now<br>[13:51] and if it was all we we had the admin<br>[13:54] page to replace flower and all that like<br>[13:58] if we ship theuler and still have<br>[14:00] problems like this<br>[14:02] like<br>[14:04] we like I mean obviously that'll give us<br>[14:06] more information on hey it wasn't maybe<br>[14:07] it wasn't theuler but it it's also kind<br>[14:10] of maybe muddying things a bit because<br>[14:14] like how do we know like unless we ship<br>[14:16] theuler with very solid testing it's<br>[14:19] going to be hard to tell like what did<br>[14:21] did did anything theuler introduced make<br>[14:24] this worse activate any new bugs<br>[14:26] anything like that so I think we just<br>[14:29] need to be thorough in our testing<br>[14:32] basically<br>[14:33] >> so what what I'm observing is we spend a<br>[14:36] lot of time trying to understand and and<br>[14:39] identify these bugs<br>[14:42] when we discover them or identify what's<br>[14:44] what's going wrong<br>[14:47] and it takes I think a lot longer<br>[14:49] because there is less certainty we don't<br>[14:51] have the certainty that I think we need<br>[14:53] to know when these things are being run<br>[14:56] so it for me when I run my instance of<br>[14:58] augur<br>[15:00] I don't like I'll see things get run but<br>[15:04] And sometimes I have to restart augur to<br>[15:06] go from core to secondary for a large<br>[15:08] collection or to go from secondary to<br>[15:11] facade for a large collection. And so<br>[15:14] knowing when and how everything is run<br>[15:17] for a repo, these questions that we<br>[15:20] started out with, Adrian, where you<br>[15:21] weren't sure how to describe how far<br>[15:24] along you were with PyTorch,<br>[15:26] all of that sort of<br>[15:28] >> Yeah. these questions that cloud the<br>[15:30] debugging do emerge from the<br>[15:34] non-deterministic nature of a<br>[15:35] distributed scheduler.<br>[15:37] >> I guess I just don't see that to be I I<br>[15:40] see many other I guess I just don't see<br>[15:41] that to be that big of a deal in this<br>[15:43] instance. I'll be honest like with like<br>[15:44] the last two weeks of this process, the<br>[15:46] scheduling and the ordering of this as<br>[15:49] Adrian has done the vast majority of the<br>[15:51] work so I don't want to but from my<br>[15:53] point of view from the um debugging of<br>[15:56] it um the scheduler has pretty much not<br>[15:59] been a part of the discussion at all nor<br>[16:01] a part of like the the solutions of<br>[16:03] making things better.<br>[16:04] >> I think the schedule change would be<br>[16:06] like it's a helpful change on its own. I<br>[16:08] don't think it's necessar like some of<br>[16:11] the other some of the other like things<br>[16:12] that we've I think some of the like<br>[16:14] facade issues there's other issues that<br>[16:15] we've noticed where like hey these two<br>[16:18] problems are a lot closer connected or<br>[16:20] like hey this is what's actually causing<br>[16:21] that. Um I I think this is sort of not<br>[16:24] that case where like I think yeah<br>[16:26] scheduler is a good change the this is a<br>[16:28] good change but I I think they're less<br>[16:30] closely linked then maybe the<br>[16:32] scheduleuler is linked to other other<br>[16:34] issues but yeah I mean more more like if<br>[16:37] if if someone's help like if Andrew is<br>[16:39] helping out with auler like that's more<br>[16:40] like I'll take someone working on any<br>[16:43] augur issue and like more more I think<br>[16:45] that's kind of our main bottleneck right<br>[16:46] now is more dev time on augur um I think<br>[16:51] because I think there's a a lot of like<br>[16:52] we've got like I've been I've been<br>[16:54] filing issues pretty regularly and we're<br>[16:56] up to like 200 and something like of<br>[16:57] just things people have noticed that<br>[16:59] like hey we might need to might want to<br>[17:01] fix this in the future and they might<br>[17:02] they're in various stages of whatever<br>[17:04] but<br>[17:05] like yeah I think I think trying to just<br>[17:08] really work through a lot of that a lot<br>[17:10] of those identified issues I think is<br>[17:12] going to really help like in our in our<br>[17:15] kind of goal to stabilize augur<br>[17:18] >> could you share the data that's<br>[17:20] populated in the rows for those<br>[17:21] contributors that you shared.<br>[17:23] >> It's not pretty. The data is like I can<br>[17:26] just show you the screen. They're all<br>[17:27] the I've just I'll show you what I'm<br>[17:29] looking at.<br>[17:30] >> You have an issue for this, right,<br>[17:31] Kelly? You want me to put those examples<br>[17:33] in it?<br>[17:34] >> No, I mean that issue is not remember<br>[17:36] this is that issue that I opened is not<br>[17:38] describing this problem. That issue is<br>[17:40] talking about going forward um regularly<br>[17:44] um reviewing the GitHub profile<br>[17:46] information. So, I would say if you want<br>[17:49] me to open an issue specifically for a<br>[17:50] bug that's different than the issue that<br>[17:52] I opened yesterday.<br>[17:54] >> Oh, I was just curious if there was an<br>[17:55] issue for like that I could put these<br>[17:57] examples in so they don't get lost when<br>[17:58] we end the meeting.<br>[18:00] >> I would say it's a part of like if you<br>[18:02] want me to make a sub issue, I can, but<br>[18:04] it's just the larger one that I had<br>[18:06] opened I guess like a week or two ago.<br>[18:08] Um, but if you would like to make what<br>[18:10] if you would like me to have a smaller<br>[18:12] like to make a more specific issue, I<br>[18:14] can.<br>[18:18] Um, so if you look at this is not all of<br>[18:23] these have GitHub profile information,<br>[18:25] but a lot of them do. And it's just<br>[18:30] all of these are just null.<br>[18:31] >> Wow.<br>[18:33] So,<br>[18:38] >> so if we look at this like view, I I<br>[18:40] kind of manually went through each one<br>[18:41] of these. Probably about 10 of them,<br>[18:45] 10 to 15 of them have actually have<br>[18:47] profile information that we don't have<br>[18:49] anything of. And that's why uh yeah,<br>[18:52] that's kind of what I've been looking<br>[18:54] at. Um say I think we have the the<br>[18:58] profile information is such lowhanging<br>[19:00] fruit that I think will make the<br>[19:01] coverage that we have of especially<br>[19:03] emails and just overall information<br>[19:05] about our contributors um like I would<br>[19:08] expect us to go up to whenever it comes<br>[19:11] to more corporate um repositories you're<br>[19:14] seeing like<br>[19:16] I'd confidently say 70% of people have<br>[19:20] an email like some really identifying<br>[19:22] things in their in their um profiles.<br>[19:26] I'd say generally like right now we're<br>[19:28] at like what 1% 2% um of the people have<br>[19:32] data in these in like their email field.<br>[19:35] I would expect that to go up to 30 to 50<br>[19:38] with um the login information like if<br>[19:42] we're going to get the not the login but<br>[19:44] the um GitHub um profile information for<br>[19:49] the related login.<br>[19:52] So we you said we're at like one or two%<br>[19:53] now. Would would we does that make sense<br>[19:56] as far as because right now this<br>[19:57] instance only is collecting on the<br>[19:59] default repos and PyTorch. Do we think<br>[20:02] that it it like<br>[20:04] >> should be higher? Yes.<br>[20:06] >> Well, of course it should be higher.<br>[20:07] Like I'm I'm curious like<br>[20:10] because the chaos repos in this instance<br>[20:12] are basically fully collected. There's<br>[20:14] one that I think is still pending facade<br>[20:16] but and that was last I checked a little<br>[20:18] while ago. Yeah, the chaos repos are<br>[20:21] pretty small compared to PyTorch.<br>[20:22] >> So like do we like I imagine in Yeah,<br>[20:25] because right now we're looking at<br>[20:26] number of contributors. So I imagine<br>[20:27] PyTorch probably has 50 times number of<br>[20:30] contributors that the cha the default<br>[20:32] repos do<br>[20:34] >> um<br>[20:34] >> at least. So I I I' I'd be interested to<br>[20:38] kind of see<br>[20:39] like can we break this down like look at<br>[20:42] like of of and maybe we just do it with<br>[20:46] spot checks but like of the examples we<br>[20:48] have where there's a null in the<br>[20:50] database but we can go on github.com and<br>[20:53] see there's profile information there<br>[20:54] for us to be getting like are all of<br>[20:58] those that we're spot checking coming<br>[21:00] from PyTorch or they like can we try and<br>[21:02] look specifically for Chaos<br>[21:03] contributors?<br>[21:04] I can say that they're not just from pe<br>[21:07] the ones that I'm like I'll look at<br>[21:08] people's profiles and I recognize them<br>[21:10] from Chaos. I can get like a better I<br>[21:12] don't have I don't have the number, but<br>[21:14] I can say um pretty definitively that<br>[21:17] there are profiles that are present and<br>[21:21] from Chaos that do not have their<br>[21:24] profile information populated, but I can<br>[21:28] like give me some time in the afternoon.<br>[21:30] And what I'm planning on doing is<br>[21:33] looking at each of the of the like<br>[21:36] probably just go through PR um events<br>[21:39] and look at the contributor ids for the<br>[21:42] chaos repositories and join it on the<br>[21:45] contributor table. And so we can see how<br>[21:49] many of those distinct um contributors<br>[21:52] have profile information. can pretty<br>[21:54] much do what I did here and I can give<br>[21:56] you a little bit of a better like what's<br>[21:58] the coverage. Um, but I can confidently<br>[22:01] say that yes, there are contributors<br>[22:05] that are coming from Chaos that are not<br>[22:07] having their profile information um,<br>[22:10] populated.<br>[22:12] >> I think we need to look at which job is<br>[22:15] filling out the profile information.<br>[22:18] >> It's basically contributor resolution,<br>[22:19] >> is it? Yeah, that's that's what I've<br>[22:21] been looking at for the last<br>[22:22] >> So, it's supposed to be populating all<br>[22:24] those fields.<br>[22:25] >> Process commit metadata is the function<br>[22:26] that does it. It's I think it gets<br>[22:29] called in let me check. Um, it gets<br>[22:33] called in insert facade contributors<br>[22:35] which I think is just its own task.<br>[22:38] Uh, I think it runs towards the end of<br>[22:41] facade.<br>[22:44] Um,<br>[22:46] sorry, what was your I think you just<br>[22:48] had a question.<br>[22:49] I think I'm good.<br>[22:51] >> Okay. But yeah, that's that's sort of<br>[22:53] the process. So I've I've been I like in<br>[22:55] in looking at a lot of this contributor<br>[22:57] resolution like it's been jumping<br>[22:59] between files. And so that was sort of<br>[23:01] like we we call functions that then<br>[23:03] build the URL that then do another<br>[23:05] database access for information we<br>[23:08] pretty much already have. Like it's just<br>[23:10] spread it's very spread out and hard to<br>[23:13] follow. So, I've been I've been sort of<br>[23:14] just moving stuff around and um trying<br>[23:18] to also make better use of we already<br>[23:20] have like a class like a helper class in<br>[23:22] that sort of section of the facade code<br>[23:24] for accessing GitHub. So I've been<br>[23:26] trying to kind of move a lot of the<br>[23:28] GitHub specific like API calls and URL<br>[23:32] building and stuff into that existing<br>[23:34] class so that um like it bo organizing<br>[23:40] the code and also sort of creating a<br>[23:42] better defined line of like okay here is<br>[23:44] this defined interface between okay now<br>[23:48] we're going to go into the platform<br>[23:50] specific part so that then we can just<br>[23:53] write another class for forgio or<br>[23:54] whatever implement those methods and<br>[23:56] it'll just sort of be dropped in.<br>[23:59] >> Okay.<br>[23:59] >> So, that that's kind of my my plan with<br>[24:01] with sort of refactoring it.<br>[24:02] >> Yeah,<br>[24:03] >> I'm just doing that on a branch on my<br>[24:04] personal fork of Ago right now.<br>[24:06] >> But, okay, I'll I'll try and clean it up<br>[24:08] and organize it, make it a PR at some<br>[24:10] point soon.<br>[24:11] >> And and I've been I've been tackling the<br>[24:13] commit resolution issue from a step<br>[24:16] outside of Augur. What's missing? What<br>[24:19] do we need to get? And so Cali pointing<br>[24:22] out some of these fields that aren't<br>[24:23] getting populated is helpful because now<br>[24:26] I understand there's<br>[24:30] what I'd like to understand is where are<br>[24:32] we creating a contributor row and not<br>[24:36] filling in that data? That seems like<br>[24:40] >> that's the same place I'm at. Yeah,<br>[24:42] because that seems like that seems like<br>[24:44] there's some very simple candidly dumb<br>[24:47] thing that we did perhaps because every<br>[24:50] time we make a a call to try to<br>[24:53] reconcile the commits API to try to<br>[24:56] reconcile the the contributor on a<br>[24:58] commit and put it in the contributor<br>[25:00] table or match it to an existing<br>[25:01] contributor in the contributor table.<br>[25:05] When we when we do that, we could get<br>[25:07] all the data for that contributor. And<br>[25:09] so somewhere we're not because why would<br>[25:13] we create that row if we don't have that<br>[25:16] data?<br>[25:17] >> I just hit the exact same there. There's<br>[25:21] messages to me like to Adrian our team<br>[25:23] chat that pretty much just that is the<br>[25:25] exact place that I have been today is is<br>[25:30] is going down that logical line of is it<br>[25:32] but I think the thing is that Adrian's<br>[25:34] saying is that the contributor<br>[25:37] >> is being inserted during other tasks<br>[25:41] because it needs to be able to reference<br>[25:43] to the contributor ID and then the<br>[25:45] contributor resolution comes around<br>[25:47] later to do the login stuff and so<br>[25:50] That's where the idiosyncrasies come.<br>[25:53] Um, but I should stop speaking for<br>[25:55] Adrian.<br>[25:56] >> I'm actually tracing that through. I'm<br>[25:57] actually I what I said earlier about it<br>[25:59] being an earlier step of the facade.<br>[26:01] Like, yeah, we do have a a spot that<br>[26:03] collects<br>[26:04] um<br>[26:06] contributor like events. I'm trying to<br>[26:08] find where that is in the code right<br>[26:09] now, but I realize it's not earlier in<br>[26:12] facade where I thought it was. It's<br>[26:13] probably like core or something. Um, if<br>[26:16] the events API would be hit by core or<br>[26:18] secondary, I' I'd have to look, but it<br>[26:21] it that shouldn't I wouldn't expect that<br>[26:23] to be happening in facade. I won't say<br>[26:24] it shouldn't be. Um,<br>[26:27] >> it looks like process contributors.<br>[26:30] Uh, no, that's the other fun. That's a<br>[26:33] different thing I was looking at before.<br>[26:35] >> Um, but yes, this is the rabbit hole<br>[26:37] that I've been wanting to go down of<br>[26:39] just at least we could understand it.<br>[26:42] Well, and I think you know some of the<br>[26:44] there are several threads inside of<br>[26:46] Augur that are dealing with contributor<br>[26:48] data. One of those I think my guess is<br>[26:52] one of them is filling in some small<br>[26:54] part of it that it needs but not getting<br>[26:57] the the rest of it while it's there. And<br>[26:59] then some other part of it is saying<br>[27:01] I've already got it when it when it goes<br>[27:03] and looks for that contributor. So it's<br>[27:05] not so somewhere something's adding that<br>[27:07] contributor without adding all the data.<br>[27:09] And then that's shortcircuiting wherever<br>[27:11] we're supposed to be or trying to add<br>[27:13] all the data. Do you understand what I'm<br>[27:14] saying?<br>[27:16] >> I don't think it's necessarily<br>[27:17] shortcircuiting, but it it's Yeah, like<br>[27:19] we're definitely inserting it sounds<br>[27:21] like we're inserting like an like a like<br>[27:23] we we collect the events for the like<br>[27:28] contributor events. We need we have the<br>[27:30] username of the contributors at that<br>[27:32] point. So we just make a basically empty<br>[27:34] contributor row entry with just the<br>[27:37] username and everything else is<br>[27:38] basically null so that we can have an ID<br>[27:41] to reference for the events and then<br>[27:43] later on we have it it goes through and<br>[27:45] populates it. So I think yeah adjusting<br>[27:48] the order like figuring out exactly what<br>[27:50] task that first part happens in and<br>[27:53] maybe like filling in more of the<br>[27:56] details. I so the reason I'm suggesting<br>[27:59] that is because I I suspect that at the<br>[28:02] point that we first inserted the<br>[28:04] contributor data, we assumed that that<br>[28:07] process would happen first and whatever<br>[28:10] process is trying to insert the full<br>[28:13] amount of contributor data for those<br>[28:15] fields that is getting run in seems like<br>[28:18] in many cases after we're just trying to<br>[28:21] reconcile the contrib to the commit.<br>[28:25] And so when we do that, we're finding<br>[28:27] the contributor already exists and we're<br>[28:29] not filling it in. So<br>[28:31] >> I don't see anything in the contributor<br>[28:33] resolution that would that would<br>[28:34] necessarily break in that case. Like I<br>[28:37] think<br>[28:37] >> like when we do contributor resolution,<br>[28:39] is it trying to insert all the fields?<br>[28:41] >> Yeah. So what we do is we basically we<br>[28:44] we grab a list of every like all the<br>[28:47] commits that haven't been looked at yet<br>[28:49] like commit emails and stuff like we<br>[28:51] basically do a big big SQL query to grab<br>[28:54] contributor like things that we need to<br>[28:57] process for contributor resolution and<br>[28:59] then we'll we'll look up um<br>[29:03] basically the the first part of it is<br>[29:05] like looking up the trying to look up<br>[29:06] the GitHub username from because this is<br>[29:08] coming from facade so it's looking from<br>[29:10] the commits<br>[29:12] trying to use either the commit hash or<br>[29:13] the email to find the username and then<br>[29:15] it's it builds a giant JSON object of<br>[29:18] basically all the columns in the<br>[29:20] contributors table.<br>[29:22] After it finds the username, it'll query<br>[29:23] the GitHub API, get information, and<br>[29:25] then fill in that big dictionary and<br>[29:27] then it'll probably I think it runs it<br>[29:29] through<br>[29:30] >> I don't know which of we have several<br>[29:32] different functions for adding things to<br>[29:33] the database. I'm fairly sure it runs it<br>[29:36] through one of our more standard ones<br>[29:39] that like would do like a proper upsert<br>[29:41] like it would actually like okay if this<br>[29:43] exists update it if not insert it so<br>[29:46] that it should be resilient to whether<br>[29:49] this already exists or not like I think<br>[29:50] I I keep I've been just checking this<br>[29:53] database as we're as it's doing its<br>[29:56] thing and and that I am seeing the<br>[29:57] number of rows in the contributors table<br>[29:59] slowly going up as<br>[30:01] >> are you seeing are you seeing the data<br>[30:03] populated across all the columns or<br>[30:06] >> I have not looked but I'm not I I it<br>[30:08] it's only collecting it's doing commits<br>[30:11] right now so it it wouldn't have gotten<br>[30:12] to the point<br>[30:15] >> I'm not entirely sure I maybe I need to<br>[30:17] look into it because actually yeah I<br>[30:18] don't know why it would be doing adding<br>[30:20] to the contributors table if it's doing<br>[30:23] just commit like analyzing commits like<br>[30:26] it's that's too early in the process but<br>[30:27] maybe there's something going on in the<br>[30:28] back like something ran in the<br>[30:31] background or<br>[30:34] I can actually give a reference point to<br>[30:36] that. Just a second. I'm going to look<br>[30:37] at um because I just realized I have<br>[30:40] something from the past.<br>[30:41] >> The other thing I've seen periodically,<br>[30:44] Adrian, is when we're doing a lot of<br>[30:46] heavy commit processing,<br>[30:49] >> I get a lot of contention on the<br>[30:51] contributor table if I'm doing too many<br>[30:54] repos at once. And that contention, I<br>[30:57] think, leads to a bunch of rollbacks at<br>[30:58] the database level. And so another<br>[31:02] possible area where we're missing that<br>[31:04] data is contention in the database<br>[31:09] and not catching those roll backs. But<br>[31:11] that wouldn't be what's happening with<br>[31:12] your PyTorch example.<br>[31:14] >> Yeah, because it's pretty much only one<br>[31:16] repository. I will say the number of<br>[31:18] entries um has not changed since I did a<br>[31:22] query. um the number of entries that I'm<br>[31:25] pretty sure from the profile information<br>[31:28] um has not changed since Friday.<br>[31:32] >> Are you and Adrian just to be clear,<br>[31:34] you're looking at the database Adrian's<br>[31:35] running?<br>[31:36] >> Yes.<br>[31:37] >> Okay.<br>[31:40] >> I know that may be obvious. I just<br>[31:42] wanted it sounded like<br>[31:43] >> clarification, but so just as an FYI,<br>[31:46] Adrian,<br>[31:47] >> just saying the number of contributors<br>[31:48] with profile information has not gone<br>[31:50] up.<br>[31:51] >> No.<br>[31:52] >> Okay. That makes sense.<br>[31:55] >> Okay. Um I think we can take a pause for<br>[31:58] a second because I do want to try to<br>[32:00] make more deliberate um transitions over<br>[32:03] to talk about eight knot as well. Um so<br>[32:08] >> pass over Kyle.<br>[32:10] >> Yeah. Uh so on the eight night side like<br>[32:13] I don't think it's as deep as the<br>[32:15] conversation that you guys are having<br>[32:17] with Augur but I just wanted like to<br>[32:19] bring out uh bring up like two issues or<br>[32:22] like topics of discussion. One of these<br>[32:25] I'm just going to post it here as well<br>[32:27] so you guys can follow up. Um<br>[32:34] probably link to the agenda in the<br>[32:37] >> Yeah. Not that anyone here probably<br>[32:40] doesn't already have it up, but<br>[32:42] >> and let me just share.<br>[32:45] Okay,<br>[32:48] Zoom. Zoom kind of like uh wait,<br>[32:56] I don't know how how sharing<br>[32:59] how sharing with Zoom works.<br>[33:01] >> You go under there should be a share. It<br>[33:03] should be a box with an arrow up.<br>[33:08] Uh<br>[33:08] >> yeah, on the bottom row of your where<br>[33:10] your mute kind of on the same row as<br>[33:12] your mute button.<br>[33:13] >> Yeah.<br>[33:13] >> Yeah. But like I just like to Okay, just<br>[33:17] a second.<br>[33:18] >> Yeah. Like participants, chat, react and<br>[33:20] then share. You click share and then<br>[33:22] it'll do kind of the similar thing.<br>[33:24] >> Yeah. It's just like trying to select<br>[33:26] the proper like the window.<br>[33:28] >> Yes.<br>[33:29] >> Well, yeah. Anyways, like you you guys<br>[33:31] can follow up like on the with the links<br>[33:34] there, but the idea like the first one<br>[33:37] it's this topic uh of conversation that<br>[33:40] someone like opened this issue about uh<br>[33:44] the search bar not being that intuitive<br>[33:46] and it's more like on like the user<br>[33:49] validation uh point of view because<br>[33:52] we've been over this uh when we last<br>[33:56] implemented like the search bar and what<br>[33:58] he's talking about is about uh ch being<br>[34:02] able to choose a repo or or by entering<br>[34:06] like return or like the enter key uh<br>[34:10] instead of like just clicking on the<br>[34:12] search icon. Uh and not he said like<br>[34:15] it's not very intuitive because even<br>[34:17] after he clicked on the repo is still<br>[34:20] gray. So he didn't know like how to<br>[34:22] follow up on that. He didn't know that<br>[34:24] he was supposed to be uh clicking on the<br>[34:26] search icon. Um, and then that's that's<br>[34:30] a point that I I think we've been over<br>[34:32] that, but I'm just open to like open it<br>[34:36] to to discussion as well. Like how do<br>[34:38] you think uh we should proceed with<br>[34:40] this? Like I think like we discussed<br>[34:43] before, if we just implement many ways<br>[34:46] that the person or the user can click<br>[34:48] and select the repo, I think there will<br>[34:50] be a lot of like misclicks or like a lot<br>[34:53] of query the uh duplication of queries<br>[34:55] and stuff like this that will that will<br>[34:58] actually like make it kind of like more<br>[35:00] buggy or or<br>[35:02] >> break it more. So, I I I kind of like<br>[35:05] disagree with this user, but I just<br>[35:07] wanted to hear what you guys want to<br>[35:10] >> So, I was the one who I I've been<br>[35:13] chatting with Philip a little bit. I I<br>[35:14] actually independently met him from some<br>[35:17] local Boston stuff. Uh I think he runs a<br>[35:18] local meetup here that I'm going to be<br>[35:20] at soon. But anyway,<br>[35:21] >> I think his the core point is like he's<br>[35:23] I think he's a very heavy keyboard you<br>[35:25] like he primarily is at keyboard<br>[35:26] navigation. Um, so I think I I like<br>[35:30] this. I think this change is going to be<br>[35:31] helpful for especially people who are in<br>[35:32] the habit of like enter will like run<br>[35:35] your Google search, run your whatever<br>[35:37] other search in other places.<br>[35:39] >> Um,<br>[35:40] >> I think if we've got concerns about that<br>[35:42] causing extra queries, I think we need<br>[35:44] to look at how we're processing queries<br>[35:46] and things in 8 because I don't<br>[35:48] >> I actually really disagree. So I I'm I<br>[35:52] think you're talking about something<br>[35:53] that I've experienced when I go into my<br>[35:56] 8 knot. Like if I get rid of chaos and I<br>[35:59] type in like augur and I get I get a<br>[36:02] list like this and I find the augur that<br>[36:04] I want<br>[36:06] it hitting enter doesn't do it. I<br>[36:08] actually have to hit this little search<br>[36:10] thing that that is the piece that's not<br>[36:13] intuitive at all. So the reason why we<br>[36:16] do that is because people can want to<br>[36:19] select multiple things and if you right<br>[36:22] now pressing enter adds a repository to<br>[36:25] the search list. pressing search says I<br>[36:28] want to search on this set of<br>[36:29] repositories and so that's the<br>[36:32] differentiation and the problem there is<br>[36:35] there I don't really see like pretty<br>[36:38] much what we have have found before<br>[36:40] trying to do that means that you would<br>[36:42] select on incomplete results or in<br>[36:44] people are still trying to select other<br>[36:46] repositories and it caused um issues<br>[36:49] with the application because right now<br>[36:51] if you press enter that's just adding it<br>[36:53] to the set and I don't really see a work<br>[36:55] like you you still need to be able to<br>[36:57] select a repository in the first place.<br>[37:00] And so if pressing enter says search,<br>[37:04] then you have<br>[37:07] >> what about this? So what here's the<br>[37:09] thing when I do this? Like if I add<br>[37:10] another thing here,<br>[37:13] look at this thing to the right.<br>[37:17] >> There's no there's no change to it.<br>[37:20] >> Right. But it's not it's not clear to me<br>[37:23] like when I<br>[37:23] >> search icon. Yeah. It's<br>[37:24] >> when I leave the focus here as a user,<br>[37:27] I'm expecting the data to change on the<br>[37:30] right. I'm not understanding that this<br>[37:33] is I'm not understanding that I need to<br>[37:36] do something to make the data change. I<br>[37:39] think when I search and then I go to<br>[37:41] another place where I want to see the<br>[37:42] data, I'm expecting that I'm seeing the<br>[37:45] data for these things.<br>[37:47] >> You see what I'm saying?<br>[37:49] >> I'm open to options. Uh like I'm open to<br>[37:51] hearing things. The reason why it's a<br>[37:53] search has been and that's like kind of<br>[37:54] the p the point of the the coloration<br>[37:57] that gray and maybe it's that it should<br>[37:59] be red but that's the coloration when<br>[38:01] you press the search bar whenever the<br>[38:03] data is fully collected on the Yeah. And<br>[38:06] now that tells you that your entries are<br>[38:08] searched on. I'm open to other options.<br>[38:10] I am just very<br>[38:13] um just because of the life like of the<br>[38:15] errors that we've seen in the past and<br>[38:16] where there's been crashing and having<br>[38:19] searches on incorrect or like on an<br>[38:22] incomplete set of queries. That's why<br>[38:24] the enter option has been avoided. I'm<br>[38:28] open to other options. Yes, Adrian.<br>[38:31] >> Yeah. So Sean, I'm curious to see like<br>[38:33] so it sounds like the issue like Callie<br>[38:35] was mentioning was that we're we're<br>[38:37] already using the enter key for<br>[38:39] different behavior. Like if you try like<br>[38:41] click in the search bar and try and add<br>[38:43] something without using the mouse. Like<br>[38:45] can you can you select a new thing<br>[38:50] >> like like that? Like yes,<br>[38:51] >> don't click on it. Like can you arrow<br>[38:53] down and hit enter and have that add the<br>[38:56] thing?<br>[38:57] >> No, I have to click.<br>[39:00] >> Oh, wait a minute. No, if I if I do use<br>[39:02] my arrows, then it does. Yeah.<br>[39:04] >> Okay.<br>[39:08] And then so and then so it kicks you<br>[39:10] back to that drop down and you can keep<br>[39:11] adding things.<br>[39:13] >> Yeah.<br>[39:13] >> Hit escape and see what that does. Does<br>[39:16] that<br>[39:17] >> nothing?<br>[39:18] >> But they close it closed the drop down.<br>[39:20] >> It did. Yes, it did.<br>[39:22] >> So then So I feel like what we could do<br>[39:24] is like we know when that dropown's<br>[39:26] open, right? That drop down's kind of<br>[39:27] what has keyboard focus.<br>[39:29] >> And so that's that's what's going to be<br>[39:31] first receiving the keyboard events from<br>[39:33] what like however that happens in HTML.<br>[39:36] And so we could like obviously that drop<br>[39:38] down is going to be capturing like enter<br>[39:40] is going to select and then when but<br>[39:42] when we close that dropown the focus<br>[39:44] probably is going to move to the search<br>[39:45] bar which will probably have its own<br>[39:47] event handling where we can treat enter<br>[39:50] as search. So I I think it's quite we we<br>[39:52] can use enter for two things<br>[39:55] using whether that dropown is open or<br>[39:57] not as a distinction. Like if the<br>[40:00] dropown's open enter is going to add the<br>[40:02] new item. if the dropown's closed, it's<br>[40:05] just going to trigger the search. I<br>[40:06] think that's really intuitive. Like<br>[40:09] that's at least intuitive for the very<br>[40:11] keyboard oriented users like the person<br>[40:14] who reported this issue. And I don't<br>[40:16] think that's that's not going to add any<br>[40:18] duplicate path or that's going to<br>[40:20] trigger the exact same search<br>[40:21] functionality, the exact same stuff<br>[40:23] that's getting triggered when you click<br>[40:24] with the mouse and you click the search<br>[40:26] box. Yeah, I think this is very I don't<br>[40:29] know if Dash I don't know if Dash like<br>[40:31] has that great like I don't know if this<br>[40:33] this will be possible in Dash but it's<br>[40:35] worth looking into.<br>[40:36] >> So I know it's not I know it's not a<br>[40:38] sweet design but sometimes in cases like<br>[40:41] this a button.<br>[40:44] >> Yeah, that's what I was thinking as<br>[40:45] well. Yeah. Yeah. Yeah.<br>[40:47] >> Literally the search button. That's<br>[40:49] where we're<br>[40:49] >> except it's on the left which is also<br>[40:51] something.<br>[40:53] >> It's not a button though. Yeah,<br>[40:54] >> it's it's I understand what you're<br>[40:56] saying, Kelly, but it's it doesn't like<br>[40:57] intuitively feel like a button to a<br>[40:59] user.<br>[41:00] >> Yeah.<br>[41:00] >> Okay.<br>[41:03] >> I think my my biggest I I think this is<br>[41:05] very solvable. I think we should do<br>[41:06] this. My only question is like when and<br>[41:10] like like we've got a very researchable<br>[41:14] problem of like okay, how do we how do<br>[41:16] we handle these input events in this way<br>[41:18] in Dash? And I think that's doable. It<br>[41:21] just needs someone to have time to do<br>[41:24] it.<br>[41:25] >> Like Cali and Co. Do we think that's<br>[41:27] going to fit on our road map or like<br>[41:29] maybe maybe Kyo next week or<br>[41:31] >> Yeah, I think it's a good Kio thing for<br>[41:33] next sprint. I think that's a good<br>[41:35] sizable task.<br>[41:36] >> Yeah, I agree. Yep.<br>[41:39] >> Okay. I can I can task myself with going<br>[41:41] and updating this uh issue if no one<br>[41:43] objects. Um just to add add the results<br>[41:46] of this discussion and like assign it to<br>[41:48] Kyio. Um, sounds good.<br>[41:51] >> Yeah.<br>[41:52] >> Um, Adrian, when you get a chance, can<br>[41:55] you review Kaio's<br>[41:57] PR, the heat map one? I think I think<br>[42:00] we're close.<br>[42:01] >> Yeah, I tried to do that the other day.<br>[42:03] Um, and my computer was doing that<br>[42:06] stupid Podman thing where if I change<br>[42:08] networks, it the containers stop being<br>[42:11] able to talk to each other. Um,<br>[42:14] I probably should have restarted my<br>[42:15] computer before I brought my<br>[42:18] like emergency instance collection back<br>[42:20] up. Um,<br>[42:22] but yeah, that's that's basically just<br>[42:25] blocked because of that stupid Podman<br>[42:26] bug and I don't like and now I've got<br>[42:29] collection halfway processing. I don't<br>[42:31] really want to start pietorrch<br>[42:32] collection from the beginning again. Um,<br>[42:35] >> yeah, I understand. It's just cuz<br>[42:37] >> I like I just want it to be tested not<br>[42:39] in a Mac. Like you're you're the one<br>[42:42] person on our team that's not running on<br>[42:44] a Mac. So<br>[42:45] >> should you should go grab those API keys<br>[42:48] though as Cali suggested because then<br>[42:50] you will not have to wait as much.<br>[42:53] >> Yeah. I can't restart the instance to<br>[42:55] add the API keys though unless<br>[42:57] >> Okay. Yeah. Okay. It's it's I mean I I<br>[42:59] can I can try and do that if I<br>[43:02] >> get forced to restart it or whatever,<br>[43:03] but I'd like to get it through<br>[43:05] collection and then like if we need to<br>[43:08] add more repos and collect more faster<br>[43:10] then yeah I<br>[43:11] >> this is this instance is a very like<br>[43:13] temporary like quick fix. Like I maybe<br>[43:17] wasn't thinking it's set up through<br>[43:19] fully cuz like I'm not really<br>[43:21] anticipating this is going to be a<br>[43:22] permanent DB. It's just like a tiny tiny<br>[43:25] DB that we can just<br>[43:27] >> get things working.<br>[43:29] >> I guess I I do think it does seem like<br>[43:31] this might I mean you go from one key to<br>[43:34] 20 keys um that makes a pretty big<br>[43:37] difference if collection is really slow.<br>[43:38] I think it's just if I I'd say let's<br>[43:41] let's say by the end of today if you're<br>[43:43] still like not making any serious<br>[43:45] forward progress I think it's worth<br>[43:48] considering restarting it and putting<br>[43:51] more keys.<br>[43:52] >> Yeah. Do we don't use<br>[43:54] I don't think we have anything in facade<br>[43:57] that needs the GitHub API that heavily<br>[43:59] though.<br>[44:02] >> The contributor resolution stuff is<br>[44:04] where the that's the only place.<br>[44:07] >> Okay.<br>[44:07] >> That's the only place<br>[44:08] >> and it hasn't gotten there yet. So, it's<br>[44:10] it's pretty Yeah,<br>[44:13] >> I don't know what uh Okay. Um, I'll keep<br>[44:16] an eye on it and see see how it's doing.<br>[44:18] But,<br>[44:19] >> um, yeah, we'll have to Yeah, we have to<br>[44:22] think about this because I just don't<br>[44:24] want Kyo to be<br>[44:28] like, we've been Yeah, just not wanting<br>[44:30] to be blocked in other areas, but I<br>[44:32] understand why you don't want to restart<br>[44:33] your computer.<br>[44:34] >> I could probably do it. I could probably<br>[44:36] test it on my personal machine, maybe.<br>[44:38] Um,<br>[44:40] I need to figure out how to get all my<br>[44:42] like API keys and set up over there with<br>[44:45] my like get all up or something. But<br>[44:48] >> just wanted to update as well, Kylie, on<br>[44:50] that uh that second issue as well on the<br>[44:53] larger repos. Uh, I've been able to like<br>[44:55] test pretty much like all of the like<br>[44:58] PyTorch and all of the repos and orgs<br>[45:01] that you put there and it it kind of<br>[45:03] like loaded fine. the the waiting time<br>[45:06] was not like ideal but it it loaded uh<br>[45:09] and I checked with<br>[45:11] >> you like so whenever you look at the<br>[45:13] like so the so you're sure that the<br>[45:15] graphs are actually populating with the<br>[45:17] correct data and now<br>[45:18] >> yeah yeah I I updated yesterday like the<br>[45:22] issue there with like screenshots and I<br>[45:24] have more like that I checked on the<br>[45:26] prod instance and it was like the same<br>[45:29] so it was able to it was able to load I<br>[45:32] think what was happening also is like<br>[45:35] the soft limit it was exceeding the soft<br>[45:37] limit on the work uh the workers call<br>[45:40] back. So the worker's query we had like<br>[45:43] on the docker compose we had updated<br>[45:45] before to 10 minutes but then the worker<br>[45:47] call back it was still like 240 seconds.<br>[45:50] So I was like I just updated that as<br>[45:53] well and it kind of like get rid of like<br>[45:55] the the issue but the problem is because<br>[45:58] it was exceeding this time. Uh yeah,<br>[46:01] sorry agent. I I'll try to be fast like<br>[46:03] uh so it because it was exceeding this<br>[46:05] time uh it was kind of like the worker<br>[46:08] call back is it was being reset and<br>[46:10] reloaded. So when it reloads the app, it<br>[46:13] goes back to chaos like as a default.<br>[46:16] >> But but uh after like uh increasing like<br>[46:19] the the soft limit time, I was able to<br>[46:21] like load all all of the like the<br>[46:23] options that you've put there. So<br>[46:26] >> I think it should be very solvable.<br>[46:27] Yeah.<br>[46:28] >> Yeah. Um, yeah, put a PR in whenever you<br>[46:30] get a chance. We should definitely do<br>[46:31] that in our our instance and I'm sure<br>[46:32] that impacts um Sean as well. Um, but<br>[46:36] what you're saying makes complete sense<br>[46:38] with the behavior that like that. Yeah,<br>[46:40] I<br>[46:41] >> I feel pretty confident that that's the<br>[46:43] problem because that's you would see it<br>[46:45] with the with the screen and it would do<br>[46:47] that like load thing and then it would<br>[46:48] go back<br>[46:49] >> and so yeah. Sweet.<br>[46:51] >> All right,<br>[46:52] >> that's good.<br>[46:53] >> Yep. Um, final quick announcement. I<br>[46:56] know I think Sam put this in Slack. He<br>[46:58] wasn't able to make it today, but they<br>[47:00] um<br>[47:00] >> there he's one of the contributors in<br>[47:02] the University College London. They just<br>[47:03] submitted an application for that um UK<br>[47:06] grant research grant thing.<br>[47:08] >> Yeah.<br>[47:08] >> Um so that's went in and I think they're<br>[47:10] expecting to hear back by March 20th. So<br>[47:12] we got<br>[47:12] >> a pretty fast turn.<br>[47:14] >> My grant micro funding cycles are not<br>[47:16] that fast ordinarily. So it sounded like<br>[47:19] it's just like a hey, we're actually<br>[47:22] interested in you filling out a full<br>[47:23] application.<br>[47:24] >> Yeah. It's like it's like write send a<br>[47:25] letter and then if you they like they'll<br>[47:27] invite you to apply I think is what what<br>[47:29] the hearing back by March 20th is for.<br>[47:31] So, it's there's still a lot of process<br>[47:33] to go, but I'm I'm excited for the<br>[47:35] possibility that hey, maybe maybe their<br>[47:37] team gets funded to basically contribute<br>[47:39] to Augur for a few months. Like, that's<br>[47:41] going to really help us like get a lot<br>[47:43] of this tech debt down, like get<br>[47:46] >> re like really get a lot of eyes on<br>[47:48] parts of Augur that haven't had<br>[47:51] >> comprehensive eyes on it for probably<br>[47:53] years at this point.<br>[47:54] >> Yeah. No. And I can like Adrian I feel<br>[47:57] how hard it is that you're doing so much<br>[48:00] more time on Augur than everyone. So you<br>[48:04] feel a lot<br>[48:04] >> for me. I'm getting paid.<br>[48:07] >> My job doing this.<br>[48:07] >> I know. I know. But but it's still it's<br>[48:09] like it's a it's sort of a you're learn<br>[48:12] but you're you're doing a lot of great<br>[48:13] stuff but you're also learning about it.<br>[48:15] >> Yeah. and and so I know that it can feel<br>[48:18] like getting stuck in the mud and um so<br>[48:20] yeah I agree if we can get some more<br>[48:22] people to help that would be fantastic.<br>[48:28] Yeah.<br>[48:28] >> Sweet. Well thanks thanks guys for<br>[48:30] attending this meeting.<br>[48:32] >> All right. Thank you. See you catch you<br>[48:34] all later. Bye. Right.
<!-- deep-read:sections end -->
๐ **Full text:** ![[Full Document Contents/Articles/Augur8-Knot WG, March 3 2026.md|Augur/8-Knot WG, March 3 2026 by YouTube]]
## Highlights
- We are recording now. >> Sweet. So yeah, we're just talking about the uh some of the debugging we've been doing with contributor resolution for basically the past two weeks since the last meeting. Um but yeah, I think I think generally the overall sequence of facade is basically like one of the first tasks is it's named deceptively. Its function is basically to collect contributor events. So that's querying the GitHub events API which is not really relevant to what we're doing. Um, other than the fact that that task ([View Highlight](https://read.readwise.io/read/01kpb4rz0aj3vxjkthr4ypc0ye))
- Tags: ๐ป ai highlighted
- say that yes, there are contributors that are coming from Chaos that are not having their profile information um, populated. >> I think we need to look at which job is filling out the profile information. >> It's basically contributor resolution, >> is it? Yeah, that's that's what I've been looking at for the last >> So, it's supposed to be populating all those fields. >> Process commit metadata is the function that does it. It's I think it gets called in let me check. Um, it gets ([View Highlight](https://read.readwise.io/read/01kpb4rz5rg5gbwqb2z6fqxyxe))
- Tags: ๐ป ai highlighted
- what I'd like to understand is where are we creating a contributor row and not filling in that data? That seems like >> that's the same place I'm at. Yeah, because that seems like that seems like there's some very simple candidly dumb thing that we did perhaps because every time we make a a call to try to reconcile the commits API to try to reconcile the the contributor on a commit and put it in the contributor ([View Highlight](https://read.readwise.io/read/01kpb4rz8rrh2s7gyafe7fsygg))
- Tags: ๐ป ai highlighted
- but I think the thing is that Adrian's saying is that the contributor >> is being inserted during other tasks because it needs to be able to reference to the contributor ID and then the contributor resolution comes around later to do the login stuff and so That's where the idiosyncrasies come. Um, but I should stop speaking for Adrian. >> I'm actually tracing that through. I'm actually I what I said earlier about it being an earlier step of the facade. ([View Highlight](https://read.readwise.io/read/01kpb4rzc6dxftp514rtb04ckt))
- Tags: ๐ป ai highlighted
- Uh, no, that's the other fun. That's a different thing I was looking at before. >> Um, but yes, this is the rabbit hole that I've been wanting to go down of just at least we could understand it. Well, and I think you know some of the there are several threads inside of Augur that are dealing with contributor data. One of those I think my guess is one of them is filling in some small part of it that it needs but not getting the the rest of it while it's there. And then some other part of it is saying ([View Highlight](https://read.readwise.io/read/01kpb4rzf9kryf3ayctrkgyvdm))
- Tags: ๐ป ai highlighted
- I've already got it when it when it goes and looks for that contributor. So it's not so somewhere something's adding that contributor without adding all the data. And then that's shortcircuiting wherever we're supposed to be or trying to add all the data. Do you understand what I'm saying? >> I don't think it's necessarily shortcircuiting, but it it's Yeah, like we're definitely inserting it sounds like we're inserting like an like a like we we collect the events for the like contributor events. We need we have the ([View Highlight](https://read.readwise.io/read/01kpb4rzk5y1nz9qsm1268zy0h))
- Tags: ๐ป ai highlighted
- >> I don't see anything in the contributor resolution that would that would necessarily break in that case. Like I think >> like when we do contributor resolution, is it trying to insert all the fields? >> Yeah. So what we do is we basically we we grab a list of every like all the commits that haven't been looked at yet like commit emails and stuff like we basically do a big big SQL query to grab contributor like things that we need to process for contributor resolution and then we'll we'll look up um ([View Highlight](https://read.readwise.io/read/01kpb4rzpfajyhhcc12r9nhpjv))
- Tags: ๐ป ai highlighted
- >> Are you and Adrian just to be clear, you're looking at the database Adrian's running? >> Yes. >> Okay. >> I know that may be obvious. I just wanted it sounded like >> clarification, but so just as an FYI, Adrian, >> just saying the number of contributors with profile information has not gone up. >> No. >> Okay. That makes sense. >> Okay. Um I think we can take a pause for a second because I do want to try to ([View Highlight](https://read.readwise.io/read/01kpb4rzye9tmw5webjqhhr1wg))
- Tags: ๐ป ai highlighted