- Duration: 29 min
- Platform: zoom
- Source: Read.ai 01J923092BPZD6NV2HGFGDATJ5 (https://app.read.ai/analytics/meetings/01J923092BPZD6NV2HGFGDATJ5)
Transcript
[Michael Houck]: Hey, Mo, what’s going on, man? MJ: I’m fixing it. [Michael Houck]: How are you? [Rafael Bruno]: Hey, guys. [Michael Houck]: No, no office today. [Rafael Bruno]: Oh, my wife is having a meeting, so there is I think it’s from a movie called Highlander. There can only be one, but in that case, There can only be one immortal, but in our case, there can only be one in the office having a call. [Michael Houck]: That’s fair. That’s fair. Good reference. [Michael Houck]: Sid, how are you doing? [Sid]: Yeah, doing good. Going good today. How about you guys? [Michael Houck]: Yeah, good. All right. Well, I think, I don’t know if Response can join us, but Yeah, guys, great job. Like just taking a second. It took us way longer than we wanted, and it was probably way more stressful for you guys than you wanted to be. But we really, really did a good job with this. I keep getting people emailing me saying how much they love it. I’m adding some of those to the channel, but there’s more than that too. And the amount of bugs is very low, at least from we’ve seen so far, and all minor stuff for the most part, except for the one scraper thing that we fixed last night. So yeah, I’m really impressed. Great work. [Rafael Bruno]: Thanks for the support, Sid, Mehul. You guys did a great job. [Michael Houck]: Yeah, team effort for sure. Cheers, guys. We need the pizza party, Mehul. Where’s the pizza, right? [Michael Houck]: Cool. Well, look, I think this week will probably be, since we don’t have crazy bugs, I think it’ll be pretty late. And I think the next few weeks will kind of give us a chance to be a little bit lighter after like a month or two of a lot of work and a lot of stress. So I think it would be good. So I added stuff to the sprint. I can share my screen in a second. But I think first, we’ll just get through these initial bugs. And then we can dive into, Rafael, for you, the referrals page. Sid, for you, the inner circle launch. And we’ll do the front end for both. So we’ll see where we get to this sprint. But I also added a bunch of old scraper tasks in here for Rizwan. I messaged him about them. They’ve just been lingering for a while. Just good for us to kind of take this moment to go through the backlog a little bit there and finish that project up. Once RISC-I finishes this backlog of Scraper stuff, we’re going to be trying out a new addition to the model where we’re going to give some users the option to automatically schedule times for when we should look for posts from them and have the scraper look at that time and pull in the post and start initiating the matching with creators automatically. So that way, no one needs to go in and even bother to send the post themselves. It can all be automated. So we’ll see. But we’ve had some users ask for that, and they’re pretty excited about it. So I think it could be a good addition to the flow. Test that out probably next month. And we’ll spend this month sort of building an MVP with RISC-I. If it goes well, then we’ll build it into the core model and turn you guys loose on it. So we’ll see how that goes. But just want to keep you in the loop with sort of that experiment that’s kind of going on in parallel. [Michael Houck]: Let me share my screen. And then. We can just sort of go one by one and you guys tell me. These are the bugs that we have on here right now. Rafael, you added these earlier. And while you added this change about the emails, that’s a little lower priority than any bugs, but still important for us to do, because it gotta look good. So. Yeah, I guess. Rafael, I’ll start with you. I know you have these going on. I know the Typeform stuff is kind of annoying. But yeah, just give me a heads up, your kind of read on where we’re at and what you’re working on. [Rafael Bruno]: Okay, so first impressions, I think we are good when we look at the integration with the UI and the backend, because as I shared with Hauk, I think we have like five issues going on right now, but only four of them are from Typeform. And one of them is related with some email stuff that I didn’t fully test it. So it’s good to know that really released a whole new version and replace a lot of the code base. And we only have like those three issues going on. About those bugs, I’m taking care of them. They’re a little bit difficult to test and to find where the issue is, but I’m still working on them. And I expect to have them solved by tomorrow. [Michael Houck]: Cool. Sounds good. What about the scraper? Is the integration with that working? Everything good? Any concerns there about engagement statistics being logged or backup creators being messaged or anything like that? [Rafael Bruno]: I sent the message to Rizwan. He told me that he would let me know when everything was ready, but he didn’t message me yet. Regarding the backend, everything is ready. He just needs to to adjust some stuff on the scraper part. [Michael Houck]: Okay. Can you stay in close touch with him on that? And once he’s done, then we will need to do a data cleanup for any broadcasts that were shared between the launch and that time. Basically, we’ll need to log engagements. We’ll need to log any statistics about the post when you update their statuses. Basically all the stuff that Rina does manually. So maybe touch base with her and just see if there’s anything else that needs to be done too. But yeah, cause people are going to be curious like why the dashboard isn’t updating for them and stuff like that. [Rafael Bruno]: Sure. I’ll do that. [Michael Houck]: Okay. Let’s, let’s make that a priority. Cause I think that’s probably higher priority than the type form or the email stuff. [Rafael Bruno]: Okay. [Michael Houck]: But I know it’s obviously it’s on Rizwan. So just stay in touch with him and keep me in the loop. [UNKNOWN_SPEAKER]: Okay. [Michael Houck]: Sid, what about from your perspective? [Sid]: Yeah. So currently I’ve started working on the groups thing, which is in a circle and it is going good. So I’m working on the API part. I think we discussed the flow earlier for the MVP. So that is, I mean, I know what the actual flow is. I don’t have I mean, I just have one question. And I don’t see the design for that groups for the like, for example, if you have created your inner circle, and if I request to join, then I don’t see the Figma design for that page. So is it ready? [Michael Houck]: When you say request to join? What do you mean? [Sid]: So for example, you created your inner circle, you signed up and you order your inner circle got created. Now there’s this feature as well, right? That you can share your link, your inner circle link with others. And then if you shared with me, I will be able to request to join. Right? So that’s, I couldn’t see that because I’m developing, I’m, I’m writing API logic based on the designs. That’s right. Yep. [Michael Houck]: So the one difference there is that with inner circle, if I’m I don’t need to then request to join. I accept the invite, right? So that’s like a functional difference. But with that said, they still need to see a screen when they click the link to join. So I guess that screen wasn’t done. Maybe I was in oversight on my part. So I’ll work with the design team. I’ll make a note to do this. Group with design team on inner circle acceptance. [UNKNOWN_SPEAKER]: screen. [Michael Houck]: Yeah. So we’ll get that done. That won’t be their project this week because they’re already working on something else, but they’ll do that next week. So we’ll have that, uh, next week. [Sid]: Okay, cool. I mean, that, that’s the only difference, right? Like if I, if I’m joining through the shared link, then I will be automatically joining the group. [Michael Houck]: When they click the link, they should land on a page that like explains what inner circle is, what megaphone is and all that stuff. And then they click a button. On that page and takes them into the onboarding flow. Or if they’re already a user, it just accepts the invite for them. [Sid]: Okay. So they will be automatically approved in the, in the inner circle, right? [Michael Houck]: Yes, because they were invited because they have that person’s link. [Sid]: Okay. Okay. And how will that invite be shared, like through mail or, or just a separate application will be open because on mobile we can open the new application, WhatsApp, Telegram, but on a desktop, how will, how would that be? [Michael Houck]: Right. So it’s, it’s just what, why would you open WhatsApp or Telegram? [Sid]: No, no. I mean, if let’s say you, you are on that, your profile settings page, and then we are showing that in a circle link in their design, and then underneath that are icons to share the link through, through WhatsApp, through, through Telegram, or even mail. Right. If you’re on a mobile and you click on one of the WhatsApp or Telegram, then WhatsApp app will open and then you can just select the contact to share with. My question is, on a desktop, how would that be? Or would it be? [Michael Houck]: Yeah, I guess we wouldn’t show all of the icons on desktop. So I’ll tweak the design for that as well. [Sid]: OK. I mean, I wanted to design the back end in a way that would send the messages across any platform. [Michael Houck]: But I think we don’t have to worry if it’s not they’re on desktop yeah I think like I mean there is a telegram and I think there’s a whatsapp uh desktop app too but it’s probably just easier to not show those I think it might confuse people they don’t already have those apps I don’t think they’re super common on desktop yeah yeah okay I think I’m clear I’m I’m just working on the api so one thing uh about [Sid]: creating group creating inner circle group on signup is completed I’m working on the other part where you actually That one is in progress. That is going good. I don’t want to block. [Michael Houck]: Can you make sure that the linear tests are updated? I think there are tasks already in the groups MVP project for all of those things. But if they’re not, you can just add them. [Sid]: I think, OK, OK, I will check the ticket and add more tasks there. [Michael Houck]: Yeah, because if you go in here, there’s a bunch of these tests in here. Maybe some of them are outdated, some of them apply to the bigger groups launch that we’ll do later, not inner circle. But there’s probably ones in here that reflect what you’re doing. So if not, please add them so we can keep track. [Sid]: Yeah, yeah, sure. I’ll do it now. [Michael Houck]: Cool. Okay, great. Emma, how are things on front end land? MJ: I guess everything is good, going good. I was just trying to fix a couple of bugs I already fixed. Most of them is trying to edge case scenario. And right now also pointing me a few, a few issue that a user was going to the older password flow because they are not aware of that. Like we, everything will merge into the single, single part of it. So I am just writing the logic. So if in case if someone going there, it will automatically redirect to them, to the create account that we have currently as a V2. And one more thing Rafael, Rafael given me about some of the dashboard where the round of problem was having. So I’m just fixing that as well. [Michael Houck]: Okay, cool. And after that, just let me know what’s thing that we can pick up. Yeah, I think I tagged you on the stuff in here. The main thing is the group screens and also the referrals page screen. That should also be in Figma already and ready to go. So those are the big things for this sprint, like the group detail UI, And I might actually tweak the group detail UI for inner circle specifically. I’ll make a note for that. So are you, are you deleting the group first and then refiller or referral first and then group? Sorry, what’s that? [UNKNOWN_SPEAKER]: Yeah. [Michael Houck]: Um, I guess since there’s some changes to make on the groups one, you can do the referral one first, cause that’s already totally set and ready to go. Um, or the groups one, I’ll make some changes probably to tomorrow or Wednesday, and then you can come back to that either later this week or whenever. MJ: Okay, perfect. I’ll start and refer that page. Does the referral page backend was ready or it’s still not? [Michael Houck]: Backend’s not ready yet. Rafael’s just going to get started on after these bugs. MJ: Okay, cool. [Michael Houck]: Cool. And Rafael, one other thing to note, I moved the pricing change to next sprint. Sprint, let’s just focus on referrals page and do as much as we can there. And then we’ll update the pricing situation for next sprint. [Rafael Bruno]: OK. You meant the subscription? Yeah. Those pricing issues. [Michael Houck]: OK. There’s a group with sub-issues here. It’s all these tickets. Update pricing structure. OK. Cool. Yeah, look guys, I think it’d be an easy week. Hopefully we don’t find any critical bugs, but honestly seems really smooth so far. We’re a couple of days in, so I feel pretty confident. So yeah, I’ll keep you guys updated if we get any more support tickets coming in from users, but been pretty light so far. So again, nice work. [Rafael Bruno]: Thanks. Thank you guys as well. MJ: I’m going to hop off. [Sid]: I just shared your message just to confirm these. This is a scope right as I create tickets accordingly for each of them. [Michael Houck]: Sorry, what’s that said? [Sid]: I sent you a message. This is a scope right? You shared earlier for four tasks, so I’ll create linear task and that group will be accordingly. [Michael Houck]: Let me get back to you async on this. I’ll reply after I have a chance to read your message. [Sid]: Okay. Cool. [Michael Houck]: I’m going to hop off. If you guys have more to chat through post-launch, feel free. But yeah, I will see you on Slack. [Rafael Bruno]: Hey guys, do you have anything to discuss? MJ: Rafael, one thing, right? So is there any way like we can have some Thresh ID? So what happened, right? So recently I got couple of issue from the Rhino and in post-hoc also we don’t have recording for those user right. So seems like very I’m finding very difficulty like what is the scenario that user has let’s say which API I do we log the stuff in Slack but it’s very difficult to get into it and to find the actual users any of it. So I also exploring if something but they are saying like it’s mostly through back end that we have trace ID from that. So that if we put it, we will get to know. [UNKNOWN_SPEAKER]: Okay. [Rafael Bruno]: A trace ID. Like, uh, okay. So each request will have a single user. MJ: So that if in case we can get to know, like, okay. User does first make this API call. What is the response? And then this API called this API called. [Sid]: Okay. I can do that. [Rafael Bruno]: Go ahead, Sid. [Sid]: One question, sorry. So without a post-hoc, will you be able to find the trace ID of the user of who is in production? Because without post-hoc, we won’t be able to get the trace ID of the request. MJ: No, I was not talking about a post-hoc. I was just talking about like any other custom implementation where we can find them. [Sid]: saying let’s say there’s a user Rob, a hawk at the Hawk news, right? If we don’t know what action they’re performing, we will not we’ll also not know where they are the trace ID of the request, right? So if we don’t know the trace ID, then we like we won’t be able to see the user journey in the in the API’s what all API’s were called or what all methods are called in the logs. MJ: But when we when we have email right from email itself we can query it, right? And from the user state, pass the TraceID, right? [Sid]: So you’re saying TraceID should be saved in the database and same ID should be logged every time? MJ: Will remain same for single users only, TraceID, unless user logged out and logged in back. [UNKNOWN_SPEAKER]: Interesting. [Sid]: I was under the impression that TraceID changes with each request. No, no. MJ: If we change it, each every other request, right. We’ll not able to check the journey of the user, but I’m still not sure. I allowed to maybe I’m not sure. Like I’ve done like from past couple of project, I seen this kind of scenario where you used to like just based on a threshold ID or request ID or TRK ID. It helped us to define something or else maybe if the only reason is right. We do have a good amount of logs. But the finding the issue in Slack, it’s very challenging. [Sid]: Correct, correct. The problem I see, and even Rafael, you can jump in. So the problem I see, let’s say if we just keep one ID, right, for one user at a time, and if we go back in the past to see more logs in the past, like two days, logs from two days before, then there would be multiple IDs and we would not be able to know which ID belongs to which user. Because if the ID keeps updating, one ID only at one time, then two days, if we are viewing logs from two days before, then we would not know this ID belongs to which user. So I think this also calls out to one thing, Rafael, if you have worked with Sentry. [Rafael Bruno]: I’m not sure if this is the case, Sid, because for what I understood for Mehul’s request, We need one ID per request, right? So we can see on the logs what is happening on that specific request. I don’t see why we need to, of course, we won’t just log the ID. We will have some other stuff like the user ID and et cetera, so we can identify the user. [Rafael Bruno]: I didn’t understand your your concern. So could you please explain it again? [Sid]: If the ID keeps changing, right race ID, if the if the race ID keeps changing, then if we if in case we are viewing logs from the past to the logs, which were logged like two or three days before, then at that point, the ID would be different because in the last two days, ID has ID may have changed. [Rafael Bruno]: Oh, not only they will be different, but on the same I would say on the same second, not the same second, but for each request that they make to the backend, the ID will be different. So if they make a request to get the wallet, their ID will be one. And if they make the request to get the wallet history, the ID will be another one. [Sid]: So let’s say there are two APIs, wallet API has ID one and wallet history has ID two, okay? The trace ID will always be the latest one. So the user ID will have trace ID as two, correct? [Rafael Bruno]: No, the trace ID will be ABC for one and DEF for the other two. [Sid]: Let’s say that, let’s call it request ID. The request ID is specific for that request. Yeah, yeah. So basically we are allowed to save the request IDs in our table as well for all those users. [Rafael Bruno]: No, we don’t need to save the request ID. The purpose of the request ID is just for logs so we can accompany the request ID journey of the user. So if the user is calling the wallet history endpoint, and we make like, I don’t know, 10 logs on the channel app info on the wallet history endpoint, we can accompany the sequence of those logs just querying by the request ID, but just on Slack. We don’t need to put that on the DB. [Sid]: Fine, Roger. [Rafael Bruno]: Sid, you were telling us about another thing. [Sid]: I think I’m clear. I’m good. [Rafael Bruno]: OK. One thing, when you are implementing the groups feature, let me know if you have, if you want to integrate something with the broadcast flow or sending messages because I can tell you the right way to call those APIs. [Sid]: Yeah. Yeah. I was just looking at those APIs. I think that’s pretty much clear with the new refactoring and all that stuff. But still, I think I’ll be able to take it. If I, if I have any questions, I’ll reach out to you. [Rafael Bruno]: Okay. Thanks for that. Okay. [Rafael Bruno]: Does anyone want to discuss another thing? [Rafael Bruno]: Okay. Good job, guys. See you later. Good job Rafael.