Open Feature Project, 3 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, August 3, 2023

Description

Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/

OpenFeature website: https://openfeature.dev/

A

A

B

A

Hey I have no c yeah.

C

uh Application and and then after vacation I, had to work and.

D

Hey guys morning or.

E

Afternoon, for.

F

D

All right, let me pull up my notes. Real.

E

D

D

I'll send the notes here too so feel free to add anything. If you have any specific topics.

D

I'll try to described today so, if I get distracted. That is why.

D

All right, hey, Ben,.

D

Hey guys, all right added I, just linked it, but a few more people joined so I'll go ahead actually and wait until Tom joins real, quick and then set it one more time. Sorry about spamming the chat, if you don't just mind or mind, adding yourself uh as a participant and we go ahead and kick it off. Hey Tom.

E

Hey how's it going.

D

Well, how you doing it's.

E

It's good I'm, I'm uh I'm rushing to get all my morning. Things done in time. Nice.

D

All right, I'll link it one more time all right.

D

um Yeah I guess we can go ahead and kick it off. uh I think everyone everyone's basically attending one of these meetings. I believe right. So, if not feel free to introduce yourself but okay, we're all good all right. uh It looks like Thomas. You have your first first topic on there.

G

Yes, um I was actually working in a Java SDK and uh like doing a provider, and uh what I noticed is like uh when we use set provider in in the sdks uh like the initialization States is uh async, which is what was the decided uh back in the days, but uh I found it like a bit weird for for people using the SDK, because they probably will have their first evolution uh with an answer as provider not ready and and I was uh like just wanted to bring it like.

G

If we want to introduce something that being sure that when you use set provider, you can wait to have a real estate uh from your provider before being like having a waiting statement not having to put listener and all of this to to get notified from that, because just it's a lot of overrated. If you want to do that compared to what vendors are doing actually in in, if you look at flexmates or even lunch directly they're, just like you use you initialize it and you can use it right away.

G

You don't have to add extra stuff to wait to be ready when, when you increase your SDK, so I'm not saying it's a wrong pattern that we're using it's more like. Should we add another way of being.

D

Sure or something yeah taught about something similar in the JavaScript one where you basically just have like uh you register it, and it's just like await this. Until it's ready or throw or whatever the behavior would be um I.

H

D

That makes sense, yeah I would agree with that um Todd do you have any thoughts and, and what would you like to do as kind of a Next Step.

A

um Yeah I mean it's like a one-liner in JavaScript.

F

A

For instance, to just like basically set a Handler at a Handler and await the uh like, basically resolve the promise with the fire of the Handler. It's a little bit more complicated and it's slightly more complicated in in Java, I, think um and other languages that uh aren't so callback friendly as in Kuwait uh a native days in Kuwait, um I I. Think I am in favor of some kind of convenience.

I

A

um But there's some stuff we have to think about around them, like am I naive kind of initial first plus blush reaction. After talking to Thomas and I, put something there's, there's a good I, don't know Thomas. If there's that uh slack thread you want to link in here, because maybe people will like to read it um yeah, but the it was something I put in I. Think a different thread with Thomas was yeah.

A

Maybe just like a wait for provider ready and you could Supply a provider name or just none for the defaults, and then it would block until the provider is, is ready, which I think would feel natural for a lot of use cases. um I, I, guess that I have a couple open questions there. It's like well really you'd be awaiting initialization. So does that throw if initialization fails I'm inclined to say? Probably yes um is there like a default timeout and then you throw after that time out?

A

um Does it just? Does it not throw and then all your stuff is defaulting with error messages or error evaluations? After that, there's a there's, a few open questions, and maybe it's not even something we want to spec out because I don't know if it. If it really is the same in every single SDK I think you know, things are very different, like go as channels JavaScript, like I, said as async awaiting promises and then Java is, you know more more thread.

A

um Threads are more kind of part of the Paradigm, so I don't know if it's something we want to spec out, but it's at least something we should consider SDK to SDK uh what we want that, like waiting for ready to look like if you're kind of waiting for it in an imperative and blocking way with the behavior should kind of be, should we should at least discuss it and maybe consider specifying it um like as a as an optional thing, but at least if we do that, it'll be somewhat consistently implemented.

D

Just to have like this discussion captured somewhere, um even if it doesn't end up going like into spec necessarily, but just having like the discussion log captured in essentially an issue in a pull request.

D

Thomas, would you mind putting like the initial draft together.

G

D

Through it on there, okay.

G

Open like an issue or open request for an office. Thank.

D

You very much yeah anything else on that topic.

H

um I had a question in general about the events uh and and basically the way that we set them, and then we meet them and uh um so, like the first question that I have is I think like in general, it whatever that is in the specs right now is more like State uh than events, because, like you just want to say that hey like, uh like the provider is ready or like provider, is um like an error state or in the state state.

H

The reason that I'm saying that is State more than an event, because events are normally like fire and fruit like you actually emit something, and then you don't keep it anywhere. And then, when you listen to that again after the image is emitted, you don't get the like replay kind of like that.

H

The event was actually happened, so you might come to some sort of like racing issue if like, for example, if you set the provider and then provider like somehow emits the signal that hey, like I'm, ready and then like uh in some other frames, you just like set the Handler and then do we expect that we get this like emitted event.

H

Again, um so we go directly forward with the the uh whatever you want to do, um and then is it kind of, because I think it wasn't really uh specified anywhere in the specs that this, like events, should be replayed um when you listen to that again, like add a new Handler, for example, um yeah.

A

So that's, actually it actually is. There's there's a the point probably needs to be expanded, um as came up recently, but there is a. There is a specific point about ready handlers, specifically replaying, but I think that ready Handler uh as well as as well as the error Handler. Basically any handlers that um correspond to those provider.

A

State changes um need to be replayed right now that the spec Point only says the ready, Handler I can get you the the point that specifically says it, but it's exactly to handle the use case you're, describing where your provider is ready and then immediately, because that's a totally different section of code. You add a ready, Handler and you you might not get it because your provider was ready before you added the Handler that Handler should run um and that that is there.

A

I can show you the point, but the point should actually also apply to error handling. Cavendu pointed that out, I think a couple weeks back and and I don't think. We've amended the spec to say that, but it probably should be amended. Yeah.

H

So I think I think that it was kind of mentioning that, uh like it, this is not like really events. It's like. We want to keep providers States and observe the provider States. So then observing the provider. States kind of like also indicate that uh we want to keep all of that. Basically, the last state like is it state? Is it there or is it like red? And uh another thing is what about re-ambition like, for example, um imagine middle of the app session?

H

Something is changed like you just say that hey I want to add age right now, because the user inputs that um and then the contact is changed. Then I want to emit like stale again and then ready again, because and then imagine that you have a composer and then first you are actually listening for this Handler. That provider already. Does that admitting so? Does it mean that imagine that your first screen like a login screen or whatever is like um so should we listen for the first mission election.

A

That's a really good question and actually um I'll link this in the CH in the chat and in the doc. uh Somebody brought this up. Billy, Billy, Lynch, um I, think yeah, so I I put it in the chat here. I'll also put it in the doc.

A

A

um But the the I think it's a question around. What really what you're saying the thing is that um this is more of a concern specifically for the client, which is probably why it's something that you've thought a lot about, because I know you've spent a lot of time working at Colin um when, when we're talking about the server the change in the context, the the context is dynamic. It basically changes every single request.

A

It's like a transient thing, um so you wouldn't really want to admit, admit events around that context being changed really um because it's a it's basically part of every single flag evaluation on the client.

A

When we have that the static concept, Paradigm or the static context, Paradigm or the you know, we call it the stat context Paradigm, but basically what it means is the we expect that there's kind of this um conscious uh and change around the the context being mutated, and then we hook in functionality to that so I think that's kind of what you're describing um and this issue was open to kind of add kind of Eventing around that and notifications around. That does that kind of relate to what you're talking about am I understanding, correctly yeah.

H

I mean exactly like what I was thinking like a potential solution would be like um utilize, this for kind of mid-session updates utilize. Some other events like Pro, like configuration, update, something like that or rather updated, and then, um like the provider, is ready, like it doesn't change the state, uh but it has some effects. Something happened like you, you can't miss it and it's okay to miss it, but um yeah.

A

Yeah I I totally think this is important in the client. It's something that it's something that I think we kind of didn't think about implementing when we first did this static context Paradigm, but after this issue was opened, I I personally think it's pretty necessary to be able to observe and react.

I

A

That situation so I definitely think we need to refine the issue a little bit. I'd love your and anyone else's input on on the issue that I linked but I, think I would love to see this enhancement. It's going to be really useful for the client I, don't really see it as applicable on the server. So we'll have to be careful to specify that it's not it's not really an event. That's going to matter too much there. I can't!

A

Imagine why you would care if the static context has changed when you have it updated at every flag evaluation, but for the case of the client I think it's definitely relevant.

H

Yeah, we actually also added something like in the kotlin um like um like uh continence the date which is likely use um suspending for provider ready, so the update provided already and then that makes sure that we do it only once so like the first time that, like we just checked it as soon as the provider is ready or is already ready, then go to the next line.

B

D

Yeah I think we uh yeah. Let's work through this. This pull request. It's it's linked in the docs, real, quick, but I do think it's something that we can. We can work through uh kind of asynchronously or chat about in the next session, if necessary, but perfect. Yeah thanks for the the feedback there um Todd looks like you're next.

A

Yeah so I lost track um yeah. This should be pretty quick.

A

um I'll I'll put another Link in the chat, so everybody knows what I'm talking about there's um there is a document status section in the spec here it is, um and this basically outlines the stability of uh basically particular features in the SDK I think we're doing a little bit of a disservice to our consumers, because um we we've marked um some of these sections is as stable, sorry not as stable as hardened or experimental, um and uh it's not really exposed to them very well, like I, wouldn't expect any consumer of any SDK to go like be like.

A

Oh, this SDK features events and then run out to the spec and see the stability level of events is experimental and therefore we can make breaking changes without doing a major version. Update that's kind of what this contract stipulates.

A

um I, yeah, I think we're I think we're a little bit doing a disservice to our consumers by not making that very clear to them, um because they have to go to the spec to get that information, so I'm I'm interested in how we can maybe expose that um in the sdks. Like uh a contributor to the Java SDK Giovanni was saying you could use annotations on methods a lot of times. People pull open the source. Sometimes when they look at the contracts.

A

That's one way to do it, but I'm interested in what other people think. Maybe it's like jsdoc, javadoc, inline, doc, kind of thing um to just to Mark at least Mark experimental features and then I guess the corollary.

A

The related thing is: do we want to think about kind of graduating some of our features, especially now that we've we've um we've had events out for a little while we've released the the client SDK for for the web at least, um and we're coming up on I think coming up on a year, I think since our first one that I was soon so just putting that out there to people.

J

It's Tricky I can't think of any language. Other I mean Java has like deprecations is almost like a first-class citizen. Doesn't it and I don't think many other languages do.

J

I can't think of any.

A

Yeah, the the The annotation based thing came from grpc, so grpc basically has a no-op annotation in in a couple of their implementations, where they just like put this annotation on a method, and it says like experimental. It does absolutely nothing. But if you look in the, if you right click and go to the definition, you'll see there that it's experimental, I, it's it's something um I I, don't know. If anybody has other ideas, though,.

D

I mean I, guess the one thing we should be clear about is like if it does land on the spec like we need to do everything we can to avoid breaking changes like you know, even if it is marked as experimental, um and you know, I I think with that in mind, it's like as long as we're very careful in what we're we do have to make it we just basically would you know if there is JS doc or something you could say that, obviously, above the the different portions um and I, also one of the topics I wanted to talk about was an updated readme like maybe we could add it in there just say like it's available, but you know kind of used with caution or whatever we could add the little disclaimer there um and then, if we do make any breaking changes we just have to.

D

You know obviously very clearly uh state that in the readme or the release notes and possibly like a migration plan, if possible, so I, don't know I think anything else would probably be either too difficult to maintain, or you know, kind of become out of date or something fairly quickly.

J

I think I think um lights, light bumping as a semper. Major version is I. Think that's probably like the most like well understood like we we've had this a few times before um and then we've had customers who just like go from major version, two to Major version four and then like. Why is the code broken and it's like did you? You know that happens occasionally, but Jen I think generally, people are fairly like I, I, think I think people would be more cognizant of a December major version change than like I. Don't know.

J

Maybe a deprecation wouldn't be good, but I, don't think many people would be looking in the source code potentially either I, don't know. I I think you can lean on sember fairly heavily these days. My experience yeah.

C

Especially if you wouldn't- and if you, if you like, would not change the version, maybe to a major to remove something that has been influencer I mean tooling, would break in lend cases, including that would automatically I, don't know, increase the version numbers or dependencies or so.

C

um On the other hand, I think it could happen that we get quite conservative on doing experimental stuff. If we go for the other road, because it would always mean a new major and in the end we end up with, like version 100 dots, whatever um also also hard, I'm, not sure.

A

Yeah agreed with Thomas on the thing he just put in chat the two. This is a bit of a side point, but man I, hate, major major versions and go anything past the one and go. It feels like a nightmare for maintenance.

D

Yeah yeah I definitely agree. Okay, um so I I definitely think we should review the document status if nothing else um and then I think we'll just have to be careful and more appropriate. Do a major version bump I think that, like that, that is the easy way to do it, of course, like that's the whole point of like that, uh those the versioning scheme like that um and yeah, so maybe just it's more case-by-case basis and a lot to just use our uh use. The situation, I guess to decide what version makes sense.

J

Maybe sorry go on go ahead, Ben, okay, we've we've had this one of the things that if we could go back and change is like there's there's been some upgrades we've made to our stks, where it's been difficult for us to hard fail. If people are um like there's, if there's a, if there's a version, mismatch between the SDK and the API and then they just sort of like things silently, you know like rules silently don't work as expected or whatever.

J

So, if there's opportunities to build in like hard failures into the open feature SDK at that point, rather than just like no offering stuff or whatever that's you know, that's that's. Probably a good approach as well. I wish we'd have done that a bit more.

I

Yeah, that's one of the changes that we we made going from tablets without Cycles like there's certain things we just hard fail. We hard throw an exception or something on, and it's made our lives a lot easier because there's so many like there's so many exceptions of of SDK exceptions that you're talking about in our backing code for tablets where you just have like, if you're this version of Android or whatever, to fix this thing like we have this, like this random exception, and it's just like it's a nightmare to maintain.

A

Yeah and and I'm guessing in both those cases that you you, when you guys are talking about, is failing really quickly on Startup, probably not at some arbitrary point of runtime, um which, which I think is like something that that yeah I agree, I think we should kind of encourage that as a policy, we have like a never throw policy with the exception of configuration, so I guess the corollary is throw please during your configuration of something is invalid or doesn't make any sense.

A

I I think I would encourage SDK, Implement and implementation still like Trend that that direction.

A

All right just to just to drive this point home, I I, think um maybe I'll do a review of the of the spec and open an issue like with some some things that we might move to to hardening or even stable, um but like a good example of something that you know just we talked about today that that is probably along the lines of of a potentially breaking change right, as Thomas was talking about this, um the the set provider and whether or not it returns immediately or blocks in Java uh that if we change set provider um to block that would probably constitute like a breaking change.

A

So those are the and I. Don't think that we're talking about doing that, but, like those are the types of things that we need to be really careful about doing, especially before we Mark something hardening or stable, um we want to make sure that, like the horse, you know the the horse is out of the gate once it's stable. So um we got to be careful about that kind of thing.

D

All right, perfect yeah, it sounds like that's a good next step, dad if you don't mind, reviewing our statuses and highlighting the ones that are ready for the next stage. uh Dominic. It's like the next topic, yeah.

B

It's maybe not a topic but a question uh because usually kubernetes is used for for bigger systems. uh So so, basically, if you have something you want to scale, there is a higher chance that you also use the features and kubernetes offered the native nice deployment features with rolling binary, update and I was thinking. Was there any discussion or or something about considering adding something similar for for features for kubernetes?

B

You can use, of course, uh add-on for for kubernetes to use the features, but if at some point it will make sense to to use the features in the kubernetes and have the one common API for that, maybe it should be a part of kubernetes itself. I was just wondering if there was any discussion about that.

D

um No, not really I mean I'm, probably the closest thing is we had like the open feature operator, which does a little bit of that, but it's not like natively built into kubernetes. Nor have we really talked to the team about that. um I mean it's, it's interesting, I, don't I, don't entirely know how it would would work. But um if you have a proposal or something I'm happy to take a look at it.

B

Okay, I will think about that, because we are now working on not only using Google internal solution, but also encourage people to use more open source solution in Google. And of course, kubernetes is a very basic choice of.

D

B

D

B

D

Popular I'm sure it's it's popular at Google as well, uh yeah yeah that would be that'd, be interesting. Yeah if you want to put something together, just kind of what your thoughts are. I I think I understand what you're you're getting at but uh being able to like read through the dock uh would probably allow me to understand it a bit better.

B

Okay: okay, thanks yeah.

D

Thank you uh cool, uh just a reminder: I link it one more time. If anyone else has any agenda items, uh please feel free to add it um does look like I. Have the next couple um just want to let people know uh We've updated the open, Telemetry hooks uh primarily in JavaScript, meant for node, primarily Java and go um one kind of cool part.

D

Is we have two two separate hooks now, one for traces and one for uh metrics, and we also have the ability to uh especially in JavaScript, so you can check out that implementation, but the other ones will probably quickly follow. You can basically register uh a callback that would allow you to take uh flag metadata and add them as dimensions and so that what that would allow you to potentially do is set things like this was the project ID. This was the environment ID.

D

Whatever else that would have to come from, you know the management tool itself, but that would allow you to kind of slice and dice and say like this. Was the you know a particular evaluation for this feature flag in this project in this environment, and things like that, so it it's completely like neutral. You can do it with whatever back end, assuming that data is supplied, but it should allow for some really interesting. You know granularity in use cases.

D

So if you have a second, definitely take a look at it, but it's a pretty cool new powerful feature.

D

uh Next, one is uh some readme improvements, so I've been looking at basically improving our readme templates for all the sdks. um So all the sdks kind of read in a similar way and provide useful examples. um I have a pull request open in the go SDK and I'll link it in the docs when I finish talking.

D

But if, uh if you don't mind, taking a look at it and reviewing it, because if we like that style, I'll just update the core template and we'll try to update all sdks to follow this, the nice part about it is, is I'm trying to highlight kind of like the initial, like user, happy path to get them set up quickly, but then also like highlight each feature.

D

That's available in the particular SDK and it's basically in preparation, because I've also worked on some tooling to suck in those readme's into the documentation and kind of do some basic like massaging on it. So it looks nice in our docks um and so that way we only have to really maintain the sdks, and then it will get pulled into the docks and look nice. So I'll link both of those uh pull requests uh in the the notes in just a second, but definitely some feedback on.

D

That would be great because the follow-up would be once we have kind of this automatic, readme ingest or whatever. We want to call it to build out some kind of like support Matrix then we can show like you know. The SDK is in this uh maturity level and it supports this spec and all of that stuff. We can do that basically uh automatically when we pull in these various SDK read meets so that's kind of part of the plan. I think it would definitely help people kind of discover.

D

You know Java, is this far along, but rust is not far along at all type of thing and possibly even help. uh You know attract some maintainers for the different sdks foreign.

D

And then the react SDK so now that we have uh the client side in a pretty good spot, I think the next uh one of the next really useful sdks would be react.

D

um Of course, there's like a million different Frameworks and stuff. That would be potentially useful, but react seems to have uh kind of been dominating recently, and it's certainly something that would be nice even for, like our playground, app and so I think it makes sense to at least start the discussion of like what we would like that to look like um in the past. We've talked about it basically being like an extension to the JavaScript SDK itself, and it's just had you know, provides Hooks and some nice.

D

You know kind of uh react, focused tooling around it um and I, like so I kind of like to start that conversation, because I could also see similar patterns being applied to other things like. If we wanted to do. You know specific Integrations with some. You know back ends tooling, like I, don't know an sjs or whatever ever um you know, we could start basically just applying like framework specific wrappers around our SDK and so yeah uh Todd I think have you created that issue?

D

Yet if not, we may want to knock that out today and we can add it to the notes and kind of start the conversation of like what we would like this. uh You know what we want the SDK to look like and feel like and make it as friendly as possible to react developers in this case.

A

I, don't I, don't I can't remember if I created it or not, I could I definitely created it in my brain whether or not I created it. Yeah.

D

E

More important but.

D

uh I think we can knock that out uh today and I'll update the notes once it's alive. Yeah.

K

I had the question about um the react Library, um so so the the the.

K

So we're using like postdoc and postdoc started charging for each feature, flag request and at the moment our open Future is really um living around like doing a feature flag check per uh like each time.

K

You want to check if in black is enabled or not and I, wonder so post to cast this as this bit more costly event, decode, where you can basically get all the enabled um Flex for specific context or a user and I was wondering if it's something we want to add to the open future client to so you can just query all active future Flex for our user Voice or like.

K

Is it something so.

D

Kind of like a bulk, evaluate for like the.

K

D

Developer so we we had talked about it at one point um I mean technically it's possible, but there was some like. It was kind of discouraged for a couple of reasons. um We could pull it back up as a discussion point but like even in the SDK I.

A

Actually, don't think hearing what what was said I, don't think that that uh a bulk evaluation is actually what is being called for if I correct, if I'm wrong, but it I think that I think that our our web SDK might actually solve this problem for you um at least partially, because we do have the the knowledge of when the context has changed. So you could, for instance, bulk evaluate in your provider, but not expose that to and then cache everything, but not expose that to the actual um SDK right.

A

So if your provider is just when a context attribute is changed or when a user first logs in or whatever does a bulk evaluation, you can just store all those flags and then evaluate them and return them whenever you want um I, don't I. Don't really think that a bulk evaluation per se Mike is is particularly relevant if your goal is just to reduce traffic to the back end. That you're talking about I, think the knowledge of when the context is changeable, basically facilitate that, for you.

K

D

Okay, so I do think I think I do think that was potentially covered, but definitely let us know if something's missing, um but just to kind of close up the the bulk evaluation. There's a couple reasons why that was discouraged and it was partially around it can be kind of expensive for the ones that have to do like individual calls, which yeah isn't some isn't the primary well.

D

It is a huge concern in the ones that that's an expensive operation, but the other one was like uh it makes analytics borderline useless then, because you basically like have no idea if a flag was actually used or not um because it would be well they're all gathered and we're not tracking, like actual usage at that point, so um yeah there's a couple reasons why we were discouraging the bulk evaluation point, but there is I think an issue still open for it. So if it's something that you'd like to oh.

K

Find a ticket and see here if it's worth continue on that one or not great yeah,.

A

I can send you some Doc, but based on what you said, I think that our kind of initialization plus um context change stuff, and maybe even some events like it was mentioned earlier in the meeting- could could help you. But I think that you could basically do that bulk evaluation per user and then save yourself. The API calls um yeah yeah.

K

But I'll send you that talk great. Thank you very much. Yeah all right yeah, the react Library would be nice to have I can try if you can get something to work um the coming week.

D

Well, yeah I think if we get that issue out there it'd be really nice to kind of get everyone's thoughts on how it could and should behave, um hopefully from a code perspective, it's not too too bad, because a lot of it would be offloaded on the SDK I. Think.

C

Now would be interesting for me to read we kind of wrote something for our Customer because yeah they they wanted to use open feature um mainly because I I said it would maybe be quite a good idea and I used react and we built something, and we learned stuff that we wouldn't do nothing to would be interesting. Maybe.

D

Yeah yeah that would be really interesting feedback, then so um yeah once we have that issue out there. Maybe if you could do your brain dump a.

F

Lesson learned that would be perfect.

D

Awesome um just an FYI I did update the uh the notes and I have the pull requests to the go, pull request and my auto gen doc pull request which that one's still a draft waiting on the go one, but any feedback would be really appreciated, hoping to have that merged, possibly today at least the go one. So if you have a chance, please take a look at it and then Lucas. It looks like your your last potentially unless someone else adds something.

C

Yeah, so that was one thing that came to my mind. We had a discussion and we had I'm, not sure and I, don't find it right now, something that we already discussed somewhere and that we had a longer discussion on and someone else came and asked something and regarding that and the answer could have been- we have decided there for those reasons that we do something like this, but we don't have that, and I just mentioned that, for example, for some stuff I could imagine having something like decision records.

C

It could be, for example, for why do we use NX for the mono repository? Why do we have a money repository at all for providers?

C

um I, don't know why do we use Behavior driven tests, whatever um something like this? That is pretty hard to change and that you can like discuss much on um and you can just like mention? Okay, we decided because of this- and people can just look at something like this and say: okay, I buy that or I see differently, um yeah of, for example, like this um and I'm, actually not too sure, because I think it's.

C

It could become something like we start with it and it's hard to like continue on it, and so that's actually what I sometimes feel about the um the off apps, because your thought Todd said: yeah. Okay, we have the ofaps, and yes, some of that stuff that I'm asking for is actually in there, but the semantics like of offep and what it means is kind of different.

C

um A bit and I was just wondering and I. Had this I had the structure of something like an architecture decision record, maybe like the Mike and I got stuff in mind, um but I'm not sure how to open operationalize this and here in such a context, was just something that I want to mention, because I have the feeling it could help, but I'm, not too sure how we could how we could apply it, that it also works and not just be starting. Let's say afterwards: yeah.

D

Yeah or yeah and I definitely want to kind of avoid adding too much to the process, if possible, but I like the idea, um maybe yeah, maybe we can try to work asynchronously on that, a little.

E

D

Figure out what to do um or where it could live, what the process looks like.

E

D

Know because, even like the NX one that you brought up like I, don't know all right, I was just like. That's the like, you know, what's an acceptable, you know reason for it like who who can approve it. I think there's there's a couple questions we would have.

D

Maybe, ironically, we could create an o-fep for the process to avoid of apps for decision making or something, um but uh we do I think need a spot to kind of talk through what we'd like to do for maybe these ones that shouldn't require this more like formalized process that maybe the ofap covers. So one.

A

Thing that could we could maybe use that would be lightweight, is GitHub discussions. uh I mean we could consider that um at least then we'd have like a like a document or something we could point back to, because I I think when I hear Lucas's what he's describing the paint, what he's describing it's 100 just like we already talked about this and everybody kind of agreed and then somebody else came along and they weren't in the discussion and- and it's just like just pointing them to that discussion- that's long-lived and more formal, maybe.

I

Maybe discussions.

A

Is good enough, um uh especially if we like structure them with kind.

C

Of inspiration or.

A

Something error, format, yeah.

C

And maybe maybe that could be something, um and maybe we could, but the thing is maybe it would be cool to have something where you can just look at and don't have to read a whole discussion also because what I would like to see is like what was decided. Okay, just because I have to know where to look and then the why, and maybe the Y is just we thought.

C

Nx is the best tool right now for mono repositories and if I buy, that I can I can just accept that we use the next, for example, and if I say okay but I, don't think so and I think we could be way better. It's just like you can be better in deciding and if something should be discussed again or so that's why why I like it yeah? That's like yeah, yeah,.

D

I think it I don't have answers to all the questions.

E

I

D

Think it's worth talking about like it would be nice to just have a spot to like kind of hammer these things out quickly and try to get General consensus and if, if it's a yeah, if it ends up not working out in the long run, we can reevaluate it and work through it. Maybe discussions make sense, but I don't know. If you can do that org wide or if it has to be on a repo, um if it can be or quiet, it might be a good solution, but I.

A

I was just trying to figure that out right now, but it doesn't look like it's possible, but I'm I could be missing. Something.

D

Wow yeah: let's: uh where can we take that.

L

I did pop this in the chat, but something that I've seen before is just having some kind of decision record repository. The decision records are all saved right um as part of markdown docs inside of that repository, and the discussions just inherently happen on issues or pull requests.

L

um So you also have that history of discussion as well.

A

There is org level discussions as well, um you have to choose a hosting repository, but basically it Maps or like one repository, it could be like the board.

E

A

Repositories, it's also an option if we didn't but yeah the toms Tom suggestion also could work um something to think about.

D

Yeah I mean discussions could be like I'd have to look at it, because it would be nice if we could say like we have our normal conversations in a issue or something if we could like convert to whatever discussion or something and then label it or like it's just, maybe an easier workflow to capture some of this um I can take a look at it a little bit too and see if maybe we can enable it, for you know, experimenting see if it works and always remove it if it doesn't um I.

A

Yeah I haven't used.

D

Discussions much so I, don't know if it's a good approach or not.

A

I just linked the the work level settings I think only admins will be able to see it but yeah. It's basically like you can do Word level discussions. You just have to choose an owning repo, but so that's another option. It looks like we have a few options: I'm I'm open to any of them.

G

A

G

Can also help for adopting people also responsible, protect.

E

G

Have questions and we can use discussion and discussions.

D

Now be nice to enable hey, yes,.

G

For now you have to go to slack and register on in CNC, F1 and so on. So maybe it blocks people to ask questions.

D

Too, if I remember right so I think it may be worth turning it on and seeing how it goes.

F

Yeah I think it's I. Think Thomas's point is right um that anyone who's not on slack, who doesn't want to join slack or who can't join slack. um It's another Avenue for people to communicate with us, which is I'm all for.

D

Yeah and if it's Uruguay I think it makes it quite clear: I mean that is one of the challenges.

E

D

Have like 40, repos and like where do you go? What questions do.

E

You have like all that right.

D

So, um okay, maybe we tried both then I can enable discussions across the org and we can try to see if we can use that for possibly decision making as well as obviously like general questions and troubleshooting.

D

It will be pretty Bare Bones at first, though obviously, so, if anyone has any like initial questions to kind of seat it, uh you know, please do even if you want to answer your own question.

D

A

All right, I think we're at the end, um unless somebody else wants to say something, but I wanted to Circle back really quickly to something that was happening in the chat back to uh Dominic's Point.

A

um If I understood you correctly, Dominic I think you were maybe proposing like making the potentially the apis crds, we defined an open feature operator like more like more General, and even maybe seeing if kubernetes is a wider body would be interested.

E

A

Them I think that's a really interesting idea. I think that, um like even for vendors, for instance, it would be interesting to be able to say this is a standard feature flag definition, and if everybody could at least agree on the definition they could build their own operators or whatever that would Echo these definitions into their back ends. There's a lot of like agreement to be and discussion and like stuff to talk about there I think, um but I'm I think it could be a very interesting discussion to have and and I don't know.

A

If there's a community, that's better positioned to do it than this one, uh but it yeah it's a it's a big topic. So if, if I understood, you correctly I think it's something that I would be interested in talking more about.

B

Okay, I'm also open for discussion.

G

E

G

Different defining a standard for flight seems hard, I think it's uh topic that comes super often, and nobody want to take it for now, but I think like. We will have to at some point just to at least contact vendors and see uh what they think. If it's a good idea to be the standard schema for Flags or not because.

I

H

G

No ones want to go there for now, but uh yeah I.

F

D

Know yeah we may have to do it because I think, like even vendors, could like transform their definition into this like centralized one too, like I I, get it and like I, don't think anyone's gonna be like asking for it necessarily, but we may like from a vendor perspective. I think users certainly would potentially, but the the unified flag definition is something I think we're gonna have to think about quite quite a lot, um and almost certainly something that we'll have to do eventually is just how do we?

D

We do it and yeah it's gonna, be tricky to navigate but doesn't mean we shouldn't do it. In fact, we almost maybe should because it's it yeah it's what standardization means. Basically all right, um yeah is there anything else. It looks like we made it through the agenda for the day open all right, perfect. Well, thanks. Everyone uh have a nice day thanks.

J

Guys, thanks bye.

D

Thanks pretty much later see ya.