GitLab Create Editor Group, 15 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor Monthly Meeting

Description

In this video the team talks about the general strategy and challenges of upcoming work in all our responsibilites.

A

So hello, hello, we are here on the 11th of february for a monthly meeting um yeah, that's exciting. I thought it was like a good conversation going on very good, I always say half and yeah, let's jump into the agenda and then, let's see maybe we have like some open free time in the end or so for us to discuss anything else that pops up. But I trust eric has a lot of things. He can fill up the rest of the time anyway.

A

um Cool uh short upcoming time-offs, not sure if anybody has anything else updates, maybe mine one or so. Oh, it's read only sorry. You have to read it now, so I'm not going to tell you.

A

I'm even going to tell you, because I think it's important but like for the upcoming like weeks, I think till the 2nd of april, I'm usually off now on fridays. Just have more time with with family, also because challenging times challenging times we'll take fridays off.

A

It would be nice that would be nice. There's like a whole movement going on right now, regarding like doing the for work for day work week, right and google is like pushing for it and more and more kind of voices and that's interesting discussion going on there.

A

But yeah um general short update, okrs are live, so we put up with our new cars there's like still some work. I need to do. There um feel free to click on the link or so in general. I want to kind of give you a short update, um so please everybody can read through it um and yeah we didn't.

A

I did not pay like too much to attention like it in the last quarter, especially because, if we were in the process of being like a new team and kind of formulating everything and the goals were mostly set to like how the teams were structured previously, so we didn't do too well on some of them, and this is like nobody if here in the team, is to blame for this as all good in this case.

A

But we start to do pay some more attention to it going forward um and some parts I want to highlight in just I shouldn't have written milestone and just like okr, basically for the this quarter um on the one thing is like our narrow, mr rate, um so I completely ditched the previous numbers we had, because now we're kind of like really measuring the whole mr8 for the whole team and kind of calculating backhand and front end together and come up with like numbers for the whole team, and we could aiming for roughly like 10 mrs per milestone or months, basically is what we're trying to go for um the last milestone we hit around the 8.5 and we kind of were changing around between, like eight and nine or so it's good, and I think, aiming for ten is definitely possible because we have some people here who, like turn out like 30, mrs in a given month, which is like crazy, but that's also good for us as a team, but the samara.

A

It should be something we can all like focus on, which is a good goal for us to have. um Also another cool highlight. I'm super excited about uh will really aim for getting like two new maintainers in our team. This is good because it makes our team a little bit more, even more powerful, like with um more advancements. On the one side, we have fran who's, now, really pushing hard to kind of like get his maintenance. She ready, which is great and also himanshu, will be working on his maintainer issue.

A

So let's aim for them and yeah. That's good news, I would say, and then the other thing I want to highlight is as well we'll focus again on having like one mr contribution to our handbook page um this quarter. I definitely finally want to pick up. I know I talked a lot about it or changes I want to make now. I finally want to take it.

A

I think it's getting a little better now with okrs out of the way to really focus and have some time for this, but also everybody please take time to maybe also find a nice contribution to the handbook, make it better. um I think we're really impressed of building like a really really exciting and good handbook page. um So there's a lot of cool things. We can do there and yeah we'll just keep track of this.

A

This milestone, or this quarter basically- and my general goal is for our monthly meeting that I'm going to give like a short update on where we stand in the ocr. So nobody of you kind of really have to actively track it like too much but I'll give everybody a hat up. Where do we stand number wise and this kind of stuff, so we all kind of like treated it with like or have more visibility. This whole thing, which should be exciting.

A

Any immediate question regarding, like our general team, okrs.

B

What is a narrow, mr right,.

A

So that's usually just like mrs- we kind of uh contribute to the gitlab main project and have like the the group editor label on it and are kind of like contributed by people from our team.

C

That's sort of getting back to our discussion yesterday during the backlog refinement that we as ics are expected to deliver a certain amount of certain number of mrs per per milestone. That's how we are measured.

B

So the narrow part is what I mean. Is there a wide.

C

We have too too few too few mrs per person per milestone. Now.

A

There's like an outer mr rate as well, which is, I think, the one contributing to other parts beside the gitlab project and, as far as I said, the narrow is one only the main gitlab project. So anything else is like not counting in this metric. If you contribute a lot to like dab or any other projects inside gitlab, I'm not sure those are counting in the zmr8.

A

B

Www never never did yeah, but.

C

Also, this is this is very, very frustrating moment for those contributing to gitlab ui, because gzlab ui.

A

C

Towards that as well.

A

That is absolutely right and that's absolutely shitty.

D

Why why are you not counting those or like? Why is it? Is there a technical reason that we're not able to count those.

D

A

You have to ask the people who kind of put up these these graphs. um I think it's like just how they accumulate the data, I'm not sure they take all projects in the gitlab ecosystem into account. Just what I understand, but it's a good note for me. I will kind of find find a clear definition of what narrow mr rate in this case means.

D

um Oh, when you mention outer mr rate, that includes all the projects. I guess, or I think.

A

Those dmrs that are counted but are contributed outside of gitlab and those are usually the ones that are not counted for this general, mr narrow, mr rate, which we take as a general comparison across the team. So maybe that's the reason why it's like split up.

B

A

B

Technically possible, because all of last year, when I worked almost exclusively on www, that was counted for my reviewer and mr rate, because that was all I was working on and.

D

And I would imagine like for the folks that are, you know, really focused on giddily like they have this set up for them too, so it should be hopefully trivial to add one of our front end projects that uh yeah. That's that's interesting,.

B

It's just a matter of adding it to whatever size. It's graph that you're, particularly looking at.

E

Sizes, that's right! That's that's what it's called.

A

Cool yeah, that's it to do for me I'll figure out a complete definition of everything, or so maybe I kind of talked completely nonsense right now. I will clarify on this and give you an update in the editor team channel.

A

Cool the other thing I'm super excited about. We kicking off like personal okrs for everybody, uh so we have our pdps ready the personal development projects um which I'm super excited, because it's now like a more official form like I know in the past, we kind of tracked some kind of like kpis and goals like in our one-on-one document or another document on the site.

A

um I think now we kind of put it more in sync and how we kind of work at gitlab, maybe kind of like even combine it with parts of like our day-to-day job and also we now have it easier to kind of cross-link between different projects. So there's now our project for every person. There just be aware all those personal development projects live in the gl editor group.

A

This is where everybody of you is like a developer in so this means, or so everybody has like access to each other's uh projects as well, so don't put like super confidential stuff in there.

A

If you plan to um the thing is why I kind of went this route or so is, I still want to say: okay, maybe just like room, and somebody has like work to want to contribute or there's maybe tasks where people want to really kind of join first forces or work on something together, so we don't kind of create a unnecessary barrier.

A

um In this case everything lives in the gl, editor group and there's also now a team project that I'm going to kind of use for, like some really team tasks that are related not necessarily like to code or so or anything, but things we want to do as a team um like a editor team day which we're going to do sometime this year, just a small highlight but yeah.

A

This is this. uh We can talk about everybody's, like pdps in our one ones. I started to kind of talk about them anyway, already with some of you, but otherwise, if there's any questions, just let me know- and with this I took already like 15 minutes of everybody's time and I hand it over to eric who's sitting on hot coals to fill us in on his strategy.

F

Now I uh thank you for taking enough time for me to catch up on a little bit of stuff and write some notes, I'm just coming online after taking a few days off, so I have a lot to wade through um I'll, try and keep it quick, mostly because I don't know what else to talk about, and I want to give you all some time to ask questions. If you haven't um there's a read-only note in there uh the tldr is sorry.

F

I haven't made a ton of progress, but I'm working on trying to whip our category strategy, ethics and overall, like organization of ethics and issues into shape. I did a bit on static site, editor and wiki and started on, I believe, snippets last week, but it's a big effort. It's going to take a little while and hopefully on the other side of that it'll be a lot more clear.

F

What our our real priorities are for each category for the categories that are prioritized and the uh next steps and- and you know, immediate opportunities that we have in each one. So um on that note, uh roman michael and I met uh right before I left or a little bit before I left and had just like a little brainstorming session. There's a link to this um whimsical diagram. It's not complete. I wanted to go back and fill it out, but for my read-only note I didn't get time to before.

F

I left I'm going to use this as a way to map out larger initiatives and features for each of the categories figure out, which ones are dependent on each other and which ones we have to do in sequence. These aren't necessarily comprehensive, but in an ideal world these would all make it in each each little square. If you click through, I can share my screen too. uh Just in case you don't have an account or I don't know what that read-only view looks like if there is works, yeah, okay,.

G

F

Anyway, so the idea is, like you know, for editor light, which is not complete, but you know we would have little blocks like. These are the things we want to build into editor light. Each one could be an epic or and have sub epics. Maybe um same thing goes for web ide.

F

We spent a little more time on web ide and snippets than anything else during our sync meeting, and so I intend to go through and fill this out if you'd like to help out or maybe pair up with me and think through a category maybe like dennis, you want to go through editor light with me. We could set up something like that next week.

F

uh Maybe help me uh fill this out uh if you want to just jump in there and and put some stuff in maybe like draw a box around your work, so I know I'm not confused where things popped in, but that would be helpful. I would love it um and then you know. uh Ideally it's gonna end up in a form like this, where I can start sequencing things like okay and the web ide. You know roughly this year we'll do these efforts and that will build will build into such and such you know,.

G

F

A road map should be so that is something I'm working on, and hopefully um we can get excited about the output and the clarity that we'll provide um soon uh next on the agenda. Unless there's any questions about the fact that I don't have a completed roadmap to share, um I saw some comments. uh While I was off around settings, um availability versus visibility that came up again, this needs to be documented, better and that's my fault, but the just to say.

F

To summarize the question um we had some effort involved in turning off items from the left, nav bar in the settings. So right now you can turn off things like wiki issues, merge requests and a bunch of other features they're all defaulted to on. But if you don't use those features you can deactivate them in the settings at the project level. um There's a whole bunch of issues all related to making that more consistent, so that all the features that are generally possible to deactivate can be deactivated.

F

In the course of this, we discussed something where we might provide visibility, control, not just availability. So the idea that a feature is available like we do for wiki, because it's the one and snippets they come to the top of mind, they're already implemented this way. You turn it off. You try and visit a wiki and you get a 404 like the feature is not in gitlab once you turn it off on a project level.

F

That's what we mean by availability, visibility.

F

This concept came up a lot and it's interesting, but not our priority right now, but the idea that you could change the visibility of your left hand nav to make it cleaner or more relevant to you or your project, but still have access to those features. So imagine the wiki is turned off on the left nav, but you can still visit the wiki directly.

F

That is something that is an interesting opportunity that we would need to validate whether it's something we want to do and what the return on that opportunity might be. That would be a coordinated effort. It's not what our category is focused on, like our group is focused on right now for the category. We should be thinking about availability, in that we want the application, get allowed the application to behave consistently for features that could be turned off for those that don't use them.

F

So that said I'll document all that, so that there's no more debate and I'll create an issue or an epic to investigate the idea of like a customized visibility.

F

My take on this is that we would likely have the growth team or someone else do the research here. This is something that's probably bigger than even our group would would tackle directly.

B

I've got one question related to that, so I know there's at least one. I think there's multiple places where those slider toggles only control visibility.

B

So is there going to be like a preliminary effort to at least clean those up or like switch them to controlling availability, because I think that's where a lot of the confusion comes up, the existing ones that only control visibility, and then people invariably say well, should it control both or one or the other.

F

Yeah we, the the effort right now on our plate, is consistency so yeah. Absolutely we should. We should be consistent and if there's a reason that can't be turned off like I know, one in particular that we worked on is now only controlling visibility. We should go back and finish that up, so it controls uh availability.

F

If there's anything else that we didn't touch. That is behaving like that. We should first validate that there wasn't a good reason and and if, if it's just a matter of um implementing that, then it'll just get added to that epic. This is right now, though I'll say not our highest priority. Now that work is getting queued up for more impactful work.

F

um We should keep this ball rolling, but um that is a um we'll just say a secondary priority for our group, ideally one where we can do it a few more times and get a more carefully documented epic and then turn it back over for other people, community contributors or other groups to pick up and follow our pattern to implement on their own.

F

uh So just so, I don't take up all the time. The top nav changes that we're working on uh michael has completed some solution: validation on consolidating our um drop down menus for projects and groups into a super menu. That is where everything will be found and much more easily accessible. We're getting some really good feedback from that solution. Validation, he's working on polishing up the ui for mobile and I haven't caught up on the latest over the past few days. I saw a bunch of issues going back and forth.

F

I'm hoping we can kick that off at least start work on that in 1310. I don't know what the size of the effort is, but I imagine I gather that this was discussed in the um issue refinement session and and there's still a lot uh a fair number of unknowns. So um yeah I'm excited about that work, though I think it'll be one of the more impactful changes that we've done to that category. So far,.

F

And the last point I had is right before we or right before I left. For my time off, we had a great meeting to sort of talk through our iteration plan and technical kickoff for the rich text. Editor um pretty sure I recorded that and put it on youtube, but um wiki is still a great target for this, and even more so because, right before, like literally an hour before I logged off, I was finishing up- work reviewing our product performance indicators, and so uh we we're reviewing those with product leadership this week.

F

I think today- and I was looking at our numbers and our the summary background here is um when we look at our performance indicators, there's a handbook page. So this is all public.

F

I don't need to mask any numbers, because none of this is secret, but we have an algorithm that estimates our uplift for self-managed users and the the reason is because about half of our self-managed users, maybe a little more don't report their usage through usage pain, and so we kind of just take our best guess as to how many users of the group that don't report would be using our features for wiki.

F

That chart was way off and it said we had something like five or six million estimated users and like 400, 000 actual users like there's no way literally no way. That was right. The data team fixed that and it looks like our our data is normalizing, but our uplift now shows that we probably have close to 800 000, maybe a little more 820, 000 monthly, active users for the wiki, which is really nice to have a category that is so widely used and makes it even more impactful.

F

The changes that we're planning with the rich text editor. I think we're going to reach a lot of people and make um you know a lot of really positive change to the wiki and hopefully see that grow as more people realize it and you know, use it and decide they want to use it more um yeah. So I'm excited that it's it's an interesting data point just to reinforce using wiki as our starting point. um It certainly won't go unnoticed.

F

I will point out um the the numbers: don't change our overall product company, our strat, our company strategy for investing in the wiki. It's still not like getting it's not getting re-prioritized to the top of our list, just because it has a lot of users, we're we're focused on the right things, we're contributing to the wiki with the stat, with the um rich text editor. But uh right now it's it's still prioritized like it is prioritized it's it's probably.

F

You know um it's getting actually a, maybe a disproportionate amount of work in that friend's, been doing all that great work on the back end to help clean up our group wiki effort, but it's more like a uh 15 to 20 percent of our time that we should be spending on wiki as a as a group um and then, if that changes, of course I'll let you know.

F

Any questions or roman do you want to uh I I was trying to answer your comment pretty much.

A

I think you answered it.

A

I'm surprised it's like over, like one number that I heard like some time ago was like it was 100k 250k we said like okay makes sense to me to to not heavily invest in it. 800K seems like okay, that's actually kind of good usage for so.

B

In any case, it seems like converting into view, is like a good thing to do, and let's get that out of the way like we were discussing yesterday,.

B

A

It yeah we have to do anywhere, so I think, there's a bunch of investment we need to take, or so as jet says, or so, I'm still surprised by like the some of the product decisions, or so that's not getting more attention now, because this seems like a very high impact feature, probably more than like web addie or static site editor. So any of what our goals do have.

F

But yeah actually um so to elaborate a little bit on uh the relationship to the between the wiki and static site. Editor, I think um a lot of the interest in creating the static site editor group was around the idea of what is like a next generation collaborative environment. Look like this data point. Alongside our continued like.

F

Detailing of the architecture for this rich text, editor has me thinking a lot about how they play together and what's what the difference is and different use cases. So I don't have um maybe like a um really comprehensive and and easy to summarize answer here, but um it is something I'm thinking about very often these days and it's like: where does where does wiki fit in once? You have a rich text. Editor.

F

Is there some way we can bridge the gap between the two or are the use cases distinct enough that we can continue to develop them in parallel with a shared editing experience, so it's top of mind, but um not necessarily uh not necessarily just defined enough to to to put into a direction page.

B

So I remember once sid explaining his thinking on why a static cited, editor approach like why wikis didn't work for many people's use cases and why static site editor was where he wanted to go, and it made a lot of sense and it was pretty succinct.

F

There's a handbook page: why wikis don't scale and uh wiki handbooks don't scale, it's specifically for the idea of a handbook, I'll put this in the agenda and they're right on. I think that there are valid use cases for both. um I let me drop it in the agenda here.

F

um Wiki handbooks, don't scale there.

F

I think we need to get more clear definition on the personas and use cases that each are solving um wikis as documentation or wikis. As you know, collaborative note-taking things like that um could potentially just be solving things better, uh there's less upkeep, but uh for.

F

For the at least the near future, unless we built this into wikis like for something that would require a like review flow, you would need something built on the repository that can go through mrs static sites can offer that and obviously you get more control over the output, and you can do things that you can't do in the wiki today, not to say that we couldn't build the wiki to support things like including partials, and you know things like that. It's just you know it doesn't do it today.

G

F

Know if we would have to like you know, change the back end platform to support that kind of feature.

B

But um yeah it seems like the crux of sets point. There is like a static site, editor approach, lets you be, mr centric, and with commits and discussions around them and whereas wikis don't have that workflow ability.

F

Correct yeah, I mean that's a big one, um not to mention the the types of sites that static site, editor or a static site generator can put out. You know, marketing sites and things like that, like more fully featured sites are possible with a static site. uh We've seen some interesting movement on people using like a public notion page as their website, which is kind of an interesting use case, but a little, maybe a little niche for the market.

F

um I'm interested in that, though, and I'm looking into who's doing that and and how it's going. uh I know I've visited two or three randomly where I'm like. Oh well, that's that's notion what what's going on there! So um there's something there! It's not!

F

This is more like, maybe a two to three year strategy, though that we'll realize- and I'm not saying it's gonna, take me two to three years to define it but like uh something that we'll be implementing and iterating on um over the next two three years, not necessarily uh in the next six.

D

Months, where do you think the most significant problem lies when you compare the users goals and our wiki feature? Do you think it has more to do with the management of the wiki, creating updating pages or the reading of the wiki of the user? That's actually gonna that isn't looking to edit it, but it's looking to just get involved.

F

I mean that's a good point too, like we're our our um our core.

F

I don't know our core job to be done. I guess, with with the stocks I editor was driving people to make edits uh right, like we weren't interested in bringing more people to the page to consume the information, but our wiki data is people interacting with the wiki, because a wiki is meant to be there as a source of information, so I believe at least we're counting users page views as a monthly active user, um and as we should, I think that that's the crux of the value that the wiki adds.

F

um So I think I mean I think that is a major distinction. I think you're you're very correctly pointing out that um for a wiki to be useful and successful, it's a lot of it is around consumption uh of the information that somebody has put in there.

F

The the power as chad was mentioning um the power of a static site generator and a um a collaborative editing process built around that, like we were building for the static site editor, is that um we're driving collaboration on that content, which is a much more narrow slice of the potential user base.

D

Right so I was thinking um this is a crazy idea um like when you compare when you hear wiki, like I'm thinking, wikipedia and all the other like self-managed like out of the box wiki solution.

D

So it's interesting that we call our feature weak, because when you compare it to those it's it's, it's lacking a good number of not only usability of me trying to find things and because, thanks for categorize and and however, but also from the management perspective, I wonder if, if it would be an interesting catalyst to imagine a wiki, even though I can still edit it the way it is, but if we just deployed it to like a gitlab pages site and it stood alone on its own and we weren't polluted by the project sidebar and all the other gitlab stuff going on.

D

This is a knowledge base, that's out there and so me as the user. Now that I'm not polluted by the rest of everything. uh um How else do you say weak.

D

I love it anyways um if, if, if the wiki result could stand alone and be decoupled from the rest of gitlab, like a get lab pages, would then, like you know, as a user we'd have a lot more ability to view things like the the user should be able to see version history and like comments made on stuff and the user should be able to. You know, do advanced searching on the wiki, um and that would be really interesting.

D

If me, from the editor perspective, I'm just focused on making pages, but we've automated all the other wiki features for end users to have a positive roman. You keep laughing at me.

H

And keeps laughing, I love it. How do you say wiki?

H

Is it probably like super german, like I said, wiki, wiki wiki, but.

A

I I don't love about it. Just like I was so happy about this coincidental casing, but it's an interesting way of pronouncing it, and then chad says that is an interesting way of pronouncing.

D

That's that is different. Okay,.

H

Wiki like wikipedia it's, okay, we're we're still.

D

Waiting for myself to say you all, I think I can. I think I can add this one too. Absolutely I love it paul. Please keep doing, never change. I love it. Yeah.

F

You don't need to change for us.

F

I I hear what you're saying paul and actually you're right on uh one of the the big audacious ideas that I've had is like what and we've talked about this as a static site, editor group about the handbook as a product in that, like you, could just quickly spin up a handbook and it's powered by the static site editor, and it's got all these like defaults, and you just like you get a handbook right.

F

We could shift our focus and say our wiki or wiki is powered by the static site editor. It is not traditionally a wiki in that it is got a lot of features similar to that type of category, but it is powered by a static site generator and the pages are stored in a git repository.

F

I think that could be super powerful and it could enable our users and our customers and everybody who wants to have something similar to quickly spin up a project that matches ours in the app like it just exists, but also clone it and do whatever they want with it right. They could change the look of it, they could add functionality to it as we build out the rich text editor to support custom content, block types or something like that they could extend it to support rich media embeds or like we have.

F

We have some customers that would probably be very interested to like build a you know, uh a widget that embeds and renders 3d objects. You know so that you could have game data game assets or something like that documented in an interactive modules. So I'm right there with you, I haven't formulated this. I your that's a great question and a great observation. I think we could work towards there. I'd be worried about um alienating our existing users and converting the data over, but it probably is a surmountable problem.

D

Correct me: if I'm wrong our previous static site, editor vision was, we could use this across a number of different static site generators.

D

You could use this for jekyll, you can use it for hugo or whatever, I think the main benefit here and the main benefit for wiki readers and editors is, I don't want to mess up like we would abstract away the generator and I'm just focused on pages, and then the readers just focus on being able to find their stuff, and that sounds like a much more focused problem that we would be able to do something really interesting with. Certainly I, uh but I think one one powerful thing too as well is that version history?

D

It is part of the data too, that gets generated that can the static site generators, if we're in control of it, that we can um that we can even make presentable on the end product yeah.

D

I uh I can see the value of wiki and I see where, where sid's coming from, because I saw a video of him talking to paul up to about uh wikis versus wikis versus uh um static site generator things, and I feel like this- might actually hit all the all of the problems. Because when I think of two like how wikipedia is edited, um there's a virgin history and there's you know not, everybody is allowed to touch every page.

D

So there's kind of like a change request, things that happen and you can see those discussions and so to me, it just seems like our wiki implementation is just missing a lot of those features. Maybe because we're doing too much as opposed to constraining our uh constraining to what the users actually can and should do.

A

I wouldn't say what we do sorry from front: go ahead.

G

Yeah also because we are using a framework underneath so we didn't build this from scratch, so we are still limited by that library's feature.

G

That makes a lot of sense.

D

F

A

And and one thing that I kind of like missed this is like now, let's feel like, okay, that we said we want wiki like to do too much or so for its scope, or so I think we just kind of try to cover like too many different workflows with too many products like we have a wiki which is like a cache, allows you to kind of kind of structure, some kind of data, and it's basically static data you want to have somebody to consume.

A

Then we have the product gitlab pages that allows you to kind of deploy some markdown stuff or so or like has a certain way of like building it. And then we have like static site editor, which allows you to successfully edit markdown files, and in my ideal world, like all these kind of things, would be one product we're just saying: okay like either, I use it for a wiki. I either use it like as a data generation.

A

I use kind of uh the static site, editor or rich text like to just change everything and the default setting just gives me a way where I say: okay, there's one click option of like deploying it and whatever how I want to use it. It's just like up to me and it's living, maybe inside my project, so I get all the benefits of the whole mr flow out of the box anyway, and so, and we have basically everything in place for making this happen.

A

We just kind of really need to start putting the right products into the same space. Think about it holistically and find one solution.

B

That's what I was thinking, it's really, this venn diagram, there's like different users and there's this overlap of cms-like features and static site, editor, jam, stack-like features and wiki-like features and there's different users that care about different things. So it's really a design problem. If you like try to make something that does all of those things you're, probably it's going to be hard to make everybody happy.

B

So it's like how do we focus on these user personas and make something that are they the same product or are they different products or are they two or three products? I think it's really a design problem.

D

And I think it'd be interesting, focusing on the focusing on the read user, because our customers are interested in the read user like like that's the end and end user of all the knowledge and information and be interesting because you can sell it to the admins too, of, like the readers are really able to find what they, what they all the information, they're needing and they're able to view 3d models and all that stuff, but that I think prioritizing that user. It sounds sounds neat which.

G

I think is also.

D

Kind of the way the the out-of-the-box wikis have done just say.

B

It like cartman, says kitty chick.

D

Realize I'm getting pretty close to saying wookies you.

B

D

F

Reading wikipedia the other day wikipedia, that is a thing actually wikipedia.

D

It's a great source.

F

Of information for star wars, true yeah,.

H

F

B

This is fantastic.

F

I think you're all right on uh and I love the idea of. um uh I don't know just picking a path right like picking a static site generator that we can use abstracting it away entirely and not worrying too much about extending for everybody else. Yet you know obviously like as as the product evolves and this wiki on pages concept works out.

F

We might still find that it's it's useful to host other types of sites and other types of statically generated content can make its way into that vision that we had for the static site editor already, but as a way to bridge the gap between wikis and and the static site. Editing experience in our our new editor. um I like that a lot. I would be super interested if you just let that simmer for a bit and think about that over over the course of the next.

F

I don't know, weeks or months, and- and we can keep talking about this I'd be. I think we would get a lot of support there um as far as like product company strategy. I think nobody would complain about us moving in that direction. um We'd probably want to validate a few things from the ux and um technical aspect about migrating data and how what our mvc really needs to be and how fully featured it would need to be to make that kind of impact. But I yeah I like the thought process.

B

There's things like the the a and jam stack apis like a lot of times. People want static sites, so they can match up external apis or have a lot of control over that you, don't necessarily you know, put code in a wiki at least not traditionally.

B

True true and like the cms approach, a lot of people want a lot more control over styling. You know that's why the marketing went away from the jam stack, but they care a lot about how it looks. That's you don't necessarily want to do that with a wiki or you'll end up. Writing a cms, and you don't want to write another cms.

F

Yeah, the biggest uh the biggest urge I have to fight as a product manager for this group and the former static site. Editor group is to reinvent wordpress and rebuild wordpress.

F

As soon as I find myself thinking in that direction, I have to recalibrate and say: okay, let's take a step back, there's a lot of money there just.

D

Describe wordpress again.

F

Let's figure out what we're really building, um but yes, yeah you're right, um absolutely very, very uh poignant, observations from everybody. Thank you, um yeah. It's a good way to energize my brain after pto. Thank you for for that.

F

F

That was it for me if you want to um maybe stop the recording. We can touch more on that last point, but um that's it.

A

Sounds good thanks for the good discussion and I'm going to stop the recording.