Hello, folks. Can y'all hear me or is there a really bad echo? Hello, no echo. Yes, I was having a bad echo yesterday and I had and then today I still have the same setup and here we are with no echo. It's weird how technology works. Or doesn't work. Yeah, I didn't do anything yesterday. That's like the worst part when you're like I touched nothing. As I always say, someday I really want to see a Star Trek where they like dial up the aliens on the Enterprise. And the captain is like, Hello, can you hear me? And the alien is like, What? What? Are you speaking? Oh, there's an episode. Yeah. Oh, yeah. Yeah, he pulled that once. In the original series. Can you try turning your comm system off and back on again? Yeah, I'm just going to jump in and out of warp and we'll see if that clears it up. Well, wait, like one minute, maybe less for other folks to join and then we'll get started. Josh or Steven, you're also going to take it away at the zero hour mark while I ghost out of here to another meeting. Cool, cool. But we have some container D folks on the call with us today. Hello. Welcome to the container D folks. Derek, as I mentioned, on our last call came to contributor contributor growth working group. And was just kind of like what's this about. And we talked for a while. And we got here. So, welcome. Let me summarize and then Derek what I want to do. Actually, let's just do a round of intros because we like always usually know each other in this group. So we don't do intros anymore. But I think that's actually important now that we have half of y'all have not been here before. So, my name is Paris. I work at Apple. I do this cool fun stuff for projects with help with governance and contributor strategy. Josh, who are you? What do you do? I'm Josh Burkus. I work for Red Hat in our Ospo. And I got involved with this because among my many interests I'm a governance geek. Starting with the open office project back in 2001. Hello, hello. Hey, I'm Steven Augustus, primarily focused in the Kubernetes community. So do governance see things for a few places there. Also a dex maintainer and generally interested in just how communities get together and work efficiently. So I thought this was a natural step. Nassie. Hello. Sorry. Hey, I mean, for all, I'm multitasking and not doing it well. And I am on the Google open source programs office and I work a lot with GRPC, which is a lovely CNCF project that everyone shuts off and has an adorable mask. Maybe. Yes. A mascot is phenomenal. Carolyn. Carolyn Vence Lake. I work at Microsoft. I used to work on Kubernetes a bit. So I work in the broader community working on a CNAB cloud native application bundles and Porter, which was just submitted to CNCF. And I'm here mostly because I usually end up writing and doing a lot of the contributor growth activities on any project of mine. So I just have lots of opinions. All right, let's see. And then now we're getting into the container D team. Derek. I'm Derek McGowan. I'm the software engineer at Apple maintainer on container D for a while now. I also do some other stuff on like OCI as well. Sebastian. Hi, I'm Sebastian. I work at Docker and mostly work on the Docker engine. Also help maintaining container D and whatever open source I can find my to get my own song. Oh, that's cool. Hey Sebastian. And then Mike, that wraps us up. Well, I'm a maintainer on container D did a lot of the original work with land towel on the CI functionality that's in container D now. It'll be default plugin. We're integrating it into container D container D in the one divided release. I worked on operating systems that blue screen of death behind Sebastian. I did some work on that. It's not be on my work. I worked on OS OS to OS three and NT the original version. So you'll find my name down in that deep bowels of that code. Welcome Mike. All right. Thanks everyone for doing that. We never really do that because it's usually just us the first the first half of that crew. So the summary that I took away and Derek I want you to actually take it away from me is y'all want some help with contributor growth topics but specifically in some of these areas one role identification and building sounds like you also have some probably roles already in mind maybe even have, you know, have built off that from the last time we talked. And then also community management strategy and goals to maybe help the help maintainers out figuring out how to actually sustain that part of the function and then ultimately the outreach for that said thing. So whether remember we talked about whether or not it's like a group of people to help out with community management, a person, some kind of like strategy and or goal setting there. Did I summarize that right. Yeah, I think that's accurate. I think in the past container D's had some of that but as people have kind of moved on and as even the maintainers have like, which are different companies and stuff like we haven't had like a full time community for a couple years and yet it's kind of hard to like keep up with like other projects and such as a graduated project like keeping the same level of visibility. Yeah, for sure. And talk so actually go into the past a little bit so you said that one point you had a full time so one point full time. What were some of the other things that you maybe used to have as far as the community management side that you don't necessarily have any more. I think a lot of the roles we have today just even just like interfacing with CNCF and like organizing like who's speaking at different conferences and the different like speaking opportunities. Like keeping track of the people who are coming in and interested in container D and like mapping them to either the right people or like helping them like it started and stuff like all that stuff's been done directly by the developers, which it's kind of hard sometimes like stuff like falls through the cracks or like, we really have to be on top of anything. He said so for media to I think at one point right like you're y'all are doing your own tweets and stuff like that to you right. Yeah, I do most of the Twitter work. You like it don't fit. All right, and then let's go into a little bit more of the background around the roles do you and because I can't remember from the conversation that we had before. Do you currently have any other roles identified outside of like the standard whether it's maintainer or what have you do you have any tell us a little bit about the roles that you have. Yeah, so we have three roles today so we have maintainers, we have reviewers and we have a new security advisors role reviewers and maintainers are the more active roles. So, the difference really is just maintainers are almost like part of our governance process in terms of like voting on issues. And then actually like with right access for doing merges, but otherwise like the roles are pretty much the same so like it's just the active part is just reviewing code for both of those roles. But yeah those are the only roles we have identified today. I have about 800 more questions so I'm actually going to open it to everybody else though so anybody else want to day into either these two areas, either asking questions or either offering suggestions or advice. So, yeah, I'd love to know like what's working, or what isn't working today, it sounds like you have some new roles. How long have you had the roles, are they doing what you intended, and are there places where we could offload, or where you could offload work from that's classically divine and one of those roles into a new role. I mean, I think my goal is that I want to have a lot more reviewers so we've added the reviewer role for about a year or so and a Sebastian may know better about, we added that but we've tried to grow that number. Because that's really like what allows our project to scale in terms of like review and especially project like container D something that's really low and has high stability requirements we want as many people kind of looking at each of those poor requests as possible even for the small things. So that that's one of the things that I think we could do better at. And the others just like, I think, kind of at the project management level and just so for example like, there was some issue around not having like a security MD and like our container D project even though we had, it's like a GitHub requirement. And even though we had kind of listed like oh here's how you list things there was some issue or somebody was trying to file something. They couldn't find it. And see and see if actually kind of got involved and said like hey you need to have this like specific file and stuff like that. And as maintainers just like. I'm sure like, we don't know like or we don't really care too much like how stuff's like laid out from like a, like a GitHub perspective but if that kind of stuff's like important. Like, we need to know about that kind of stuff and like preferably have that stuff proactive like if somebody has some like requirements for how that stuff is laid out like something that was like known to us. We're not actively engaged in finding the new checkmarks that we're supposed to be filling in right in container D. So we're missing that level of communication. Right. Additional requirements to be a CNCF right maintain project. I think for the reviewers part and that's something I see in many repositories is that I think the occasional visitor of a repository considers the actual main thing is to be responsible for doing the reviewing. And I think in general it is people should be become more aware that basically anyone should be able to review whatever repository. I mean it's open source so input is always welcome and input is welcome. I guess if you get more people that are aware of that and maybe get involved into in that you can also pick actual reviewers out of that as to. Hey, this person is a great reviewer. I've seen a couple of reviews of this person on some renewable requests. And I trust this person to be doing actually proper review but getting them message out maybe one thing that I think could help the project. Do you have documentation on how to do a review for container D. That's a great one. Derek. We have anything other than just say review. We generally make sure that the people that are, you know, getting the review tag, have that capability already as opposed to, you know, giving them a set of instructions on how to make it. Right. Yeah, but we do give a lot of individual, you know, one on one kind of efforts to try to get people to review step or maintainer stuff. We also have what Derek mentioned, we have experimental projects that are, you know, non core projects, you know, sub projects that are extending and enhancing community but haven't, you know, been brought into the main main core set and in those we have their own maintainers. They're not core maintainers that are sub project maintainers sort of like Kubernetes, you know, SIGs and then, you know, and for types of projects. So, so few questions falling out of that to to kind of tag on to what Josh was saying. Documentation is huge contributor documentation if people. Things are a lot more accessible if people are given explicit instructions on how to do them to would be a question on how you select reviewers in the first place. Is it just kind of because sometimes it's like, you know, finger in the air like they've been doing stuff for a while and it probably seems like the right time, but having explicit instructions about how to become a reviewer would be good and then you mentioned one on one sessions and I think I think all of us do one on one sessions to some extent, but something that we've, we've seen to be pretty successful in the Kubernetes community and and Paris is the queen of this is exactly what she just said in the in the group chat video yourself doing a review are doing one of those one on one sessions and make that available on some YouTube playlist. Right that that becomes you know that scalable right because every time you get a new request for hey we were wondering about food right record a video on food and then put it up on a playlist right and that's you answering the question for however many to be to be fair we do have documentation to describe for you know coming on developers and documenters how they can, how they can make modifications and changes and review stuff. And we do also have contributing guidelines for the project is just not, you know, to the level of detail that you're asking about. Layer two of project maturity level contributor documentation, I think that's the, that's the way you have to look at it now like you've grown to this level of contributor documentation as a project and now you need to grow into the other layer, and that other layer is the like the documentation for your reviewers and for your approvers and for your maintainers. And the reason I was asking that is just that the documentation serves an important purpose beyond instructing people. I'm almost instead of instructing people because realistically, it's hard to cover everything somebody might need to know in terms of doing an actual review. But if you have a piece of documentation that says, here is how you as a contributor can do a review. That codes people into the fact that they can do a review follow me because your biggest barrier to getting more reviewers is that even people who contribute code to container D. Don't think that they are qualified to be a review. Yeah, I think having more documentation around that is definitely one of things we're looking to get guidance from this group, especially because like, the documentation we know works for the people who are involved, but we don't have kind of a good sense all the time, especially like trying to step out and looking at that from the outside. Like we know our documentation is not great, but we're not quite sure how to fix it on both like a process and like a technical level. I think, um, like it's kind of like the car before. Mike Mike was the culprit on that I was like looking at everybody that like, no just kidding. I feel like before like before we do the outreach that you need the people, like we should have at least some of the skeleton documentation so that like while we're, when we're doing these mega outreach efforts that say like oh container D is looking for new reviewers, they'll have something to like go towards and be guided to. So, from a documentation standpoint, I really think that like videos at this point are going to be your best friend because stuff that you're already doing and already in your flow, whereas like the writing of it is probably like the more difficult piece. And you can always link to your YouTube's and stuff from your technical documentation inside of your contributor guide and whatnot. So I think that's like, from my opinion I feel like that's where you should start is like what do I do like internalize it kind of like what do I do as a reviewer. Right, like what do I do is it as an approver that's any different than Sally down the street who's a contributor. Right. I would say depending on your technique like not everyone is a visual learner or visual teacher I guess. So even before doing the videos if you want to step back and say like, what does my day look like. Right, if I'm reviewing a PR for container D if I'm like doing maintenance work right like what does that look like do I do I stare at the do I stare at a project board. What do I do. First, right do I do some GitHub queries do like what's what's your process right. Even before you get to the point of like reviewing a PR, right and start to and then look at your documentation say is that documented. Right, because those could be gaps that people could potentially be filling a lot of the, the times, we find that a, that is an excellent, that is an excellent, excellent video. how to be a badass code reviewer to take a look at. So recently in SIG release in Kubernetes, we brought on a program manager. And it's something that we have been sorely lacking to say it nicely. I think it's one of the first times that we've done a explicitly named role like that in the community. And so Lori Apple has been just jumping everywhere in identifying things that we make assumptions on. We make huge assumptions on. And it's just because they're part of our day-to-day workflow, like as an approver or as a SIG chair, I'm going to do certain things, right? That may be happening in the background, like if it's sorting project boards, if it's adding new milestones, if it's pinging this person via DM to make sure that they're doing X, right? We have to come back and say like, is that stuff documented, right? And it may feel like it's a lot of the work that could be done by other people is assumed to work, right? It's work that you're already doing and isn't written down anywhere. So I would step back and maybe have a maintainer's meeting and just think about like what you do day-to-day and see if it's documented. Yeah, it makes sense. Yeah, discussing this within or kind of within the maintainer group. Yeah, it's definitely hard like getting everybody together, especially with like recently with like time stuff, like but yeah, understand there's no like quick recipe for some of these, but we just want to figure out like a good place we can start in some early progress. Anyone else have questions for, I do. So that's why I just don't want to take the floor. So other questions for Container D folks? Well, one of the things that sounds like is a major need is that you need to attract some volunteer, contributor, management, advocacy, whatever contributors. That is these are things that used to be done by paid staff from some company or another. They're no longer done by paid staff. And now you need to figure out how to get somebody to volunteer to do it. Yeah, yeah, kind of we don't necessarily need people coming in just contributing a bunch of code. I mean, or at least like code contributions and code reviews should scale, but like, yeah, right now I think one of the biggest laxes, yeah, not necessarily those code contributions but those other forms of like the technical contributions and helping with the process and stuff. I think that's right. So, okay, have you put out any kind of a call for that on like your user forum, mailing list, Slack channel, whatever it is? What is it anyway? No, not explicitly. I mean, we have Slack and Twitter, we don't even have mailing list. Yeah, well, I mean people of all kinds of different channels. So, I feel like the community, whoever is helping out with community could also help out with that as well. Like the channel development and communication development and stuff like that. This is Phil, sorry. I stayed quiet while I was on the phone because I didn't know how good or bad my connection was gonna be, but. Sorry, no, I thought that was April who was also on the phone. Oh, no problem at all, no problem at all. But just kind of, I think this may fit here, but, you know, container D is an interesting project because I feel like there aren't as many people all that interested in contributing but who love to play around with it as an API driven container runtime. And so, you know, even our user base is like kind of fragmented as a negative word, but I don't mean it that way. But, you know, there are a ton of people who just use container D because it's a CRI pluggable runtime and they really don't care. It works, it does what it's supposed to do. But then there's a bunch of people who end up in the container D Slack channel who are trying to build some crazy tool and doing really cool things. Those seem like the people if we have the time or energy, you know, they're kind of playing in the code, so to speak. But yeah, that's what I've been trying to think about.  So I don't know, that's an area I'd love to investigate is, you know, all these people that like container D is kind of the Swiss Army Knife API. You know, is there a chance to get them more involved? I think building some kind of outreach group for you all, it should probably be like a priority, whether it's outreach, whether it's like contributor experience and it doesn't need to be, you know, 20 people, you know, it could be a handful, it even could be, you know, some of your maintainers who also already do this stuff to like bootstrap it. But like Josh is saying, I feel like putting a call out and explicitly saying this stuff. Like I watched your intro and stuff for KubeCon and it was awesome and I loved how you were talking about more contributors. Like the next intro that you do for November because it's right around the corner, you should explicitly say this stuff. Say we're looking to grow the community in this way, like we need help with the following things and just be very explicit about your intentions, right? And see what happens. I think building that out though, like whether it's like I said, a community manager, would be super helpful. And I can give you some like pros and cons. I can like do a doc for you with some pros and cons of kind of like each group versus like person and kind of go from there. All right, yeah, that sounds good. I mean, we've been, we have a Zoom channel. We've been looking to utilize it to start something regularly. But I think what you said by having something that's explicit around saying, hey, we're trying to grow the community in this way and we're having a meeting that's specifically about this. Might invite the right people to come. I mean, maybe nobody shows up, maybe people do. And the thing is like, if you have to create the space for the work to happen, right, just like a work work, like you have to say like here's this time and space that we're going to talk about this specific thing. And that's kind of what we have to do with community as well. Like it's just one of those subjects where it's like, you know, you're going to do the code and you're going to do everything else first and like that's the priority. But you need to create the intentional space for people to want to like come and talk about it and feel like comfortable talking about that thing there. Good point first. I would say, you said you don't have a mailing list. I would create one ASAP just for the sake of like, if you can't schedule a meeting yet because your schedules don't allow it, at least you can start having that asynchronous conversation with people and start generating ideas for what might be in those meetings. Like community extensions and maintenance with CNCF type project or type requirements, that sort of stuff. Yep. And I was taking some notes too, by the way. So container D folks, I have some notes from and I think Stephen has some notes as well. So see y'all later on the flip side. Container D folks, thanks so much for coming. I owe you stuff and we'll I'm sure catch on the slack waves. So. For sure. Thanks Paris. Thank you. All right. I'm also going, sorry about that y'all. I'm actually going to not the container D meeting. Whatever meetings you're going to, I'm not going to that one. So I'm going to jump, but I still see Derek's on. So you might want to continue the combo. So see you soon. Later. Yeah, we've been having a discussion about setting up a mailing list. We're in the midst of a few different things on that realm, but yeah, what we're trying to figure out kind of at the higher level is yeah, how we schedule these meetings and how we get the word out. The problem with like mailing lists is they're kind of hard to bootstrap. So like I said. Yeah, I wouldn't start a new channel for this, honestly. I would say start this discussion on whatever channel your users, whatever channel currently has users on it. And if it's not, you know, if nobody's getting annoyed by it, honestly, keep it there because users tend to drop in and out of subscribing to things and having your users see an ongoing discussion on that channel about doing advocacy this or event that or, you know, contribute your documentation this other thing, kind of gives them the idea that this is a place for them to participate, even if they're no good at hacking go code. Yeah, yeah, I really like that idea. I think we're definitely going to follow up on try to get something scheduled that basically where we can continue talking about this and about the community. We definitely have our Slack channels and Twitter for getting, I think we have pretty good reach from there. But yeah, we use it kind of sparingly because we, well, that's just our style. We're not really loud vocal in our style, I guess. So how do you announce releases today? I'm curious, or pre-announcements? Oh, I mostly use Twitter for that. Gotcha, gotcha. I make a suggestion about getting people even know your mailing list exists because I've had to go through this a couple of times because you've already got people like following you on Twitter or following you on Slack. You may want to take advantage of a couple of different places where existing users are and be shameless about mentioning the mailing list and do two things. One, repeat yourself. So like, don't just mention the mailing list once because people mute Slack. You know what I mean? They don't check Twitter for three months because Twitter sucks right now. So like, repeat yourself. Every time you do a release, go, hey, here's a mailing list.  Do you want something in low traffic? We're just gonna announce releases, interesting features or blog posts or whatever. And then the other piece of it is, say what's going to be talked about on the mailing list, like what you're gonna type of topics or things you're gonna be pushing. So people have a reason to sign up for it so they understand why they'd like to and try to give them a little push to go over there. Cause like a lot of people, they sign up for your Slack channel but then like 80% of them mute it, things like that. So like right there, that may be like, that's why I think we got everyone to sign up for the mailing list just for that. Cause the signal to work noise ratio was like so much better. And just giving people things like this and then repeating it often cause people don't check these various places. Like throw it on your read me, throw it in your release notes and I could help put it in a whole bunch of places and you're more likely to get these users that you've had for years, realize you would have the mailing list. Otherwise it's really depressing cause you make it and you're like, ta-da! And then you have like five people. And they're all your maintainers. Yeah. Yeah. The other aspect is there's, I noticed a lot of the meetings are going into like a kind of mega CNCF calendar. Is that what other projects and stuff are doing to try to get the word out when they do have events other than just like spamming people but like actually getting these things into people's calendars. Like what's the best way for doing that? I love the mega calendar cause I can just look at it and know everything that's going on in the CNCF world. And then I don't have to like subscribe to five calendars. I don't know about anybody else. So I think part of it is also that as a graduated, you're graduated, right? As a graduated project, the CNCF provides things to you, provides resources to you and try your best to take advantage of them. Cause they're resources that are meant to solve exactly these kinds of maintainer issues, right? So being able to present yourself to the community, being able to, there are some program management tasks. They do help with websites. I don't know if you're utilizing the CNCF service desk right now. Yeah, we do that quite a bit actually. Yeah. But yeah, I would totally subscribe to the mega calendar. I don't always look at it, but if it's there, right? You can't say that it wasn't there, I guess. Yeah, I mean, I'm definitely not against the mega calendar. It's really good for like discovering like new events and stuff, but I wasn't sure if there was any, or if other projects were doing a different method or if they're had issues like just getting people to either subscribe to the mega calendar just for one event or an approach like that. So yeah, calendar wise, it depends on what it is. If it's something that I'm actively contributing to, I'm probably gonna be on like the mini calendar of the individual group, right? But like knowing that, oh, container D is having a discussion about this thing today. Maybe I wanna drop in, right? And having that information kind of at hand. Another thing I would say about the project phases, right? Is that for Kubernetes at least, right? A lot of the documentation that gets generated across many of the CNCF projects, they use Kubernetes as a template. I would say that as a graduated project, people are also going to be looking at you as a potential template for their processes. So I would say to one of the, I guess one of the gentle asks would be like, think deeply about your processes, right? Because you didn't just get to a graduated state for nothing, right? You worked at it over several years. So there are lots of good things in your process that maybe they just aren't documented, right? Maybe like it just works so well between the maintainers that you have that it's taken to be assumed, right? And that's something that could help a sandbox project and incubating project. So take some time to think about that stuff deeply because you will be the template for several other people. Yeah, I definitely realized that. Like we've definitely looked at some of like the Kubernetes approaches, but in many ways, like Kubernetes is just a project with a much larger scope. Too big. We don't. Container is kind of in a weird spot because like we almost have like the same number of users in terms of like if you're running Kubernetes, you're probably running container D underneath it. But the scope of the project is so much smaller that while number of users will be high, like the number of people who actually like come down and like really care and get involved at this level, we expect it to be smaller. But as the users grow and become more sophisticated, we just see there's more and more interest. So that's why we're trying to scale a process, but we realized that like in some ways, the process is unique, but in some ways, like yeah, a lot of other projects are in the same kind of level. I'll say from experience working on a lot of sort of backend infrastructure projects, libraries basically, because essentially it's what you are, right? In terms of your place in the ecosystem container D is a library for the cloud native ecosystem. What you're really looking for in terms of like a volunteer, community manager, whatever you're honestly looking for one or two people, right? You're not gonna get a whole bureau because you never do for that kind of a project. But if you have one or two people who really cares about that and has some time they can put in and put in their 20% time then that will also probably be good enough. Yeah, I agree. I think we consider kind of CNCF as kind of that bureau or like that larger body associated, but yeah, the number of like people involved like is smaller. And I think that's why yeah, we're going to CNCF to say or to ask for help in like generating these roles or in some cases like just advice for like documentation and stuff or almost stuff that could be funded as well if we need that. Yeah, documentation, I think you might be able to get some direct help with because they have staff and a contractor network. But one of the things that I honestly think you need to do is that you are going to need is somebody who can be your interface for CNCF. As in CNCF as a bunch of people and from staff, they're good about fulfilling specific requests, you know, I need an X, but somebody needs to write up that I need an X, which is not, you know, it becomes time consuming if you're a list of things that you need, which it is, is extensive. For a bunch of the projects that are primarily sponsored by Red Hat, I do that and it's a big time consumption, right?  So if you say, you know, hey, our documentation UI needs an overhaul, they need a lot of information on how and what you're actually trying to accomplish. Yeah, we had a little bit of an exercise for that earlier in the year and unfortunately it fell through, but yeah, we had somebody who was interested in doing some documentation, but as contract work, but submitted something through the service desk and basically like the task was work with the, work with the individual to come up with a very specific contract, which, you know, it's kind of out of my expertise in terms of like, I don't know what like this sort of like work contract looks like and like going through all of these like specifics. So yeah, hope with that is definitely, I think, especially like experience with that. Yeah, I mean, like we can in contributor strategy, we can help a little getting it started, but ultimately you're looking for somebody who cares about container D. Well, yeah, I think from the same point of having people come contribute that type of work, not necessarily having to do the documentation, but being able to actually like work with CNCF to like define what the documentation needs to be. Sorry, I need to drop pretty soon, a couple of minutes. So I'm going to drop in and actually give a future attraction in here. One of the things, sorry, I joined late and you know, hello, surprise. One of the things that I'll be working on with the tech writer team is starting a meeting that's available for projects to be able to come in and join and talk with the tech writers and kind of get a sense about like, if we were to be able to have a structure, what would that structure look like? And I think Derek, that might actually be something that would be helpful for you. So watch this space for more, probably like striking out in like September for that. Yeah, it sounds great. Yeah, I figured people will actually care about this, but I'm like, oh, hey, this thing that I've been working on this week, you'll care about. So, yeah, I will now continue to lurk again. Steven is laughing at me for rising up out of the deep. Like, hey, I got a thing. Oh! Yeah. I mean, it is perfect though. No, I mean, it is perfect because like this came to me like Monday and I've been working with the team like through, like, I mean, it's only Thursday here, but being able to like track towards, man, if we were to be able to have a touch point with some of our tech writers, we would have a better sense of what the projects need and what the tech writers are actually here for. Man, wouldn't that be cool? Yeah, I think the frustrating thing about that, that interconnect is that a lot of the times, having to write the documentation is one thing and potentially farming it out is another, but like a lot of the times you are the person in the best position to write the documentation or like dump things out of your head. And yeah, someone without context on the project is not going to be able to do the same level of depth as you will. So yeah, that can be a frustrating time when you have to sit down and do documentation, especially if you hand the task off, because this has happened several times to me recently, if you hand the task off and it's not clearly defined and someone who is not familiar with the area starts doing the documentation, gets to the point where you're like, it's taking me more time to do this review than it would have to actually do the documentation myself. That's one of the things I'm kind of thinking about is what would happen if we put the tech writers in a position to be a better documentation coach? Right, like how do you pair with like the, there's somebody else to be able to help keep you accountable but you don't have to be able to make up the structure from scratch. You can just put in, hey, I know this thing. Well, I think the thing we'd want most from like tech writers, not to go too much into what this meeting is gonna cover, but like when people come in and contribute and then tell us exactly like what their frustrations were, so like we've had people go through this experience and say like, oh, like I got Continuity to work but it was way harder than I wanted it to be and I wrote this documentation for like, here were all my frustrations and stuff and when a tech writer does that exercise, tends to produce really good results as well as show us where we need kind of that deeper technical, like the design and architecture stuff, like that kind of stuff. Yeah, I would definitely expect the maintainers to do but in terms of like those documentations like getting started and stuff like that, like the maintainers aren't the best people to do that because we're not getting started and we don't have a good perspective. So like, yeah, having technical writers go through a getting started and be like, this is what sucks about your documentation. This is what like I couldn't find anywhere. Like, yeah, I think as maintainers we're definitely realized that's on us to like, go and fix that. You mean Kelsey's old Kubernetes the hard way? Yeah, that one? Yeah, a lot. Yeah, go ahead, Josh. Well, no, and honestly the whole reason why he wrote that was to show everybody in the Kubernetes project exactly how hard it was to set it up from scratch. And that that was something we needed to fix. As well as teaching people about the internals of Kubernetes and how the various pieces actually interacted which is an important thing to know if you are going to be an expert.  Yeah, I think part of that is information architecture, making sure that the stuff that you need is actually in the right place. So like what's cool about that repo is, like one, it gives you a very clear disclaimer. I think a lot of people use it as law and they're like, why couldn't I do X? And then it gives you a very clear disclaimer that it's not something that's supposed to be done for production usage, right? It's meant to display some of the building blocks of the project. But what's really great about it is it does aggregate all those building blocks in the same place. So like you're starting to think about that stuff and it starts to push you out into different areas to explore that, as maybe a newer contributor, like I had mentioned this on a meeting and someone was like, I think it was actually, Celeste is one of the technical writers for CNTF. So I'm gonna mention like, well, that's not where I would look, right? So like as a contributor, as a contributor to Kubernetes, like if I'm looking for something, my first step is not to the website. My first step is to like the community repo, right? Which is a totally different ingress point, right? And you may not know about that until you hit the website, but from the website, is there a clear way to get to the community repo? And like, so you start thinking about like how people move through your process and, you know, for like SIG release, SIG release has its own repo for documentation, right? That like we lead you from the community repo into our repo, right? Because we know that everyone who's focused and our maintainers, reviewers, approvers on that content are gonna be living in that repo anyway, right? So like, yeah, I would say think about the experience, think about the maintainers experience too. There are some things that probably frustrate you about your process day to day. Those are things to start writing down to. I would say that I do agree that container, container D is kind of like cloud native API, right? It's the, you know, it's like the indirect module import, right? For a Go project that you're thinking about. So the, I would look to people who are, like if you take dims as a great example, right? Who kind of, you know, primarily works on the Kubernetes project, but also dips into container D because it's a dependency. And see who of those maintainers or who of those like, who of those transitive contributors would be interested in maybe becoming reviewers, approvers, eventually, in your repos. Yeah, we do have dims on board. He's been really, really helpful. I have to drop off, but I appreciate everyone's time. And yeah, I actually got a lot of really good suggestions out of this, so appreciate it. For sure, for sure. All right, thank you. Later. I was gonna go over some of, could we have a bunch of pending documentation PRs that people need to review in LGTM, but we have also lost most of the people who would review in LGTM those. The, so. I would say maybe we just shoot a note out to the list. There are four open right now. Looks like the what is governance one has quite a few comments on it. And just a request to do reviews, right? Yeah, I know that's one that I need to look at and I haven't, because life, but. Same, like I'm like wagging a finger at myself. So like now that the, so I mean, most of my time was like Kubernetes 119 release and that just got out of the door. That little thing, come on, Steven. You can do that in your sleep, right? 18 weeks are, I think our longest release cycle in recent time, so.  Congrats on that, by the way. Yes, congratulations. Thanks for getting that out. You might consider for your own sanity taking a cycle completely uninvolved. Just a suggestion, speaking from experience. It's, yeah, no, I mean, it's, it's masochism, right? Like there's something that I really, really love about the, I don't know, it's beyond the technical, I think that we're, you know, we're starting to really get deep into some real process problems that have existed for a few years that are related to tooling as well and starting to like fix them. So it's steady as she goes for a little bit on that end. I'm like, I'm hoping to kill Anago by 120, by the end of 120. But I think what I love most about it is that they're, it's just like where you see a lot of contributors start, like they get tossed into the fire of the release team and then you're like, oh, now go free and go do this thing over here that relates to it and seeing that happen every cycle is just, I don't know, it's kind of rejuvenating. So, but yeah, you're right. You're probably right. Given that, like you're running for, you're in committee now too. So there are plans depending on, you know, depending on what happens, I have contingency plans, so. You can always come help us with the GONAs. We're trying to, you know, get everything working with Kubernetes 1.16. So if you wanna go back in time, you know. Gotcha, gotcha. So I will say that if you're on, so what's the project called? GONAs, it's the game servers on top of Kubernetes. Gotcha, gotcha, gotcha. So if you're, I will note that we're planning, August 28th tomorrow is the cherry pick deadline and the final release for 1.16 will be September 2nd. Okay, cool. A heads up that. Good to know. It's starting to move out, it's moved to the end of life. Good to know. Okay, the, yeah, but if we can get those things. Review the things, there are. Yeah, get the merch. These are all advisory documents. Yeah.  As long as there's nothing egregiously broken about them, we should just go ahead and get them merged. The, oh, Carolyn and I also tagged you on another issue, which is in the DevStats repo. God. Me or Steven? Sorry, Carolyn's gone, nevermind. Oh. So. Would you mind linking that if it's for me or whoever it's for? No, I didn't, but I'll share it with everybody here, which is just that when Dawn was preparing the contributor health document, we realized that there was a rather ginormous hole in the data supplied by DevStats, which is nowhere is there a graph of your number of contributions or number of contributors. Which seems like a rather major omission and I spent a long time in the DevStats saying there must be something like this somewhere, but there actually is not. Oh yeah, yeah, that'd be really good. Cause she was referring people to the overall CNCF dashboard, but that just gives a current count. It doesn't give trends. There's no ability to break it down into different segments. So, the, and the reason why it's not there is it's not, it was not considered a useful graph for Kubernetes for various reasons. And the, because mostly because honestly we're not, in Kubernetes we're not worried about tracking our overall number of contributions because it's huge. Exactly, and it's usually pretty Kubernetes-centric. Right, and so most of the CNCF project dashboards were just copied as a subset of the Kubernetes dashboard. And I think here we're seeing one area where that is not the correct path. Gotcha. But I want everybody this touches including Dawn and Lori and Carolyn to actually sign off in the definition before Lucas doesn't even work on it. Since what I don't wanna do is create a chart and then have him delete it and create another chart. Just kidding. Yeah. Yeah. It's just always anytime, if you need to request something with DevStats for contributor growth or whatever, always make sure that Lucas knows when you're still discussing something because he will just go and do it. Do it. Yeah, yeah, yeah. Yeah. All right, so do we have, so one interesting thing it's, we don't have time for it or enough people for it, but the conversation about the STO Steering Committee that cropped up on the TOC list, I know that that's, yeah, I think that this is the place to have that discussion. Well, I mean, I'd like to, I was planning on actually inviting people to the governance work group meeting on Tuesday. Yeah. Because it's where we discuss those things. I am just really not clear at this point what Alexis wants because I was like, if this is your whole thing of let's have projects have a steering committee instead of meeting other governance requirements. I'm like, I'm like, I'm opposed to that. And he was like, no, that's not what I want. Yeah, I think. What are you recommending? Yeah, I think. I would just like to know what the TOC wants that I've been wanting to know that for a while. Yeah, I think it was a lot of people just talking over each other in that thread. I think what we want is to have the conversation, right? Is it a good idea? Like, is it a good idea? I think is one of the questions on the table. Right. But didn't the TOC already review the steering committee proposal and vote no? Not in a public meeting, as far as I know. Amy, do you know this? I think we've lost her. She's probably doing two different things. Because I just thought that it had already been resolved that they decided to not. I thought it was in one of the threads where someone had said like, they decided to not mandate it. It is not actually resolved. This is currently an open discussion item. Thank you, pardon. Sorry, I was in mute. So, yeah, I mean, I guess there's two different issues. Number one is, should the CNCF recommend that all projects have a steering committee? That's question number one. And the question number two is, if a project does not have sufficiently varied maintainers, is having a varied steering committee sufficient to meet graduation requirements? So there's actually two sort of separate questions. Yeah, so to me, I think, you know, part of it is I, why would we even look at a steering committee? Like why would we even look at a steering committee if like we were still thinking about what it means to be a maintainer, right? So even the earlier discussion with Container D, you're saying like this is a graduated project, right? And with a lot of potential that are concerned about overall project health, right? And it sounds like part of that path is building reviewers, building approvers. It's the same problem we have in Kubernetes, right? Building, continuing to build those people across the ladder, that's what would seed the discussion for a steering committee in one of those projects. I don't see, like, I think it's like, is it a good idea? Do we have places where we need to fill it with more structure? I think a lot of these projects do not have that requirement right now. So it should not, I don't think it should be a requirement personally. Well, I also like the Istio steering model was done for a specific reason. Yeah. I wrote it, it is, it was designed for, so this will always be my baby. It was designed for, you know, to reflect the fact that there were going to be these corporate, you know, companies that are contributing devs. And here's a spot to ensure that those folks will always have a say in, like, marketing and the administrative ops kind of stuff. So I don't see that being a solution to the diversity maintainer issue. Like, that's, to me, I don't think that a project that had that kind of a steering model would somehow pass graduation if it still was just one maintainer company. Because those folks that are on steering, for instance, I was on Istio steering when I worked on the project. Would I be able to keep the project going if every other maintainer decided to, like, move to an island? No. So, hang on, I know we want to say more stuff but we're past time. Yeah, we're past time. Yeah, so I'll reopen it, but one of the things you should know, Steven, because I know you're aware of this, so we had an entire meeting about this, governance working group meeting about this. And Alexis was invited and chose not to attend. And out of this meeting came our recommendation to the TOC, which is that we said we didn't think it was a good idea to recommend that all projects get a steering committee. It's appropriate for some projects and not for others. And that we recommended against using steering committees to fulfill the multi-organization requirement. Yeah. Yeah, that makes sense. Because our attitude was, if the maintainers all work for a single organization, it doesn't matter who the steering committee works for. Yeah. And it would make it harder for the CNCF TOC to understand what was going on with the project. So, and I'll admit that I have a significant amount of impatience with him specifically because we invited him to discuss it and he was not interested in discussing it. We asked him if we could use his write-up in contributor strategy documentation and he said no. So this is not a dude who is interested in collaborating. I think we should reserve some judgment especially on a recorded call. I think that discussions on the TSE lists have a tendency to get, depending on what it is, has a tendency to get pre-needed. And I was kind of getting ready to pop the popcorn when I saw the SDO steering committee subject lines. I was like, I need to read this later. But overall, I think it is a discussion that should happen here, right? If it's governance, that's cool. If it's us making a recommendation, it should eventually make its way to this meeting or to some recommendation on our repo because ultimately what we're here to do is kind of help the TSE divest some of the energy that they take in fielding those requests, right? Yeah. If you look at the leadership document that we have there, Dawn wrote in her own words, recommendations around steering committees. Mostly it's that it's appropriate for some projects to have a steering committee and a very short version of here's how you would go about getting one, yeah. And I think that if we haven't done it already, we need to make very clear that our discussions and recommendations that we make are exactly that recommendations. This is something that we're, we run into in, we want to help, but we don't want to be on the hook, I guess, for a failure of one of those recommendations necessarily. So it's something similar that's happening with, if you take the Kubernetes working group naming, right? Where it's like, we want to make a recommendation that gets approved by steering, right? And that becomes like, well, okay, now how do we execute that recommendation across the project, right? As opposed to, well, this body of four people decided that we were gonna change all the language in the project and what's going on with that, right? Cause we get a few questions like that and we have to make it very clear, like we are making recommendations that eventually will hopefully get approved by a higher body, right? So I want to make sure that we have a bit of like a lever to step back for my recommendation. Yeah, well, one of the things we haven't resolved is where the TOC approved material is going to live, right? So far we're just putting everything into our own repo with the idea that everything in our own repo works in progress. And one of the open questions that we have open as an issue in our repo is, where are the pieces of material that the TOC approved going to live? And nobody seems to have an answer for that. That's the same thing we have to do for naming too. We're like, okay, we're gonna keep it in this little sub-directory that we have, but like my personal feeling is that it lives alongside the style guide, right? Something contributor guide documentation. So it's very clear that it's like, okay, this is a recommendation that has turned into law or something or the general suggestion for the project. So yeah, it's tricky. It's tricky, but I also wanna make sure like it's not entirely on our heads. Once we make certain recommendations. Okay, anyhow, we are over. I know you'll probably have to run to other meetings and great discussion in general. Love talking with you all. Can you on the flip side? Bye. Later. Bye.


Hello and welcome to the Grand Line, review your source for everything one piece. Last week we concluded a highly destructive journey to take back Niko Robin, but we're not quite finished with this saga just yet as we bored the roller coaster of emotions, that is the Return to Water 7. Return to Water 7 is the 17th arc in the series consisting of 11 manga chapters and 13 anime episodes, so it's quite short considering what we've been dealing with lately, but my god does it make an impact. Unfortunately though I think we need to start on one of the more somber moments of this arc, as well as the series as a whole by discussing the funeral of the Going Merry. It was really touching to learn the story of how Merry managed to set sail and reach any slobby through sheer willpower, and yes a little help from Iceberg. And this is just such a classically straw hat thing to do, even when you're beaten and can barely move to overcome everything and accomplish your goal anyway. Really if it hadn't been already this really solidified in my mind the Going Merry was much more than a simple vessel and indeed a valued member of the crew, which made it all the more heartbreaking when she began to literally fall apart through sheer exhaustion and overuse. And then came the painful moment when it was finally time to say goodbye. Now One Piece is a pretty unique series and one of the reasons why that is, is because it can make you tear up over a ship. Merry has a proper Viking style funeral with everybody breaking down, including most of the audience I would say, but the part that really tugs at the old heartstrings is when Merry begins speaking to the crew directly. And that's kind of that. Beautifully heartbreaking moments that never fails to get me, and even the anime, which I criticised pretty heavily, managed to pull off this moment just as well if not better than the manga. But Merry was never entirely gone because her will is inherited by our new and still current ship, The Thousand Sunny. So when I saw The Sunny for the first time, I'm not gonna lie, I was slightly disappointed because as a ship, it looked really over-designed. But that makes a lot of sense considering it was built by Frankie, a man who over-designed himself. And as The Sunny's various functionalities present to themselves in future arcs, I really did come to love the ship. But just heading back to Frankie, this arc is where he becomes a straw hat officially, and I think it's fair to say that he probably has the funniest recruitment story, whereby the Frankie family had to steal his swimsuit to lure him to the straw hats. There's actually not a lot to say about Frankie during this arc, because all the hard work to make him worthy of joining the crew has already been put in.  And he isn't the only straw hat to have concluded a story arc during Return to Border 7, as Robin's plot is also wrapped up very nicely with her conversation with party-crusher Al Kijie. This whole exchange is incredibly satisfying because it shows us just how much Robin has grown since the first time Al Kijie showed up. This woman has completely transformed into the Robin we know and love today, and Al Kijie himself left us on a rather optimistic note as well, signalling that there is a faction of decency that exists within the marines. Who knew? But hey, speaking of decent marines, we have the pretty damn shocking revelation that Vice-Admiral Garp is Luffy's grandfather. Yep, wasn't expecting that. Furthermore, we have the revelation that Dragon is Luffy's father. Yep, definitely wasn't expecting that. And finally, we have the reveal of the existence of the four emperors of the new world, of which Shanks is one. The info dump in this arc is just mind-blowing, and at the time it did a fantastic job of setting up the future of the One Piece world, while simultaneously wrapping up our immediate storylines. And while I'm here, I also need to mention the transformed Kobe. Now this was a shock because up until now, Kobe had always been that pretty weak-looking nerdy kid with the glasses, but damn, he had a growth spurt. One of the many reasons why I love One Piece is because it takes characters who maybe weren't so likeable, and then puts them through their own often off-screen journey, and reintroduces them into the series in amazing ways. Kobe being the prime example of this, he reappeared stronger, more determined, and even having learned one of the Rokushiki techniques. I definitely became a huge fan of Kobe after this arc, and to this day, I get really excited when he makes his rare appearances in the series. But more than that, Kobe serves to tell the audience that even though we are following Luffy, the rest of this world is still moving. Everybody has their own adventure going on, and it makes the world feel very organic and lived in. Return to Water Seven further graced us with a few key details of world events. On this particular occasion, we were treated to the meeting of Shanks and Whitebeard. Now how often is it that two of the four emperors meet in the series? Apart from that one mention of Shanks being intercepted by Kaido, I think this is pretty much it, because Blackbeard was not an emperor when he stood in front of Whitebeard at Marineford, and the resulting conflict between Whitebeard and Shanks was enough to split the sky open, which was a fantastic reminder of just how far the Straw Hats have to go before they can even dream of competing with the top tier players of this world. And that's a theme that would reoccur in the next couple of arcs actually. Then there's also Ace vs Blackbeard, which was a great fight to watch, because it gave us a glimpse of the power of the Yami Yami no Mi, a very unique devil fruit that we still don't quite understand. And Ace's defeat here actually sets up the climax for the entire first half of the series. It's crazy to think just how instrumental this one event was going forward actually, but it was particularly great to see Blackbeard again, because we hadn't gotten anything from him since the Straw Hats escaped his grasp on Jaya. And while there was definitely something weird and unique in the air around Blackbeard then, his appearance during Return to Water 7 really transformed that into a very sinister aura. From this moment on, every time Blackbeard or one of his crew members appeared in the story, it gave me a very terrible and foreboding feeling that no other villain in the series so far has been able to pull off. Now I briefly want to mention the hilarious name dropping a Fishman Island during this arc. After speaking to Kokora, it becomes clear that the next island the log pose is directing the Straw Hats to is the long awaited world of Fishman and Mermaids. I remember very well just how excited most fans were at the prospect of going there at the time, and it's pretty ridiculous to think about just how close we physically were and just how many arcs there actually were before we would get there. By my account, we have a whole seven arcs between Return to Water 7 and Fishman Island. So yeah, let's not hold our breath for that. Next, we're going to move to another in a series of touching moments this arc presents us by wrapping up the story of Usopp.  And here I need to throw a huge bucket of respect onto Zoro for stepping in and towing the line here. I'm sure that Zoro felt the exact same way as Luffy in regards to wanting Usopp back, but he did make a great point about not being able to trust somebody who can just up and leave the crew in the way he did. He wants Usopp to take responsibility for his actions, as I believe we all did. As much as I loved Usopp's journey in my opinion, he was definitely the one who was most wrong in the situation on Water 7. And after some math, I'll start. Usopp gives us the heartfelt apology that we wanted, which results in both he and Luffy breaking down into tears and a proper rejoining of the crew, which completes the Straw Hats at last. One of the things I appreciate most about this saga is that it follows three major Straw Hats, Robin, Usopp, and Frankie. And despite the grand events that take place, it really is the personal story of these three individuals, coming to terms with who they are and their place in the world, which rather conveniently for all three happens to be aboard the Straw Hats ship. It's writing on a scale that we have never seen before or since, because most arcs in the series follow the struggles of a third party, with the Straw Hats stepping in or if they do focus on an individual crew member, it is the sole journey of that member. And I'm not saying these are bad at all. On the contrary, the writing for these arcs is also brilliant for the most part, but it will never match just how beautifully Oda weaved the personal stories of these three Straw Hats at once during this whole saga. And that pretty much does it for the Return to Water 7. Next week, we'll be leaping into the unknown realm of the Florian Triangle to experience the horrors awaiting us at Thriller Bark. If you enjoyed this video, then please feel free to like, favorite, or subscribe. And please do comment with your thoughts on the Return to Water 7. This has been the Grand Line Review, and I'll see you next time.


In the first film of this series, we examined the basic properties of magnetic cores. In this film, we'll be dealing with three types of core transfer loops. The single diode transfer loop, a split winding transfer loop, and the inhibit transfer loop. The simplest of the three transfer loops has already been described. The single diode transfer loop. In the single diode transfer loop, we assumed that both cores were initially in the binary zero state. A non-dot input pulse switched core A to the binary one state without affecting core B. Later, a dot pulse applied to the shift winding cleared core A back to zero. The flux change in core A produced an output there. The pulse traveled along to the input winding of core B, entering it on the non-dot side and switching core B to binary one. Thus, at time t zero, we stored a binary one in core A. And at time t one, we transferred that binary one to core B. The selective isolation of core A from core B was achieved by placing a unidirectional device, the diode that gives this loop its name, in the circuit. The diode allowed current to flow in the circuit in one direction only, into the non-dot side of core B's input. But we can work many variations. For example, we can turn the diode around. Now the situation is reversed. Now the diode will allow current to flow around the circuit in the opposite direction only, into the dot side of the input winding at core B. To demonstrate the loop as we have it here, we'll assume that both cores are initially at binary one. A pulse is applied to the dot side of the input winding of core A, switching it to the binary zero state. The change in flux in core A induces an output on the dot side of the output winding. But the diode stops the flow of current in this direction. Core A now holds a zero. Core B remains as it was, at one. However, if a non-dot pulse is applied to the shift winding of core A, it switches the binary state there back to one. The change in flux induces an output in the direction the diode allows. This pulse enters the input winding of core B on the dot side, and core B is switched to binary zero. In effect, we have transferred a zero physically from one core to the next. We have used the single diode transfer loop two ways. First, we were storing a binary one in core A and transferring it to core B. Second, by reversing the diode and changing the input to and the transfer from core A prime, we used the loop for storing and transferring a binary zero. And in both cases, the transfer was physical. That is to say, it was done by producing an output pulse that switched the next core in line. And in both cases, we were able to control the time of the transfer. The input pulse at time t zero placed the bit in storage, and it was held there until the shift pulse at time t one transferred it. The single diode loops have many applications in automatic data processing systems, but there is a limit to the amount of control they provide. Suppose, for example, there were several inputs coming into the first core of a loop. In this way, there are three inputs here. The one at the left will set the core to binary one. The top and bottom inputs will clear it back to zero. And as the diagram indicates, whenever the core is cleared to zero, an output occurs. Switching core B to one, but this means that either one of the dot inputs can bring about a transfer of the bit from A to B. The bottom one or the top, tighter control is frequently necessary. We may want the shift to occur only when the bottom pulse is applied. That is, we want the transfer of information to be conditional. As the diagram shows now, the other two inputs can be used to switch core A back and forth between the binary one and the binary zero states. But an output will occur only under the condition that a binary one is stored in core A and a shift input is applied at the bottom. Let's put the time symbols in the sequence we want. We should have the dot pulse at the top come in at time t one. If this pulse is applied, it kills the binary one that had previously been placed in the core. That is to say, it resets the core to zero without providing an output pulse. The shift pulse comes in at time t two until the shift pulse occurs without the occurrence of a kill. There will be no transfer of information to core B. The circuit we have here is the second of the three we are considering, the split winding transfer loop. This logical diagram explains what it does. But we'll need a schematic diagram of a split winding transfer loop in order to see how its work is done. Start with core A. We'll add two input windings first. The input on the left is connected so that the current flows into it on the non-dot side only. This is the one that our logical diagram showed as coming in at time t zero and setting core A to binary one. At the top, current comes in on the dot side, setting core A to binary zero and the time is t one. There is also an output winding at core A. And like those in the single diode loops, this output has more turns in it than the input windings have. Two diodes are used in the split winding loop. As you see, they're placed so they oppose the flow of current coming from either side of the output winding. Finally, we'll put an outlet into the circuit between core A and the lower diode. We'll call it point Y, and it will serve to conduct current out of the circuit. The reasons for all this will be clear after we set up core B. First, we'll wrap two small windings around core B, an upper winding and a lower winding. The polarity is the same in both cases as the dots indicate. The two small windings are joined together at point X, and this gives us the split winding from which this loop gets its name. All that remains is to connect the split winding into the circuit and provide it with an outside source of current. Before we go into the complete operation of the loop, let's see how the split winding itself works when a pulse is applied. The current travels up to point X, where it divides into two branch currents. The upper branch comes into the dot side of the upper half of the split winding, producing a negative flux in the core. At the same time, the lower branch of the current comes into the non-dot side of the lower half of the split winding, and the result is a positive flux. If the two branch currents are equal, then the two magnetic fluxes will be equal and cancel each other out, leaving the core in whichever state it was initially. But if the branch currents are not equal, then one or the other of the magnetic fluxes will prevail. One more point. The pulse we've been applying is the shift pulse for the loop, and its time designation is T2. To demonstrate the operation of the split winding transfer loop, we'll clear both cores to binary zero. Now we'll apply the three input pulses in sequence. At time T0, a pulse comes in the non-dot side of the left winding, and core A is switched to binary one. Ordinarily, this switch would produce a pulse coming out of the non-dot side of the output winding. But the lower diode prevents a flow of current in that direction. Core A now stores a binary one. Core B has not been affected. At time T1, a pulse is applied to the dot side of the other input winding of core A, switching the core back to zero. Again, the result ordinarily would be an output pulse on the dot side this time. But the upper diode stops it, and nothing happens at core B. With both cores at zero, we go on to the next step. The shift pulse at time T2. As we saw before, this current goes to point X, where it divides. And the branch currents enter the two halves of the split winding. The upper branch current comes out on the non-dot side of its half of the split winding. The lower branch comes out on the dot side of its half of the winding. And both of them move along to the diodes. The diodes conduct in this direction, and the two branch currents flow toward core A. But the lower branch does not get there. Instead, it flows out of the circuit at point Y. The upper branch, however, does reach core A, entering its output winding as a dot pulse. Since core A is in the binary zero state, that is, its magnetic flux is already negative, an additional pulse of dot current will have no practical effect on the core. There is a counter EMF induced in the winding when the pulse is applied. But because the change in flux is so slight, the counter EMF is negligible. As a matter of practice, however, a small coil is inserted into the lower connection to provide a counter EMF there that will balance the counter EMF in the output winding. Therefore, the upper branch pulse meets no more impedance than the lower branch does. The impedances are equal, and so the branches are equal. At point Y, this upper branch current joins the lower branch and flows out of the loop. The result is no change in either core. Core A remains at zero because the upper branch current is applied to its winding as a dot pulse. The upper and lower branch currents are equal, and therefore core B also remains at zero. Because equal currents there produce opposing but equal magnetic fluxes, which cancel out. So far, we have not transferred information from A to B. We need to make a change in the sequence of inputs. Again, at core A, we'll apply a non-dot pulse, T zero, switching the core to binary one. But this time around, we'll skip the dot pulse at T one and leave core A at one. Then the shift pulse is applied. To understand what follows, we must look at the output winding of core A. With the core holding a binary one, the residual magnetism is in the positive direction. The upper branch current comes in as a dot impulse, a negative magnetizing force, and switches the core. But as one result of the complete change of flux, a large counter EMF is induced in the winding. The impedance, now presented by the output winding, is high. In fact, since this winding has more turns in it than any of the others, the impedance here is the highest in the loop. Its effect on the upper branch current is to make it smaller throughout its course. Let's go back to the moment when the shift pulse was applied. The current divides at point X, but in this situation, it divides unequally. The upper branch current is relatively small. The lower branch is large. The upper branch current working alone is able to switch core A from binary one to binary zero. At core B, however, the upper branch is working against the larger lower branch. And magnetic fluxes that result are also unequal. The weaker negative flux is overcome by the greater positive flux, which switches core B to binary one. To summarize the operation of a split winding loop, we can switch core A back and forth without affecting core B. But when core A stores a binary one and the shift pulse is applied, the one is transferred to core B. And all of this is shown in simple form in the logical diagram. Incidentally, to illustrate the split winding, the shift arrow is placed here at core A in the logical diagram and not at core B. Because this shows its function to clear core A back to zero and at the same time put a one in B. The third transfer loop, the inhibit transfer loop, is really a variation of the split winding transfer loop. It offers the same kind of isolation between the sending and receiving cores plus an additional means of control over the transfer. We'll need only two inputs to core A, the input pulse that switches core A to binary one and the shift pulse. But we'll be using three cores. The third core, C, has its own non-dot input and it shares the shift pulse with core A. If core C is at one, the shift pulse will clear it back to zero and the change in flux will of course produce an output. But this output from C serves a special purpose. Whenever it occurs, it will prevent or inhibit the flow of current from core A to core B. And this action gives the loop its name, the inhibit transfer loop. In order to transfer a binary one from core A to core B, three conditions must be met. Core A must be at one, core C must be at zero, and the shift pulse must be applied. In other words, assuming as usual that the three cores are initially at zero, if there is a non-dot input at A and no such input at C, then the shift pulse will transfer a one from A to B. But if the input does come in at C, there will be no transfer. Schematically, this loop resembles the one we've just been studying. There's the same split winding arrangement to which the shift pulse is applied, the same diodes, placed so they oppose the flow of current out of either side of the output winding, and the same outlet connecting into the loop at the non-dot side of the output winding. The differences are all on the left. We won't be using the same kind of output winding. Core A has to be moved up to make room for the third core. These two, A and C, have identical input windings and identical output windings. Now the output windings are unique. Their dot sides are on the right, facing core B in both cases. And their non-dot sides are joined together. We extend the Y outlet to meet the common non-dot side, connect the dot sides into the circuit, and our schematic diagram of an inhibit transfer loop is complete. Notice that each core is isolated. Core B is not directly affected by what happens at A or C because the diodes oppose the flow of current from A and C. The diodes also isolate A and C from each other. A change in the flux of A will not produce an output to C because the lower diode will not conduct in that direction, nor can there be an output from core C up to core A because the upper diode will not conduct. Only one kind of transfer can be made in this loop. It will occur when a shift pulse is applied to the split winding and divides unequally into a small upper branch and a large lower branch. This is very much like the split winding loop itself, but the inhibit loop has a different way of making the branches unequal, as we shall now demonstrate. All three cores are cleared to zero. A non-dot input is applied to core A, switching it to binary 1. And for our first operation of the loop, core C is also switched to 1. Now the shift pulse is applied. And the question is whether the branch currents into which it divides at point X will be equal or unequal. The answer depends on the impedances they encounter. Look at cores A and C. Both are at 1. In both, the magnetic flux is positive. Both output windings receive branch current on the same side, the dot side. And the windings themselves are identical. Consequently, the impedances are equal. If the impedances at core A and C are equal, the shift pulse will divide into equal branch currents. At core B, the equal branch currents set up equal but opposing fluxes, which cancel each other out, and leave the core at binary zero. At core A and at core C, they come in as dot pulses and switch the cores to zero. The two branches join at point Y and flow out of the circuit. Thus, the shift pulse cleared cores A and C, but it was unable to transfer the one from A to B. To achieve a transfer, we'll apply the input to core A, but not the input to core C. This switches A to 1 with its flux in the positive direction, leaving C at zero and its flux negative. A dot pulse entering the output winding of A will meet a high impedance, but the impedance at C will be low. Under the conditions we have here, the binary one in core A can be transferred to core B. When the shift pulse is applied, it divides unequally. The upper branch, which comes up against the high impedance at core A, is small, the lower branch, which has only the low impedance at core C to overcome, is large. The result at core B is the same as it was with the split winding loop, a weak negative flux and a strong positive flux, and therefore B is switched to the binary one state. The upper branch current clears core A back to binary zero. The lower branch has no practical effect on core C because it is already at zero. And again, the branches rejoin at Y and flow out of the circuit. In this operation, by keeping C at zero, we were able to transfer A1 from A to B. Would the reverse be true? Suppose we kept core A at zero and put a one in core C. Would we then be able to transfer the one from C to B? No, because the impedances would be reversed. The high impedance at C would result in a small lower branch current, and the upper branch would be large. The upper branch enters the split winding at B on the dot side. Therefore, B would stay at zero. The function of C in this loop is to inhibit the transfer of information from A to B when the inhibiting action is desired. The three transfer loops we've been examining, the single diode, the split winding, and the inhibit, have an amazing number of applications in automatic data processing equipment. One device that is widely used is just a simple extension of the single diode loop. Four or more cores are strung together in a series of single diode loops. The shift pulses are alternated. That is, one pulse serves cores A and C, and the second pulse serves B and D. This is a magnetic shift register, which provides a temporary storage for binary information. Here's how it works. At time t zero, an input pulse applied to core A places a binary one there. The first shift pulse at time t one moves the bit to core B, and the second shift pulse at time t two advances it to core C. We now have one bit stored in the register, and we can store another one by applying an input pulse to core A again. The capacity of this particular four core register is two bits, but there are registers that can hold as many as 50 bits or more at a time. Essentially, a register accepts information when it is available and delivers it when it is needed. Two rounds of shift pulses will send the information into the output from core D. There goes one bit and there goes the other. A magnetic shift register can act as a speed buffer. For example, it can receive information from a relatively slow source, like a teletype writer operating at standard transmission speed, and then deliver it to a device that operates at high speed, like a magnetic drum. We've been looking at a serial register. It handles information serially, one bit at a time. But registers that work in parallel are put together by combining split winding loops with single diode loops. In fact, almost all the functions of control, logic, and arithmetic are achieved by using these three loops, singly or in combination. They have many advantages. They are small and lightweight, so that a lot of them can be put onto a circuit panel. And they are rugged. The single diode, split winding, and inhibit transfer loops are, in a very real sense, the building blocks of an automatic data processing system.