Cloud Native Buildpacks Learning Sync, 3 Nov 2020

Previous Meeting

⏯

youtube image

►

From YouTube: Learning Sync: 2020-11-03

Description

* Set Agenda
* Responsibilities
* Should we version docs?
* Stricter release process? Batch via release branches
* Should learning own user research?

A

A

So, what's our agenda like for learning, teeth, meanings.

B

I know I don't know like, I think we should figure that out.

C

First agenda is to set the agenda.

B

Pretty much um so yeah, I guess that's kind of what I meant by introductions. But, yes, I said the agenda sounds more appropriate, um so we all know each other right, joe javier david there's a couple more in.

C

B

Yeah no new faces all new to this meeting, but not new to each other. uh So for other, uh I guess meeting sub team sinks, uh the kind of standing items are status, updates and release planning.

B

I do wonder how that fits in with what we're doing, whether or not we want to align with something like that or do something completely different. Given you know the way that we work on this particular sub team.

C

Yeah, I think it's probably good to be in like we have a essentially continuous release flow, and it's probably good just to be explicit about that. You know we don't like bundle up a bunch of changes and then ship them to the website or anything like that.

C

um It's probably it's probably good to be explicit about that, just because um that might not be obvious for some things like potentially like as we do ad registry stuff or something I could imagine that I'm not going to need to change. You just need to be aware of it. You know.

B

So I am curious um right now, this learning sub team. What all is it responsible for because I feel like I have a an idea, but I don't know if it's really encompassing everything that we should be taking care of.

C

Let me pull up the dock and see if it's remotely accurate.

C

So according to the governance plan, which I shall link here,.

C

um We own docs the docs repository the resources repository in the samples repository.

B

What's the resources repository.

C

I just looked at this recently. What is it two years.

B

C

Like this yeah, it was like uh a place where we put a bunch of links. I think, before we had like a website.

B

Do we want to continue keeping that up to date, I'm not entirely sure what.

A

Yeah, can we retire that.

C

I think so um and like I was, I was thinking at first I was thinking well, maybe there's some things that we'd want to leave here, like v2 build pack links, but honestly, if it belongs here, it probably is worth documenting at this point.

A

Yeah I'll I'll make an issue on um the docs website, the docs repo to like port anything relevant from resources. Maybe.

C

Yeah that'd be great.

B

C

Yeah there's a lot.

B

Of outdated stuff, here too, like the docker images, it's like pointing to an rpax um user.

C

Yeah, let's kill this.

B

Thing right putting that on the agenda.

C

Yeah, actually, that I stumbled on that. We use the build packs, io name space right for docker hub.

A

Let's build packs, forge that's old.

C

Oh, it sounds like a.

B

Little golden breadcrumb or something be awesome.

C

That sounds like steven's old.

B

B

Cool, so we've got docs, we've got resources that we're going to kill and then samples.

B

The registry uh related stuff- I know I'm playing with that- a little bit uh with travis. That's not going to fall under learning.

C

No, but if we well, I don't think so.

C

No just because it's part of the website doesn't mean it's part of learning, yeah, you're thinking specifically about the search web interface right right, right yeah, I I mean, I don't think so. um I suppose we own, like the entry point to it, if it's on the website like if there is a search, button or link or tab or whatever, like we own that, but as far as it goes from there, it's just you know redirecting or whatever to um to the search web ui and that we don't own.

B

Yeah and that'll be completely isolated. Yeah.

D

A

Just that reminded me of a bad um search experience. They had another open source thing, so I'm gonna link to that on our issue. Make sure that we have a better search box.

C

uh Something that's not captured here that we do own is the blog.

D

C

And even though it's not a source code repository, I wonder if it should be included in that government's governance. Doc. Oh.

B

D

C

On uh I can't copy paste into the stock.

B

Of course you can, are you on a windows, machine.

C

C

C

Yeah, I think we should just include it in there something we own, even though it's not a.

C

C

So I'll do that. I have a note. I also need to add um a link to the docs from the spec. So we you know, we've talked about how people get in this like github loop, where they're looking at code and looking at the spec, and they really just want the docs.

C

um So we'd agreed in some meeting to add to the very beginning of the readme and the spec, um a sort of like you, probably don't want to be here. Kind of link.

B

Okay, like you, don't want to be here, that's it's funny. I.

C

A

Yeah we were talking with someone for the presentation they're like yeah, I read more spec than I ever thought. I was going to.

C

I don't think they need to right it's just because they get they end up there right. Our docs are good.

A

Especially if people comment and tell us what we can add, it's even.

A

Better, um we should also probably do some discussion on relevant issues or prioritizations and the learning and the docs issues I know prioritization makes sense, but we should at least figure out. You know god. This is something we should really get to. Sooner than later,.

B

All right, so, let's have that meta discussion, but before we get there should we assign these action items so like kill resources, I believe david, uh you volunteered for that.

A

I don't know how to do that. I was going to make an issue on the docks, um but if there's not really any relevant information on it, then that's probably just like an advent thing to archive it.

C

Yeah I'll do um how about, if you don't mind, just taking a look at it to make sure that there's nothing that looks important there I'll archive it just so, just let me know when you've had a look over each of the links.

B

Yeah, maybe you could let joe know when you're done and be archived.

C

And then I I was already planning to do the other two, um so I don't mind doing them unless somebody wants to pick them off.

D

Sorry I was late.

B

You're all good we're going we're going through and trying to figure out what it is that we do in the learning center.

A

I don't know if you can see former things in the chat but we're using this same basic document. The sub teamsync document.

D

You could share it again.

B

Yeah, I'm posting it. Oh quick finger david.

B

D

B

D

B

Then, let's talk, maybe meta about some of the prioritization, so I think in every other, like maybe sub team or repo right, like we're really talking about pack and life cycle like each one of those repos has a certain cadence or release strategy.

B

That makes sense, I think, because- and then you know from that, you could talk about like milestones right, because there is something that you kind of batch up and release for the learning and when we talk about specifically the website right, I feel like that's the primary uh repository to talk about that, isn't a thing right and so then we just have a list of issues and I think david. Your question is: how do we go about prioritizing some of that? I know in the past.

B

I created milestones for things that were somewhat relevant right, so things like questions that came out of kubecon right, I kind of put a milestone around it. um Other things I forgot. What other milestones there might have been like pac release, potentially create a milestone for that, but it never felt quite as organized as any of the other release processes so yeah. I don't know exactly what to do there, but that we can have a discussion around that.

D

One thing I've been wondering about which I feel that other projects, um like docker, for example, will give you like versioned docs, so that, if I haven't updated to the latest api, I can still get the information. That's relevant to me right is that something that we are considering.

B

In my experience with doing that, especially on like tools that are meant to kind of gather, information like confluence, like versioning, docs or associating docs to any particular version, is like really hard because there's a lot of replication and then there's like only small snippets that actually change right so like managing all that, like I, I could see, has a lot of overhead unless we want to like very specifically target and minimize like okay, we're we're documenting the different versions of the spec right.

B

Like we're kind of doing this already for migration guides, we have a migration guide of 03.04 or 405, and that, like makes sense right, like it's very specific but then to be able to say like this is how you do it, for you know pack 0 130, and then this is how you do it on pack 0 14 0.. That seems very strenuous.

A

Yeah, it's also, I feel like before. Ga it wouldn't necessarily be something that uh I I think would be the most important um like. I know when I let's say like look through like github docs and like they have I try and like I know the google sends me to the wrong version. Every time attempted to the enterprise server server, not enterprise, server or whatever, or what have you um it's always a bit of a annoyance to get to where I actually want to.

A

So I would probably vote against it, um but with having some, as you said, a new posted some like explicit materials on migration.

B

A

D

B

Sorry go ahead.

D

um I'll just add that there are places in our docs that are very tied to the particular api. So like we have a platform api section, obviously, but then there are other places where we you know I don't know, but does it is that okay or do we want to try to remove some of the specificity? That's tying us to a particular api version.

B

So there's two things that come to mind right. One of them is, I don't like. I think it would be beneficial that when we look at a very specific guide tutorial or whatever document right that we know what apis we're talking about right or referencing, or maybe when they were introduced, it's a better term of of saying it right, and so you could envision sort of like labels right where it says like this. Is this guide uses uh build packs, api, o5 and platform, api, 06 or whatever right?

B

That could be a thing and then maybe to ease or help with that. As I know, like you know, in the past, we've talked about or been wanting to batch changes, so we anticipate that there's going to be a new release of the life cycle with the latest version of the api.

B

So we know that we're going to have to like document some of these new features or changes, so we start creating the docs for it, but then it becomes like a coordination hassle to be like. Okay, like you know, let's ship ship lifecycle and then release this right away right. So I think we've never like formalized that process.

B

So I wonder if, because the lifecycle and pack have very specific release, cadences or strategies, whether the docs website could kind of figure out a way to work with them right, so that we do have some sort of uh batched releases.

B

But I don't know I I feel like that kind of goes against what joe was saying earlier, like keeping that fluid continuous delivery model. But maybe we could have.

B

D

So in the implementation team, like the sub team sinks, that we've had we've talked about bringing some docs issues into the milestone for the next life cycle, so that you know a minimum number of stories might get completed before that ships.

D

But that's kind of looking at it from the reverse angle. Right.

B

Would you elaborate on that a little bit so you're saying you will create issues in the life cycle, repo that say like document this on the website.

D

I don't know if we will go so far as to actually create issues on the life cycle, but just as part of our work we're trying to get at least that's that's my hope right that, like we consider part of our software delivery, like the actual documentation of said, features.

D

B

I wanted it yeah I was gonna say like um so. The spec has a very uh specific branching strategy. I do wonder right to kind of try to satisfy both. You know wanting to release continuously, but also, at the same time like batch changes, whether something like release branches that are almost in parallel for the next upcoming api changes or pac release or life cycle release would work right, so you could foresee that main could continuously get updates.

B

But then we have a set of documents in lifecycle. Slash! Oh I don't know what version you all are at right. Now: 10 12, whatever right.

D

B

10. so there's a release branch with that and then that's where the lifecycle you know or implementation team is creating docs around that right or our team as well, and then once the life cycle releases, then we essentially just create a pr that merges all those changes into the main branch and deploys.

B

D

I would be in favor of something like that, but at the same time I kind might personally. I feel that our biggest problem right now is the lack of documentation at all of many things that um I I almost feel like. We that that would be a higher priority than figuring out like how to batch stuff.

B

But is the problem with documentation that we're trying to backfill documentation, or is it that we're, let's say delivering the software without considering the documentation and only thinking about it after the fact.

B

D

B

Say that you know like I'm, going to take pac, for instance right if we were to say like hey, we really want to ship this documentation. Alongside with this next pack, release right and then kind of make that a as a goal or strategy that we use. Then I could see both of these going in and then you'd have the documentation that we say that we lack right. So it's kind of like more strictly adhering to a process than we have in the.

A

B

That's the only thing I could come up with right now.

D

Oh, I uh I see that we're we're running low on time, and I know I missed the whole first half of the meeting, but I just want to bring up one other thought regarding what this team is about and uh just see if anyone um also thinks this way like we. This is echoing something that came up in our like. You know: cmd contributors at vmware retro yesterday, which is learn like learning about our users, as well as helping people learn about the project. Is there any scope for that in this team.

B

So, are we saying like uh being able to create surveys or reaching out to users and gather data? Is that kind of what you have in mind? I don't know: what do you think about that.

C

I mean if I guess, if we have the bandwidth, um uh I also I don't know if I'd want it to be an exclusive responsibility of this team, because I wouldn't want that to be something that uh other sub teams, or you know, maintainers or whatever of the life cycle or pack defer.

C

Because, oh you know, the learning team's got that it just seems like a bad pattern.

C

So maybe it's something we facilitate, don't necessarily.

C

Do all the work or something.

A

A

I know like in I guess, pivotal uh or vmware more, I think, um having designers uh you know, drive that effort can help. You know them. I guess associate exactly what's necessary to pick information to pick up. um I don't know if that should be.

A

um It's definitely something that I guess in general, we probably should do more. I don't know, as you were saying, whether to be our exclusive responsibility.

D

But I think the same thing could be said of the docs too right, like I, don't think it's healthy for the learning team to be responsible for all docs right. You know um there should be some back and forth there too, and you know maybe we that was already discussed so.

B

Yeah, maybe the the term facilitation really is. What makes sense here right is we could figure out how to do it, maybe strategize on how to reach the right people that we want to ask about this, but then definitely not come up with the questions we want to ask and all that stuff right. I think we we need to gather that information from the rest of the community or the.

B

A

That could be a good thing in our agenda item, meaning like oh who, who or what is a someone we can reach out to. You know like a recurring item like who can we reach out to um for pack or for feedback.

B

What do you mean, like so you're saying, reoccurring, item every single week? We would try to reach out to somebody. What's that or.

A

Brainstorm: brainstorming, someone we could reach out.

B

To I don't know, I guess when I, when we're talking about like your use of research, I was thinking more in lines of like creating a survey and then like just spreading it as far and wide as we can to try to get the very specific groups that we want in here, which I would assume are developers for certain scenarios or cases.

C

B

C

Mean like there's, I think, there's lots of different things that are not mutually exclusive. Like broad surveys, we could do.

C

um I know terence- and I have done this with some of the like heroku customers using buildpacks, where we set up a dedicated like hour, show us what you're doing and how you're doing it a little bit more focused on that single customer user.

C

So yeah, I think, there's a bunch of different activities, and maybe maybe what david's suggesting is like make a point of discussing whether we need to have any of those coming up.

C

And then you know in in in the sense of facilitating, like let's say we let's say: there's a customer.

A

C

A user trying to think of a good example, let's say like gitlab or somebody or I'm not trying to think more like a build pack, users and authors example, but like we could make sure that someone from pac is there and someone representing implementation team is there and someone from distribution team to you know facilitate it, but make sure that the the various sub teams are still representing themselves and not relying on us to do it for him, even though I think all the teams.

C

I just mentioned it's us here, so we have enough for like cross-pollination right now that it may not matter.

A

We probably need someone from the courtyard so.

B

C

Just create a team that doesn't that's that doesn't have anybody else on it from any other teams, we'll just call it something. Weird.

B

Yeah, I think, from my perspective, the one that we're seems harder to get at and is very valuable, is like the app developer perspective right, because a lot of us here were like in the weeds, we're inside it, and so it's kind of weird to get the perspective of somebody that just comes into it and is actually trying to do something with it.

D

That could also help us understand what it is. We need to better document right because, like there's a very long list, I think of things that we would like to add. But what would be the most valuable, I'm not entirely sure cool.

B

So I know we're at time, so I wonder if the one action item out of this, at least is to put in you know a standing item, at least for now to strategize on what it is. The first thing that we want to do as far as that user research point is whether we want to do focus group or survey right and then kind of take it from there brainstorm on that.

B

Cool cool anything else before we drop off.

B

All right awesome! Thank you all. This was awesome.

B