Continuous Delivery Foundation Events Special Interest Group, 3 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CDEvents / SIG Events Vocabulary Meeting - May 3, 2022

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

A

Good evening.

B

B

So I saw in the chat that derek is late if he even shows up- and I also heard I saw a shot from andrea- that he will also be late so because he needs to carry his children for some some activity, but he he will probably show up in five ten minutes. But let's see, if that's joints before we start.

B

A

B

C

B

It's good, so eric is a bit late.

B

We don't know if he will join at all, but here is oh here's. How are you you got out to the meeting.

D

Yeah, the other parties said: oh actually, we're running over time. So let's wrap up.

B

D

Went up really nicely.

B

You didn't need to crash the meeting.

D

B

Yeah, good, um okay, I guess we can get started. We have quite a few already get out. I can shine on my screen. Maybe.

A

um Just as a bit of an information to the rest of you, um I'm switching position or have switch position internally or ericsson. um So in the future I might not be as active or I probably will not be as active as I've been before. I won't disappear completely, but uh you will most likely see less of me.

A

B

That's that's unfortunate. Yeah.

A

So you wear it at least.

D

Is the new position still connected to ci in any way, or is it completely different.

A

Yeah, it's connected to ci uh so uh and I will still be uh I'll, be part of the the afl work, uh but they wanted to to put some additional effort inside ericsson.

B

I know where you live, matthias. I will come and haunt oh yeah.

A

I'll probably be uh putting some comments in there if he, if he even thinks I should do that, so I'm not completely out but uh less time.

D

That's great that's great.

C

B

Unfortunate for us.

B

A

B

Yeah, I provided valuable input to the project so far.

B

B

Yeah, should we go into the two different topics that has been added to the agenda? I added one of them. I guess you andrea added the other one or what was it? Maybe.

C

I I added it uh so. The first one is the discussion about the request that um I don't mind which order we go.

B

Yeah, I was hoping to see mauricio here, but for that discussion, but we could of course discuss it without him anyway.

B

Otherwise we can look into the other one here. We can switch order out of them and start with the the other issue, the one that you wrote, andrea, called the pull, requester sure.

C

B

And we might see mauricio rage in the meeting we'll see, so I can bring up that one.

B

And I think it's very good that we start detailing new or new parts and structuring the events, uh the syntax, it's very good that we we progress there. I think so. I very much look forward to this being merged. Eventually, when.

B

uh I had some comments on it, though. um I'm not sure how much you've seen those comments, andrea and if you might even have reply to them,.

C

um No, I've not looked at this pr thing, since I was back from um my holy days. Sorry about that.

B

um Yeah so let's see where I had had some comments. Where was that, of course it's not visible in this view,.

B

And it's easy to see: it happens that.

B

Or maybe andrea, do you have a special special agenda you'd like to raise for this specific pull request, or should we just discuss anything?

B

What do you feel is more more urgent.

C

um Well, I mean I agree with you. I think it's uh important to get the the schema um in and that hopefully unlocks the work of the um of the sdks uh but um yeah. So I definitely happy to to discuss um what is the best uh structure we wanted to have. I had some ideas in mind that I put into this vr, but I mean not necessarily the best or um I was trying to uh physically yeah.

C

I think we discussed a bit about this reuse, the the schema a bit for for the objects where applicable, but there I think, last time we discussed that we could do also this the other way around um compared to the way it is defined. Now.

B

Yeah, so one thing that that I really want us to discuss is the proposed structure. Here. um I think one comment was that we could also show a complete uh event with the the data field added because in the cloud events context there is the data field after this or whatever, but in the in the object where our payload will actually be stored.

B

So if our payload is in json format, which is actually what stated in this example, then I believe we could have a show, a complete event so to say from cloud events perspective, including the payload part. So it's even more clear how the complete json structure will look.

B

That makes it also possible to relate the the cloud events fields with the seed events, fields, which are to some extent overlapping, and of course they are, they might need to be in both places duplicated, since we will parse the city events part- and I guess our event. Schemas will only consider the city events parts and not the actual cloud events, parts those are already predefined, what they would look like, so the schemes we will provide are for this part of the event. Only of course,.

B

So so the data property and also the schema, is it called the data scheme. Now what is it called? Maybe I think I commented on that as well.

C

I think the schema is the link to the schema. Then data is the actual data um yeah.

B

So those two could probably be added to this example cloudants context here, because we cannot live without them, at least not without the data payload.

B

I don't remember now: if data schema is, maybe is mandatory or is it optional from cloud events perspective, I don't remember it's it's.

C

B

It's optional, okay, but I think we have said that we actually want schemas and by that I think we should state that from our perspective it should be mandatory to have it in the cloudance parts.

B

If we could or could we split such requirements, maybe we couldn't, we could maybe only require what is in the city. That's paid out.

C

um Yeah, I guess, having the schema in there. That's I. In fact I had a question about that, so the having the the link to the schema there. I think it's uh it's handy, especially a development time.

C

uh If you want to to build a client that receives that event, um I suppose once the the client is defined, having the link to the to the schema and there is not strictly necessary as long as you have the version defined because the the scheme, and as long as in the spec, we associate the version with a specific schema version, of course, because the.

C

But yeah so I'm not sure, I'm not sure if a client will use the the schema at one time to parse the message, that's um which, which I think it's a reason why it's optional. In.

C

Cloud events but yeah.

B

Of course, yeah.

C

But regardless I mean I agree, we should always have the content written according to the schema.

B

Yeah, we can maybe at least recommend it to be part of the the cloudants context, but you might not need to require it then I'm thinking of I mean, for example, if there would be if there will be custom schemas, which would somehow restrict the content of the event further from what we have described in our seed events, spec.

B

That could be one use case for needing to provide the schema here as well, because I mean we could, for example, limit the value range of certain parameters in a specific use case of these events so whatever, and then it's valuable to be able to provide that narrowed or limited schema.

B

I think, but maybe that's an edge case for now.

A

We can at least probably think of it, because it could be that the the user wants to have a more detailed version. As I said of it, and for example, they have ranges of values and so on, and then it.

E

A

Be good actually to be able to find that schema, so you know uh what it wasn't and how to read it.

B

Yeah, so from experience with iphone ericsson, for example, we have. There are some a lot of fields which are free text strings, but we internally want to limit them to a certain range of enums with certain predefined values, so we can easily interpret them from the ericsson perspective, but then, from a more general open source cycle perspective, they do not need to be limited that way.

B

So I think we we need it. We need an iphone. Therefore, I think it would be needed here as well for some use cases.

B

Anyway, that might not be most the most important part, but did you know something about that on the hour.

C

uh What was the last question and then sorry, yeah.

B

Did you know something about the schema that could be recommended to be used but might not be required? Yeah.

C

Yeah yeah, I will. I will update that.

B

Yeah so then, when it comes to this specific structure, uh we have uh what is called the subject here, which is more as a placeholder for the actual sort of say, interesting content for the event. As I see it, and then the task run here is the doctor gato the verb or the. What is it now happening?

B

Yeah the name here subject.

C

Underneath, yes,.

B

The predicate right or what they call this part.

B

A

That the subject.

B

Yeah about the story I mean this, this is, uh is this the noun and this is the verb. Then we've talked about those different terms. The parts of the.

A

B

C

Yeah, it's also now.

B

Okay, it's called subject: okay right, so then this part is a subject there. We have a subject, and then we have a subject here as well, and we have a subject out here. So a lot of subjects in this structure which we need to clean up, I guess a bit.

B

uh We cannot of course change this. It's the cloud events defined name, so we cannot change that, but whether we should call our thing here subject as well or something else uh we can maybe discuss uh and then, when it comes to the actual structure, I propose two alternative structures here which we could discuss. If I find it now yeah here we have them.

B

uh One could be this that will more or less just flatten the whole structure. So we have the the generic part which is valid for each event and then on the same level. We just add the event specific parts.

B

This might be confusing if, if you can't really see which fields are generic and which are not.

B

And that might be a objection to that.

B

Another way would be to instead have a separate structure for the the actual common parts which could be called meta or something else common or whatever, and then the actual event things I mean that would yes make it easier to then I mean this could be a sub schema for this generic part and then the actual event is contained.

B

Actually event parameters are contained on the top level. Instead, I don't know if that makes sense or not, but we should just choose the one that is, we feel this is best for our both us producers and consumers. Of the events, I think.

B

B

Do you have any direct comments on that sunday, or would you prefer this improvement that you proposed.

C

um Well, the the one I propose resonates with my way of thinking, because it kind of encapsulates um different things and if we had, I imagine we can have like we will have extensions and maybe other linked events or other parts of the message that we might add in future and then kind of the sub that the specif. The details of the subject um remain isolated.

B

Okay, so you mean then those will be after this on the same level of subject. Is that what you mean? Yes,.

C

Okay, I mean the the subject in line the fifth field. In that example, um it's a copy-paste error. So definitely the first version of the subject in this. This is something that needs to be removed. That was just.

A

C

Mistake for sure, um in terms of structure um yeah, I thought it it looked. um It looks nice um in or easy to parse for me, but uh because then I I know that all the fields under task run are specific to a task run, and I mean we could have something like meta there like he proposed, um and then you could infer the fact that these fields are specific to a task running from the type, because it's a different.

B

C

B

Yeah, we might not actually need this level since it's already a task run event this or do we need this as well, then, or could we flatten it one level you think otherwise, I don't know um what extra.

A

Information does.

B

This year, yeah.

A

One question there is: uh when you parse such an event, and do you want to have an event specific key in the message? Basically, do you want do you want to be need to look up okay, what type of enthusiast and then look for the key, or do we want to have generic keys in all the events, uh so you can more easily parse out and events.

A

Do you understand what I'm talking about and you follow me? I think partly.

D

So in in one aspect, it's it can be annoying to have keys whose name depend like it gets hard to write a schema for something like that where you have different, but on the other hand, it's nice to to know that the id and task and pipeline run etc. They they connect to a task run.

D

uh I lost half my train of thought, though,.

D

Yeah, the other part, if we make it generic, I guess there are certain subject, information that would not be generic. That would only apply to specific types of subjects. Subjects like a task run so task run, can definitely be part of a pipeline run. But maybe something like I don't know a deployment event, maybe or a degradation is not part of a pipeline run because yeah services degrade whenever they want to, not necessarily because they are in a pipeline.

B

So I believe, yeah. I believe that we have said that some fields should probably be mandatory in any event type such as id. Isn't it didn't you say somewhere, andrea that certain fields should.

C

B

Be part of the subject.

C

Yeah, the id definitely must always be part of the subject. That's the. I think, the only one that is mandatory for all subjects and others. Others are really like it's where we we build the it's where we use the dictionary to say: okay. This is the official name for this property uh that you know. We want to be recognizable across uh different platforms.

C

So if you have an artifact, um you will have the id and then you will have the url or a sha or whatever the names we pick, but those names will be both specific to the subject and also should be shared across platforms.

B

Yeah one way to deal with that, then, if the idea should always be in any subject, would be to lift up the actual id field into the subject, object itself and then have the event specific field in a separate object under it.

C

B

We can always parse this subject. There.

D

Maybe then it might also be nice, but maybe we're going too far connecting to what matthias said before to also have the type of subject on the top level or next to id. So then we we can check that. We can check that first and if that is of type task run, then we know that there will be a task run key which we can look into again. It has to do with with how simple it's to.

A

D

A

D

C

D

If we have this, then we could also just do it so that we don't call that task run key task, one. We just call it subject or data whatever we want to call it because then the.

A

D

Perhaps clearer, in that sense.

C

B

A

This resembles a bit of the idea that I put in my comment.

A

It's on cloud events binding.

A

I put a comment there on suggested, which could do something like this, but the idea there was then of course, as eric said it's easier to parse it. So it's it's always a known key.

D

Yeah, this is going to be a small anecdote, but something I ran into big problems with when it came to having a sort of more dynamic keys in object was when I wanted to use graphql that it really doesn't like when you have dynamic keys. It wants the schema to be exactly the same all over the place. Otherwise it's really hard to query or I'm just stupid, which is also an option, but I think it was a graphql.

B

D

B

The question I don't know andrea, you said that that the the subject shouldn't be that's a typo, but but what do you think it should be, then, should this not be there at all or because this.

A

B

String as this one currently.

C

So if you're, putting together the kind of the header part and the.

A

Thank you and you're, looking only at the body right.

C

Yeah, no so yeah. The first subject should not.

B

C

Yeah, that's right.

B

So this is the cd events body yeah.

C

Yeah yeah, so the first copy of subject has just copy pasted from the top, and I forgot to delete it.

B

I mean okay, that shouldn't be there. I was thinking if this id below there already existed somewhere on the top level, but it doesn't then, should this be on the top level and since it's mandatory in any event, currently it can be on the top level instead and what makes it different. From this I mean this is a uu id right, the event actually.

C

That's the event id um so the subject id is not unique for the event. It's something that you can uh say give me all the events related to the subject. For instance, if you collecting all the events- and you know it gives you if you the ability to to easily search for or if you are listening for events and you get the initial event for a certain subject, you might set up set up a filter. That says give me the other filter for all the events from this other subject.

B

An alternative would be to do it. This way, then.

C

Yeah um I mean there.

B

And then we don't need the sub part there. Maybe everything can still call it subject. Maybe.

A

Just as a reflection there, um if you would type out in both examples how you would access subjects in the first example, it would be subject.id.

A

In the second example, it would be subject underscore id um yeah event, data subject id or you have event data subject, underscore id.

A

So I don't know, actually I I'm when I when I see it like that, I'm wondering maybe it's it's a little bit easier to actually have the uh yeah that one, because.

B

A

You can basically says: okay, what keys do I have under data subject.

C

A

The last one will it will be a little harder time trying to figure it out.

B

Yeah makes sense.

C

Yeah that that part I like in in the way, a structure that, if you use like a json puff into a certain field, you basically see in the json path the.

C

What is it that you're addressing um I mean if you have the task run there, then you see a subject: passcode id and it's clear, but but um I.

B

C

I understand that also you, you might say you want, you might want to say, okay under data, if you put it under data and the anonymous one, you don't see it in the json path, but then it's the same path.

C

I'm actually not sure what is easier for passing. It's, whether whether it's easier to have data that might contain different things or it's easier to have different keys, but the same key always contain the same kind of schema. It makes sense.

A

I'm wondering like if you're, if you would be querying something uh say, you have a bunch of events and you're querying if the search path would be the same for all type of events, in my mind, I'm thinking that would be easier.

A

So, for example, you say.

A

Yeah date event, data subject um id equals and then you can get all the ones that have that one. But if you would have different ones for like task run, build and so on, it would be more difficult to do that. So.

A

Convenience for kind of like searching and and and describing paths I in my mind it sounds easier to have it and that path fixed.

B

Did you mean this one? This is easier or.

A

Yeah, where is a known path down in all events,.

B

One drawback is that it's a bit harder, maybe to read this event, this json blob manually it's easier for every machine and that's maybe what you should focus on, but it's a bit harder to have these intermediate levels.

B

When you look at it manually, maybe or you just get used to it,.

A

Yeah, I would probably vote for.

B

Yeah yeah data is not a good thing, that's already in the cloud events part. So maybe something else here.

B

I don't know what it would be called, but content oops.

A

Subject or something that content could be, we.

C

A

A

B

B

The alternative, well uh yeah, maybe you're right, actually andrea- that this makes it a bit cleaner.

B

My suggestion was, then, if we take. This first example, which we seem to vote for right now, was to include the top parts in the other structure. Let's just call it meta for now.

B

I'm not sure if that l helps in another way, then it doesn't really. Since all these are standard parameters and the same in all events, then that level is just unnecessary. Additional information in this kind of.

D

Even with that, I guess if you introduce a meta top level thing and put, for instance, event id in it, then it's no longer a cloud event.

B

Yeah, yes, it is, I mean this is still inside the cd events, data payload, oh.

D

Sorry I thought it was on the top.

B

Level- okay! No! So so we are not on this top level. Here we are just in in the seed event. Context part right yeah, but it doesn't maybe make much sense then, to have this level uh with this in mind that we discussed now.

B

A

One thing would be that you don't have any bare it's more. Let's say like symmetrical that you don't have any any data directly on on on like event data, but you always have have it one step down. If that is uh makes anything easier.

B

Yeah, I think andrea. You mentioned that, for example, extensions could be on another one in parallel with subject right.

C

B

Something yeah.

C

C

Something like that, yeah and that's a whole other story, but I think I mean for sure um the application will want to different platforms will want to add data embed data in here um and yeah. So we we might have a combination, I guess of documented uh extensions, so that other can parse, parse them or just freeform.

C

C

I guess that's um yeah, that's another discussion. We haven't really started yet.

B

But just yeah, but just for the sake of the discussion now, if we should make this extensible with with more parts, then we should only have the common core parts here and then we have the event specific ones here which are part of the actual protocol. And then we could have additional extensions here.

B

And if, if we would, for example, have links in these in here as well, we might have them as a separate part. I'm not sure if that should be in this level. Maybe that's to be clarified, but uh if we would call them links in this protocol, that's what we call them in eiffel tower.

C

Yeah, but we can, we can use that as a working name. I mean just for now.

B

So as a complete thing, what do you think does this look like a good structure to me? That looks quite quite good.

B

C

A

I I could actually, when we're looking at like this, I wouldn't mind the math apart.

B

A

I don't know if you want to call meta but just caps liking, so there's nothing uh because now there's kind of like I don't think the right word, but like levels of information, yeah.

B

A

B

A

Like version directly on it and then there's subject which is under and the other ones have also like deeper structures.

B

Yeah, it makes sense if you would do it if you would, for example, document that we have event data dot, and then we have.

B

Main structure part you could like a document, the syntax for the or which is a structure syntax for the event. The payload would be the main structure and then it will be properties.

B

Under that main structure, properties or object, and then there would be object, properties or something like that.

B

Does that make sense then this would disability would be the the yeah sorry the main structure, and then we have properties for other objects, and then we have that content. Maybe it's on here now.

B

Something like this.

B

You see what I'm aiming at.

C

Yeah, I guess that's something that will specify with the schema anyways but yeah.

B

C

B

Would need such a level on also on these parts. We shouldn't put properties directly on this level here in the in the path, so to say the json path.

C

Yeah, if it's just a cosmetic thing, I mean we can decide to do it or not to do it. uh I don't see any it's fine for me. If we want to have the extra meter, I don't see any downside, um apart from maybe making the adjacent path slightly longer, but I don't think it's.

C

um I don't think that that's a problem, um I think that's relevant for, like the uh it's more relevant, maybe for the cloud events, type of fields.

C

Because they may be used for filtering filter to filter when you have a lot of messages, so.

C

I personally liked meta better than common.

B

I'm used to meta, so that's fine, that's what we use in iphone. So that's perfectly fine with me. I didn't want to force it in here, but we can use it. Then at least people who are aware eiffel understands what it is about. I think.

B

So is this something that we would like to propose them, at least for now.

A

I think it's looks good and I kind of like nice with that definition, you had above there also main structure properties.

A

That type of thing is for me, this is more of consistency and that if you have something that is consistent, it's easier to to parse and program against, so I think it's.

B

I guess it could structure your sdk code in a better way. If you have an object-oriented program- language, for example, where you implement sdk, you could more easily define these as classes.

B

It would be probably nicer in the sdk code. I imagine.

C

Yeah, I guess um that's that's part of the thinking and with uh the objects or subjects like task run with uh fixed fields, so that, like grouped together, so you could have some something that returns you in your programming, language, a task, one object or environment object as a form, so that.

C

You can use that in the code, but this still still applies with this format. I think.

B

I was thinking that the term subject here, if it's good or not, I mean, since subject- is also in the top in the cloud events, and it stands for something else.

B

Could we call it noun properties or something instead.

A

If I remember remember correctly, we did check that and it's more it's subject to predicate. I think.

B

It's subject and predicate, I think it that's, because I think we documented that right somewhere was it here or where was it? No, it wasn't here.

A

um Is it common metadata.

B

Yeah soviets, okay, so then it's we should have subject there. uh That's the correct term, though, because uh this is the subject- and this is the predicate.

B

Just so, everyone is aware what it stands for, and this term here is the reason for calling this subject. Then.

B

Then this predicate here is not reflected in the structure, always yeah. Maybe that's the second thing. If we should to me it's fine to continue discussing this the whole hour.

B

Yeah, I know andrea that you proposed that all these should be part of the this schema or at least of the documentation that each event with the same subject should have the same list of properties in the content pattern. I guess.

B

And that's one way to do it and then document which properties are mandatory in what event and which are optional.

B

Another way is, of course, to have different json schemas, depending on the predicate, which means that there could be different properties in the content part depending on which predicate you have.

B

C

Yeah yeah, I think, from a general documentation point of view. I would still like to say: okay, these are the properties that are you you may have uh on a on on this type of subject, because then, in that place we can, you know, go in greater details, say: okay, what is the ide and put all the examples, and maybe say? Okay.

C

Make some even some platform specific example makes all the discussion and then um in the schema, you could have like separate schemas and only contains there the fields that are relevant but yeah. I'm not sure. If this answers.

B

Yeah, I think it does to some extent, at least so, let's see where I want to be here yeah, so I think that's what you proposed right in the.

B

If I do it like this instead, I think it's seen here right these things, uh so that you propose where where we should have different the properties as optional and whether or mandatory where they should be not permitted or permitted, and so this would be the documentation stating how, for a certain predicate which properties are then mandatory or not um yeah, that's another way to do it than how we do it in eiffel. But I wouldn't say it's wrong: yes, because of that.

B

So for the same subject, but with a different predicate, there will be a different list of mandatory and permitted and so on properties.

B

It's kind of related to the discussion that we need to have soon on the whether we should have links or not in the events.

B

But I guess until we are there. I guess this could be the way we document these things, because if we would have links uh it depends on how we would introduce links, of course, as well. But if we would have links and then have some statements saying we shouldn't duplicate any information that has previously been sent by your necessities necessary event or something.

B

Then we don't need to repeat that information again, so we shouldn't even be permitted in the following events on the same subject, but I think we are not there yet and we might want to support.

B

Events with full say, subject: bodies anyway, even if we introduce links so that it's possible to to provide all the information in each event, instead of needing to have links between them and needing to aggregate multiple events.

C

D

See what you mean yeah.

C

It makes sense, I mean.

C

It seems to me, like a very strict requirement to say if an information was ever sent not to send it again.

C

I imagine if I'm starting to listening to events, and I miss the first event, then I will never get that information again, so it.

B

Yeah, unless you're aware of a database where you know that all events are always stored, then you can ask the database for it, uh but that that's that's more in the in the links discussions. Maybe we don't need to go into that detail there, but one thing what just strikes me in this I mean the pipeline run is another subject which has its own content properties.

B

And we will, of course, never include all the pipeline round properties. I guess in all subsequent events and whatever happened before this task run. Event is not either part of this subject structure, so there will always be information that is not sent in the current event, but you would need to find up some other event to be able to find um yeah. I'm not sure where I wanted to go with that, but.

C

You know, I think, yeah that's another example of information that it only sent once or only 17 other events. um That may be where you were going.

A

The question there is, if you want to uh you, can think of it. I had a with a pipeline run there. I had an an idea if you want to list it out to reference a section instead, so yeah, you stated apple, so you saw that it was a reference out to be more explicit, but you can think of it. um Going back to this. With with the documentation, uh I had, unfortunately, a bit of problem trying to figure out or map this.

A

These uh manager permitted not permitted things, um so I would basically probably prefer that okay, if we state deficient pipeline queued and we actually state these ones- are mandatory and these are optional and because that's for me, it would be easier to kind of like map uh what type of properties you can use here.

B

You mean you can.

A

B

The documentation instead of a table then or.

A

Yeah, do you follow what I'm, what I'm out after.

B

I think so so it should instead be in this bullet list. Instead of having it in a table. Was that the thing you wanted to say yeah.

A

uh It feels a bit uh difficult to to um uh trying to grasp okay, which, which was that I could use and which, not because you you basically need to if we just have a table like this, and you want to figure out how does the whole event look like? You need to scroll up and down all the time, and you need to go up to the subject. Look! Okay.

A

What fields was there and then get down here again, uh so you have to scroll a lot in order to get out okay, which fields are there or not?.

B

Yeah, so here we see the the different I mean this is common one, but then we have source and testing and type around those. So these are the properties for the this. For the prop there's com, sorry, subject, properties right, subject, content properties uh and then they should be the same as in this table.

A

Yeah, so I'm wondering if we'd like, to need the the kind of like overview, but instead place them in each one. Of course it will be kind of a repetition, but I think it's going to be easier to read and and map that mentally.

B

So splitting this table into each of the sub lenses that you mean yeah.

C

Yeah I was trying to to avoid to repeat all the examples and description and so forth, and but yeah I mean oh, this could be made as links to the original table that helps but or we could copy paste. It's just that.

C

If you update the description then of the source or task name, then you you have to go and in all the events update the description everywhere around.

B

C

One alternative.

B

I guess could be to add columns here for each of the three predicate events, so cued started finished as columns here and then add the check boxes here and then just maybe refer there from this documentation. Is that would that make it any easier? Of course, then we'd only be in one place, but still it won't be under each event type. But since this is not I mean if we have the same subject content for each event of the same subject, we don't really need to document the complete event content in each predicate section right.

B

We can instead refer to the event structure, which is in this subject section. If you follow what I say.

A

As long as the reader has these time, so, for example, if I'm interested in the cute event- and I want to figure out okay- which parameters uh do I need to have here or not? If I can get a grasp of that easily and then it's it's perfectly fine, but uh so it's really convenience or right to convenience, and I would probably confirm before really convenience.

B

C

To me, that's why I put them in a table instead of having columns, I put them in a in a table with all the fills, because then, if you want to see the keyword event, then you have the list here. You don't have to cross-check or do anything, and at least that that was I was trying to do, but but.

B

C

B

Said but it might not be clear: what is what what does it mean with status here? What does it really mean, then? You need to go up here and say: okay status, yeah, that's a status of a finished task run and you can have these.

A

B

So then, you anyway need to go up there, but I'm thinking this is maybe documentation technical thing then, but I guess we could have used this as like documentation snippets instead. So this is one documentation, snippet stored in a separate file or somehow, and then it could be shown both here and here.

B

If we want to so then it's only one place to change in the actual source, documentation file.

A

That could be one thing.

C

Okay, but it seems that it's mostly uh yeah, as you say, you know, like a documentation, technical challenge. More than.

C

B

Not sure, if markdown supports that in a good way, yeah I've actually seen it in internal documentation that we have such snippets. It should be possible to use it in markdown. Have there some kind of? Is it called include, or what is it called? I don't remember.

A

Yeah, it's basically a pre-parsing that you uh fragments they call it.

B

Pregnant but maybe that's in our internal framework, but here, but we use that that's not part of markdown. Is it.

A

uh Not in it not in itself, it's a pre-processing step.

B

Okay, and that might not be supported in github, of course,.

A

Unfortunately, not.

B

I'm not either here.

C

We we could have some template with metadata and that is merged and marked down, then for visualization and get. um I think that.

B

So we only have a few minutes left should we do some uh updates to the actual.

B

uh Pr here from our discussions, I can just add this more list as a comment in the hole on the pull request itself. I clean it up a bit just so. This is not what we want.

B

If I remember now, and not the later part, either.

B

But this is something that we would like to see and this structure here. This is, of course, a later edition if we want to, but we can have it for reference because should I include this part up here as well or I need to restructure it. Of course,.

C

um Yeah, I think so, would be nice.

B

I could do that offline. You need to spend your time on it.

D

C

Yeah I'll update the pr then before the next meeting. So we can do another round of review and hopefully.

B

Good, so any other business, then we didn't get to the mauritius issue there, but we take that in another meeting I think or we can take it- maybe.

C

um Yeah yeah, yes,.

B

He will yeah, so we might be able to talk to him there about those things. um Anything burning, andrea regarding city events, con or something like that that we should say something about.

C

um The only thing I mean the uh the virtual part of the conference, um so we have someone from cncf that is working and setting up the um rsvp link so that soon, um hopefully we will distribute a link so that if you are attending remotely, you can just rsvp there and attend the conference and and for the in person and so in the room.

C

We will need to have a few folks, one or more and they're helping out with kind of syncing the in-person event, with the virtual one in terms of questions from the in-person audience going to a virtual event or question from virtual attendees going to in person speaker this kind of situation.

C

um So I already have one person uh who volunteered to help stefan montre from uh mirantis is his help. Happy he's going to be in valencia and he's had to help with this. uh But I think if we can have maybe two or three, so it doesn't have to be one person doing this throughout the day and that's that's better.

D

Is it stuff like uh someone in the audience, asks the question and then you repeat it into a microphone, so the virtual audience can hear it as well and those kind of things, sir, yes or you type.

C

It in the uh chat for the zoom or yeah this, this kind of someone watches the zoom chat. Also, if someone asks a question, then you can repeat it: yeah.

D

So that's I think you mentioned it doesn't seem like that is the current state, but that we may that maybe we were required to bring our own gear for making it virtual. But I guess that's not the case now with they will have like.

B

I think that was the rumor about that, but now it when we talked andrea to emily the other day, I think we heard that they will actually have gear for us, so we don't need to bring bring it ourselves.

B

Unfortunately,.

C

All right, um I got to jump to the next meeting.

D

Oh yeah yeah: if we have a vocabulary meeting in two weeks, it will be live in valencia. Yes, yes, but we will have a.

B

Meeting next monday right, so I hope to see you there yeah good thanks for today, yeah. Thank you.

A