Cloud Native Buildpacks Learning Sync, 8 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Learning Sync: 2020-12-08

Description

Meeting notes: https://bit.ly/38pal2Z

A

All right, so, let's see um I see, there's there may be some new people. um So if you'd like to introduce yourself, please feel free if you'd like to be a silent observer. That is perfectly okay as well.

A

All right, so, let's uh go ahead and move on to stand story. The standing items for status updates I'll kick that off by saying that we did create a new page, the community page on the buildpacks.io website.

A

As of right now it has kind of a couple.

A

I guess places you can go to contact the contributors and and just ask questions that sort of stuff. Then, additionally, it has the a calendar- and this is kind of more or less a work in progress, but the calendar right now includes the working group meetings and the sub team syncs. I believe uh the implementations team is looking into potentially doing something similar to like a tech talks where they'll kind of get together and dive a little bit deeper into very specific uh technical problems.

A

uh So once that is a little bit more solidified you'll likely see those added on here as well. um All of this is is managed through the same repo, the uh yeah, the docs repo, and so you could add calendar events uh via that mechanism. There's a readme for that, but yeah, that's pretty much something. I've worked on in regards to the learning track of things any other status.

B

Updates it's great javier.

A

Thank you. Thank you.

B

Yeah that looks.

A

Good, okay, any other status updates before we move on.

A

All right sorry go ahead.

B

I was just gonna say I I I haven't worked on documentation in the last. You know week, but we are planning to release the life cycle this week, so I'm hoping that that can be concurrent with some docs describing the new apis and how to migrate um but subject to resource availability. So we'll see.

A

Right that makes.

A

Sense, cool all right. Moving on to user research, um I don't know natalie if you'd like to speak a little bit more about this as well. I know you're facilitating a little bit.

B

um I would just encourage anyone interested in this effort to check out last thursday's working group um recording where we kind of brainstormed different data points that we would like to gather from people that we talked to and um just keep an eye out for an upcoming rfc um with, like the I guess, the script that we'll iterate on or when this gets underway.

A

Do you happen to have a link to that uh document? I know that we were also looking for volunteers to help through.

B

A

Interview process.

B

Let me see if it was actually linked in the.

B

Looks like that was probably shared in zoom chat, so I can get that link and put it in here.

A

Cool yeah, if we could add it to the user research section, then uh yeah, we could hopefully get a little bit more traction there as well cool okay. um Next, we do have kind of an an agenda item that was in the let's see the future topics and it talks about how do we pick up issues and prioritize them? I'm assuming we're referring to documentation related issues.

A

I know we had kicked off this conversation, but I didn't know if we've kind of put a bow on it or if there was more to discuss.

B

Here I mean I'm kind of curious. This is like related to what I said about the life cycle right like how do how does the learning team and the other sub teams like.

B

Define the responsibilities and the processes that we.

B

Have or don't have for making sure that, like documentation is released concurrent with the software that you know it describes.

A

The way I personally see it is the learning team in regards to any documentation specific to any individual. I guess repo or program right. It is really just facilitating that team and not doing that work for them right so because I think that would I don't know like that. Just wouldn't work overall, it wouldn't scale very well um so so that is, you know, hopefully that answers that part and and create some sort of clarity there.

A

So where I think the learning team you know fills a different gap, is the one that's more intended to that. You know user experience right. So when we talk about the documentation, that's hosted currently on buildpacks.io is more geared towards providing guides to towards providing that. You know very nice smooth, hopefully uh user experience of onboarding, but it isn't to like one of the things that I recently came across that I feel like maybe we're going down the wrong path.

A

Is we have a page, a reference page for the build pack api or the platform api?

A

And although you could see that it tries to add a little bit more clarity, it seems like it's actually detrimental because we're we're kind of staying out of date like we can't keep it up to date, for one right and if it really is about comprehending the spec itself, then I feel like the spec itself, should be clear and not have another layer of translation to explain what the spec is right.

A

So I feel like in my mind that should go away and we should just focus on clarifying the spec itself so that we don't have two pieces of information to keep up to date. As we, you know, progress through the different versions and all that, so I know I'm kind of going into a different.

A

You know side tangent, um but when I we go back to like uh what is it called collaborating with the different sub teams, I think that's very easily doable if the sub teams themselves own the documentation and again just the learning team facilitates a place or area to place it.

A

And then, if there's any mechanisms necessary for sort of like versioning that documentation, which is, I think, something that we've talked about, um whether we wanted to keep any older version documentations and we ultimately said we didn't right like that, would just add a lot of maintenance overhead that, at this point in time, wouldn't really be all too valuable since we're pre 1.0.

A

Maybe that'll change once we're past 1.0, but for right now the value versus cost isn't quite there. Does that answer your question.

B

Yeah this is this is helpful. I think this also helps like maybe.

B

Like illustrate the need for more processes around documentation and like the other sub teams, right like which we talked about, but.

A

Yeah yeah and we still haven't, figured it out right like I can look at the issues in docs and some of those issues do kind of make sense to be on the learning team.

A

But then some other ones don't seem as applicable right like document exact d output, like the learning team, has very little insight into exactly what that means right, and it's really more of an implementation detail that the implementation sub team would have a lot more knowledge of, and so, if we could get it from there, um I think it'd be more useful, um but I don't know like it just seems like we haven't, figured out exactly how to bridge that gap between where the issues are actually stored.

A

Right, maybe an option here would be to not allow these issues to be stored in the docs site and more or less be stored on the you know, whatever other relevant repo it applies to, and then just pr is obviously created on the dock side, but not the issues themselves. I don't know if that would work, just kind of thinking out loud.

B

I did go through at one point and add some labels to issues that I felt were like. Oh, the implementation team is well placed to work on these.

A

Oh, I do see those uh-huh.

B

Yeah, like some of them are maybe like it's questionable. It really could be just anyone with broad knowledge could pick it up. But, like you know to your point about exec d right like that's something that I I feel like, we could slap a implementation label on that and just make that.

B

Owned by that team.

A

Yeah, so why don't we do something similar to what we did for the rfc process, right, where we add a sub team to that issue, where applicable, and then it'll like auto, generate an owner right, an assignee and not so much that they have to do it, but they have to like kind of see it through. If that makes sense, whether that's delegation or otherwise, it doesn't matter.

A

Does that seem like that? Would work.

B

Yeah, and for that.

B

Cool we can, uh I mean we can bring that up in the sub team, sync for platform and implementation. This week we throw it on the agenda.

A

Yeah for sure yeah that'll be tomorrow and thursday, so I think it'll before we like, you, know, throw people at it. We might want to announce it to them.

B

A

I think that would that would definitely help out that'd, be awesome.

A

I'm stealing your text for platform.

A

All right anything else on that topic.

A

I think the the latter part of that conversation, the prioritization, then just falls within those specific sub teams right because it's kind of up to them to figure out what that looks like or what makes the most sense.

A

Okay, anything else.

A

I I will throw out a plug for kubecon. Eu they've started accepting papers, so if you'd like to you know, make a presentation for cmb, um please do so, and we are here to help. If you know you need resources or you need just an audience to kind of go through it, we could definitely do that as well with that guess. This is goodbye, see you all online.