GitLab Create Editor Group, 13 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Editor Group Backlog Refinement - 2021-01-13

Description

Bi-weekly backlog refinement session for issues related to the Editor group at GitLab

A

All right, hello, everyone, um it is january, 13th 2021 and we are um refining the backlog for the editor group. So uh the agenda is just to look at the issues that we've labeled for backlog refinement and then, if we have time we'll move on to other categories and discuss, um I have been labeling a few, um perhaps slightly generously they're, not necessarily.

A

Exactly ready for the the scope of this meeting, but they were ones that I knew I wanted to talk with you both and so we'll just look at the um just the filter with that label. So let me share my screen and we can just look at the same thing.

A

There we go I'll, make it a little bigger all right, there's a few here, we'll just start top down.

A

This one, I did not add the label, so uh oh, yes, I did this one.

B

This one, this one came up in the conversation yeah, that's.

A

A good one to talk about, so I my understanding is this button. Doesn't this drop down here that says text.

C

It doesn't do anything.

A

No, it's like you.

D

A

D

I have no idea it was implemented long time ago uh when I believe that you like it, it was implemented all the way in hamel view, and then we had this refactoring and I was struggling to figure out. What is it supposed to do and I couldn't figure out that because it was like there was just not enough connected dots there, so I just went on and just didn't connect it to anything when we refactored the view.

D

Okay and uh it's already about a like- it's probably yeah, quite a lot of time. We are with this uh non-connected functionality and nobody complained so far yeah. So I assume this and it's just like uh intuitively.

D

I cannot even say what it is supposed to do really.

A

It looks like a final encoding preference, but uh I wouldn't imagine well yeah. I don't know.

D

Technically, I would, I would um the only scenario where I would assume this might might be used is when, if, if we would be rendering the uh binary files and then we would switch between text and base64 uh encoding, but since we did not really show binary files at all now nowadays, this this thing just doesn't make sense.

A

But yeah it does well, it doesn't make sense either because you know you're looking at a a rendered binary file. You're not going to want to manually switch it over to view the text of that file and like hand edit your binary.

A

It's just wild guess, and it's just like.

D

This button is, is really like. You know whatever it's exactly what it says. It's just text, nothing more like just.

A

Placeholder all right well, this is an easy refinement, then remove the bug. I mean remove the button yeah um if nobody's complaining about it and there's no clear value. Removing the button will be one step further to hearing about it if it does provide value to somebody, even if it's a as we discussed in slack, even if it's a placebo effect, and somebody thinks that this is doing something for them and they have an impression of what this is doing. It would be great to hear what they think the value their.

B

From this is especially.

A

Since it's not getting any value, my guess is, we will never hear about it again and it'll just be a cleaner, toolbar yep and if, for some reason down the road, we do find a reason to switch file and coding within the editor. We certainly would have to build that anyway and and scope it and plan it and understand actually what we're supposed to be doing yeah. uh So anyway, that's that's great.

A

Let's say uh I mean I don't want it to linger, uh we're doing 13-9 planning, but this seems like the the lowest of the low effort to just remove a button, especially if it's not even hooked up to logic. Yeah. It's like.

D

Weight should definitely be one, and I don't know like we can. We can assign it to 13.9, but it's yeah.

A

Yeah I mean, let's see, I don't see why not uh when we're looking at capacity, I will, um I will say you know it's lower priority than some of the other work but yeah. It's.

D

It's something you know like to just to switch context during the day.

A

Yeah, I'm gonna put in a stretch anyway and take off the backlog, refinement the.

D

Only the only the only complexity here that I that I would anticipate is uh this is actually the review process, because the reviewers and maintainers might freak out that we remove the button without actually explaining. Why we do remove it so sure, like the emergency quest, has to be very clear in in in communicating that this is. uh This is the button that has not been connected to anything.

A

Makes sense, that's a fun one. To start with, I like that, all right.

A

This is one I was really excited to talk about. So let's talk about disabling the web ide there's some some comments here that I left in the thread, but the issue that was created, uh I believe by a member of the community.

A

This is not a gitlab employee um is, uh is not actually the main goal of disabling the web ide for the for this user is not um to prevent people from using part of our product necessarily, but um if you, if you read the further details, it's it's around the fact that the web ide appears to be a way around enforcing gpg, signing and um committing to the repo without having a signed commit um so to to kind of preface the the conversation.

A

I am fairly strongly against a user toggle setting in gitlab that would turn on or off the web ide or turn on or off web editing. In general, I may be biased as the product manager for the editor group, but I don't think that's something we want to make configurable.

A

I would much prefer to have the web ide support signing in some manner, if that's even possible- and we can talk about that in detail or at least respect the settings of the project. I don't want the web id to become a work around to get around a preference that we have in our own product. That says you know only signed commits should be allowed and then the web id actually.

D

Keep in mind that uh this is not limited to web ad, only right so, for example, it's it's going to be the same issue like you go to the repository, you open a file and you add it there and you you technically take the same route as you would from weber, so this toggle would would, as you as you mentioned, uh would have to completely disable any editing experience that involves committing yeah.

B

D

B

For the for the rest of the api.

D

Yeah, so it's like it's just if this is the thing for them like, depending on how large this customer is, I would just say that probably they need some some other tool yeah. Well, because I mean it's really hard to cater for this scenario. Yeah go ahead. Chad.

E

It says: there's a repository option to only allow sign, commits, isn't the real problem that any of those methods don't respect that, like the.

B

E

Fix is that the web ide, the single file, editor and everything else, should respect to only allow sign, commits.

A

Yeah- and I think that that's the that's the course of the conversation that and the the the thinking that I've taken on this is like there, there have been other requests to turn off the web ide as a way to enforce like some workflow on an organization. I'm not entertaining that right now. I don't, I feel like we.

A

We should take a stance and have an opinion on that, and my opinion is that we don't want to turn off web editing altogether, um but this is a very valid use case for for implementing a feature that exists in our product for premium. Users which is to enforce signed commits, and you cannot enforce sign- commits if you are also giving the users away around it through the web interface.

A

So um I don't know enough about signed, commits and private keys and how that might work with a web editor to to start solutioning here, but I think the the mvc for this is definitely just having the web id and web um any web editing the the single file editor to respect that setting and prevent commits from being made.

A

If that setting is turned on.

B

This is not the first time we've we've discussed this. I think we we had this problem before in the past, but the main problem is that, in order to sign the commit, you need the private key and you have to enter the the password to sign it with the private key, and we don't have that in. In the platform I mean it's quite tenuous to have the private, the private search in the in the platform.

A

Yeah- and it seems um counter to the idea of the private key to somehow have them store it on their account right, like that's the opposite of what we're going for exactly. Can you can just sorry sorry go ahead?

A

No. I was just looking through this other issue, but go ahead.

E

Enforcing it seems like that would effectively like if we gave an error in some central place if to enforce this option. That would effectively just make all of the editors not work, which is maybe what we want.

A

I think to begin with. Yes, it is what we would.

E

B

Do that I I didn't, I didn't see that image you're, showing at the moment so it seems github- has some special private certification or signing mechanism using their own private key.

B

I mean the user says all commits made by this are sent by special service white key.

A

Well, that doesn't take you anywhere.

B

So maybe they are somehow self-signing commits coming from ladies users, using their own private.

F

A

An interesting approach, I um would need to look into that. This is signatures automatically added both for ppr, merge, commits and changes because of that, it's possible to verify such commits in a clone repo after downloading a public gpt key for no reply.

A

Well, there's certainly a little bit more background in research on whether or not we could have signed commits from the web editors. Would that be something we would need.

A

Some collaboration from another stage on like could we chat with somebody.

B

It's social code.

A

Source code yeah.

B

But I I agree that this decision is quite dangerous, because after we implement this kind of setting for projects, somebody will say hey. This is quite tedious. I want a setting for my group and the projects inside that group in order to disable enable them all. So I think that the right approach is to fix this and or implement this.

A

Okay, um what I will do is there are several related issues that I linked here. Most of them are closed. um This is the open one that we were just looking at, um which is.

A

Which is assigned to code review, I will chat with them about who would be best to implement this and what the priorities could be there. It's obviously been around for a while. This is this issue is created three years ago.

A

It's not the maybe most pressing thing, but I'll probably um close this issue referencing the other one uh about supporting signed commits in the meantime. I don't have a project that I can set up. That is, um that would enforce this setting uh to test out the behavior of the single file editor in web ide. I remember seeing something on slack that implied that maybe the single file editor already behaves appropriately, but the web id does not so.

B

I think, and you can do it in the gitlab repository you can create a branch and commit to that branch using the single file editor.

A

A

Yeah I'll give that a try and then, if there's a discrepancy- or you know like, I think in the meantime before we implement this it'd be great. If we could um display an error in the web, ide and just say, and maybe just disable the commit button.

B

That can be also quite dangerous.

B

Unless we really really really want to enforce this, because there might be complaints by people using this or even changing a file and they they are getting these, these errors.

A

So the the issue in question um mentions that this is only available in premium and higher. I believe that the there is just there's a you know: a setting for.

A

Rejecting commits when they're not signed through gpg, so I think, um while an error might be annoying, uh we would be.

A

We would be going against the spirit of that setting by allowing a commit.

B

But I I think this is a good. This is a good caveat. I mean if users, if that users really want to prevent non-sign commits from going to the repository he can enable that, although he might not be in the right tier to have this, this push rule, but if the push room is enabled the weapon, he will fail.

A

That's yeah, that's what I'm looking for yeah and I I just don't. ha I don't have one set up or I didn't set one up before this meeting to just got to to verify the behavior, but my my opinion is that if this setting is configured and turned on the web, id should not be able to commit until it is able to commit signed, commits so there's probably two issues, one that is going to take a little more research and investigation into whether we can do signed commits online.

A

You know on the web or and then there's a second issue for just making sure that the web ide is not a workaround for this setting.

A

um I also will try and find out how many people are, how many installations are actually trying to do this. That could help us figure out priority and how widespread this might be. uh How many people might run into this issue?

A

um I'm not sure that exactly where that's instrumented or if it is but we'll try and find out how many installations are enabling this setting so that'll, be the outcome there. So takeaway for me is I'm going to respond to this issue, so we're not interested in disabling the web ide, but we will respect the setting and prevent it from committing when that setting is turned on and we will follow up about.

A

The assign commits in the web. Ui, which sounds like github is figured out. So we can take some inspiration.

A

um Next, one.

C

Combine review and commit tabs into one yeah this. This is something that.

D

That was bugging me in like for forever technically, and um this is more like you know, user experience thing that technically when you're there, there are two scenarios where, when you get to web id first you're about to edit the source code, the second one is you're about to review the merge request.

D

uh The problem is that in both scenarios we show three tabs like, as as it's shown on the screen, we show uh edit, we show review and we show commit tabs.

D

The problem is that when you're editing, uh editing emerge, request or you're editing a repository, a review tab doesn't make sense at all like what are you doing the review? You don't review anything, it's it's for merging blast.

D

So when you, when you edit, when you're done with editing your your source code in the edit tab, you click commit and you switch uh the jump over to commit tab right away uh when you're reviewing a merge, request, you're getting to the review tab right away, and in this case the commit tab makes no sense at all, because there is nothing to commit when you're merging reviewing merge requests.

D

So my my idea was that we might somehow in a smart way, combine the review and commit tabs because technically they provide pretty much similar information, uh the only difference being that on the commit tab, we show only the differences like the diff, uh the the change list and in the review time we show the full uh tree of the repository.

D

uh So I was thinking about like combining these two things, because uh every tab that we have to load takes resources. It affects performance, it affects user experience because those tabs just are like are very confusing, like review tab in editing process and the commit tab in the reviewing process.

D

uh So I was thinking about combining those those things, but then michael uh answered there, and I think we we might get into the discussion on how to do this. How to do these things? Because, uh from from his response, I still don't agree that we need to have like to to to keep those steps like at minimum.

D

I think we have to remove review tab when we are editing and we can re remove, commit tab when we are reviewing, because we know from the router what uh what action we are about to to do in the web id.

D

But we'll get to this discussion, and probably it's go. It's going to take a couple of rounds of discussing these things before we before we will be able to market us ready for development or just discard this. uh This issue.

A

Yeah thanks for bringing it up and and for for thinking through the ux there um and just to demonstrate and make sure I understand fully what you're saying so if I've got a merge request here, I'm going to see put in the changes and I'm reviewing them. I go to edit them.

A

Okay, yeah, like I get the diff view right, yeah.

D

You get the defu if you go to the third step to the uh commit, you still get the diff, but in this case it's broken diff, because it's not like kind of really working div and this tab just doesn't make sense at all when you're reviewing the things because you're not about to commit anything uh and the same thing. If you are editing the source code, the review tab doesn't make sense.

A

Whereas, if I'm following your logic, the idea behind the commit tab and the review tab is similar, except for the context the user is coming to the web ide, um given each uh yeah.

D

So if you turn yes, so we we uh at every uh moment of time, we do know whether you're in the review process or you're in the edit uh process, because the url tells us that information.

D

So we can, uh we can have the combined view uh for commit and for the review, like even the button commit, doesn't make sense when you're reviewing the uh the merge request.

D

So we have to be much smarter about uh conditionally, showing the elements uh on the screen to the users depending on that or another context- and this is this technically comes to our discussion of the in-context editing as the whole in the project.

D

So the commit view shows pretty much the same. Div editor, with the exception of the left navigation bar being dedicated for the change list instead of the full navigation tree, but this again can be conditionally loaded as well.

D

So that's that was my idea here.

A

Yeah I mean I like the thought I'll read through michael's response again or you know in more detail uh and add some some additional thoughts. I think preserving or I should say, catering, the ui and and the experience in general to the context.

A

Given that we know the context, as you mentioned, sounds valuable to me. I think understanding a little more about the different use cases coming from a merge request and reviewing versus someone, maybe more like me, where I might jump in from the merge request to make an edit and a further commit.

A

A

Could help us explore some of the.

A

um Some of the nuances to the experience that you're talking about for in-context editing, so something like yeah.

C

Just difference between.

A

I'm reviewing the diffs versus I'm actually just coming in to make further edits to to make like.

D

And this this is this. This uh has a really like uh a really smooth uh implementation path, using very minimal changes like we can start with just to to kind of measure the uh to get the the um the interest in in these changes.

D

So we can just hide these tabs for, like for when you you're editing the content, uh the content, we hide the review tab so so that users cannot get to it and when you're reviewing the merge request, we hide the commit tab and the commit button, and then we just check whether anybody complains about this, because in this case we we do preserve the same naming that people got used to so could and it could be enough for us.

D

The main thing that I want to avoid is to get this confusion that technically we in every context we have three tabs. So probably each of them has some value, but one of them is constantly broken because it just doesn't work in that or another context.

A

Yeah I mean I would say that uh preventing people from committing if you're coming from the merge request could be potentially dangerous for the workflow that I just described, which is like I'm going in here to add additional information to this release post or whatever, like that path I just took to get here, is one that I take frequently and whether it's right or wrong, you know.

B

A

But something I do sometimes, if I need to like add an extra line or just change a word. I don't necessarily want to do it from uh the suggestion in in context of the mr, which is what I mean by like. We should explore that further and in in our uh effort to bring in context editing uh into the merge request. But this.

D

A

This is the this.

D

The important thing here to keep in mind that uh what I suggest does not prevent you from doing what you just described, so the edit tab will be available in every scenario.

D

So you get to the review uh tab, but the edit button, edit tab, will be there all the time, so you will still be able to edit the things. The question is: how do we do? How do we uh reveal the the commit tab if you do make changes while reviewing nmr right, but then again we do have the state that tells us whether we have changes or not. So if you are in the review, if you get straight to the review process, we show only two tabs edit and review.

D

Then you want to do the change you go to the edit tab. Make change and our state tells us. Okay, we do have the change. Then we reveal the um commit tab. We can. We reveal the commit button and you are free to to make your commit. That's it yeah, but.

A

D

Sorry, I I I think I misunderstood.

A

Because I thought you said that we would just allow reviewing but not committing what you were. What you were getting on does not show the commit tab that.

D

You can see that was about from this. That was about.

A

Like the default.

D

State of how people, in my opinion, how people interact with web ide like if they review their review, if they edit they edit. uh It's the only scenario where you uh edit the file while reviewing, is when you review your own, merge request in most cases, but that doesn't happen. That often like, usually you do review your merch request before you push it to to to reviewers.

A

Yeah I mean I, you know I I don't have the legacy of um the decision making process here, but it feels like the commit tab is a little bit left over from when we staged um files and had a little more file, management and stuff in general. um I I definitely can see your your standpoint here on the fact that they're they're performing similar options. It seems like to me if I could simplify the distinction.

A

uh You could it's really just about what um you could combine them into one tab and just provide different options for what you're viewing like? Are you viewing only the files that are changed, or do you want to see all the files? Are you reviewing the changes since your last commit or the changes since the you know the the merge.

D

Target branch yeah.

A

um And then so, like you know in in oversimplifying it again like if you just had a default view for the review tab that just showed only the files that were changed. Essentially what we show in the merge request itself and then had a button to show all files and like toggle between that um it seems like it would negate any value that the commit tab has in general. In this context,.

D

I'm with you yeah, let's yeah, so the main the main idea is to is to provide as a simple interface as possible to people who are executing the default action, but that, when users explicitly require like do some action that would require us to uh to extend the interface that's.

D

This is like the user-driven uh extension of the interface and that's that's something that users, no okay. I make this action. This thing happens: okay, that's cool, but if users are throw, we we throw everything we have at the user right away. That's a bit overwhelming! I think.

A

Yeah, I I'm with you. I think it needs a little more back and forth, like you said with with michael and let's get it, um let's get the proposal crystal clear before we we try and um schedule it, but I I'm all for iterating on the on the ux and simplifying the the overall experience. I think he had uh mentioned a couple concerns about just in general, like um providing visual feedback on the commit tab. I think really what we're talking about is.

A

Ultimately, letting combining the two tabs and have them serve dual purposes depending on the context, but the the mvc for for hiding one or the other could potentially make it. So you know the the utility of that um commit tab where it shows the number of files is, is lessened uh in the near term, but I I think we can. um Let's, let's take a look at some of the alternate proposals, go back and forth and get a couple designs. I I don't have any real reservations uh to to moving forward on this.

A

I think in general. um It makes a lot of sense. Thank you. I'm gonna leave without saving that change, so I don't mess up my release post and um I will leave this open. So I can go back and make some comments, so um this was the other one. I was looking forward to talking about. I'm excited about this one, because I have a big question about editor.

A

Config uh paul brought this one up in in an issue that was assigned for thirteen eight, which seemed like a small bug, which was that the single file editor um doesn't add the trailing new line character when it commits the the file the changes to the file, but the web ide does by default, and in talking through that behavior we kind of realized that the reason web ide can do. That is because you can override that behavior. If you want to through the editor config.

A

If we extended the single file editor to have the same default behavior, but don't let the editor be configured to not add the new line value you would never not be able to have. If you catch my double negative, like you would never. You would always have a new line at the end of your file and anytime, you edit it with a single file. Editor would add it back in. You could get an assert if you didn't want that new line for some reason, whether it's a file encoding or your personal preference.

A

You would be stuck in a circular editing loop until you got so frustrated that you edited it somewhere else. So my opinion is the solution. Here. Is that the single file editor or editor light as a whole? If, if because I don't understand still quite where the distinction is on, where the behavior would be uh added, but if uh the single file editor can reference the editor config values, then it can behave consistently with the web ide.

A

We can default to adding the newline character and allow people to create the editor config file to override that behavior. If they want to, and then there will be consistency between the two editing experiences.

A

So is this something that we would build into editor lite to reference the editor config file, or is this something that's inherent to the two actual implementations of it? Yeah.

D

This I think, uh uh answered uh in this issue, and it really implementation of editor config in web id is just like. We just make the api call. That's it.

D

We make the api call, we get the config we're done, it can be, uh and it will be the part of the uh of the web id extension for edited light right now when we are moving to edit light, but nothing really prevents us from making from making it like part of the uh core extension, for example, so that whenever we use edit light, this is available for the users and every instance of uh eddie light will will use it. So there is no uh no complexity here.

D

Yes, right now, we have similar different implementations of edit light in single file, editor and monaco technical, because it's there is no uh eddie light in web id. Yet we are working on that only so yeah. These are different things, but it's going to edit.

D

The uh like web id goes to edit the light the whole web id will be wrapped into in in an extension, and then we can just dissect that extension and decide what parts of web id implementation are valuable for the for the overall editing experience across the whole product and just make it the core extension. That's it.

A

Yeah, I'm generally all for that. My my question here is given the reach of the editor light that we imagine are there editing experiences where we wouldn't want to respect the editor config values like given that snippets uses the same editor.

A

The presence of snippets implies a separate repository, so it would potentially not be looking for the same editor config, and so maybe it wouldn't.

B

Well explain: yeah. Those would be two different repositories. One I mean you can you can still add a editor config file in your snippet repository.

A

Would uh yeah, okay and then I guess same thing goes for wiki if we had a code view uh separate from our rich text editor on wiki, and we wanted to use editor light. As that code view, it could have a separate editor. Config same thing goes for static site, editor down the road.

D

Also, there is the pipeline authoring uh using.

A

D

Light right so uh and the the the the alternative is, we can also make it uh uh sort of choosable or like optional for the users. So we can, we can allow users to just you know, run the command in their editor instance and load the editor config whenever they want, or we can uh make this available on the per instance basis.

D

So using the editor you config is uh going to be put into the separate extension and then every instance of edit to light will, uh like the author of every instance of editor light, will be able to say. Okay, do we need this extension or not? That's it yeah. There is.

A

A lot of flexibility.

D

A

Yeah, that's good. I think the the the simplest answer for now for right now is that it sounds like building the like a core extension for reading the editor config values into editor light is the is the path we should explore right now um and then, as we yeah as we implement that, and as we find other scenarios where we want more flexibility or um inconsistencies, seem odd. We can.

A

We can look into ways to either surface uh like a snippets, a message in snippets that says you can create an editor config file to change the behavior of snippets or something like that. uh You know some of this might just be documentation as well.

D

Yeah yeah it's but, as I said this is, this is really trivial thing like this can like fetching editor, config and applying it can be, uh can be made an extension already tomorrow and we will have it in 13.8, but it's just it's just a matter of uh creating the extension. That's it.

E

You can also give them.

B

E

I was saying you could also give them an option somewhere in the in the project or instant settings. To say uh here is the editor config I want to use and then across all of the different features that we'll use the same one yeah.

D

E

Want the same formatting, they might not.

D

Yeah well, whatever like whether we allow users to decide on editor config for different projects or like use, project wide, editor, config or like different different set of set of configs.

D

Using like creating the the extension for dealing with with data to config will be beneficial because we would we we will be able to to uh specify what are the config to use on that or another instance, whether to use it at all. And that's it's just going to be flexible.

A

So you said you could have it tomorrow, so that means it's probably like a it says, fairly trivial, a one way or something like that. Man don't catch me on my words.

D

No, I'm I mean like uh okay, um I I I'm I I suppose we can have it tomorrow. I like we can have another.

A

Thing you want to have it, I'm not saying you need to have it tomorrow, although that's.

D

Not funny I mean that.

A

That's what I, but but.

D

uh Yeah, it's like one or three: oh it's! It's definitely not three! uh It's it's going to be one because it it is like, indeed in the poc, for for the uh web id running on data lite. We don't have this uh branched into the extension like it's it's global extension for web ide, obviously, but we can take it out there and um the the the only thing that I have to think through.

D

We don't have the paradigm of the uh core extensions, yet I I was thinking about this for for uh for quite some time, because uh we will have to at some point create this core extension uh that is going to be used by all the editors in the project and um this. This is this one. This is one way of doing this.

D

Another way of uh of doing this is, as I said like to just create this regular extension that we do support now and then uh add it as dependency for web id and for the single file editor, and this this can be. This is very trivial to to do. Indeed, okay,.

A

uh The only reason I'm asking is because we we were doing planning for 13.9 uh and getting the web ide using editor. Lite is one thing: that's slated for 13.9, so if you could take care of it at the same time, uh that would be great yeah. I could put this probably. I could see this as a stretch goal for 39 and waiting for 1310. I don't think it's critical, so um as long as it's on a radar for, I think we can.

D

Handle it uh uh during that process because I, like I've, I've already got a couple of merch requests uh towards this. This goal um merged, but the main thing like the main extension, is not um it's not prepared as the merch request. Yet so I can just create two two extensions really like one for editor config and one for the remaining part of the web id.

A

A

A

uh So I just made a note, as far as like implementation goes I'll leave it up to you. If there's there's no concept of core core extensions. Now we don't need to reinvent the wheel. If, if, as you mentioned, you just create an extension for both single file, editor and web ide within editor lite that respects the editor config. I think that achieves the same goal and we can move towards a core extension that has that consistently across all instances of editor light. That makes sense to me.

A

um Well, you know I, I think, that's enough. We can tentatively uh schedule this for 13.99 and, if and and discuss the details in the issue later cool.

C

C

Oh, this was a fun one.

A

I'd like to discuss this one: how late does this meeting go? Oh, we still have half an hour, um so this one came up as a as a customer request, so we had a customer who was on a trial of premium and invested some time in building a group wiki which is only available in premium.

A

They did not buy premium. I don't know if they went on a free, tier or or a lower tier, but regardless the data exists, but they have no more access to it because they're trial ended.

A

um They wanted to be able to retrieve it. They were justifiably confused and a little upset that they couldn't get to the work that they had put into it.

A

um From a product standpoint from a pricing and tiering standpoint, I don't necessarily want to make a group wiki data available to somebody who hasn't paid for the tier that has that feature, but I do think that granting read-only access to that data is important, so they can retrieve it and so that if they ever upgrade it's there for them, if they they upgrade their their plan and the group wiki comes back just as they had it. That would be the ideal solution.

A

um I believe this could be handled through support for now. We don't necessarily need to do anything here. The support could get access to that data and find a way to make it available for the user um and that's the path that this will take immediately.

A

But I'd like to discuss just you know for for backlog, refinement reasons like not saying we need to do this in 13.9, but is there a way we could solve this a little more elegantly for self serve that doesn't it doesn't make the user feel inconvenienced for not buying premium, because it's not for everybody, we don't want to make them feel bad about it. But still gives them access to the data um in a way that doesn't require interfacing with support.

A

So my thoughts here are in the proposal um whether this is done through the ui or through you know, just get access to the repo or something like that through the api and command line.

A

I'm interested, I saw a friend you, you commented a couple.

B

A

And um I don't know if you want to elaborate on that.

B

Yeah so um at first I thought that.

B

Allowing the read-only access to the wiki to the group wiki would be a good solution, but that would only allow users to read the wiki, not download the wiki. We don't have any functionality to download wiki repositories compared to the functionality that we have um with projects projects has the functionalities going to download them. So the problem is that, and we have all the tools we need, the the to bundle. The git repository is, though, is done by an rpc call to italy.

B

So we just need to tell italy to bundle the wiki repository, but if we do this through the ui, it will require ux. It will require required to add new rails routes, which in this case, will be complicated because of how wikis works.

B

So my recommendation could be as like we have, for we have an endpoint called export. I think it would be to add an endpoint, a new endpoint to group wikis and also wikis. If we want to download them. If you have uh yes or read access or download code wiki access, it would be more straightforward than a ui approach.

A

Yeah, I agree I mean I think.

F

As far as like, besides sorry sorry, sorry.

B

F

B

If we let the user to access through the browser to their read-only wiki, we may be as a company and because they are not in the right tier. Maybe we don't want them to access or we don't want the wiki to be available to anyone if the wiki was public.

B

Maybe we don't want that functionality if they don't if they don't, if they aren't in the cheer mm-hmm.

A

Yeah I mean I I from a from a product and hearing perspective, like I'm, not trying to be vindictive for anybody that downgraded or or didn't, extend a trial. You know or didn't pay for the same plan that their trial was on, but, like the the reality is like we've, we've got a premium feature and uh to make it available, even in a read-only way to those that don't pay for the feature erodes the value for those that do um and makes it harder to manage.

A

I mean honestly, it's just going to be more complex, as you mentioned from the ui standpoint. We're going to need to do more validation, and I don't know, I think I think, api access to export the data is the simplest path to making sure that people have access to what they created, uh while not complicating the the tiered pricing that we have in place. So until we invest more time and thought, and if this comes up a lot more, I could see us exploring a way to, for example, check the existence of group wiki data.

A

And if you don't have access to group wiki, we could have a way in the ui to let users clone that to a new project and make a project level wiki that they can then access and edit. um But it it. The same thing could be accomplished by just letting them download the data and then do that manually. So um yeah.

A

I think I think option two makes a lot of sense read only access to export the data through the api, and then we document it for support and for you for anybody that is searching for it in the docs.

A

um So that's the.

A

C

Oh, that didn't work mark.

A

A

No, not a robot, I just typed fast, um okay, uh it's not the highest priority. This came up once in the past month, so I'm I'm not saying we drop everything and do this uh we'll keep it in the backlog. um What do you think as far as complexity for for waiting like.

B

uh I think we have all the tools we need. I mean italy works with repositories, so it doesn't work with projects or italy or sorry or groups or whatsoever only with repositories. So we can. I think we can connect all the gears quite quickly and say italy bundle me the gita, the group wiki repository and it will return it and we can even reuse some code that we have in the project, export and coin.

B

So I think it will be quite straightforward.

A

Cool um given the documentation and stuff I'm hearing like a three, but if you think it's maybe less yeah yeah all right, let's just say three for the purpose. I.

B

Think I think it will be less okay, but if we see if we have any unexpected situation, let's give it a three.

A

Mm-Hmm, um okay! Well, that helps. I will uh update the description in a little more detail to take out the references to the other options and make it more clear what we're doing and then I'll take off the backlog, refinement, label and we'll get it prioritized.

A

File moving on the file context path for the gitpod button is not updated when browsing the repository, oh yeah, I remember seeing this one so the gist of this one is that when you are browsing through the hierarchy of your repository and you click on the get pod button, it will always load the route of the project.

A

If I remember correctly,.

B

Oh, I think no, I think the problem is that if you are in an interior route and you open, git pod, it takes you to the main route, not to the folder that you might be browsing at that moment. When you open github.

A

Yeah right right! So so, if I'm in.

A

I don't get uh yeah get pods enabled here. So if I'm in you know app controllers import whatever- and I want to open this in git pod.

A

It's going to take me to the root app level is what.

D

It says yeah, the problem is that uh technically what happens is that the button doesn't generate the link based on all the uh url mutations. So technically, when you get to the root of the repository and then drill down to the subfolder to the subfolder, then we do update the url, but we did not reload the page.

D

So technically, are we using the history history api in the browser to push these states, but the uh the url of the button doesn't get updated. uh Contrary to that, if you reload the page, then the button is initialized with the url that is on the page and then it shows the correct url.

D

So technically it's just a matter of uh I don't know.

D

Listening to the history uh changes or that might make more sense, just generate the url. The moment user clicks the git pod button, so the user clicks the get button we do identify where we are in the repository structure and that's what we sent to git pod.

D

Probably that's going to be like, instead of constantly listening to all the uh changes in the url.

D

That would create a lot of uh noise in the in the front end on the client, so we just generate the url. I'm sorry.

E

I I can't reproduce this when I click into the app directory. It updates my button without reloading the page.

D

Nice, then, probably it's uh it's kind of bug. Let's see.

C

D

Yeah, you need to be logged in.

E

Well, I'm just hovering over looking at the link, I'm assuming that the link is where it actually goes.

D

You don't actually we just have to make sure that we didn't reload the page before getting here right, uh so that if we could test this once again so drilling down from the oh okay.

A

Cool um yeah: well, let's verify it, but the link does look right, you're right, so uh yeah go.

C

A

Out and I mean.

C

Well, yeah: let's go into a javascript file right, so we do get updated url, but uh this happens.

A

When it's reloading so without reloading, let's see if it lets me start up now.

B

Yeah, just in the old url yep.

A

Yeah, you can see yeah yeah.

D

Controllers yeah, so you were navigating back and forth back and forth, but the url hasn't been updated for the button. So I just suggest we we can try to. We can attempt to generate the url uh before we get to the uh git pod before we send send user to the git pod.

D

Probably I don't know, I might say some nonsense now.

E

So your button didn't update when you clicked on.

E

A

Like a browser extension or something.

E

uh I think I don't know, I just followed some instructions.

E

Somewhere, maybe it.

D

Was a while ago it's it's the button that either allows you to open the repository in web id or in git pod.

E

I don't have that drop down. One.

D

Because, probably you don't uh you don't have the git pod set up for I don't remember whether it's per user or per project. Actually I.

E

Think I must have yeah. It must be the browser extension that I'm seeing.

D

Oh man, that's you know, that's not a representative test.

A

All right, so the the potential for the proposal is that we send the right path to getpod, which is yeah that I agree uh how we do that. I think we'll need to test whether or not we can do that at the time they click.

A

I don't think this is hugely important, I'm not going to add it to 13.9, but it's good that we diagnosed it.

D

Well, it's it's! It's really.

D

I would. I would suggest putting it into the 13.9, because it's it's it's not uh it's not a rocket science to implement it, uh but I suspect that a lot of people do use git pod and it might be a bit annoying for them.

D

I'm not sure whether we have any statistics on how many people do open repositories and git pod, but I've heard a lot of praising that gitlab switched like suggest, git, pod integration and uh probably it would be nice to to.

A

It's fair, I mean it's certainly nice to have 13 nines looking a little heavy, but.

D

Just as a stretch or.

A

Something yeah, I think as a stretch, it works all right. If not, it can be 13 10.

B

A

That's that's the definition of a stretch goal.

D

And we can assign it to front, I'm sure frank will be.

A

Happy to do front and stuff he has about half that list.

A

Yeah, there's um there's a good amount of good amount of work on your plate here coming up, france so glad you're back.

B

I'm not sure I can say the same, given the amount of work.

A

All right so last one on the list and then we can just wrap because we were right at about a time use uh one editor in multiple instances for multi-file snippets. This one um had been sitting around for a little while, and I think I.

B

A

Backlog label because I just wanted to understand the benefits and and complexity here.

D

Yes, so um I think fran will uh will let him know more about it. Editor light is his thing, but okay, um so we uh for multifile snippets. We do use real light right, uh fair enough.

D

uh The the way it is integrate implemented now is a bit inefficient, because if, let's say we have 10 files in a snippet, we do create 10 different uh editors for uh one editor per file, however, editor lite allows, and actually it suggests that the most optimal way is to create one global editor and then create one instance per file instead of uh one editor per file.

D

uh That way we can share some some settings, some configurations we can share some instances and so on and so on. uh So this this issue is really about. Like it's not a bug, it's not a thing. It's just like a minor change to architecture, to optimize the performance and optimize the uh the memory consumption when editing the snippets. It's it's primarily for primarily about editing the.

A

A

That's it yeah makes sense, um I mean I, I don't see any reason why we wouldn't do it. uh Do you think I I mean I don't know we need to get a better sense of exactly the reach of multi-file snippets at this point, and I know it's instruments, so I need to run the latest numbers, but um from from my perspective, it can sit in the backlog for.

D

As long as we need to.

A

Yeah, I I can see this coming up again in that discussion for in context editing if we potentially have multiple files in an mr and we're instantiating the editor light in the. In that view, you might.

D

Have really no.

A

D

No, um like it yeah, it might the same thing like uh it will. uh This discussion will be uh we'll we will get back to only in the case. We are on the view of the multifile snippet and a user wants to edit several times several files at a time.

D

Otherwise, users added user edits one file at a time. This means that we create the instance of the editor and we create the global editor. We create the instance for this file and that's that's pretty much it and then the user clicks another file and we create instance for that file. We do.

B

D

Technically the uh if we have to solve this for the view this this might be another issue. These two can leave separately, no problem there and when we uh start implementing the in context editing for the for the snippet view, we will implement it correctly right away, so we will create one global editor and every one instance whenever user requests the inline editing, but that won't fix the editing form. But at the same time the editing form won't affect that implementation by any means.

A

All right well I'll, continue to gather that data. I don't know how I would quantify the performance benefit here for those users that might be doing that, but uh you know I think it's relatively small and reach that it we can keep it on the backlog for a little while, like you said,.

D

It's it's about adding form like uh performance uh when it comes to performance of the views and the editing forms. People users usually have different expectations and different sort of different perception of performance. For these things. So, uh like shaving off, I don't know like 100 200 milliseconds on the edit forum. Won't won't give us any like any praise for performance improvement.

A

Yeah yeah, I'm with you all right thanks for elaborating.

E

A

E

Anywhere else already like in the web ide to have the the single.

D

E

With multiple instances.

D

E

With the fact is this, is it worth dog fooding it maybe on snippets, something that's not as widely used.

D

Okay, man, you're opening a really really dark pandora's box now uh so added editor light allows you to like fundamentally the uh the way we do it in web ide or we are about to do this because I didn't like. Oh I'm sorry, um web id is not edited light driven yet right. There is only the poc for that, but uh let's assume that web id is running on edit light so uh fundamentally arc.

D

Actually multi-file, snippet and web id will be implemented a bit differently because for the multi-file snippet we really need to create multiple, multiple instances, because we visually see different editors different instances on the page, while with web ie, I'm doing it a bit smarter and we are reusing only one instance there and what we do there. We switch the models, so there is one level deeper abstraction kind of so we have one instance in the web id. So we do not- um and this is this- is the merge request that got merged today.

D

Actually, we did not throw away the resources when uh switching the files or something we just create new model for uh for, like you, click on a file in the navigation tree. If this file hasn't been opened yet we create the monaco model and put it into the already existing instance of the editor. Then you open another one. We create the model and swap the models in existing instance. We do not discard the instance.

D

The only moment we discard the instance uh is when you close the last file in web id, so the last tab in the editing interface, but otherwise these are, they will be implemented a bit differently like the multifile snippets use really multiple instances, while web id uses one instance, but multiple modules that get into this instance.

D

So if, if that makes sense,.

E

So the only point I was making is, if, if we are planning to or when we're planning to do this for uh issues or mrs the same architecture, it might make sense to do it on snippets first, as a dog footing in a less used and less important part of the app.

D

Yeah, if we are, uh if we're ever going to to to introduce editor light for merge requests uh for the for the changes tab of merge requests, then obviously it's going to be the same principle like one instance per uh changed file, but uh I think we have really long way before that. That happens.

A

The other thing I could think of um again very far in the future, but something we've talked about with the static site editor with the complexities of some of these pages, where you might have embedded code in your content. We have uh potential to identify code blocks of template layout or like mermaid, diagrams or whatever, and show those in a like code, block, embedded, editor right so in in a potential for like a handbook, page, that's very complex, you might have three or four or five of these spread out throughout the page, maybe more.

A

It would be beneficial to instantiate one editor and then- or you know, to have one instance of the editor or multiple instance of one. That's what.

D

I'm trying to say.

A

Yeah exactly so.

E

But again that's.

A

Pretty far in the future, I think that uh that helps me understand this issue, a lot better, but um certainly keep it in the backlog and and keep it in the back of my mind, for when we get closer to that kind of interaction,.

A

I think that's that's the end of our list. We didn't have time to go deeper into any other categories, but I I got a lot of.

A

A lot of issues refined in my mind, thank you, as always for your input, anything that we're right at time, but um I've got a few minutes before my next one. If there's anything else, you wanted to chat about.

B

Yeah regarding the geo issue that you mentioned yesterday um and group wikis, um I read last comment and I think they said that they were going to tackle it. Not us.

A

uh No they're gonna make space for helping, so they want it to be self-serve uh like we take our best stab at it, and if we need assistance they're there to help.

B

Okay, so I I think, because they they tackle snippet completely because they were, they are building this framework for for geo resources. So maybe they want to try teams to be on their own, the geo resources using the framework.

B

So it's not going to be as straightforward as straightforward as I thought, because we are going to deal with the framework, but at least we have something to compare like snippets, yeah and.

A

E

A

A

We can, we can definitely talk about that more on our next refinement issue or just in the issue itself, but they they are um making themselves available to help, um but they would like us to to see through the work.

A

Great well uh again, thank you and um roman will be back starting next week and he'll be back to running these on our next session, but it's been fun trying to understand what I'm talking about in the past couple months. So thanks for humoring me uh have a good rest of your day. Everyone and I'll see you on slack right, talk.

B

To you see you, everybody.