So it is the SEC, meaning secure and govern, growth and data science, meaning applied ML, ML ops and anti-abuse team meeting. That's a big mouthful. We might get a better name over time. And that's our meeting for September 14th or 15th in APAC. And hi, Alan, glad you're here. Why are you here when it's midnight? We can talk. Glad you're here. Don't make it happen to come to this meeting since it's really late for you. But I'm glad. Thanks for coming at least once. So News and events. I've got a lot of things on the agenda today because of some of this. So apologies for that. I think it's going to go down over time. Based on feedback. I'll work. I'm going to work to do more summarize communications to improve the signal to noise ratio and my communications to groups of people, including this group of people. This was wrote in for this group, adding more items to our staff meeting agenda, often as read-only, rather than posting to our Slack channel. And I am going to be assuming that people leaders on the team will attend this meeting or read the notes and not rely on the Slack channel. So keep that in mind. Let's see, B is a read-only item, unless anybody wants to discuss it. And C, Phil has.
Hi, welcome, Alan, to the meeting. I've asked Alan to step in as acting full stack manager for security policies while I hire an EM. Alan has graciously accepted this wonderful opportunity, so welcome Alan. Thank you. I've got the next item as well. So anti-abuse is moving product sections from SEC to data science. Data science is effectively a rename of the Model Ops section. So data science will include two stages. The existing Model Ops, which has three groups in it, which Mon can talk more about. And the anti abuse stage, which only currently has one group, which is called anti-abuse. I think at some point there are plans to split anti-abuse into two groups, but that's not in the near term. And we're working through all the changes around that. There's lots of workday changes, lots of handbook changes. Mon, did you want to say anything more about data science or ModelOps?
No, I think for us, we just roll up to data science. Everything else stays the same. We still have the two main groups, Applied ML, ML Ops, and then later Data Ops as part of it, yeah.
So, thanks Thomas, for continuing to compile and report across all my teams that I'm responsible for in the engineering allocation meeting on error budgets and reliability and security incidents. So really do appreciate that.
Gotta give Neil a high five too. He does half of these now. And apologies for the noise if I keep asking for what's the story behind what's going on with reliability or error budget stuff. Just trying to provide air cover.
And I apologize, Neil. I totally forgot you took half of these since Thomas has been doing it for so long, but appreciate it, Neil. I know you volunteered for it and we discussed it, but I just forgot.
Kind of a thankless role, honestly. And I volunteered because of the exposure I get from it. It's nice to be part of a different collective group of people. I was going to mention, I'll type this in here, but Tiago had set up for container security a bot that weekly, I think it's Mondays or like Sunday, will ping the team and ask for a volunteer to go and resource that data and we just enabled it for Threat Insights. It's actually pretty sweet and it just it does all the work for you, Thomas, right? We don't have to ping people ourselves, so I'll put a note in there for that.
Pete, GAP is read only and Bill you've got G.
Yeah, talent assessment. So we had an update from Juliana. The dates haven't been confirmed yet, but it'll be sometime from mid October through till December. I think eGroup sign off is expected to be mid December before everyone goes on holiday. They've got a draft timeline in there, but the dates aren't in the handbook yet. The big change is we're moving to do it in Workday. That's not available yet. I haven't seen a demo of it. I don't know what questions will be asked, but there's an optional self evaluation which will move into Workday and The work that we do as managers will also happen on work day. At the moment, some people are using the Google Doc, which is listed on the Talent Assessment page for self evaluations and for the manager work. I'd suggest continuing to use those docs until we get access to work day and see what the exact differences are.
Each I enjoy read only, unless anybody wants to discuss them. Thomas. Yeah, I didn't care.
Yeah, apologies for the late, like live addition to the agenda on this one. But one more note on a change we're rolling out within Secure, pretty lightweight, in that we're establishing a second team within dynamic analysis. And so, issue is there for folks that would like to follow along or ask any questions about it. For the plan for right now, is I'm going to be serving as a team acting and in addition to normally scheduled. Some duties for lack of a better way of putting it. And so happy to answer any questions folks have about that.
I had a quick question. We've done the same thing in Threat Insights with Neil and Tiago each having teams. What are you gonna call your new team or how will you differentiate?
Was not planning to differentiate it. It's just a second team within dynamic analysis. We're not creating a new group, which I think is the same pattern that's happening within Threat Insights as well. It's just two teams. No, I know that there's Tangerine and there's Navy. I'm not a Tangerine person myself. So we'll
Yeah, I don't know if there's another T color, Thomas. I struggled with that one, but that's the theme.
Tomato, I don't know. We'll figure it out.
The differentiation, I think the difference between what's happening in Threat Insights and within Dynamic Analysis is that this is a split along feature category. Even though we're keeping that we're not spreading a new group, the distinction is along who's working on specific feature categories themselves. So, where the fracture point is happening is a little different, but the approach and effect are the same. I hope.
So on to big rocks and hot issues section. I don't know if it's a big rock, but kind of belonged here perhaps more than other places. So I did that survey where I got an awesome response rate from the team on how to improve the MR rate for the team. And then I took a really long time to go through all the results and summarize and make initial recommendations. So I lost a little bit of momentum. I got caught up in other things like cross-functional prioritization and the customer escalation. So since then, this is actually used by John Hope to lead a discussion at the development offsite last week on just improving engineering velocity is one of the things he used to power it. So it had value there, But I've seen no comments, I think, from anybody in this group, which means either no time, forgot about it, or it doesn't, we looked at it and it doesn't have much value. And any of those things are okay. I'm just curious where the group landed. And if you haven't taken a look yet to see if there's anything you wanna take away from it on things you might wanna consider, I'm asking you to do so, and to consider, not to do, but to consider. Anybody got a chance to read it yet and think about it or not just yet? It's not. My guess is perhaps everybody's really busy and they haven't looked yet.
I mean, at a high level, Jay, Neil, Tiago, we've talked about changes. I think Jay, you've already looked at some changes around refinement. That was an area that you were going to look at for anti-abuse and report back by the end of the quarter. Tiago and Neil, I can't remember what we ended up with for 3DM science.
Yeah, I'm hoping that MR rate is kind of an artifact or byproduct of some other actions. The big thing we're doing is more whole type of work like random miscellaneous not scheduled not PM necessarily, actions or issues. And that actually is creating some more additional work. Like it's just like free time work. I wanna change of pace, move to something else momentarily. And these are generally smaller types of issues too, so they're quicker to knock out. Therefore they create more MRs, which has been a cool by-product. So I think that's helping us succeed there.
Yeah, we're also seeing some success with, we've implemented like a weekly refinement meeting to kind of check in, make sure that stories are broken down tiny enough. I think with smaller bits of work, we're seeing a higher MRA. It's debatable whether or not that's like just inflated, right? Like you can work on a small piece of code and ship it, and you can do that a lot of times you're going to get a higher MR rate, or trying to be reasonable with that. I am noticing a nice take up. After implementing the refinement meeting, So let's hope for the best.
Go ahead. Sorry, I was gonna say one note on refinements in static analysis, we're experimenting with a new section in our planning feature. It's called Looking Forward. And in there, we're using that as a baseline where we add issues that we think need refinement that will most likely be worked on in the next one to three milestones. So we're using that as kind of a base cover for some engineer to go in and add their issues and make sure they get refined within this milestone. Not necessarily any implementation, but just refinement itself.
I should stop talking on mute. Thank you, Omar. Thomas, you want to verbalize your comment?
Yeah, I'll verbalize and then I'll say more and then I'll finish writing what I was going to put down underneath it in just a moment. So this was an agenda item with the EMS and I can say it now in the secure stage, since that is the analyzer teams now. So this was a topic yesterday. So I would assume that this is more like I had a chance to read but not digest the content. And what I was about to write, and I am cautious in saying this because it almost comes across as smug, and that is not my intent. In that, looking at the MR rate within SEC compared to company-wide, historically, it runs two to three MRs per engineer per month higher. And I think a good bit of that has to do with the, I mean, we've taken this to be true, or at least asserted it to be true in that it's smaller teams that are working closely together in less busy projects than we see within the Rails platform itself, which does have an impact. It's, that's not to say that we cannot do better, but the comparison, The favorable comparison, at least to me, and I will admit this, at times will lessen the urgency on this particular topic. And I have to admit that bias that I have.
Thanks, Thomas. Thanks, everyone. So, I didn't see any comments on the issue. That's totally fine. People found some of it useful, some of the analysis useful, and that's great. So I will close the issue accordingly and just link to these notes. It's good stuff. Thomas, you've got item B.
Okay. I'll write after this then. All right. FedRAMP and the can't or won't fix security issues that we may be having. We've got them for security issues that are subject to FedRAMP. If you have a feature category that is FIPS compliant or certified, you're probably going to be part of the FedRAMP evaluation and any security issue that has a CVE associated with it, which means dependency or container scanning specifically, has to have a remediation plan, even if they're false positives. That's led to a separate discussion on what do we need to do? Do we need to do anything related to security findings on the commercial versions of analyzers specifically. That was the catalyst for this particular conversation because on container scanning, we get a lot of findings related to Debian based images that that project has not shipped a fix for or won't ship a fix for. So there is a separate thread that is going on here about what to do, and can we do deviation requests in bulk for this class of findings. The TLDR is below, and there's a couple of options that are being brainstormed within this particular thread. So I wanted, and I know I've said a lot of words, and I didn't say it well, but I wanted to bring it here in case there was any questions or commentary.
Nothing directly related to what you've just talked about, but sort of related. For FedRAMP, you're looking at any FIPS related security issues that have been raised. How far are you going in terms of auditing to find anything that hasn't already been identified?
There is, I'll link in another issue, a separate issue that has instructions from AppSec on what they would like us to do as far as setting up container scanning. And They have set up a project with a single configuration that they're asking us to use. There is some debate as to how that project has been configured because it uses a combination of three container scanning tools rather than one. And so they've asked us to use that as a baseline for the FIPS images specifically, since they're UBI or the UBI specific images. They're equivalent in my mind, even though they're different meanings.
So TLDR, talk to APSIC, got it.
Nikhil, Nikhil George is our stable counterpart of Focus on No, at least in SEC. And so he has been quite responsive and keen, and he is also helping chase down answers when he doesn't have them. So that's a big,
he's been a big help thus far. Yeah. Big help thus far. So in Thanks for bringing this up, Thomas. So in the hallway, so from the development staff meeting, I copied and pasted the notes in there, but NED is, the TLDR is, can folks, the request to me and my peers is can folks check with their teams to see if the approvals are affecting them? So this is the new approval rules on segregation of duties. So I asked this group, not that everybody's here, but in the group, and they shouldn't be, as all meetings are optional. But has this had an impact, these new approvals?
Anecdotally, I've seen a few cases where team members have realized that they need to get an additional approval, but I'm not aware that it's actually slowing things down.
OK. No news is good news on this probably, unless we're missing, unless it's happening and we're not noticing it, we're just slowing things down. But just keep an eye on it in case it does. Everyone, please. It's good stuff. So With recent changes, we've done a couple of different changes with secure and govern broken up from secure and a data ops team and this and that is, I just compared the name of my team with my peers. My peers have one word team names, ops, dev, create, et cetera. Mine is growth and data science, which is pretty wordy. It also makes it so that when I go into dashboards, I have to pull data from multiple places across my teams. So I was thinking about a one word name. I've started to get feedback on it. Naming things is really important at GitLab to name the right kinds of things and give them good names. So I'm going to run it by David DeSanto tomorrow. He's a great person to bounce such things off of. I landed on enrichment because what we do makes other things better. We enrich them. It's kind of a very broad term, but it does cover what we do. Not sure we're going to change the name, which I'm not sure it's going to affect anyone but me. That's actually my intent is it only affects my stuff not everyone else's. But maybe everyone else's in a small way, or others in a small way but we'll see. Any thoughts on this good idea bad idea. I'm not way to this. I'm looking for feedback.
Yeah, obviously the other examples relate to either sections or stages, Whereas enrichment doesn't. So you'd be introducing something new here. This affects me as well. I have a subset of enrichment, so it would be kind of enrichment light. I'm not sure. I'm not sure. I think you and I have spoken about this. I'm not sure we would get approval to introduce a new name or department level. We'd certainly have to talk to PeopleOps about introducing that in Workday.
OK. So a couple of things, you know, these kinds of things I would sometimes put in Slack, but I'm trying to avoid a number of distinct Slack messages, so putting it in here, making a lot read-only when possible. So, I've got C, though it's not read-only. So, I would like to add announcements of work anniversaries and new hires to the meeting template. PM does this. I attended the PM staff meeting. I was a guest speaker there this week. And the camaraderie, we have good camaraderie. The camaraderie there was pretty good. Fern, who's shadowing me today, I think he sat in on the PM meeting as well. It was a pretty good feel of just people really knowing each other well and getting along well. So those are just two things I took away from it is anniversaries and new hires. I'll verbalize Tiago's comment. Great idea for new hires, don't care much about work anniversaries, We already have a bot for that. What I'd say is I always seem to miss the bot announcements as they cover the whole company versus a bot just announcing for our team. If no interest in that part, I'm happy to exclude. So Neil, you like the idea of adding
anniversaries or you don't?
I mean, just last week, I think it was Phil celebrated his third year and I congratulated him but then I missed another team member in sec, cause there's like 20 people on that list. Plus it's team member updates. That's not a channel I look at a lot, like weekly. I just happen to see that the day of. So, I do like being able to celebrate together in this group.
Maybe also thanks or praise section, like thanks for doing this. Great job on that. To remind ourselves to do that as engineers, we tend to focus on the problems and challenges and not the celebrating the wins.
Are you suggesting that we add new content into this document for that, or that we just link to the Slack announcements that we've already made?
I think it's nice to verbalize them. So maybe link to the Slack announcements, but also verbalize it. I know it sounds like a bunch of busy work. I don't want to do things twice. Maybe we add the sections and people use them as they see fit. Whatever that happens to be. But please don't over, don't create busy work for yourself either. So, it's a judgment call by each person. Thomas, it looks like you had a, Thomas and Mon, you had some thoughts on this too?
Yeah. I like it. We don't celebrate enough. We don't do enough for team cohesion, team celebration across the board. And just as a corollary related thing that I haven't communicated well, I was hoping to add this kind of thing to our monthly section wide retrospectives, new hires, discretionary bonuses, work anniversaries, big feature releases. I mean, anything that we want to announce and celebrate, we ought to make sure that it's, I don't want to say shout to the rooftops, but, or shout to the heavens, but they're big deals and we don't make and we undersell. In my opinion. Yeah.
Oh, sorry. And hey, Fernando here. So I'm shadowing Wayne now, just to introduce myself from the technical marketing team. And I'll send the document right now, which is something that we do for our kind of get together team meetings. And it kind of shows, you can look through it. I shared it to everyone on the Zoom chat. But you can see that we provide updates, the new team members and small little introductions. And you can see sections that we have on gratitude and actual spotlights that we show like who we're actually praising, what they've done that's good and how we can highlight that because that will motivate employees kind of really increase that morale because what we're seeing is these employees are actually getting recognized for good work that they've done and they're getting shout outs because a lot of times, at least in our team, the case is we don't really, although we work with each other, we sometimes are kind of siloed busy working on different things. So it's good to know what everyone's working on and what everyone's doing. So somewhat related to what you were just speaking on, but just that I'd share that.
Thanks, Fernando. Doing D, so I'm not going to read all of this from Daniel Croft, But summarizing, he is looking for feedback on the development vision and mission and direction. We're brainstorming in the development department on mission and vision in particular. The approach is we want everybody to open up a little spreadsheet and follow the instructions, anybody interested. So if you're interested in doing so, should take about 10 to 15 minutes. Please do it in the next week. Good stuff there. Something we covered also at the development offsite that Daniel took as an action item to follow up on. It's good. Thomas, you've got E?
Yep. Because I cannot remember. And so I'm hoping to crowdsource a little bit of configuration archaeology, so to speak. Is there a reason that we don't use reviewer roulette? If folks can remember. The reason I'm asking is contained within that thread, but that is a tool that actually is being used to track if we have enough maintainers on any given project. And since we don't use it, we're showing up. And so that's why I'm asking.
When you say reviewer rule, are you talking about on the individual analyzers?
Speaking only for Dash, we haven't had a need for it because we have six engineers that's just going to rule out the same six people.
Yeah, rule a six-sided die. That's what I kind of think it is, but it's from a larger, like if the company, like where do we need more maintainers is the question that the organization is asking.
I mean, I'd suggest they're looking in the wrong place. If they're looking in Rule 8 to find out the number of maintainers, that's the wrong place. The engineering projects page should list all the maintainers. If you set up your team YAML entries correctly. I would have thought that was more than a single source of trade.
Apparently not. So, yeah.
Yeah, I'm looking at the chart. I mean, I think on some of these projects, we just haven't filled it out. I'll give you like we have the API. Because we have one engineer that works on it. So we haven't gone and added a maintainer there because They know who they are. So if we are trying to maintain that as a single source of truth we need to just go through and scrub it.
Sorry, Seth I'm reminded of this. I'm reminded of the Spider Man meme with the two Spider Men pointing at each other, who's the reviewer who's the author It's the same person. It's been a long day, so I'm a little punchy. But yes, that makes sense.
Seth, are you saying you haven't added it to individual team members' YAML files in the handbook yet?
Right. I believe for that one, there's just no entry for it. I mean, we could.
I think if you do that, that should do it.
it should. They shouldn't be using just roulette. They should be using that as a source of trades, and I think if you've listed maintainers, that should cover it. A follow up question would be, does that does that cover the senior plus engineers must be a maintainer requirement or not?
Thomas, you buried the lead. What do you call it? Buried the lead? I took the read only off your comment there.
Well, we're going to end with the best news of the day. That's all. But the maintainer requirement, yes, it does. Maybe because it's for senior plus, going back to that is just maintaining one or more, I think is the requirement for Member of Berkeley.
I was talking about the Olivier news.
Yeah, I know. I was just making sure we were finished with the topic above. All right. And we're at time, so I will move on and take that as a prompt. Yeah, Olivier has popped back on Slack to announce that the newest edition of their family is here and happened over the weekend. So, big congrats to his family for that. And we'll be hoping to celebrate him later when he
does when he when he returns to work. Google. Thanks, everybody. Have a great day.