Augur/8-Knot WG, March 3 2026 ![rw-book-cover](https://img.youtube.com/vi/qc000j4r-Ho/maxresdefault.jpg) 🔗 **Source:** [Augur/8-Knot WG, March 3 2026](https://www.youtube.com/watch?v=qc000j4r-Ho) 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 is named such that I thought it was collecting contributors and I think that task does insert contributors because I imagine it would need something to reference the events to but I don't think it's it's not gathering it's its purpose is not to gather the profile information because that happens after that happens the commits get analyzed and the committers uh get like inserted and then we do the contributor resolution where we look at the commit like the commits table and we try and find either using using the various a couple of couple different GitHub APIs to try and get a GitHub username to get their profile to get the rest of the information. Um, and it's that that sort of after the commits are being processed. That's sort of the part I've been focusing on for the last probably week or so. Um, and that's that's I think I've been we've been running a bit of a a sort of hot fix branch um to with some just sort of quick changes to try and get things up and running again. And then also in parallel, I've been doing some more reworking of like trying to just organize the process a little bit better for contributor resolution anyway so that we can so that it's it's easier to sort of have a known like hey we need to make these calls to GitHub and like it's it's you don't have to jump between three different files to read it and also I'm going to need to rework it anyway if if we're going to be adding more PL like making the contributor resolution work for Git. lab, work for 4G, work for any new platforms we want to add in the future. Um, I think that's largely been what I've been focusing on. Like a like how do we how do I make sure that Callie's not blocked on the analysis she needs to deliver, but also like how do we sort of make learn from this and figure out like, okay, how do we make Augur more resilient to like, hey, we found a data collection error. Like I've been starting to think about like backups and other things, other tools that are going to help us have things like this that happen in the future not be as bad. >> Um yeah, a quick question for um Tom. Have you taken down the affiliations page for the um for y'all's instance of of 8 yet? >> No. you I I would appreciate if you did >> because it is grossly inaccurate and I don't and yeah I think that until this contributor resolution issue is resolved that page should not be public. Yeah, I put a patch in the in one of our uh Slack channels, Sean, for it's like a it's like a small git patch you can like just throw up and rebuild the container or how I don't know how. >> Oh, okay. So, >> like you just I just removed it from the navbar. Like the page is still there. It's just not visible in the navbar. So, it's it's >> which branch which branch would I pull because that's how I do it. Uh it's I think I think I did make a PR on 8 knot that never got merged. Um let me go find it. Yeah, I I don't have time to go through eight not and do an edit, but I can pull a new branch down and run it. >> You How up to date is your I think this branch might be based on de our dev branch. So, I'm not sure. >> I mean, I think that's a good thing. I mean, >> that it's based on dev. >> Yeah. >> Yeah, I think it is. And I was it was this year that I updated it last I want to say toward the end of January cuz I was making sure it was up to date before Chaos Con. >> Yeah. So there's probably not very many changes since then. >> I put it in Zoom chat. It's the disabled affiliations branch. >> Um yeah because I but sorry to derail from what you were saying Adrian. I just really wanted to make sure this is um because this is interrelated. Um, I think if anything I'm realizing that we have more silent users that I think we realize. Um, and >> what's leading you to that? Like are you seeing people kind of talk about this data stuff? >> Yeah. I mean there's like I'm just I feel like I'm on calls or oh you found that one person that's a super user and then I'm on another call and somebody's mentioning using eight non a combination to claude. like it just seems like every week learn of more people who are using it relatively regularly and we aren't really aware of them and so I think it's worth like I that's why >> people looking at eight not >> yes um and so I just think that's why I think that it is important um for us to take take this down >> wrong data yeah >> yeah because then like realistically We're no better uh no better than LFX insights right now like whenever it comes to this stuff. >> Yeah. I mean affiliation data has always been something that needs to be you need to have a map of what the affiliations are for people. So what we >> I guess for us we're just we're not we are not holding up to the stand to the what we say the data is right now and so I don't think that those visualizations should be up. I think it's kind of as simple as that. Um but kind of going back to to the collection um yeah that makes sense Adrian. I guess we can just wait it out. It does sound like that there are API calls in that chain and so it might still be beneficial for you like there are a lot of API keys that are not being used right now. Um, so something to consider, um, especially when we're going it's going through and doing all the contributor resolution because I remember um, Sean mentioning that there is a different API rate limit for this and so having one API key is going I would >> limits the search API that that's um that is true but that that is our second and less reliable anyway method of trying to find a username. So, >> I'm not talking about username. I'm talking about GitHub profile information. >> The GitHub profile information that that's just the that's what the regular I don't I don't think that has a separate API limit because that's just users endpoint, right? >> Uh um so yeah, I don't I I'd have to look at what API we're using >> commits API and everything else. >> I do want to Yeah, >> sorry. I do want to understand a little bit better about missing profile information. So the contributor is it that the contributor wrote does not exist, Kelly? >> No, it said that the that I go through and I can look through any of the entries of the login. 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. So it just hasn't made it from GitHub's API to our database yet. >> Yeah. >> Yeah. >> So you're talking about like the URLs, the gravitars, the >> Yeah. I mean, or look at their login. It's just that it's quick to get to it. I'm just saying that if you look at the at the profile for the login for any contributor row, I can send over a couple of different examples that I've I've seen, but it doesn't really you could click, at least from what I've seen, it doesn't take very long to to find an example. It usually takes me looking at one or usually yeah, one, two, maybe three entries and then I can find an instance of what I'm talking about. Um, if you give me a second, I can switch to my computer and just show examples. >> Yeah, I've got I've got my contributors table open right now and I see, you know, obviously different levels of the profile being filled out. >> Start clicking on somewhere there's no basically no profile information. Like it's all null. If you go to one of the links, like I think what Callie's saying is that she's gone to three or four of them and within that she'll she's been able to find like >> fairly consistently. Just give me a quick second. I'm going to switch devices. >> Okay. One thing I also noticed too when I was kind of looking through this, I I might maybe I should repeat this when Kelly gets back, but um in trying to just sort of double check my understanding of that sort of earlier sort of pre-commit processing step of facade um or I don't know what it I was looking into something and I found a a task that we are running on an hourly basis that looks through contributors and fetches profile information. Like we're updating contributors supposedly hourly, but we're only doing it for the created at and last used time stamp fields. >> So we're making an entire GitHub API call to that same endpoint we're getting the profile data from. and we're we're in we're we're adding we're populating that data hourly but not using it like we're not we're fetching the data and then throwing it away. So that might be another cool place to try like to potentially fix that task. I'm currently working on that um to fix that task so that we can get like maybe it's it's not necessarily directly from the Jupiter resolution but it's that other process that we already have for populating that data. >> All right. So in my my understanding of theuler is that it does not have like tasks running hourly that everything is run as a as a sequence. >> We do have a couple I mean we have there's the tasks that like refresh the materialized views and stuff that do get run >> yeah more fixed time schedules. So this this is another one of those like it's sort of a separate >> class of tasks >> but there is one that populates this data that we are not using like to the fullest extent that we I think should be. >> And you're sure it's getting run? >> Uh I have not 100% checked. I need to see if I've even I'm really hesitant to I don't want to touch my local instance because that's what's trying to populate our little backup DB right now. Um, if I forgot to start flower, then I won't. Yeah, I don't think I started flower. Um, I don't know if there's a way to see which tasks have run without flower. Okay, I might I might do some spelunking through rabbit MQ commands in a bit to try and find that. But um it's if if someone's got a instance that's got collection running, which I sort of doubt at this point, um it is the process contributors task. Um I'll see if I can double check that's what it's actually going to show up as, but it's it's referenced in celery app.py. um as a as a periodic task. >> Yeah, this I mean I think I think a lot of this will become easier to manage and a little bit a lot more clear when we have a the job scheduler um as a bit more transparent. Like from my perspective, a lot of what we're talking about could be fixed much more quickly and deterministically if we dealt with the job scheduler. >> I mean, yes, but I don't think we should wait for that cuz this this is this has been actively >> putting bad data into augur databases for months. >> I'm not suggesting that we wait for it. I'm suggesting that a lot of the conversation that we're having about the full population of contributor data and periodic tasks and how they run and when they run, if we go and deal with the job scheduler, I think that we will be able to speak more authoritatively. >> Uh maybe maybe as far as the scheduler goes, I think the the tasks themselves seem to be getting run. So I'm not >> like >> I'm not worried about >> the dual source of truth thing with celery. Yeah, sorry for interrupting Andrew, but yeah, like I guess the as this debugging process has been going through, I don't think we've hit a single point where the problem is because of scheduling. There's always been an actual bug in the code that has caused these data issues. So, I'm not the scheduler is not really the um or at least up until this point has not been the source of the problem. Well, part of me wonders too like like if like if it is largely largely sort of just various bugs or tech debt or whatever with our tasks like if we even if we did have theuler thing ready now and if it was all we we had the admin page to replace flower and all that like if we ship theuler and still have problems like this like we like I mean obviously that'll give us more information on hey it wasn't maybe it wasn't theuler but it it's also kind of maybe muddying things a bit because like how do we know like unless we ship theuler with very solid testing it's going to be hard to tell like what did did did anything theuler introduced make this worse activate any new bugs anything like that so I think we just need to be thorough in our testing basically >> so what what I'm observing is we spend a lot of time trying to understand and and identify these bugs when we discover them or identify what's what's going wrong and it takes I think a lot longer because there is less certainty we don't have the certainty that I think we need to know when these things are being run so it for me when I run my instance of augur I don't like I'll see things get run but And sometimes I have to restart augur to go from core to secondary for a large collection or to go from secondary to facade for a large collection. And so knowing when and how everything is run for a repo, these questions that we started out with, Adrian, where you weren't sure how to describe how far along you were with PyTorch, all of that sort of >> Yeah. these questions that cloud the debugging do emerge from the non-deterministic nature of a distributed scheduler. >> I guess I just don't see that to be I I see many other I guess I just don't see that to be that big of a deal in this instance. I'll be honest like with like the last two weeks of this process, the scheduling and the ordering of this as Adrian has done the vast majority of the work so I don't want to but from my point of view from the um debugging of it um the scheduler has pretty much not been a part of the discussion at all nor a part of like the the solutions of making things better. >> I think the schedule change would be like it's a helpful change on its own. I don't think it's necessar like some of the other some of the other like things that we've I think some of the like facade issues there's other issues that we've noticed where like hey these two problems are a lot closer connected or like hey this is what's actually causing that. Um I I think this is sort of not that case where like I think yeah scheduler is a good change the this is a good change but I I think they're less closely linked then maybe the scheduleuler is linked to other other issues but yeah I mean more more like if if if someone's help like if Andrew is helping out with auler like that's more like I'll take someone working on any augur issue and like more more I think that's kind of our main bottleneck right now is more dev time on augur um I think because I think there's a a lot of like we've got like I've been I've been filing issues pretty regularly and we're up to like 200 and something like of just things people have noticed that like hey we might need to might want to fix this in the future and they might they're in various stages of whatever but like yeah I think I think trying to just really work through a lot of that a lot of those identified issues I think is going to really help like in our in our kind of goal to stabilize augur >> could you share the data that's populated in the rows for those contributors that you shared. >> It's not pretty. The data is like I can just show you the screen. They're all the I've just I'll show you what I'm looking at. >> You have an issue for this, right, Kelly? You want me to put those examples in it? >> No, I mean that issue is not remember this is that issue that I opened is not describing this problem. That issue is talking about going forward um regularly um reviewing the GitHub profile information. So, I would say if you want me to open an issue specifically for a bug that's different than the issue that I opened yesterday. >> Oh, I was just curious if there was an issue for like that I could put these examples in so they don't get lost when we end the meeting. >> I would say it's a part of like if you want me to make a sub issue, I can, but it's just the larger one that I had opened I guess like a week or two ago. Um, but if you would like to make what if you would like me to have a smaller like to make a more specific issue, I can. Um, so if you look at this is not all of these have GitHub profile information, but a lot of them do. And it's just all of these are just null. >> Wow. So, >> so if we look at this like view, I I kind of manually went through each one of these. Probably about 10 of them, 10 to 15 of them have actually have profile information that we don't have anything of. And that's why uh yeah, that's kind of what I've been looking at. Um say I think we have the the profile information is such lowhanging fruit that I think will make the coverage that we have of especially emails and just overall information about our contributors um like I would expect us to go up to whenever it comes to more corporate um repositories you're seeing like I'd confidently say 70% of people have an email like some really identifying things in their in their um profiles. I'd say generally like right now we're at like what 1% 2% um of the people have data in these in like their email field. I would expect that to go up to 30 to 50 with um the login information like if we're going to get the not the login but the um GitHub um profile information for the related login. So we you said we're at like one or two% now. Would would we does that make sense as far as because right now this instance only is collecting on the default repos and PyTorch. Do we think that it it like >> should be higher? Yes. >> Well, of course it should be higher. Like I'm I'm curious like because the chaos repos in this instance are basically fully collected. There's one that I think is still pending facade but and that was last I checked a little while ago. Yeah, the chaos repos are pretty small compared to PyTorch. >> So like do we like I imagine in Yeah, because right now we're looking at number of contributors. So I imagine PyTorch probably has 50 times number of contributors that the cha the default repos do >> um >> at least. So I I I' I'd be interested to kind of see like can we break this down like look at like of of and maybe we just do it with spot checks but like of the examples we have where there's a null in the database but we can go on github.com and see there's profile information there for us to be getting like are all of those that we're spot checking coming from PyTorch or they like can we try and look specifically for Chaos contributors? I can say that they're not just from pe the ones that I'm like I'll look at people's profiles and I recognize them from Chaos. I can get like a better I don't have I don't have the number, but I can say um pretty definitively that there are profiles that are present and from Chaos that do not have their profile information populated, but I can like give me some time in the afternoon. And what I'm planning on doing is looking at each of the of the like probably just go through PR um events and look at the contributor ids for the chaos repositories and join it on the contributor table. And so we can see how many of those distinct um contributors have profile information. can pretty much do what I did here and I can give you a little bit of a better like what's the coverage. Um, but I can confidently 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 called in insert facade contributors which I think is just its own task. Uh, I think it runs towards the end of facade. Um, sorry, what was your I think you just had a question. I think I'm good. >> Okay. But yeah, that's that's sort of the process. So I've I've been I like in in looking at a lot of this contributor resolution like it's been jumping between files. And so that was sort of like we we call functions that then build the URL that then do another database access for information we pretty much already have. Like it's just spread it's very spread out and hard to follow. So, I've been I've been sort of just moving stuff around and um trying to also make better use of we already have like a class like a helper class in that sort of section of the facade code for accessing GitHub. So I've been trying to kind of move a lot of the GitHub specific like API calls and URL building and stuff into that existing class so that um like it bo organizing the code and also sort of creating a better defined line of like okay here is this defined interface between okay now we're going to go into the platform specific part so that then we can just write another class for forgio or whatever implement those methods and it'll just sort of be dropped in. >> Okay. >> So, that that's kind of my my plan with with sort of refactoring it. >> Yeah, >> I'm just doing that on a branch on my personal fork of Ago right now. >> But, okay, I'll I'll try and clean it up and organize it, make it a PR at some point soon. >> And and I've been I've been tackling the commit resolution issue from a step outside of Augur. What's missing? What do we need to get? And so Cali pointing out some of these fields that aren't getting populated is helpful because now I understand there's 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 table or match it to an existing contributor in the contributor table. When we when we do that, we could get all the data for that contributor. And so somewhere we're not because why would we create that row if we don't have that data? >> I just hit the exact same there. There's messages to me like to Adrian our team chat that pretty much just that is the exact place that I have been today is is is going down that logical line of is it 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. Like, yeah, we do have a a spot that collects um contributor like events. I'm trying to find where that is in the code right now, but I realize it's not earlier in facade where I thought it was. It's probably like core or something. Um, if the events API would be hit by core or secondary, I' I'd have to look, but it it that shouldn't I wouldn't expect that to be happening in facade. I won't say it shouldn't be. Um, >> it looks like process contributors. 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 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 username of the contributors at that point. So we just make a basically empty contributor row entry with just the username and everything else is basically null so that we can have an ID to reference for the events and then later on we have it it goes through and populates it. So I think yeah adjusting the order like figuring out exactly what task that first part happens in and maybe like filling in more of the details. I so the reason I'm suggesting that is because I I suspect that at the point that we first inserted the contributor data, we assumed that that process would happen first and whatever process is trying to insert the full amount of contributor data for those fields that is getting run in seems like in many cases after we're just trying to reconcile the contrib to the commit. And so when we do that, we're finding the contributor already exists and we're not filling it in. So >> 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 basically the the first part of it is like looking up the trying to look up the GitHub username from because this is coming from facade so it's looking from the commits trying to use either the commit hash or the email to find the username and then it's it builds a giant JSON object of basically all the columns in the contributors table. After it finds the username, it'll query the GitHub API, get information, and then fill in that big dictionary and then it'll probably I think it runs it through >> I don't know which of we have several different functions for adding things to the database. I'm fairly sure it runs it through one of our more standard ones that like would do like a proper upsert like it would actually like okay if this exists update it if not insert it so that it should be resilient to whether this already exists or not like I think I I keep I've been just checking this database as we're as it's doing its thing and and that I am seeing the number of rows in the contributors table slowly going up as >> are you seeing are you seeing the data populated across all the columns or >> I have not looked but I'm not I I it it's only collecting it's doing commits right now so it it wouldn't have gotten to the point >> I'm not entirely sure I maybe I need to look into it because actually yeah I don't know why it would be doing adding to the contributors table if it's doing just commit like analyzing commits like it's that's too early in the process but maybe there's something going on in the back like something ran in the background or I can actually give a reference point to that. Just a second. I'm going to look at um because I just realized I have something from the past. >> The other thing I've seen periodically, Adrian, is when we're doing a lot of heavy commit processing, >> I get a lot of contention on the contributor table if I'm doing too many repos at once. And that contention, I think, leads to a bunch of rollbacks at the database level. And so another possible area where we're missing that data is contention in the database and not catching those roll backs. But that wouldn't be what's happening with your PyTorch example. >> Yeah, because it's pretty much only one repository. I will say the number of entries um has not changed since I did a query. um the number of entries that I'm pretty sure from the profile information um has not changed since Friday. >> 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 make more deliberate um transitions over to talk about eight knot as well. Um so >> pass over Kyle. >> Yeah. Uh so on the eight night side like I don't think it's as deep as the conversation that you guys are having with Augur but I just wanted like to bring out uh bring up like two issues or like topics of discussion. One of these I'm just going to post it here as well so you guys can follow up. Um probably link to the agenda in the >> Yeah. Not that anyone here probably doesn't already have it up, but >> and let me just share. Okay, Zoom. Zoom kind of like uh wait, I don't know how how sharing how sharing with Zoom works. >> You go under there should be a share. It should be a box with an arrow up. Uh >> yeah, on the bottom row of your where your mute kind of on the same row as your mute button. >> Yeah. >> Yeah. But like I just like to Okay, just a second. >> Yeah. Like participants, chat, react and then share. You click share and then it'll do kind of the similar thing. >> Yeah. It's just like trying to select the proper like the window. >> Yes. >> Well, yeah. Anyways, like you you guys can follow up like on the with the links there, but the idea like the first one it's this topic uh of conversation that someone like opened this issue about uh the search bar not being that intuitive and it's more like on like the user validation uh point of view because we've been over this uh when we last implemented like the search bar and what he's talking about is about uh ch being able to choose a repo or or by entering like return or like the enter key uh instead of like just clicking on the search icon. Uh and not he said like it's not very intuitive because even after he clicked on the repo is still gray. So he didn't know like how to follow up on that. He didn't know that he was supposed to be uh clicking on the search icon. Um, and then that's that's a point that I I think we've been over that, but I'm just open to like open it to to discussion as well. Like how do you think uh we should proceed with this? Like I think like we discussed before, if we just implement many ways that the person or the user can click and select the repo, I think there will be a lot of like misclicks or like a lot of query the uh duplication of queries and stuff like this that will that will actually like make it kind of like more buggy or or >> break it more. So, I I I kind of like disagree with this user, but I just wanted to hear what you guys want to >> So, I was the one who I I've been chatting with Philip a little bit. I I actually independently met him from some local Boston stuff. Uh I think he runs a local meetup here that I'm going to be at soon. But anyway, >> I think his the core point is like he's I think he's a very heavy keyboard you like he primarily is at keyboard navigation. Um, so I think I I like this. I think this change is going to be helpful for especially people who are in the habit of like enter will like run your Google search, run your whatever other search in other places. >> Um, >> I think if we've got concerns about that causing extra queries, I think we need to look at how we're processing queries and things in 8 because I don't >> I actually really disagree. So I I'm I think you're talking about something that I've experienced when I go into my 8 knot. Like if I get rid of chaos and I type in like augur and I get I get a list like this and I find the augur that I want it hitting enter doesn't do it. I actually have to hit this little search thing that that is the piece that's not intuitive at all. So the reason why we do that is because people can want to select multiple things and if you right now pressing enter adds a repository to the search list. pressing search says I want to search on this set of repositories and so that's the differentiation and the problem there is there I don't really see like pretty much what we have have found before trying to do that means that you would select on incomplete results or in people are still trying to select other repositories and it caused um issues with the application because right now if you press enter that's just adding it to the set and I don't really see a work like you you still need to be able to select a repository in the first place. And so if pressing enter says search, then you have >> what about this? So what here's the thing when I do this? Like if I add another thing here, look at this thing to the right. >> There's no there's no change to it. >> Right. But it's not it's not clear to me like when I >> search icon. Yeah. It's >> when I leave the focus here as a user, I'm expecting the data to change on the right. I'm not understanding that this is I'm not understanding that I need to do something to make the data change. I think when I search and then I go to another place where I want to see the data, I'm expecting that I'm seeing the data for these things. >> You see what I'm saying? >> I'm open to options. Uh like I'm open to hearing things. The reason why it's a search has been and that's like kind of the p the point of the the coloration that gray and maybe it's that it should be red but that's the coloration when you press the search bar whenever the data is fully collected on the Yeah. And now that tells you that your entries are searched on. I'm open to other options. I am just very um just because of the life like of the errors that we've seen in the past and where there's been crashing and having searches on incorrect or like on an incomplete set of queries. That's why the enter option has been avoided. I'm open to other options. Yes, Adrian. >> Yeah. So Sean, I'm curious to see like so it sounds like the issue like Callie was mentioning was that we're we're already using the enter key for different behavior. Like if you try like click in the search bar and try and add something without using the mouse. Like can you can you select a new thing >> like like that? Like yes, >> don't click on it. Like can you arrow down and hit enter and have that add the thing? >> No, I have to click. >> Oh, wait a minute. No, if I if I do use my arrows, then it does. Yeah. >> Okay. And then so and then so it kicks you back to that drop down and you can keep adding things. >> Yeah. >> Hit escape and see what that does. Does that >> nothing? >> But they close it closed the drop down. >> It did. Yes, it did. >> So then So I feel like what we could do is like we know when that dropown's open, right? That drop down's kind of what has keyboard focus. >> And so that's that's what's going to be first receiving the keyboard events from what like however that happens in HTML. And so we could like obviously that drop down is going to be capturing like enter is going to select and then when but when we close that dropown the focus probably is going to move to the search bar which will probably have its own event handling where we can treat enter as search. So I I think it's quite we we can use enter for two things using whether that dropown is open or not as a distinction. Like if the dropown's open enter is going to add the new item. if the dropown's closed, it's just going to trigger the search. I think that's really intuitive. Like that's at least intuitive for the very keyboard oriented users like the person who reported this issue. And I don't think that's that's not going to add any duplicate path or that's going to trigger the exact same search functionality, the exact same stuff that's getting triggered when you click with the mouse and you click the search box. Yeah, I think this is very I don't know if Dash I don't know if Dash like has that great like I don't know if this this will be possible in Dash but it's worth looking into. >> So I know it's not I know it's not a sweet design but sometimes in cases like this a button. >> Yeah, that's what I was thinking as well. Yeah. Yeah. Yeah. >> Literally the search button. That's where we're >> except it's on the left which is also something. >> It's not a button though. Yeah, >> it's it's I understand what you're saying, Kelly, but it's it doesn't like intuitively feel like a button to a user. >> Yeah. >> Okay. >> I think my my biggest I I think this is very solvable. I think we should do this. My only question is like when and like like we've got a very researchable problem of like okay, how do we how do we handle these input events in this way in Dash? And I think that's doable. It just needs someone to have time to do it. >> Like Cali and Co. Do we think that's going to fit on our road map or like maybe maybe Kyo next week or >> Yeah, I think it's a good Kio thing for next sprint. I think that's a good sizable task. >> Yeah, I agree. Yep. >> Okay. I can I can task myself with going and updating this uh issue if no one objects. Um just to add add the results of this discussion and like assign it to Kyio. Um, sounds good. >> Yeah. >> Um, Adrian, when you get a chance, can you review Kaio's PR, the heat map one? I think I think we're close. >> Yeah, I tried to do that the other day. Um, and my computer was doing that stupid Podman thing where if I change networks, it the containers stop being able to talk to each other. Um, I probably should have restarted my computer before I brought my like emergency instance collection back up. Um, but yeah, that's that's basically just blocked because of that stupid Podman bug and I don't like and now I've got collection halfway processing. I don't really want to start pietorrch collection from the beginning again. Um, >> yeah, I understand. It's just cuz >> I like I just want it to be tested not in a Mac. Like you're you're the one person on our team that's not running on a Mac. So >> should you should go grab those API keys though as Cali suggested because then you will not have to wait as much. >> Yeah. I can't restart the instance to add the API keys though unless >> Okay. Yeah. Okay. It's it's I mean I I can I can try and do that if I >> get forced to restart it or whatever, but I'd like to get it through collection and then like if we need to add more repos and collect more faster then yeah I >> this is this instance is a very like temporary like quick fix. Like I maybe wasn't thinking it's set up through fully cuz like I'm not really anticipating this is going to be a permanent DB. It's just like a tiny tiny DB that we can just >> get things working. >> I guess I I do think it does seem like this might I mean you go from one key to 20 keys um that makes a pretty big difference if collection is really slow. I think it's just if I I'd say let's let's say by the end of today if you're still like not making any serious forward progress I think it's worth considering restarting it and putting more keys. >> Yeah. Do we don't use I don't think we have anything in facade that needs the GitHub API that heavily though. >> The contributor resolution stuff is where the that's the only place. >> Okay. >> That's the only place >> and it hasn't gotten there yet. So, it's it's pretty Yeah, >> I don't know what uh Okay. Um, I'll keep an eye on it and see see how it's doing. But, >> um, yeah, we'll have to Yeah, we have to think about this because I just don't want Kyo to be like, we've been Yeah, just not wanting to be blocked in other areas, but I understand why you don't want to restart your computer. >> I could probably do it. I could probably test it on my personal machine, maybe. Um, I need to figure out how to get all my like API keys and set up over there with my like get all up or something. But >> just wanted to update as well, Kylie, on that uh that second issue as well on the larger repos. Uh, I've been able to like test pretty much like all of the like PyTorch and all of the repos and orgs that you put there and it it kind of like loaded fine. the the waiting time was not like ideal but it it loaded uh and I checked with >> you like so whenever you look at the like so the so you're sure that the graphs are actually populating with the correct data and now >> yeah yeah I I updated yesterday like the issue there with like screenshots and I have more like that I checked on the prod instance and it was like the same so it was able to it was able to load I think what was happening also is like the soft limit it was exceeding the soft limit on the work uh the workers call back. So 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. So I was like I just updated that as well and it kind of like get rid of like the the issue but the problem is because it was exceeding this time. Uh yeah, sorry agent. I I'll try to be fast like uh so it because it was exceeding this time uh it was kind of like the worker call back is it was being reset and reloaded. So when it reloads the app, it goes back to chaos like as a default. >> But but uh after like uh increasing like the the soft limit time, I was able to like load all all of the like the options that you've put there. So >> I think it should be very solvable. Yeah. >> Yeah. Um, yeah, put a PR in whenever you get a chance. We should definitely do that in our our instance and I'm sure that impacts um Sean as well. Um, but what you're saying makes complete sense with the behavior that like that. Yeah, I >> I feel pretty confident that that's the problem because that's you would see it with the with the screen and it would do that like load thing and then it would go back >> and so yeah. Sweet. >> All right, >> that's good. >> Yep. Um, final quick announcement. I know I think Sam put this in Slack. He wasn't able to make it today, but they um >> there he's one of the contributors in the University College London. They just submitted an application for that um UK grant research grant thing. >> Yeah. >> Um so that's went in and I think they're expecting to hear back by March 20th. So we got >> a pretty fast turn. >> My grant micro funding cycles are not that fast ordinarily. So it sounded like it's just like a hey, we're actually interested in you filling out a full application. >> Yeah. It's like it's like write send a letter and then if you they like they'll invite you to apply I think is what what the hearing back by March 20th is for. So, it's there's still a lot of process to go, but I'm I'm excited for the possibility that hey, maybe maybe their team gets funded to basically contribute to Augur for a few months. Like, that's going to really help us like get a lot of this tech debt down, like get >> re like really get a lot of eyes on parts of Augur that haven't had >> comprehensive eyes on it for probably years at this point. >> Yeah. No. And I can like Adrian I feel how hard it is that you're doing so much more time on Augur than everyone. So you feel a lot >> for me. I'm getting paid. >> My job doing this. >> I know. I know. But but it's still it's like it's a it's sort of a you're learn but you're you're doing a lot of great stuff but you're also learning about it. >> Yeah. and and so I know that it can feel like getting stuck in the mud and um so yeah I agree if we can get some more people to help that would be fantastic. Yeah. >> Sweet. Well thanks thanks guys for attending this meeting. >> All right. Thank you. See you catch you all later. Bye. Right., Augur/8-Knot WG, March 3 2026, YouTube, 01kp8gw0vfwz1sd5hjavg8t1sy.