Open Feature Project, 25 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, May 25th, 2023

Description

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

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

A

B

Everyone, how are we doing good and yeah yeah too bad.

C

Oh knackered today.

B

Though I don't know why.

D

E

I'm just going to keep muting because my housemates in another meeting at the same time.

A

E

Hey guys, hello, how are you.

D

F

B

Wonderful, how you doing good! Thank you! I'm fine.

D

C

D

C

C

All right, let me pull up the notes quickly.

C

Anyone have a strong desire to be a scribe today,.

B

E

Past for me, okay,.

C

B

C

Missed it, I was just asking if anyone wanted to be a scribe today, and uh so far people aren't jumping at the opportunity.

E

I heard this last person to join the coolest subscribe, so I told Dusty that.

C

Makes sense? Oh no.

C

David, would you mind being inscribed.

C

I always get sidetracked, so it's better to let someone else uh handle it. So all right, um I'll link out the Rock. If you don't mind just adding yourself to the participants list and if you have any agenda items feel free to to go ahead and add yourself um and we can go ahead and get started.

B

C

Cool uh I'll start off with the uh I didn't add my name here, but I guess: I'll I'll handle it. We did release the version zero, six zero of the spec um last week, and so uh there's also a blog post that I had put together. It's not released yet, um but I did get some feedback yesterday uh reviewing that and if all looks good, we can go ahead and release it uh thanks Thomas um yeah.

C

So if you have any questions, definitely take a look at it, but I I tried to cover a quick, quick summary of what each like major feature in the new spec um is and then kind of a couple of use cases around it and then also tease, basically that the next part of the spec is going to be client-side support. um It's something! That's uh this release sets us up, hopefully nicely for, and Todd's uh already has like a either a draft PR or a PR ready to rock already so um yeah.

C

Take a look at the the blog, take a look at the release and then uh yeah definitely um help putt if you're interested in the client side spec, because I think that's definitely going to be a Hot Topic um Todd. Do you have anything to add there I see that you added some.

F

Stuff, uh just really minor, the only thing that I'll, add I'll, add a link to it. um uh This. This is a query. uh The thing I I just put in um under that point. This is a query that basically searches the whole org for issues or PRS with the 0.6 v060 label.

F

um So if there's a PR or an issue related to implementing uh implementing zero six zero, it will show up there if you open an issue- um and it is related to anything implementing this just go ahead and add the label I'm trying to do that myself, but it'll just give us an overview of that kind of stuff and obviously you can filter by repo it and that type of thing too.

C

Yeah cool any any questions or anything to add on that section before I move on cool all right um next one. This is something Uh Kevin do. Is uh it had a conflict today, so he wasn't able to join and talk about it himself, but we did uh create this metrics of uh earlier in the week and, basically to quickly summarize it we were just trying to figure out uh for a open, Telemetry, metrics plugin for open feature which type of metrics.

C

Would we like to capture what we would like to call them, and uh if, uh in what dimensions, would we like to be able to split these metrics on? So that was the intention behind that one um I think we're pretty close. I just want to kind of do like a last call. If there's anyone that wants to take a look and provide feedback, you know please do because otherwise we'll probably merge tomorrow.

C

The only part: that's maybe uh that I'd like a little bit more input on well anything. You can, of course, provide input on, but the one that I'm a little uncertain on is. Is this scope Dimension that I've defined here and basically there there's one uh piece that makes splitting these metrics may be a little bit tricky um and for those unfamiliar, the dimension is a way to basically like divide a metric.

C

So if you're looking at like Impressions over time or something like that, you can use Dimensions as like a like a you, can either split or filter on these dimensions, and so some obvious Dimensions would be like a flag key. So you could filter on that, for example. So if you wanted to see, like you know, uh Impressions over time, filtered by a key you'd use the the um the key dimension, um but then how would we split or filter on a particular like environment, for example?

C

So if you think of like a lot of uh a lot of feature, flagging use cases like you have a core feature flag and then it's the the the definitions are basically changed per environment, and so we would need some understanding of maybe like the project and environment that a flag was in, for example, um and though that terminology varies across tools and vendors. So the proposal I have out there right now is scope.

C

So if we basically let the provider optionally Supply as flag metadata the scope of this flag, which would be kind of up to the provider to Define, but it could be like uh it could be an ID- it could be like a you know like a namespaced project and environment.

C

However, like the provider would want to do it if it comes across in a flag key, which is part of the updated spec by the way, the open, Telemetry hooks can basically use that and add that as a dimension, if it's omitted, it would not be edited as Dimension. So it's a totally optional uh piece, but uh we do need something like that. I just don't know what we want to call it, and so scope seems to be the most like general purpose term that I could think of.

C

uh But if people have you know, ideas uh you know, naming is always difficult, so uh feel free to like comment on that. We can talk about what that should be called.

C

Oh, uh that's it kind of, in a nutshell, uh any questions on on the metrics or Dimensions, or anything like that.

F

I'm, not an open, Telemetry expert by any means, but my understanding of the of the the problem you're describing too is kind of like another way. To put, it would be just a way to name space Flags, like environment is kind of one way that you might want to name space them, but you may, for instance, in one kind of in the context of one um Telemetry back end. You may have uh multiple clashing flag Keys, just in different projects like it may be that one project has one.

F

Our application has a flag key that clashes with another flag key in a different project and they're they're logically separate things, so you could use the scope to kind of segregate those as well, um even if you're not doing it for environment. So it's just like a general name spacing I would say also is that is that.

C

Right, yeah I some something along those lines and I think the terminology there's a bit tricky, but um maybe it just really comes down to like whatever our definition of this Dimension is. uh That should be maybe clear enough. So one of the things that we talked about in the eofap was to Define what a scope means in our glossary and maybe that's sufficient here, all right um so related to the ofep.

C

We um our project or our open feature itself was actually accepted, uh as I guess mentors in the Google summer of code, um so it'll be myself and David, acting as mentors for uh Mahir, um so you'll probably see him around on slack. His project is basically to streamline the ofep process, and so right now we're working on like kind of defining an ideal flow, um and so, if you have any ideas, feedback pain points whatever.

C

Certainly let me know because my my main goal is like: if we can do a nice job like kind of streamlining this enhancement process, we could, uh you know basically, hopefully donate it to other cncf projects and other projects that, like you know, have similar processes in place. So um we started outlining, you know, I think what what an ideal flow would look like uh and then uh then here we'll be implementing that writing documentation and then creating some like automations around that as well.

C

um One that I think particularly could be interesting is essentially like once we achieve uh all of the approvals that we need um having a bot that basically does like a last call, so it would say, like you know, we've achieved this. This will be merged at this date. Unless someone, you know, speaks up essentially uh and then basically it uh it kind of takes like the emotion out of the emerging release. It's just like we've we've gotten the approvals. uh You have your chance to to stop it.

C

uh If you don't, for whatever reason it's just gonna merge, we can of course make it amendments later, but it just makes that process. You know pretty pretty straightforward and I think we could also apply that logic in other places in the project yeah.

A

I think we should also look especially for the offer process. We discussed this also in a governance board before whether everything that right now is in Old, Fab should really be an overb or it should just be an issue uh because some of them are actually issues.

D

C

A

Like the scope for extended, uh then it shouldn't even be an open, uh because obviously the old Fabs then go to the TC. They go to the governance board and not just to the maintainers, uh which usually makes the move, obviously slower, uh but obviously that's not necessarily. Expertise is uh with them as well, like first back changes, I think it's. It still is in the same scope of the spec uh that we had defined and it's just more implementation related. It shouldn't even make it to an offense necessarily.

C

Yeah I I think, and we can hopefully leverage some ideas and things from like open Telemetry, for example. For that you know, features shouldn't necessarily require an o-fep unless it requires, you know, touches multiple repositories or you know, changes SDK Behavior across multiple SDK things like that. So um that is part of the. The things that my hair is going to look at is basically what what we should uh require a nofap and what wouldn't so clarify.

A

I'll just bring it up because I think there is some urgency there, because right now the offer process. The way the repository is structured for approval.

A

uh It would allow you to merge, even if not all GC members uh have agreed to merge uh and as soon as we as we switch this over, we will have a much shorter time to approve of apps like looking at the one we just discussed uh about the metrics before none of the GC members currently has approved. We have taught from the TC, so I think we should Define this. Rather sooner than later,.

C

Yeah I mean I I'm, not sure if a GC member even need to be approving uh nofa but I guess that's something that we could certainly talk about. Adding.

A

A

An issue for an issue, definitely not I, think that's why we need to have to clear distinction and I think we should have this rather sooner than later, that's right! That's why I'm bringing it up here! I.

C

Mean that's as simple as like a code owner style, so I guess! If, if that's what we want to do.

A

Oh I know: I can't enforce it, but I won't have the rules in place. That's my point like what what has to be go into the offer? What is fine being an issue.

C

It was to streamline it too, so I don't want to have too many processes in place, otherwise it like discourages.

B

C

You know people from using it, but yeah I point taken I think yeah figuring out what what it like once we it's in place, and we have approvals like what constitutes like an accepted uh thing and all it needs to do is be well defined and understood and I think it's yeah, pretty straightforward, okay, um yeah, so I guess uh to quickly summarize that we're working on the process.

C

If you have any ideas or complaints, you know there's a couple issues open right now in the um both up repo- uh and you might see, may hear around both on GitHub and then in slack as well. So um he's a student uh and yeah so definitely help him out. If he has any questions and uh yeah I think it's gonna work out. Well, um that's it! For that section. Any questions about uh Google, similar code or that ofap process.

C

B

C

uh Just a reminder: um here's the notes: if anyone wants to add any agenda items otherwise uh I'm gonna hand it over to Todd.

F

Yeah I'll be pretty quick. um We we still have. We have basically one remaining um PR open to the spec um 171 I've linked it there. It's been open for quite a while, um but it was in a draft state for a long time um and the reason was it basically contained everything we, we kind of believed would be necessary for for client um support, adequate client support and open feature, so it included events and initialization is shutdown which are now part of the spec proper.

F

um So really not the only remaining Delta. Is this static, Dynamic context stuff, which is basically the only thing left in the pr. So um this is this static, Dynamic versus Dynamic context, stuff um Pete did a great blog post on it I've kind of mentioned it in these meetings. More than once, if you want background, I definitely would recommend uh checking that out, um for, like some philosophical background, I'll, add it to the document here, um but yeah take a look at the spec change.

F

The interesting thing about the spec change is that there's a lot of conditions and it essentially won't impact any um server-side SD case, so it won't impact yeah any of the the current sdks that um are really intended for server-side usage um it it's basically how the web SDK is currently implemented, the experimental web SDK, and it would be how you know mobile sdks, would be implemented. So take a look at that.

F

If, if you're not super familiar with client use cases, be them mobile or web, um maybe refer um the pr to somebody who might be interested I'd love to get more input, especially from mobile application developers um on that stuff, um yeah I think that's all I have to say there um any questions. Comments on that.

E

E

B

E

Static like we have some customers so sometimes like instantiate, multiple, crazy sdks on the client or occasionally like change the I, don't know if the splitting here so when I read it through I can't and I didn't comment about this in GitHub, because I wasn't sure if it was just like.

E

Like in flagsmith, they're not immutable, well, they can be overwritten right.

F

Yeah, it's a it's a kind of a relative term, honestly static, I, agree, static, isn't perfect um and and if I think, if we don't like that terminology, I'm totally open to changing it, it's already changed from like a single user to from multi or sorry multi-context to single context, because that wasn't quite accurate either it's it's that it's more static and that changing the context is, is expensive and frequently involves some kind of network traffic.

F

um So yeah the context isn't, isn't really static um it entirely. It's just that it very likely won't change across evaluations right um in in the server side. We have a very Dynamic context in that basically request to request event to event. The context is completely different. It usually represents a totally different HTTP request, a totally different user for the client side. The context is much more static right.

F

It's it's a user who, logs in it's, maybe changed when some attribute about that user changes if they, if they add something to their car if they change their username, that type of thing. um So it's more static but yeah. It's not static, I'm, totally open to changing changing that terminology and make that clear. If anybody has.

C

Anything yeah I think it is worth looking at it's just hard because it's like dynamic or less dynamic or something like. So if.

E

We can come up with, we can just have more static and more Dynamic I know it's really tough I mean just Jonathan I kind of yeah like severally. It's kind of this classic thing right. It's like do you want to be like you, they use software engineering or are you computer science like that's the kind of where these are lying, I kind of like static and dynamic, but I just we want to. We definitely want to make it clear that, like these are like.

D

E

Static right, like it's, not static in the way that the length someone writing the language are like a a piece of code would.

D

Think of it right.

F

B

E

Think, as long as it's clear and that yeah.

B

E

Sucks because, like we have people, do sort of like weird stuff, they instantiate three instances of the client-side SDK to do weird things just because they have to for whatever reason and people could be like. Oh I can't do that, because it's static.

E

C

Think that was.

D

C

The point, though, to be honest, like to make it work across as many tools as possible like we wanted, not discourage people from setting context, but we want to like make it clear that it's a relatively expensive operation um but static I think we can think of a better name, uh and maybe it's even worth I forget why we pivoted away from client server. I know we started there, um but maybe we just circle all the way back to that term. Who knows? uh Do you remember why Todd foreign.

F

I think because we we projected that the client might be used in cases where um it's not actually a client application, because it's not part of a client server architecture. So you know, if you have a, if you have some like desktop application, um it may it may have feature flags and not necessarily be a client of anything, but that's like a fairly Niche case, I I I'm, not necessarily against the client server. That's that's practically how it's probably going to work out in a lot of situations.

E

I think static and dynamic, infers more information than client and server, which is using.

D

Knowledge right.

B

Yeah, the only other one I had there was, like maybe user context and I. Don't know, I, don't really like Global context, but um maybe because, like one's kind of user, specific right, like the context, is kind of specific to that user and then the other one's more dynamic, because the user can change per per request.

F

If we could do single versus multi-user, um two is as well, though yeah, but.

C

We wanted to shy away from the user too, so that was the other challenge.

E

Yeah I mean from yeah there's a non yeah like there's. Definitely a set of people that aren't identifying as a human being at all in context. Yeah.

D

What, if you have something like I mean the current implementation is like setting it on the client. It could be something like a client context or so so that it implies that it's like the context bound to that client, which doesn't imply not changeable but also doesn't apply any semantics for what it's used for.

F

Yeah, that's that feels like more like the user context versus or well client context versus global context that Jonathan proposed, but I mean yeah, I, I, don't I, don't think I think this is mostly a language thing it doesn't. It won't really won't really change much about the implementation, but it is important that we communicate clearly what what this means right so I'm happy to take this discussion offline and create an issue and like maybe we can have a whole bunch of proposals and, like add points to them and vote on them.

C

um Yeah I think that's a good approach. It's yeah, it's not a technical thing. It's just a communication issue, so um yeah I think we can kind of summarize what we talked about here and if you don't mind, capturing that an issue and then putting in slack or something, let's see what we can do.

C

Well, yeah any other thoughts on that one, otherwise I think we can probably move on to your next topic. Todd.

F

Yeah, the other one was was, is really short and sweet, so um we rotate we basically kind of rotated the technical committee. That's not based on any policy. um It was just like. We went kind of from a bootstrapping technical committee uh that kind of helped us get started to a new TC um and uh yeah. The the nominees were um Thomas uh who's in the call, uh as well as Ryan uh lamb, who is not with us today.

F

He's West, Coast I, believe so it's hard for him to make these calls, but uh yeah they're, both um helping out on the TC along with myself, so you'll, see them in PRS, you'll, see them uh reviewing the spec and stuff like that, and on calls and stuff like this, keep in mind, you can self-nominate for the TC. If you're interested in joining, uh we do have some restrictions on composition and what companies people are from that sort of thing.

F

But if you're interested in the responsibilities you can see, the community um contributor ladder I think has that as well as the uh technical committee Charter. So yeah thanks thanks to Ryan and Thomas.

F

That's really all I had.

C

Yeah awesome, cool um and just to kind of clarify, Todd's statement on that too. uh There's no, like you know, companies that are excluded or something it's just to make sure that there's proper, uh uh you know representation and stuff. So if it's of interest and you're able to kind of fulfill the requirements, certainly you know, let us know like definitely I, think having a more like filled out. Tc could benefit the project in general, so yeah. Definitely, if you're interested, uh let us know um we can take a look.

C

uh It looks like probably David out of this. We used to have this at the beginning, all the time I don't actually know. If there's anyone, that's like brand brand new uh for the first time, but if there is or if you haven't, had a chance to introduce yourself, if you want to unmute and say hi uh feel free and.

G

I can go Mike, I, Am brand brand, new, um hey I've, just been kind of like fly on the wall, so nothing really to contribute here. But um a Max was uh turned on to the open feature project a couple of months ago, because we've been uh migrating, our monolith, I work for a company called justworks, so trying to decide how we um handle a single provider, but then keep the evaluation unified, which is open feature. And so it's it's been good to to find that out.

G

um We are a rail shop, primarily branching into golang wrestling, um some other things, and so our biggest challenge was uh having a functional, Ruby SDK to at least get the features of the spec that we need today, which is basically the provider evaluation and then the context.

G

um So we took it upon ourselves to write the a a ruby one, just because the official one didn't have the context stuff that we needed yet and the provider interface, but we use something called sorbet, which is a rabbit hole and the Ruby community, and so ours is sorbet aware, which makes it not a great candidate to be upstreamed as the official Ruby implementation, because you probably don't want to introduce that dependency. But uh anyway it was.

G

It was fun getting to implement office off of a specification and um we're about uh almost done with hooks, which was we started this before 0.6 was released last week um and then once we're finished with hooks, we'll we'll pull in some of the new features like the initialize startup uh permanent, that kind of stuff. So uh yeah that's been fun and it's been fun to attend this. Just to see um how the the back end of the spec works.

C

Awesome yeah welcome, Hey I knew your name was familiar, so I apologize for.

G

Not remembering.

C

That you weren't in a meeting or not but.

G

Nice to meet you yeah.

C

Certainly, let us know if you have any issues with the spec or you know Clarity, and maybe we do figure out a way. I mean I'm I'm, assuming if you guys are using, you know sorbet and Ruby you're, probably not alone. So maybe there are opportunities to link there or whatever so uh yeah. That.

G

Sounds really good, there's. Definitely like some interplay. We could do um we're also interested once we do the sorbet one uh and upstreaming some of the stuff we can into the primary one as well so um yeah that just kind of looks like ripping out the sorbet specific stuff and then embracing more of the duct type in Paradigm in Ruby. um So it's actually easier to to kind of work backwards from like the the more strict type system approach.

G

C

Cool yeah and those ones like that one in particular, is like sub 1.0, which is why it hasn't really been released or it's not in the docs or anything like that. So yeah, if you, you have some stuff that we can go Upstream. That would be awesome to make that a 1.0 release.

E

Max I have a super quick question: um I, don't really know much about sorbet like I'm, just curious to know like how is it being adopted widely in the Ruby community and is it is it to Ruby what typescript is to JavaScript roughly? Is that right.

G

uh Yeah, that's a great question um so from the adoption side of things you're seeing a lot of it. uh The projects uh originated in stripe and still maintained by them. So I mean they're, like kind of a big gorilla in the Ruby ecosystem, uh notably they don't actually use rails, which is kind of the the other side of the coin. When most people talk about Ruby but Shopify who's, the other big gorilla that uses rails uh also stewards that project in some capacity too.

G

So you see a lot of Enterprises really embracing it just because once you get to um like Ruby Paradigm start to break down around 50 engineers and so having the type system starts to help out tremendously there um in terms of like how it relates to typescript, it's it's very close, and it's like a similar idea of. Let's add, like static guarantees to uh a dynamic language.

G

um Implementations are slightly different, so like typescript transpiles into JavaScript at the end of the day, uh whereas sorbet kind of has like two modes you can operate under, one is purely static where you're not bringing anything about like sorbet into Ruby, which works well with non-sorbet projects and then there's another approach where you can actually use something called sorbet runtime. Where you get Ruby constants, you can actually utilize, so things like enum so like Ruby, doesn't have a built-in enum.

G

So the sorbet team built, like a t enumclass that you can inherit from and actually get like an exhaustive enumeration, which is super hand. Super handy, uh there's like a there's, a struct in there, which we use extensively in our open feature spec, which gives you like immutable Fields.

G

um That kind of idea a lot easier out of the box. um Immutable Fields with type information, I should say, um and so that's kind of the the difference is. If you opt for that runtime thing, you're, basically forcing anyone who pulls in your library to also pull in the sorbet runtime Library, uh and you know, depending on the team, they might not want to do that, and that introduces um a somewhat controversial thing in in like a type system right.

G

So if people don't want the type system they're going to be like I, don't want to pull this in um and that's why it's a little bit trickier than typescript, where you can tree shape that stuff out and still get a lot of the um from like development time. A lot of the affordances.

G

um But you know, sorbet puts it into the uh like dependency chain which becomes problematic. So um that's what I say when I mean there's, probably like a official SDK that if you just wanted a vanilla, Ruby implementation, uh there's a there's a way forward with that. uh That is less strict from a type standpoint, but still satisfies the specification and then there's like the more rigorous sorbet one, where you'll actually get um way better type guarantees right. So.

C

Yeah, which I think like yeah I, mean I, think open feature solves the problem for like larger Orcs, like if you're on a really small project, like there's still value, of course, but like um yeah, so I think yeah having something like sorbet could be really interesting to to officially include somewhere, but I. Think figuring out where that lives and how that is included in the project is, is maybe a deeper discussion for another time. But yeah really interesting. I know very little.

D

About Ricky.

C

To be honest, ah awesome, uh yeah anything else or basically out of agenda items um and unless someone else wants to I think we've met everyone. Oh the last thing, I want to mention real quick is the zero six zero spec is pretty far along in implementation in the JavaScript SDK.

C

um So thanks Lucas for uh a lot of your effort over the last week, um I think almost everything is included in the latest. Pull request. uh Pull request. Excuse me so once that's merged and approved I think that will be likely the first SDK with full zero six zero support.

C

um So, if you're looking for like kind of implementation like a reference implementation, um you know take a look at that SDK for some ideas.

C

That is basically it anything else no thumbs up from Todd away from Jam. Sorry, I, guess, that's it! We can wrap up thanks. Everyone thank.

B

D

E

I'll talk to you later.