Open Feature OpenFeature Project Meetings, 24 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Building the roadmap on GitHub - May 24, 2022

Description

Michael Beemer, Todd and Oleg discuss how we could build a new full-fledged roadmap for OpenFeature and what features GitHub Projects offer for that. Also we discussed GitHub automation through .github and with help of GitHub Actions like Release Drafter

OpenFeature website: https://open-feature.github.io/

A

All right and I can share my screen real quick. So um basically we had uh you had created the uh the project section of the open feature or for the open feature. Org.

B

Here, which, I think is great.

A

um It's using like the new, uh pretty cool projects beta.

B

A

Good, um my question is like these are all extremely high level. That's totally fine, but I need to start breaking it down into more. I guess granular sections um looking at the current state of uh github projects like doing like kind of nested high level or topics in here is not currently possible, maybe not even recommended so would you recommend me like basically adding some kind of like you know? You know, column and label here, so we could filter like main initiatives.

B

There are multiple ways, so we, if you want, I can show you how we do it for captain yeah.

A

That'd be perfect because.

B

um Another few examples, but in such case you need to stop sharing the screen so that I do that.

B

Interesting I'll uh close this slug so that it's not disturbing okay and this might create um yeah. So this is my screen. Yep.

A

I can see it.

B

Okay, so, basically, when you work with github projects, um there are multiple ways to adjust the dashboard. Actually, there are multiple visualizations available only in projects beta.

A

B

Example, we recently created a documentation thing.

A

B

Here you can see that there are labels, but also milestones. So, for example, if you have a milestone like well here, we use it as a kind of epics. Actually you can where.

A

Are the milestones defined.

B

So milestones can be defined basically on the project level. Well, on the repository level.

A

B

So, for example, uh for python is the key or we can say whatever one two zero really.

A

If I went to the spec we could say the spec could be like alpha beta.

B

A

Or something like.

B

That and yeah we can do that. If you want some milestones, we can create a new milestone.

B

Something like that.

A

B

It makes sense.

A

To be that, let's leave that one just optional for now, because I'm not sure when, when.

B

A

To that uh but okay, so we'd want to be like that verbose too. We wouldn't want to say just like alpha right.

B

We create a milestone and this milestone actually exists only within this repository. Okay. So what you can do is you can group them but yeah. This is a difference between labels and milestones because labels, you can operate them across multiple repositories in github projects and milestones are not implemented like that.

B

So, for example, this is alpha release. Do you have any uh topics you would like to really introduce in this milestone.

A

So I've been I in preparation for this meeting. I've started like defining all of the issues.

B

A

And I was going to port them over based on your feedback, so I have a lot of things ready to rock and I'll. Do that? Probably right after our call.

B

A

But yeah nothing necessarily, although we could probably move some of these. Like um I don't know the hook specification and stuff like that could be added to the alpha one.

B

Yeah anyway, uh we can later adjust it if needed,.

A

B

So I will just.

B

Okay, it shouldn't be a problem here, so I will just assign it to the milestone open uh future spec alpha. So you can. You can see it here. You can also see issue list right here right now and what we can do else that if we go to our project now we can configure the visualization because by default you cannot see that, um but you can actually adjust the layout. So, for example, uh you can set up milestone. Labels repositories probably doesn't make sense. I didn't pull requests, so it's one of possible visualizations.

B

A

I think keeping the main one as clean as possible makes the most sense.

B

A

Was kind of what I was thinking is like I like what you have here for the most part, and maybe I clean up just a few of these items, but I want it to be like.

A

I think I want it to be these kind of high level topics I think and then maybe create views that could like show. uh You know this is the spec work. This is where we're at.

B

This is what we can do right now, because yeah, for example. uh So this is not a good example, but, for example, captain roadmap, how it looks like we have slices of this roadmap for particular topics like functionality, core function integrations community documentation, and we can do it like that here. So, for example, if you want specification so here, for example,.

B

You can find a good imagery for that, but yeah sure yeah yeah. So here, for example, we can do search filter and, for example, we can just filter by the repository for.

B

Example. Second, I don't remember what.

B

So here I just excluded here I will include so basically it's all github queries supported here.

A

B

So here we are, for example, two altered map items are defined in the specification repository.

A

Cool and then I could have something yeah in here uh that makes sense. Okay,.

B

So, for example, what you can do you can also set up all the visualization like we did before.

B

So the repository doesn't make sense, remembering pull requests labels, but you can adjust it as needed.

A

So when it comes to main initiative should should would you recommend this being just kind of a dump of everything, or should I somehow keep it like at like extremely high level uh topics here, because this is kind of like the main landing page.

B

So here you can adjust as needed. So one thing that for my initiatives, well, you still can have a filter even on the main view.

A

Right, yeah, that's what I'm wondering like should I maybe apply something to to only show like kind of high level topics here or is that not considered like, I guess, good practice.

B

I'm not sure, because that would say that roadmap itself is high level topics already. That's.

A

B

Yeah, maybe actually like.

A

Just to some extent, some of these don't really make sense anymore. So maybe it makes sense to start dumping out.

B

Yep, so what we can do so if you see, I think that the item is already completed so, for example, github organization bootstrap. So that's not really case by now uh so bootstrap governance process. We can see that it's done because I believe it's done by now yeah, so we can dump it if needed, but yeah establish regular project meetings. Again, nobody cares by now yeah uh it's just unboxing project application in progress, uh define.

A

The defining initial stop is more like. I did actually update this issue associated with it, but it's uh I also want to port it. To this.

B

So what we can say that it's preview, that some bits are needed, but basically people who care could take a look: okay and yeah for stop bootstrap comments. Processor, pro probably close to the issue.

A

B

It's completed.

B

A

See actually, if you select that define initial scope, if you just like open it right there so, like I dumped a bunch of stuff in here as placeholders, basically I'm going to port this to uh basically initiatives more or less and then hopefully apply filters based on some of the stuff. You see here to like kind of reference all.

B

Of that yep I agree so yeah define project of kids. Actually alpha version, I guess plant stop. Communication channels are planned. So probably I should have created item for social media project logo. You're done archive initial project website done archive yeah.

B

There should be a hotkey for the defining the final governance model yeah. I think it's still open.

A

Yeah we can do the announce uh project at kubecon. That's done.

A

B

Yeah then better release your general availability release. It so far.

A

I mean really even number one is done too this one I mean.

B

Okay, let's close it.

A

B

Yeah so define initial scope. I mean.

A

Honestly, most of these could probably go away when I, after I've gone through and done the rest, because I think you can accomplish most of the stuff with uh you know. Different labels and filters and whatnot like the the road to general availability, should probably be done with milestones. Based on what we're seeing here,.

B

Yeah, this is what we can do so now it's rather just polishing and we can so fast. Of course, the main question would be what we need to put on the roadmap.

A

And I have that kind of done. I think now, um so I can I'll start plugging away on that and I think when that's done I'll archive all the stuff you have currently.

B

A

I think I guess the question is like what would be a compelling main landing page like what would be something that you could say like what is the current state of the project or doesn't it matter? Could we like look at because, like I almost need something? That's like the spec is in progress. The whatever is.

A

I think I think I need something like that, but perhaps not.

B

Yeah, this is a good question, so I think that so when captain we just put whatever needed- and this view isn't very friendly right now.

B

So what I would do here is that if you want top level items, maybe you could have a board that consists only of nodes, uh because it's possible. I guess so. You can select field that it excludes everything. That's.

A

What I'm wondering maybe just have incredibly high level topics like whatever define or like alpha release or something like that uh for the spec or something so yeah.

B

Yeah so see something like that.

B

So we can do something. Like example,.

B

Component, just disex.

A

Little tilde in there is that.

B

Oh, no, it's actually it's defined.

B

No, it's not fine, because.

A

I think you have to get rid of the dash in front of the org. You know it, you did it on the other ones. Yeah.

B

So this one just excludes everything, so it doesn't. Allow me to write a note like that. I believe.

B

Oh okay, so yeah, I guess uh uh some filters are not exactly as we one would expect, uh but yeah okay.

A

So I mean maybe it's no big deal I mean maybe like at the moment people care more about the specs. So maybe, if I could put the spec as like the main landing page basically and show like the different topics that we're working on where we are um things like that, may be really really nice uh and then obviously the sdks are next and then some of the other stuff kind of like downstream there. So maybe, instead of doing some of the other pieces, I would just focus more on on the spec.

B

um So this one would be something like all.

A

Yeah, basically, like all topics or something you know basically, um and then that would probably be at the end of the list. You know what I mean it's like. If you want to see everything we're working on, you would go to the last tab, but if you're going directly to the modem roadmap with no view selected you'd land on the specification, so I think this is stuff that I can kind of handle. I was kind of just talking through or trying to think through it at like.

A

uh You know what would make the most sense uh to you, that's kind of where I really wanted the feedback. I.

B

Think the work itself.

A

I can do uh pretty easily um seeing like the filtering and you can create custom columns. You can add in, like you know, whatever statuses you need like, that stuff seems pretty straightforward. um It.

B

A

Just I was kind of just trying to figure out how we went from the stuff you had, which I think was solid and breaking it down. You know because they didn't really have those layers of abstraction, although I actually, maybe you can help with this one. I saw something in a video yesterday that, if like say, if you select test, for example, so number nine.

B

A

If you open that up inside here, I think there's a way to write the issue in a way where you can like basically highlight it and say like break into issue or something do you know how to do that.

B

A

Thing not converting that to an issue but like converting, like a bullet point into an issue effectively.

B

I haven't seen this functionality, but let's this year, maybe.

B

So basically, it's a standard syntax for check marks and.

A

If you select it, no, not don't do that select the test one, maybe in some like if you hover interesting, because.

B

A

In a video like from github or get github a few days ago, they had a way where it was like, like listed out as.

B

A

To accomplish, and if you hovered over, it was like create like a sub issue or something.

B

Yeah so maybe it's possible. Maybe it requires another feature flag to be enabled because uses feature flags, but yeah.

A

I can look into that if I figured out I'll, let you know, but I think like that would be pretty handy because then these these effectively turn into like epics. That could reference.

B

A

Issues and whatnot so yeah.

B

uh Yeah, so you can see that there is project, so I basically have all of feature flux enabled I mean once which are public, so that is set by now that yeah. So basically, this is what we were trying.

B

A

Yeah I'll play around with that, but this all makes sense so far. um Well, I guess yeah. My main question was more or less like. Should I create multiple projects or just try to apply a lot of filters and stuff to.

B

A

And have like one project that just has encompasses everything and just has different labels that allow me to like slice and dice it.

B

Yeah, so what I would advise that the roadmap doesn't have to include everything so world club roadmap is already for top level initiatives.

B

So if you need to create something specific so, for example, python sdk and whatever you use 2000 tasks there, maybe you want to have a separate project, but for roadmap you still have something top level like uh uh uh python, sdk version, 1.0 python, sdk version, 2.0, etc. With scope.

A

Yeah, okay, I mean, I think, really what you have here and I'm going to go through it with specification, but we have status and milestone and then the title, I think, will be very powerful. I'm not even sure if, like labels are totally necessary, then to some extent here.

B

The benefit of labels is that you can quickly filter by them, um especially on this view. So, for example, you want to see all documentation items, you click and you get them.

A

B

So this is probably an advantage, but it requires labels to be properly said that number of labels should be limited. But for me actually it simplifies navigation for all dashboard, because I can easily get a slice without negative.

A

Can you send me the captain, one I'll, probably just use that as a frame of reference as I go through this and how detailed are some of these issues? If you click on them, I guess technically they're not issues. Are they in.

B

This case well, uh so some issues are quite detailed. So, for example, captain enhancement proposals they're, basically pieces of specification, so they have specification, they have a bunch of statuses. They have linked tickets if needed. So this edition some other items like captain community and cubecon valencia. Well, there is some text there.

B

A

Yeah, what about in terms of like a template for this to have some kind of consistency? Is there.

B

We have some issue templates so for examples for for bugs for feature requests for integration requests um and how it works. So, for example, for integrations. We recently moved to another repository to avoid pollution of the main one, and here you can see, issue template created by adam garner.

B

So there is basically a template that uses a new layout which so in github issues you can use, forms right now. Okay, so this is this.

A

Oh cool so it'll like pop up and at like a form that you fill out to like start to template the.

B

B

I guess something is broken, because, usually so we should generally open it, it should templates, I believe, just second, maybe it's just a small bucket right away, because we were doing a bunch of experiments, but then some things could forgotten.

B

Github issue template actually that's interesting because it really doesn't show it here.

B

So, for example, here, if you create an issue in captain, it will show you dialogue where you can select a type of the issue, then here, for example new integration, and it actually opens this one but copies all the context instead. So something is definitely broken in this repository, I'm not sure what uh but yeah I'll figure it out later, but generally for each type. You can stop your own template either as form or all style like this one, and then you automatically get labels assigned, etc. So users don't have to care about it.

B

Sure, because bonus points that you can have additional metadata. So, for example, we send people to slack that is also security, metadata new integration, and you can see that it actually redirects to other things, because we use standard github metadata to adjust it. So it's not an issue template, but it points people on the same list.

A

uh Recorded uh security, vulnerability that one's called okay.

B

So security is basically standard uh functionality, so for security we have captain.github. So it's global configuration repository and here, for example, we have secured tmd file and if it's configured in this repository it applies to the entire organization by default.

A

So I yeah- I had a question about that, so we actually are using the dot github um in.

B

A

You had set that up and we have like licenses and stuff like that. But how does that actually apply to a new repository because it doesn't seem to just like inherit, like I thought it was going to it.

B

Should inherit so, let's take a look so in github here we have contribution code of conduct readme, so these files are inherited license.

A

Right, but if you create a new repo, it doesn't show up unless I'm doing something wrong.

B

It doesn't show up so, for example, which do you want to take a look at like.

A

If you, if you just hit new right, I guess and tried to create a new repo here.

A

um Do I need to do something special here.

B

No, no, you don't need so I will just.

A

B

A

Here you have like the license like selection thing and all of that.

B

A

Do nothing and do create repo, at least it wasn't for me creating uh or porting of the license and other stuff see. Okay,.

B

So, let's take a look so here what you get by default. We have code of conduct.

B

So contributing file. It also comes from this repository, so here so when you create a new issue, for example, uh it should show you your comments.

A

B

Pulls this data it doesn't license because the license has to be defined in every repository. It's just a requirement of some licenses.

B

A

Yeah, okay, okay, cool, so everything's working, it's uh license was the only one that was a little tricky because I thought that that would like be added right to the repository, but no cool.

B

A

B

So this repository can also be used to stop default, github actions to stop default issue templates and other things. So it's quite handy but yeah. It still has its own limitations.

A

Yeah yeah, okay,.

B

A

Okay, um anything else that you're noticing that needs like immediate attention.

B

A

Guess like like to go through, I think we have to make sure that the apache license is like universally applied like it looks like it's missing from the python sdk.

B

A

Guess I'll I'll make sure to add that prior to or or does it not need to be everywhere.

B

Like which one.

A

Like there, you can see like some of them had like detected the license. Other ones did not likely because of what you mentioned, where it.

B

Has to be on every repository.

A

So we should go through and make sure that we add an apache to license to all of them. Yes,.

B

So this is well it's easy. You just do that once.

A

All right- and you can see them all all right here- yeah, okay, cool yeah.

B

For the rest, uh yeah most of metadata could be stored in github these days.

A

Yeah: okay, cool, okay, um yeah. I think that helps quite a bit I'm going to dive into what we did, I'm going to focus on the spec portion of that, because I think if I.

B

A

That, in a good spot, it's going to make people feel a lot better. I'm also going to make the uh sdk repos public with that disclaimer um I'll probably also update this back and try to like. uh I don't know- I probably won't get to it today, but I'm gonna start uh updating that readme a little bit as well.

A

B

um It still requires some liquid work to stop everything. I actually wanted to stop it in captain and then move it over then keep going.

A

Yeah um yeah, it's uh it's interesting! So.

B

A

Yeah, I think this will help quite a bit, though, if I can get this in a semi decent spot, then I don't have to like individually answer slack messages, theoretically, at least about like what the status is. It's like go look at the board because that's basically what I would be doing so.

B

Hopefully that helps.

A

I'm hoping to have it done by the community meeting at least maybe not done, but like underway um solidly underway. So people can understand what we're doing.

B

A

Concern about this- and I think we've already talked briefly, but it's like the reason I was reluctant to do it at first was to some extent it feels like we're sort of mandating the direction now. um But, of course someone needs to kind of take some kind of initiative, so I'm not sure how to balance. You know, initiative versus community well,.

B

For me right now, so the project is in pre-alpha stage.

A

The governance.

B

Is an input strap stage, so basically we go. We tried something we learned. We are just for me. It's perfectly fine that you create a template roadmap. I mean put everything there. It still comes on with a disclaimer, then basically review it with the team at the meeting, and then you agree what goes there? What's not?

B

Okay! I wouldn't be too concerned about uh doing some experiments right now, because everything is under the disclaimer of experiment.

A

Oh yeah yeah that all makes sense. Okay, um I guess last question because it just came in like 25 seconds ago, someone just opened up an issue on our spec talking about uh hook, context and stuff, like that. um This is a good question but like if we were talking about from a project planning standpoint. If I had like hooks as a item on our spec, uh you know project board. Would it make sense to like reference something like this inside that ticket effectively?

A

So it's like it's a little bit easier to drill in or no.

B

Yeah, I think it can be totally done, so one, of course, is milestone, which is probably not appropriate there right, but yeah. So formally, there is no sub tickets on github issues, but you can just reference it so, for example, 68- and this is uh what draft hook specification right?

B

Yes, so here, for example, uh we could do like. I usually do so something like scope here, you can use this metadata, which is a checklist and here, for example, uh yeah we around hooks whatever else we have so, for example, or recorder rank and state. uh Finally, who cares.

A

Right, okay and then this could basically be slapped right back on to the uh like. This should be probably converted into like a road or a a.

A

Yeah, like yeah, exactly.

B

I think uh so, for example, let's try to do it, so I uh put it here then I put it on the road.

A

The project- okay,.

B

So on the project uh right now we don't have automation sets, so it just goes to non-status, because if you set up automation you can actually set up automatically states based on statuses, etc. So.

A

Yeah, that would actually be cool too, like if we could throw like if it's something new, it should probably be under like proposal or something like that, and then we'd have to kind of manually change it to.

B

uh Yeah so, for example, currently we can put on.

A

Our book or backlogger yeah, whatever.

B

Yeah, you can easily set up automation so a bit of workflow uh and here, for example, when item added to the project uh status backlog set, enable just enable yeah. So there is a bunch of default workflows, so they actually publish this interface quite a lot uh but yeah right now. It should be by default.

A

Cool so now, if we go to the specification tab up here, it should show the draft hook specification yep right, like it could do.

B

A

One in the top left here it should show just that one hopefully.

A

um Right, like the other tab off to the left, slightly.

B

A

The the specification tab that we have up there that should just show.

B

A

This one, okay, I know we added a few others, but I see okay.

B

Yeah, so you can also set milestones for this because I believe that so here we basically get only a top level item because we haven't added other to the projects, but once you navigate, you can see all these items.

A

Yeah: okay, that's what I want to do here, because I think, having all of those listed out, you know fairly well and then uh it's starting to link to other issues and discussions about that makes it pretty nice and.

B

Quite a bit more.

A

Transparent than okay yeah.

B

Yeah because then it says.

A

Track, that's what I was looking for. You see that uh tracked in you know 42 at the top. That's pretty cool.

B

So basically github, it's all references automatically uh yeah here, I'm just hitting milestone, so you can easily do it in other interface or maybe you can just maybe at some point. You want to create a label for hooks and you don't know so it's up to you how you define it.

B

But you know, if you go to milestone, you will actually.

A

Can hooks be uh repo specific.

B

A

They org specific.

B

uh So fork specific what you can do uh so if you go to github organization, so here you have to stop default labels uh so and when a new repository gets created, then you get labels.

A

B

Topics so, for example, for topics we can uh say that by default we.

A

I see okay, yeah.

B

So here you can adjust these labels that all also configuration is code topics so, for example, settings yaml, github application, which can actually add a github settings code. So.

B

Just showing so well maybe it's mostly for simon or whomever wants to play with it. So there is an app called settings. I believe.

B

Maybe maybe they moved it.

B

No, it's still here, I'm not sure why he didn't find it.

A

Okay and then with.

B

Yeah there is view all button: okay um yeah, but basically this is a promote application. So basically promote means that it's standard configuration framework and you can define this github settings yaml in the dot github repository and once you do that, every repository which is connected, uh it will get saved.

A

Cool yeah so like, and I'm assuming, if we leave things out, they're just left undefined, but studying things like home, page and topics and stuff would be great to automate yep cool yeah. I know that's a great tip. Can you send me that one too? Actually it's just app settings. I can find that actually.

B

Yeah so I'll send it to the chat, and you have this recording.

B

A

Github's, pretty flexible man, it's pretty cool.

B

This is actually a main difference between github and github and other systems, because they invest a bunch of time in this ecosystem, so both ups and actions and uh thanks to that, actually there is a lot of features available. So I've.

A

Not even looked at this, but that's uh to get tipped yeah I'll, take a look into it.

B

Yeah so yeah, there is basically infinite organization management things so, for example, hello, boat, stale boat, which automatically closes steel issues.

B

Well, I hate this board, but it's a separate story, but yeah you can actually find a lot of good stuff here or, for example, I personally make fun of release drafter, which often automates really is uh change. Locks based on pull requests. So it's not a git change, lock, it's more high level based on pull requests.

A

Okay, and, and so would that mean that we really semantic convention would not really be necessary, because that was something that we were actually todd, and I were talking about it's like do we try.

B

A

Semantic convention, or do we just use like detailed, pull, requests and stuff? I.

B

Would, rather just be honest, well.

A

That's that was todd's uh uh hope as well. So I think that's that's good to know. Okay, yeah.

B

So we use it in jenkins, we're quite successful again. I have no idea what my marketplace search doesn't work, but I'm able to find all these boss etc. Right now, so we use it in jenkins and, for example, most of jenkins change logs for plugins account he built on this app. So, for example, let's take something useful, like configuration split plug-in so here. Currently we have continuous delivery. uh So sometimes versions are not that informative.

B

A

And that comes from the pr yep like title then, and then you just drill into the exactly.

B

So it's basically a title and label so, for example, here you how.

A

Do you enforce that on the pull request or or don't you it's.

B

Automatic, oh, you mean how you're enforcing.

A

Because, like here's, gonna have to have something on here right to know, if it's like a breaking change or something or is that like? How does it know that or does it not.

B

So, for example, for breaking change what we have in jenkins unless it changed, or since I stepped down a bit so here, for example, we just have a label for breaking or for removed, and once you put this label it automatically gets here in the.

A

Top, if you just apply that to the pull request, then it just works.

B

Exactly so, for example,.

A

Oh man, that's way cooler than doing like a semantic convent commits.

B

A

Cause then everyone's gotta screw around with that, and you get a yeah right, tooling around it. So this is. This is way cooler.

B

Yeah, so basically, currently, this draft is maintained by a few people from the junkies community because we are adopted mostly everywhere. So here, for example, we just use double github, so you can see that even for the jenkins core, we have unified configuration and here so, for example, it hub. If you go here, it's here release drafter, so here you can see basically how it works for us. So by default we use two-digit versioning, not somewhere, but you can configure somewhere as well.

B

uh Here we have priority so based on label like breaking removed, major features etc. So we generated this layout, um then we also have some excluded labels so that we don't include everything and then we also replace some text. So, for example, here we automatically capture issue ids from jira and replace it by jitter hyperlinks.

B

So if you have a release, it gets automatically replaced and, for example, for us we can use the same for open feature, enhancement, proposals or whatever they call it eventually, okay and you're interesting.

B

So it's quite helpful actually.

A

And is that that's just applied across all orgs then because you're putting that inside your uh github file? Yes,.

B

Or should I do.

A

It like in one of our repos at first and then move it.

B

Yeah yeah, as you prefer.

A

Okay, what do you think, what would you recommend or doesn't really matter at this stage.

B

Well, it doesn't really matter the stage so for issue templates. I would recommend to start them, build building them in the main in dot github right away, because otherwise it's difficult to drag them uh for github releases, etc. You can actually start using don't github as well, because the tricky point, even if so here I just use source repository, but you can actually have multiple configuration files.

A

Isn't that just yeah, it's something you just get to choose from then: okay, is there some like like, instead of just reinventing the wheel for like issue templates? Are there some like good resources, for I can just kind of like you know, borrow and modify.

B

Yes, there are actually even a repository for you for your templates, the problem that I believe that it wasn't updated.

B

Complete templates, if I recall correctly so the problem for that, is that I'm not sure this repository was updated to a new version, but here we can just uh check so, for example, issue template. So you can see that uh these are rather old versions.

A

Okay, I'll poke around and see. I just like no no reason to reinvent the wheel if someone's already done a nice job, uh you.

B

Know coming up with.

A

B

Yep, so you can find there is a bunch of repositories that are many projects that heavily use it. So engineering on is many of the features, but you know we each other need to catch up for issue templates because we haven't adapted uh adopted alpha. Yet I mean that is uh yaml forms.

A

Cool okay, I think that helps a ton yeah thanks for for going over. Oh, can you send that to me too, that release draft thing didn't didn't, find it in an immediate google search. So if you have it, that would be cool.

B

A

Sweet yeah, I think those apps and stuff looks sweet. That's something! I'm gonna definitely keep in.

B

Mind so when somebody asks why I cannot use gitlab right now is because lack of this ecosystem, because even before they introduced github actions, it was super powerful and now, with github actions, where you can basically do anything you need for organization management, it became super cool.

A

Okay, cool yeah, I think- uh and I think I'm gonna sync up like david periodically, but just doing some kind of regular touch points, because, like this, this like I knew I was kind of lacking in some areas, but like going through it with you, like, there's stuff that like looks incredibly useful and I had no idea existed so like doing these at some semi-regular sink. I know you're super busy, but any anything where we could kind of just go over.

A

uh You know org health related issues or something would be pretty.

B

Easy to do that so actually we need to do it anyway, because we need to share expertise even within our hospital, because all of us have different experience so someone, for example, a new team member who actually helps with captain right now.

B

So he also has a lot of github organization experience, but we don't have the same experience. So it's great for another sharing.

A

Yeah, it doesn't have to be super frequent either, but just doing it every once in a while would really uh really help. I think cool all right. I know it's getting super late there. I really really appreciate the time.

B

And uh yeah, I still have another meeting soon. Oh my gosh, I spent almost all the morning trying to get the passport and they totally failed. So that's a bummer.

A

Well, best of luck with everything and uh yeah. Don't don't burn yourself out, though,.

B

Yeah, thank you. So should I just probably publish this video on open feature, youtube was unlisted because I don't think there is anything secret there.

A

Yep, that's fine with me. I guess yeah um sure.

B

So unlisted, so that it doesn't go through all the notifications. Eventually, you might just want to have these notes about implementation et cetera, but they.

A

I I don't know about that, but maybe I guess the world can see how naive I am to some of these github principles.

B

All of us contribute to open source. You can go to my first commits to open source. Well, I hope nobody does it when the interview.

A

Yeah sounds good cool all right, yeah, thanks again for your time uh have.

B

A

Good night I'll talk to.

B