 Hello, everyone. I think we'll get started. Welcome to an introduction to Cloud Foundry Core Development. My name is Jen Spinney. I'm a software engineer at SUSE. I'm based in Nuremberg, Germany. I've been a CF core contributor for two and a half years on a variety of core open source Cloud Foundry teams. And I am Luan Sentos. I'm a software engineer at Pivotal. I've been there for five years, actually, and on CF as a core contributor for four. I'm based in San Francisco, but I actually work from home out of Davis, California, which is a few miles away from there. So I work remotely with my teams. The motivation behind this talk is to introduce people to the way that we develop Cloud Foundry itself. So the intended audience is either people that use Cloud Foundry and are curious how it works under the hood, or people that are maybe curious about contributing directly to Cloud Foundry and getting involved in this ecosystem. It's a little bit different than most open source projects, which is also what motivated us to do this talk. The way that we do internal development is much more pairing focused, much more focused on a bunch of extreme programming principles. So we want to introduce you to how we do development and how to get involved in open source Cloud Foundry development. Cloud Foundry, just a brief history of where it came from, started from VMware, which is why we still have VCAP services, the VCAP Bosch user, things like that. Then it was run by Pivotal. And then in 2015, it was transferred over to the Cloud Foundry Foundation. It is still heavily contributed to by Pivotal, but they're no longer the company executing it. It's now a fully open source project that's run by an open source foundation. So inside of Cloud Foundry, inside the foundation, we have a lot of open source projects. For example, we have Diego that you might have just heard about in the previous talk. Diego is thematically related to a bunch of other teams that we consider the runtime. So we have this thing called a project management committee, or a PMC, that groups together a bunch of projects that are all thematically related. This PMC has meetings every other week to double check that everyone's on track with their projects. The project leads come together, discuss what their roadmap is, make sure that everyone is working well together and everyone's direction is aligned. So here are three examples. Diego, CLI, Cappy, but the dot, dot, dot here represents a whole bunch of other teams in this runtime PMC. Similarly, all the PMC leads then get together occasionally and form the PMC Council to make sure the PMCs are all aligned and everything as an entire Cloud Foundry is on the right path and working together. Cloud Foundry is governed by contribution. That means that you can't just come up as someone that's not involved in Cloud Foundry and say, oh, I think Cloud Foundry needs to go in this direction. You guys should write your code this way. The idea is that the more full-time developers that you devote to open-source Cloud Foundry contribution, the more, say, that you get in technical decisions of Cloud Foundry. The foundation guidelines leave it actually up to the PMC to decide what a dedicated contributor is. But the general guideline is someone that's working full-time, at least 75% of their time, on open-source Cloud Foundry projects. So they're not working on proprietary stuff. They're working on the open-source teams. And that means working from the common team backlog. They're not working on their particular companies, desires, at least 75% of the time. They're working on whatever the open-source team has decided is the open-source priority. So how does someone become a dedicated contributor? We have a process called the dojo. That is six to 12 weeks on site at a dojo facility. You are pairing. You are immersed in the Cloud Foundry culture of development. You are a normal team member on a real project. This is not some special class you take. It's not some fake project or beginner project. It's a real project. And the idea is to get completely culturally and technically immersed in the Cloud Foundry development culture. The idea is to get very fast onboarded into the code, the architecture of the product, but also how we do TDD, how we use CI, and our development culture in general. The first steps to doing a dojo is to contact this email address, cfdojo at CloudFoundry.org, to figure out where there is space on a team for you. Because you're joining a team as a real normal member, there has to be space. They have to want someone on that team. And there are a variety of locations where you can do a dojo. There are several in the United States. There are two in Europe. So there are a couple options there. The first thing you're going to do after you've decided that there's availability and there's a site where you're willing to travel to if need be, is to do this pair programming phone screen. The idea of this is to make sure that you would be a good fit for this pair programming TDD kind of environment and make sure it's going to go well during your dojo. If that screen goes OK, then you get on board onto the team like a normal team member. And if the dojo goes well, then you can join a regular team either in person or remote. So if you had to travel somewhere far to do your dojo, you can continue being a full-time CloudFoundry contributor remotely after that point. And a little bit about those themes. CloudFoundry is really global. In fact, we have members of the core teams, of the active teams, all over the globe. You can see on this map these pins on the map are only the active teams, not counting the incubating. In fact, the incubating teams here would be much more than that. And as of right now, when we were preparing this talk, we're spending four continents, eight countries, and nine time zones. And we all work together to building this product that we all like and use. And some of those themes are actually even distributed amongst themselves. I mentioned myself. I work remotely from home. And my team has people in San Francisco, in Portland, in Toronto, and in Santa Monica. And we all work together in the same backlog. That's the Bosch team that I'm working on right now. For all of those distributed teams, they actually follow a fairly similar structure. All of the teams will have one assigned product manager who is responsible for receiving input from the community, from the PMCs, and digesting that input into a roadmap for the team, organizing that into a prioritized list, into a backlog for the engineering to work on, making sure that the engineering team always has value of work to perform. And they're also responsible for serving as a bridge between their own teams and the rest of the organization via communication with the PMC meetings, on mailing lists, on the community advisory board, and other things. The teams are also composed of, of course, engineers. And we actually compose teams in pairs of engineers, not in individuals, because we do pairing for everything, for every development story we work on. So we're going to have at least one pair of engineers on any given team. And their responsibilities is to not only work on the stories of the PM prioritized, work through that backlog, but to ensure that the product is always releasable as much as possible by maintaining and grooming a continuous integration pipeline. They're actually going to talk a little bit about later. And being on a team and being part of the community, the engineers are actually in a great position to provide feedback, not only to their own projects that they're working on, but to the teams that they're interact with. So as a member of a team, you have that opportunity to really drive the direction of Cloud Foundry in both small and big ways, depending on your interests and all that. Really importantly, the teams are actually not organized in any special hierarchy. Every one of the team has the same responsibilities. As Jen was saying, even when you join on the dojo, before you become an official core committer, you're already treated like a core team member. You join the team and you work with everyone else. And no one is really treated especially. We try our best to not have any biases. Of course, we understand that people are different, and everyone has their own skills and experiences. And we try to make use of those by giving opportunities where you can use those special skills and experiences in a way that is both beneficial to the project, to yourself, and you're helping grow your peers on the team that you're working on. One of those engineers is actually assigned the role of anchor, which is commonly misinterpreted as an engineering lead. On Cloud Foundry, the anchor has a role that is a little bit different than your industry standard engineering lead. The role is actually to make sure that the team is working together and making sure that the team is successful. And they do that by working with the product manager and with the rest of the organization to make sure that there isn't anything missing, resource-wise, and that the team-builder is balanced in experience and skill. And they are responsible for onboarding or making sure that people that join the team are onboarded successfully, either by pairing with them themselves or by assigning other members of the team to pairing with them. So again, mentioning Dojo when you join the Dojo, the anchor is the one that is going to be welcoming you there and making sure that you get all the content you need to ramp up. Although the anchor is not expected to be an engineering lead, they will usually be a very technically skilled member of the team. And they have to try as much as possible to not let that position of leadership that they're put in and not let that affect their view on the opinions of the other team members because we want to favor consensus over just having your preference be overriding everything else. And finally, there's a few other roles that might apply, depending on needs. You might need a designer for something. You might need a documentation writer. There's always space for those disciplines depending on the needs of each project. So we've mentioned pairing a lot so far. We haven't really explained what that is or what we mean by pairing. Technically, not all Cloud Foundry teams pair or have to pair. It's actually up to the PMC to decide whether each project is going to use the pairing model or the distributed contribution model, which is more similar to other open source projects you might be familiar with. But what we're going to talk about mostly here is pairing because it's what makes Cloud Foundry development a little bit different. And it's what all the runtime core teams use. So it's very, very common within Cloud Foundry core development. So what does it mean to pair for us? It means you have one computer. You have two engineers working at that one shared computer. You often have two monitors, two mice, two keyboards. But you're both controlling the same computer. Everything that you work on, you're collaborating with your pair on. So you pick off a story from the backlog, figure out what you're going to work on that day, and you immediately start talking about it. It's like regular development. But instead of everything happening in your head, it's happening through your mouth. You're getting feedback constantly from your pair. You're constantly improving your ideas and getting feedback and iterating. Because we all need to be pairing on all of the stuff that we write, it means our schedule is a little bit stricter than most other software engineering schedules. We have these two four-hour pairing sessions with lunch in between. We all start at work at the same time. We all leave at the same time, which is a little bit stricter than what you might be used to. But it's kind of nice because it means you work exactly 40 hours a week and not more. And the pairing time is super, super concentrated. You are focused. You are pairing. There are very few meetings interrupting you. And it's generally much more focused than when I've experienced individual coding. There are a lot of reasons why we choose to pair. This is something you can probably see in agile conferences or in agile books. There's a big list of reasons why people should pair. Personally, I find that pairing makes things go way faster. Even though you have two people working on what you theoretically could have one person working on, the velocity is so much faster than what I've seen working on other software engineering models. So I recommend, if you haven't tried this before, to try it out and see how it works for you. I've just been super impressed seeing it firsthand, living it every day. It's very, very hard in the beginning. It takes a couple of months, I'd say, to really get used to it and not be socially exhausted every day because it is a lot more intense, both socially and technically. And it's tough to get used to in the beginning. But then after that initial period, it's awesome. Like, you feel like you're flying. One of our other core principles of how we do development is test-driven development, or TDD. That means that when you first sit down to write a story, instead of just coding the solution up, you first write a failing test. The idea is that that test will go green once you've satisfied what that story requires from you. By doing this first, before you write the implementation, you're not letting the implementation bias what you later test. It also keeps you focused and keeps you writing just the code you need to make that test go green. It keeps you from over-engineering things too quickly. It keeps you from writing code that isn't tested. And in general, this is a practice we follow throughout Cloud Foundry. Another key point is continuous integration, or CI. This is your pipeline. So when you push a bit of code, the idea is that you push to something like a develop branch, for example. And then it goes through a series of tests. Then once it passes these tests, it might get merged up with your master branch, or it might get released into the public. By doing this, we ensure that whatever we put out to the world has been rigorously tested. And we are confident about it. We are confident it's not going to break people's systems. And it's also important to keep this thing clear and green and stuff moving through. So if we have to release something quickly, that needs to take priority over everything else, it can rush through this pipeline, and everything goes well. In the actual Cloud Foundry programming offices, you'll often see these CI screens displayed in very large monitors, so everyone can see if the CI is green, or if it's red, and everyone should start freaking out, or people get a sense of being red is OK. But if it's red all the time, then people get a sense, like, oh, there's something really wrong here, and it's always on people's minds. We have a few meetings, not too many, but we're going to talk about a few of them. First of all, stand-ups. We have them daily. They're very quick. It's an opportunity for each person on the team to tell the rest of the team what they accomplished or what they struggled with the previous day. It's a perfect time for you to ask for help, to notify the team of a change in the workflow, or just broadcast any type of information in a very quick manner. Again, these don't take very long, usually five to 10 minutes, depending on the size of your team. It's usually led by the anchor, although delegating the running out these meetings is something that the anchor might do to help bring the rest of the team up to speed into the process and have other people also prepare to take over that kind of role in the future. On top of talking about what we did the previous day, we also talked a little bit about what we're going to do on the day that is starting, because these happen in the morning. So we assign pairs. Who's going to pair with who? That, again, can be done by the anchor or by someone else on the team. And it's really interesting that we actually do this, depending on the team, we try to do this almost daily, where if I pair with Jen yesterday, I'm unlikely to pair with her again today. And that helps us spread knowledge really fast across all the engineers on the team. So it's also an opportunity to do a general sync up. Hey, we're going to have a retro today, or we're going to have this other meeting today, or something like that. And also an opportunity for DPM to notify the team of something important that has come up. Say you have a security vulnerability in each patch. You're going to want to talk about that during that meeting. But really straightforward. Another meeting we have is the iteration planning meeting. We call it IPM for short. That's held weekly, usually in the beginning of the week on Mondays. It's an hour long for most teams. And this one is actually led by the product manager. And it's prefaced by a quick review of what the work is, that the work that is currently being worked on to hash out any major blockers that you might have, or broadcast some risk that you discovered, or some story that is actually a little bit more difficult that you had foreseen before. After that, the team is going to go over each of the unestimated stories, the stories that we haven't really talked about yet. In detail about where that story came from was the user value. Why is that story a priority? And then the engineers have an opportunity to discuss the risks and how complicated they think that story is. And then they estimate that story in a point value. And we're going to talk about what points mean in a second. So during the IPM, we used a tool called Pivotal Tracker. It's the project management tool that Pivotal has been using for years. And we use it on Cloud Foundry on every project pretty much. And it allows you to divide your unit's work in three main categories. Chorus, which are almost always made by engineers. And they're meant to track work that isn't directly user facing. You're not really delivering user value directly from implementing a chore. It might be something that speeds up your test or improves some part of the code base. And the value there is really in your long-term velocity of your project. Bugs, as the name suggests, are defects. Neither chores or bugs will receive point estimates because they're not actually delivering any user value. A bug is just fixing something that should have worked in the first place. So we don't actually assign point value to those things. And then really the main thing that we work on are the features. Those are the things that are delivering direct user facing functionality. And those are the features that the PM will write or either by receiving input from the community or from the PMCs and get prioritized. And then we assign point values to those. And then points are actually a relative complexity of each feature. They do not translate to time values, at least not the way we use them in Cloud Foundry. There are a notion of the meaning of a point really depends on each team. You might have a point might mean something on your team and might mean something a little bit different on another team you might join. But what's important is when you join a team, you really understand what that team means with each point. So a lot of teams at Cloud Foundry will use point scales that go from 1, 2, 3, 5, 8, or something like that. And time comes into play when you get points and you spread them over weeks. And that's where you get your velocity. Velocity is the average number of points that a team has been delivering over the past few weeks. It doesn't necessarily represent how many stories you're going to get done in a week, but it gives you a sense of how much can get done in a week. And that's how the PMCs will generally plan for when can I get this feature delivered at a general level. And then third meeting that we have regularly is the retrospective. And we call it a retro for short. Also held weekly. Also in our, this one happens at the end of the week. We do this because a really core part of our process is our ability to iterate and to change, be it in code or in the process itself. So we have these meetings weekly where we talk about what went well during the week, what didn't go so well, some things that we might want to change. These meetings are led by the anchor or by someone else that they might assign. And what's really important in retro is making sure that everyone is heard and making sure that we come up with actionable things to do to solve the problems we noticed during one given week. So how do we communicate within Cloud Foundry? And how can you communicate with the Cloud Foundry community? Most of our day-to-day communication happens over Slack. That's where you can find each team has its own Slack channel. You can reach out to the team that you want, but you know you need to talk to directly there. We also have the CFDev mailing list for more broad questions, something that might be a question that spans over lots of Cloud Foundry components. Or it's where we make our own internal announcements. It's kind of a more official channel than our Slack channels. And we also use GitHub a lot for code-specific communication. So let's say you want to get involved in Cloud Foundry. You want to do some commits, but you are not willing or able to make this kind of large commitment to go to a dojo and become a full-time contributor. How do you still contribute? If you have a team that wants to develop some major component and add it to Cloud Foundry, I think the best place for that is on the CFDev mailing list. If you send everyone your idea, say, hey, does this fit within Cloud Foundry? What do people think of this? You'll get lots of feedback and eventually figure out a way to get it incorporated if it fits. If you have a bug you want to report or something that's specific to the actual code, I'd recommend to do that on GitHub directly in the repository that you are concerned with. And if you want to have a small feature that's scoped to just one team and you don't think it's going to be very controversial, it's not the kind of thing that warrants the entire Cloud Foundry community getting involved in. It's probably best to go on Slack and talk to the PM of the team where you want to add this feature to. With that, we want to welcome everyone again who hasn't already been a part of the Cloud Foundry community, and we're happy to take any questions at this point. How does pairing work if you're doing home office? Yeah, that's a great question. So the question was, how does pairing work when you're remote? We have a lot of tools for that. There's the tech side of it, which is things like, I've used Screen Hero before, which allows you to share your screen and have two separate mouse cursors so you can work pretty well remotely, or using something like Teamux or Teamate for terminal sharing. We use a ton of video and voice apps for doing all this stuff. There's also the culture of remote development. It's really important. And this is what I've experienced, because I've been remote pre-match the whole time. I've been on Cloud Foundry, except for my dojo. I've experienced that people are very remote friendly, and that's critical to having remote Cloud Foundry development work well, is that the people that are locally in the city where the project is based are always looking out for the remote person, making sure they have a chance to talk, making sure they don't talk over them accidentally in these video conferencing meetings. And I don't know if Luan has any other thoughts? Yeah, that's the only thing that I would have to say. While pairing remotely, you just have to be a little bit more vocal, because you don't have the body cues that you have in person. But it's something you get used to. And you, as the remote person, have to learn to call people out when they're not sending those urban cues that I can't see on their face. But that's just something you get used to, and it works really well, actually. And I've seen some teams have a video. This varies per team, but some teams choose to have a constant video running the entire day. So you can see the person's facial expressions. Some people tell me they like it specifically, because when they make jokes, they want to see if the person's actually laughing or fake laughing or something like that. There's some human element to seeing a face. On the team I'm on right now, the services API team, we have a video conference running the entire day. So even the people that are locally on site, in this case London, they're always on video. And they're just typing away. We're all muted the whole day, but we can see each other's faces. We can see who's sitting down, who stood up to go get a coffee or something like that. And it feels a little bit more normal, like you're not remote when you do that. Are there other questions? It doesn't look like it. OK, well, thank you all for coming.