GitLab Create Editor Group, 22 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor - Milestone Kickoff for 14.5

Description

In this meeting we discuss the plans and issues scheduled for the upcoming milestone.

A

All right welcome everyone to the editor group, um 14.5 kickoff meeting. I believe that's the milestone, we're talking about yeah and, um as always I'll start off with some highlights from the last milestone and chime in if I missed anything not related to shipping issues, but I wanted to highlight some really amazing collaboration and both async and pairing sessions that have been happening on the source, editor architecture. I've been watching it in as much as I can understand it. It seems like it's been uh really productive and really great to see the collaboration here.

A

So I just wanted to highlight that as a right off the top from the last milestone, something that I think is working really well- and um this is the second most important highlight that I have from the agenda- is I single-handedly without any help from anybody or any googling shipped a huge feature in the content editor, and so I'm going to give myself all credit uh enrique helped me out with and by helped out, I mean wrote 98 of the code that I didn't copy and paste from stack overflow to get color chips to render in the static site.

A

I mean in the I said, static side of the content editor and um meanwhile, while I was distracting him with that also managed to ship a bunch of other stuff, along with the manchu and paul, you contributed the table of contents issue in this milestone, but we also got front matter. uh Himanshu was working on the html tags and got that merged the math markup, which ended up being a little more complex than we maybe hoped it was going to be. You got that across the finish line in 14-4 enrique.

A

So thank you for that and I promise I won't try and pick up too many more issues because uh I felt like mostly, I was just distracting you, but I'm glad you had a little bit of time to help me finish that up. Thank you.

A

B

That we got surprised by the complexity of our ships. We started like.

C

Thinking no, this.

B

Is gonna be easy? It's just displaying a color. Next to our text. It was quite complex.

A

It was I really liked watching you know, being part of the mr and watching the comments go back and forth was nice, even though I didn't see it through. I was. um I was very interested in the path that that took through the feedback cycle, so that was great to watch. um It would have been great if it was as easy as like taking the regex that we use on the markdown parser already in gfm and using it in ours and then just like decorating the element, but it was a little more complex.

A

um We closed the issue um that had ceo interest, the open web id using the period, the dot key single keyboard shortcut to launch the web id from any repository view or merge requests. That's um it's a great shortcut. It's very timely! There's a lot of social media chatter about quickly launching dev environments. So I think this puts us in a good position to be.

A

In the same conversation, um I think it's also just a nice little convenience, not that it was that hard to press the web id button at the top of the page, but I think everybody likes a keyboard shortcut actually.

D

Actually, there was uh one thing that we have: uh we didn't have the open web id button, but now we have the keystroke there like if one goes to commits or to pipeline tab on the logic west. There was no web id button there, but now the keystroke still works there good call I'll.

A

um Maybe I'll amend the release post, but there's another day before that needs to go out. I think this is a good call out. Thank you yeah, and uh there was a bug fix that that you squeezed in there dennis to um fix the syntax highlighting when you create a new file. So that's always um it's always nice to have consistency. There squash some bugs, and then we had a you know a moderately exciting week last week with our company going.

C

A

An ipo so that that also was a something to celebrate from the last milestone.

A

The fact that you all did all of that, while leading up to such a big momentous occasion in state focus and shift code, is great. So thank you for that.

A

I don't think I missed anything at least from this group. Maybe uh I I should say that I don't have a lot of um particular insight into what uh chad and fran are shipping over, while they're on the manage access, but I have to assume they're shipping amazing work, so we should celebrate that as well they're doing very good work over there. I know for a fact that they're making uh progress and making a good impression representing our team well so.

E

Yeah, I can confirm they're doing enough a lot of really good stuff over on manage and they're, consistently closing out, infradev bugs and a lot of linear scalability problems that were plaguing the managed team. So it's it's! I'm getting some really nice feedback from the manage team about them.

A

um I'll just run through our milestone goals. I recorded the kickoff right before I took some pto and um the the general gist of the next milestone is that uh our back-end team is still allocated for manage access, so we're gonna focus on some more front-end stuff uh web id state redesign. I know um we're getting close, we may or may not be wrapping it up, but continued progress there we're very excited to keep working on that um and then paul.

A

We talked about afterwards um a quarterly goal and potentially chipping away at it in this milestone, to establish the goals and uh start planning the work for the graphql observation observability effort, and uh that would be something we.

C

Can start pairing up on or yeah some uh some clarification of? What's what's going on in this realm is uh there's one graphql observability issue that has uh I've been told is top priority and that's so I've had to shelf I've had to do this at different orders than I thought I was going to so.

C

The web id state redesign is not having as much momentum as I would like implying that when it does, it should be, um it should be effective. uh That's I feel bad that uh we planned this out and it's been delayed, but I guess such is the nature when there's multiple priorities, demanding attention and yeah.

A

Absolutely don't feel bad at all. I know the work you're doing that does get prioritized is is helpful and it's all serving for a more reliable and secure codebase, which is our company's primary focus.

A

um We will uh also continue working on some of the source. Editor extension architecture work, the proofs of concept coming out of those pairing sessions and collaborative um feedback sessions. I think the um the specific issues that we have planned are a little white, but we have um we have some some work to find there and then the content editor. We have a few things going on.

A

I think uh so david and I talked about this- might be a good milestone, especially given some of the pto that's happening to get dennis to contribute a little bit if there's time again, there's a lot of demands on everybody's time. So if there's time to get dentists to help get familiar with, that code base pitch in on keeping momentum going uh we're looking to implement the toggle between the classic editor and the content editor without losing changes, that's our next big step before we really make it kind of a production ready, workflow.

A

The html comments issue was one that came up, which is an interesting little uh problem, which is, you know, template comments they kind of they just get kind of stripped out right now um going into the content editor, so we want to find a way to display those correctly handle them correctly in the content, editor and preserve them and, as a stretch, there's an issue um to handle pasting larger amounts of markdown into the content editor and having it parse. um That's that's a that's a it's a big issue, though.

A

So, if we don't ship it, this milestone, that's no problem, but generally that's that's our focus for the next milestone. um I think there's some great improvements and if we can continue keeping up the work in those three areas, we'd be in a great place.

A

So that's it for me: we can move on to the open agenda. I saw this in slack and I will admit that I could use like a 30 second primer on what it means and how I should feel about it.

E

I was just offering some assistance to our lovely release post team as they get into as many merge conflicts as humanly possible.

E

Let me just give a little bit of a primer, so yeah, so I threw this into um so this. This was spurred on by uh dennis's great suggestion about. Maybe we would like to look at considering uh being leaders in this area as we look to formalize a rollout process plan across the organization, so this was something that was suggested as the brainchild of michelle jill to help reduce the likelihood of incidents as we go through shipping out code and make things a little more stable, a little more reliable at the moment.

E

It's an opt-in process, so it's not completely mandatory, but it is, you know, there's a good chance. If it works, it will be a mandatory process. So I like the idea of us getting ahead of ourselves and looking to use it in our process de facto by default and see if we can suggest maybe some improvements, if we can look at altering the process to be better and smoother, um but it's essentially something that comes with buy-in from the developers and team.

E

So I would like to know what everybody thinks if this is something you would be interested in, you know taking part of and leading or whether or not. We feel that this might just add a layer of you know extra bureaucracy and workflow that we don't see any value with.

B

I think that um this process may add overhead to certain deliverables right, it's something that we probably should discuss at the start of a milestone uh to which deliverables will absolutely like there. I think that it really depends on the degree of complexity of the picture that we are shipping.

D

It's technically I I totally agree with you in the weekend. That's what I uh what I wrote in my comments there as well. uh This process is not for every single merch request for every single uh thing we ship, but there are two things technically that we have to keep in mind um when we, when we uh classify that or another merchant quest, whether it's a good fit for for this process. So, first, if we are about to set the feature label for for the merge request, this already yields that this is a new feature.

D

We have to be extra, cautious and extra carefully like take an extra care of quality here. So this yields for roll out plan implementation and also another thing is even if it's not new feature, but it's something that our group has um claimed. We will shape like, like from the meetings like today when we say okay for this milestone. These are the main features we are going to ship, so those the merch, the core, merge request for those features should have the rollout plan as well.

D

I think, but definitely it's not for like fixing tiny bags or something that that that's not the case, that's going to be uh very inconvenient over overhead. But to give an example, I I wrote in my last comment on the on the poll. um We had a real life example this very week uh where there was a merchant blast that we shipped we merged.

D

uh The pipeline was green, all all great and then all of a sudden we had get an incident so simply because the package queue uh package and qa job hasn't been run on the merch request and had it been run, it would fail on the merge request right away.

D

So, as two incidents popped up, we had to revert the merge request right away, but the like, we have to revert. We have to con contact the emerge, request, author, notify them and like work through the process of resubmitting the feature, accounting for the things that were broken.

D

How does the rollout plan work in this case? So if that merge request would have a rollout plan that would clearly state what to do when the things go uh go wrong like if there are any alternative things to rolling to to reverting the emergency quest. That would save a lot of headache and a lot of rounded rounds for for the davon call for the incident management manager on call, and we would just follow the procedure described by the emerging quest author.

D

So uh it would just you know it would make things a bit more predictable uh like we. We know that in the incidents we have, we have to prioritize restoring the working state of the system, rather than figuring figuring out the uh the reason for the for the incident right, so reverting always works, but it's just like it creates an overhead as well both for the uh doesn't call and for the emerging quest authors and having the rollout plan would make things a bit more simple and straightforward. I think.

C

I think um I had a comment on the agenda of I. This seems um I feel like if an issue or some sort of thing we're shipping is worth a rollout plan. It's worth the feature flag and I feel, like the um feature flag, is, is tightly coupled to how we plan on rolling things out, and uh so I think I think that might be an interesting aspect for us to explore. Improving is right now, a lot of feature.

C

Flag management is expected that you know whoever created the issue, you kind of manage, whoever created the feature flag, you're kind of managing it until we can remove it, but creating feature flags and and we're kind of there, with some of the feature flag management that exists but creating it so that anyone can pick it up, and anyone understands the state that this is at. You know what are the worst case scenarios. This could happen if it's turned on and things we expect from that. um I think I think that's really smart.

C

I would I just I think it would. It would gel more into our current process if we, if we, if we couple it with feature flags and because I think, an issue worth a rollout plan like that is worth the feature flag.

E

That in itself is quite an interesting proposal, because that is something that could be worth looking at, sending back to christopher and tim that, if something is worth one of these rollout plans, it is probably worth wrapping in a feature flag and maybe our feature flag. Rollout process needs to stay the single source of truth and just be expanded upon slightly with the good ideas they've offered here, such as metrics around us.

D

Technically the future flag uh rollout process is just the uh just one of the potential rollout plans cases. So it's not like it. The the the proposed rule out plan is not limited to the feature flags, so it's like it. It defines more uh broader scope of the templates and broader scope of the um of the potential rollout aware situations than just the feature flags.

D

It's just a matter of like reading that that uh documentation. That page it's it's pretty boring, but.

C

D

It requires some some some diving and figuring out like using real life examples whether it is a good process or not. I think it's pretty pretty pretty good.

C

One so my biggest concern is opening the door for us to roll things out without feature flags like be anticipating that we've we've planned for stuff and for some reason we thought we didn't need a feature flag or whatever like somewhere in our development guide. We say you use feature flex and that's that's our preferred method for rolling things out, because it's so easy to just turn it off. You don't have to revert, mrs we could do, and uh so I I do see how this is addressing just.

C

How do we roll things out and planning all around that but historically feature flags is how we've done that, and I I'm really concerned if, if we're looking at doing things other than feature flag, there's some very rare occasions where we don't need feature flags, um I think to roll things out, but uh I I I would that's been the safest thing for us to do. That's.

D

C

Next to each other, let.

D

Me give you an example where we don't need the feature flag. uh We are working on uh on a new feature for header that is contained in one isolated extension.

D

The we don't need the feature flag there, because in this case, feature flag would create a lot of header overhead. It would cre create unnecessary tension uh if this extension is used in only one place, then in my rollout plan for that feature for that extend dmr introducing that extension, I could write okay. If things go wrong, just remove this string in this module and we won't load this extension. That's it we don't need to revert. We don't need to uh introduce the feature flag. We just change this one. One logic was that's.

D

That's it that's much simpler than than dealing with feature flags. In my opinion,.

C

And yeah you're right I mean, and but that does still require another deployment uh we either have to revert or we have to deploy. We un remove this string or something like that. The the benefit of feature flag is yeah.

C

It's it's, it's it's more work, but if we expect things to go wrong, if they possibly could we want to be able to turn it off at runtime, we don't have it, and so that's that has traditionally just been our thinking, and so I'm it's, I'm gonna have to think about this some more, but I would be concerned if we think of rolling things out without that.

C

If we think, if I think, what's the worst case scenario and the worst case scenario isn't good, we should use a feature flag and that's that's how we've traditionally done it I'd be concerned about about not doing that, but I do think it's related to the rollout plan. I just feel like we shouldn't replace feature flags with a rollout plan. I think they're going to no.

D

No, it's not about replacement by any means. No! No! It's just uh it's just like the rollout plan is kind of broader. Has broader scope that feature flag is just one particular implementation of your love plan yeah, and that's not it's not like using one like either or.

C

B

What are we going to say? I pasted in the document a link to the several prologue plan templates apparently well, as denise mentioned, it's like uh the royal uh plan is a super set of all of those strategies.

B

Perhaps you can combine both of them uh one or or more also like something that we could also consider is why future flags uh have so much overhead as a process like can, we make seem simpler, uh the process of creating and removing a feature flag that could also help to to help a single template right and and always include feature flags in in that reload process.

D

The problem is that um it I I everything could be, could be automated and like we just you know, set the future flag with chat, chat ups and then like remove the feature flag with shut ups. The problem is that we have to document these things anyway and, like any sort of documentation, is an overhead um like generating um documentation automatically could be probably possible here so, like you know like cli it ideally or something like cli tool, where you say: okay, I want to to introduce a feature flag.

D

You specify some. Maybe even we have something like this. We use yeah. We do. We do. I think, when I started speaking about this and I suddenly realized damn. I think I have done this once yeah like so we technically, we do have this, but it's still the overhead of introducing this and passing it through the merge request, review process and then keeping like the it's, not even the introduction of the feature flag. That brings the most overhead. It's the process of rolling it out and removing the feature flag. That is usually the worst.

D

The worst thing when, when it comes to it, comes to time, and um that thing cannot be eligible.

C

Really yeah and and and yeah, and that's the that's the unfortunate overhead part of it I do I do um I am I do. I do understand that the rollout plan is a super set of. You know how we manage with feature flags just with front end. Specifically, I realize database there's things like you can't feature you're going to have to migrate things whatever like, um but I am concerned about the the part of the rollout plans that we would consider that are not feature flags.

C

I just know that we've traditionally on in our guidelines, we've landed and come to the conclusion time and time again like feature flags. Are the tool to use they're a pain to manage, but it minimizes the risk to end users.

C

That's how we should do it, but I do like thinking just from rollout plans decoupled from feature flags. I love that. How can we think about what's the worst thing that could happen and that that's a question we should always just be asking- and I just.

D

I think that's.

C

A good point- and this is.

D

Potentially this is, this might be one of the uh things in the rollout plan like what is the worst case scenario. What can go wrong with this merge request, so just fill it out as the merge request author- and that is all it's like you know the whole the whole product can go down. That's that's a wonderful answer right.

C

I would love for that to be in our mr description, a big header. What's the worst that could happen, and everyone fills out, I don't know, bring down gitlab.com, because every mmr has the potential to to.

D

And it it makes life of the main parents so much easier. You know like okay. What is the worst case scenario? Okay, goodluck.com goes down. Okay,.

C

D

Merge or not, merge um well.

C

D

C

That's funny um yeah. I I think this is good and yeah. It's not is this something, so you said this is new, though like like they're still, okay, so maybe I I would like to see um some ways that we could um influence. You know just how this makes sense for our group, uh so yeah early, adopting this and figuring out how it makes sense. I think it's a cool thing to trailblaze yeah thanks thanks for bringing it up dennis.

A

I've just been able to skim the handbook page a little bit, I'm supportive of it as as much as I can be, and and will defer to all you as far as like introducing new engineering processes, but uh the one thing that struck me is I I like the the focus on defining the metrics that we're looking to improve whether that's performance or you know, usage or something like that.

A

That obviously excites me as a product manager to be thinking about that early on, but also as a way to carry that through the mr and see you know have it tightly coupled to the feature saying this is something we expect to be able to observe. Are we instrumented correctly to observe that, if not, we need to make sure that's part of the mr?

A

If we um see something going in the opposite direction, like at least we know that you know it's it's a. I know, there's a whole area of experimentation for this too, but it's it's a way to validate some of the product decisions as well. So discussion about feature flags aside, I'm supportive of the general process, I'll I'll defer to all of you. As I said.

D

It's also, uh uh I, I think at least for me personally, like it's it's a nice way of uh of the proper uh self-assessment of the of the future. So if you like, I, I think making this as like a very valid part of this uh reliable plan like what is the worst case scenario. What can go wrong and like, if you're, really about to write something pretty uh nasty in in that field?

D

This should ring the bell for you personally as the merchant west author, that okay, apparently, this implementation could and should be improved before it goes into the product, because if that worst case scenario occurs, that's not going to be fun.

D

So yeah, that's sort of like another way of assessing the the uh the impact of each particular emerging quest, really.

B

uh It is, it is a good thinking tool. It is just not like uh something that we should adopt, something that put us in the right mindset about delivering high-risk pictures.

C

So I dropped some some questions there that we don't have to answer right now, uh but just to be thinking about how we'd want to adopt this for our group, but where? Where would we want a rollout plan for a feature to live like some things? We work on almost have multiple issues for a single, mr and sometimes we have multiple. Mrs for a single issue.

C

um I like how feature flags end up into having their own issue, uh but maybe you know we could just abstract that to like here's. Just you know, here's the rollout for this feature, and then we can include details about the feature flag in there or something that would be interesting.

C

uh I think it's also interesting, like in some of our discussion and looking at some of the handbook. The rollout plan seems to have both like requirements, information and implementation information, all together so like when it's created uh you, you kind of need to you need to know what you're doing and have planned it and you're already like working on it to some extent. uh I so I almost see this as something that it's like most of agile things. Like a really really soft plan, just something that we we continuously grow.

C

As you know, here's you know some parts of it. We can fill out ahead of time, then, as I've worked on it as we've done like some sort of spike. Oh this definitely I need to add this to our rollout plan or something like that, as opposed to when we do feature flags rollouts. That's totally done, like you know, mr, is about to be merged. Oh, I need to create a feature. I need to create the issue for this feature flag thing. So I think this is cool. How?

C

Because it's abstracted away from that feature, flagness we would be creating that plan in advance, causing us to think in a different perspective is really cool um yeah this this is. This is interesting.

A

uh I know so david's not here to give the final word on it, but we can take it. Async is in action, but I think piloting it or at least continuing the discussion under the assumption that we will pick something to pilot it with would be the best next step. So just do that see how it goes. I think the feedback we can give during this would be helpful as well.

A

If they're, looking at a wider, wider rollout of the rollout plan.

A

C

A

That's the sign that we should wrap if I'm.

E

C

E

All hanging into points.

A

Yeah cool all right. Well, um thanks for joining everyone, and thanks for watching, if you are async catching up, I will see you all soon have a good rest. Your day, all right take care. Yes,.