So this is the Media Wiki Stakeholders Group meeting here. As it is an open meeting, I think we do more like a QA, talk about what we're doing and what's all of this about. So there is no set agenda for this. What I did was I prepared three slides or four just to give you a brief overview of what Media Wiki Stakeholders Group is and what we do. And I see some faces I haven't seen before. So I think if you have any questions about the Stakeholders then this is the right place to ask them. And of course, we want you to get involved with us. So the question or basically what is this user group about? It is not responding to me. So that's taken from the website. So we are a user group, which means we are some kind of formal entity within the Media Wiki Media Movement. And we target, or most of our members are developers, system administrators, consultants, hosting providers, anyone who's involved with working Media Wiki outside of the foundation. So for third parties, which is the term we want to somehow avoid because not sure what is the second party or the fourth party or the first party. So it's basically we're targeting anyone who uses Media Wiki outside of the foundation's context on no Wikipedia and no Wiki source and stuff. Having said that, of course, we don't exclude people who also work on these projects. The opposite, we very welcome all of them. And so our goal is to improve the situation for these people. I helped them work Media Wiki, do a bit of lobbying also that the relevance of Media Wiki as a software product is recognized in the media world. We work on like campaign clients, rewrite extensions. And yeah, so there is quite a bit of scope we have. In short, we want to be a point of communication and coordination among Media Wiki users, meaning people who run Media Wiki. So that's a bit of a confusion sometimes. We are not specifically targeting anyone who is in touch with Media Wiki somehow. It's more about the issues of people running these systems. We want to coordinate different groups of Media Wiki developers and operators. And I would say more about that later. So also we want to foster and create an ecosystem around Media Wiki so that extension developers have an easy to contribute their extensions. If we try to work on stuff that targets especially these people, so that is not related to Wikimedia so much. So for example, we work on a thing called Adopt Integration or Adopt Authentication, which is not the main mission of Wikimedia, but a lot of Media Wiki instances out there use it to connect the user base of their organization to the user base of Media Wiki. Facilitate implementation of Media Wiki features, improve documentation, and contribute to the development of Media Wiki. All of this is what we intend to do, what we do in parts. The group is still growing, so this is like our mission. Maybe to show you a little bit of what we did in the past. So a few years ago, we conducted a Media Wiki user survey asking people how they use Media Wiki, what they expect Media Wiki, what the pain points are. Mark, thankfully, took over the maintenance of the API. So that has moved to the cloud services now. It won't be soon. It will be moved to cloud services soon. And yeah, so since the original maintainers, if I'm informed correctly, did not want to maintain it anymore, so we keep the service open. We do tracks and conferences. We do also conferences. So for example, we had this fantastic Media Wiki track in the Vienna Hackathon, but also the Enterprise Media Wiki conference in Houston this year. And I guess one of the things that's also a achievement of the group is that we have a good network right now. So the network is growing. And we have members of the user group that are in various positions of our stakeholders. So there are members of the foundation who also participate in MWStake. We have contributors from large enterprises. We have small businesses. We have consultants. We have volunteers, of course. And that's so obvious. I didn't put it on there, but I should for documentation purposes. So it's not only targeting professional users, as in people get money for using this. But of course, also people that use Media Wiki for their action groups, for their pet projects, for NGOs, for any kind of volunteer-based stuff. Currently, I think these are the most prominent projects. We see that this is not a full list. And I hope I did not miss anything. So one is, as I said, we are trying to get people together to do a standardized way of dealing with adult authentication. Probably that's going to be extended also to the summer at some point, because that's the new hype of authentication. Because we feel that this is a need, and we've seen a lot of separate efforts. And one of the things we want to do as a group is to combine efforts. So for two reasons. First of all, to save effort, of course, because there is like 10 entities trying to solve the same problem. That's just a huge waste of time, ideally. And second is to find a unified way to do this and find a good way to do this. That is sustainable. And we work with future MediaViki versions as well. Another project is MESA, which is a MediaViki deployment tool. And alongside that project, there comes a unified MediaViki installer. So we're working on improving the installer of MediaViki, especially in the light of the new setups, where you have a lot of services. You have to set up when you want to run MediaViki. So trying to make it easier. And I put one here, because I think that perfectly fits into the mission of what we do. That's the new privacy law in the European Union. And we're currently trying to find a position of how MediaViki relates to that GDPR. And that would probably help a lot of people out there using MediaViki in their organizations. So how can you get involved? I guess the main entry point, if you want to get in touch, get involved in what we do is go to mediaviki.org and MediaViki stakeholders group. You don't have to remember all of this. There is a simple solution you can search for MWStake, which is our short abbreviation. And you will be redirected to that page. So MWStake is what you want to keep in mind. And here you see a lot of entry points. You see a list of current projects, not updated for the GDPR there. You see the communication channels. And that's probably one of the things that are a bit obscure about our group. So we don't go to the mailing list so much for, I think, historic reasons. It just so happened. And we try new methods of communications. We had a select channel before. Now we are on Riot. And a lot of the project work is done on the Riot channels here. That's what you might be interested in. There's a high frequency of contribution. So we have several conversations a day on these channels. And that's also the point where people get connected. So on these channels, we have the multiple stakeholders I talked about. So there are people from the foundation. There are people from large enterprises. There are volunteers, and they all work together and try to solve immediate problems or issues.  It's quite easy. I have to do, I do this. It's not hard because we don't have any finances involved yet, so we just can compile a list of things we did. That might change at some point. Yeah. So apart from these lists on Riot, there's also a monthly meeting we conduct, which is done. It's a video chat session in a system called Blue Jeans. That's not hard to set up. You just follow a link, and then it opens up. Because Chris always sets up the sessions for us. And that is a task on fabricator. I opened it. Now, where is it? How do I do this? So we have, how do I get to the calendar? I can have my video right there. We'll go ahead and do a list right there. Let's do this. So we also have a website, mwstate.org. And there we have the meeting. There is no fabricator here. Yeah. I'm going to zoom to it. It's going to from here. Really? Yeah, well, I'm sorry. You want the. The point is it goes right to the Blue Jeans link at the bottom. Yeah. Click that link. OK. OK. I clicked it. So I'm usually invited by Mark personally. So I don't have to know what the solution is. Yay. OK. That's a monthly task. And you can see the previous and next buttons here. So you can always find the next meeting for this. Yeah. So that is the end of my fabulous presentation of the stakeholders, because I think most of you know what we're doing. And now for me, it's like open. So the question is, for people who are not actively involved here, what would you expect of the group? Do you want to participate? Do you have any pressing issues about media that you want to discuss, which we should tackle? That's also a question. So for example, one thing we are heavily discussing right now is, again, extension management composer. That's also one of the things we try to facilitate in some ways. And there is a session at 7 o'clock tonight. I'm not sure which room it is. But to discuss the extension management or I think they can all post it. Exactly. With sign bar about composer, right? With the sign bar about composer. Well, you've been talking about composer. Yes, I have. We can talk about composer. I think it's right in this room. Is it here? Let's see if I can. Here it is. Here it is. So you only have to stay until 7 o'clock. It's GDBR. Yeah. So this is basically, if you stay here, you are virtually practically involved in the stakeholders.  You said I was interested in the idea of integration. You said it has to be moved forward now. But I also know that for example, I thought of all about form was working on it a bit. What part of integration? From other parts. Yeah. It's the same project. It's the same project. Is there any, what's the schedule? When can we use it? We were just talking about that before this. You're talking about that, right? Yes, sir. Yeah. We were just talking about that. Just out there, Robert and I were working on it. Just now we're trying to merge some changes that I have with his work. I need to deploy it for customer of mine. So there'll be soon. OK, right. So one of the questions about it that I think needs some discussion and socialization is the naming. So there is an existing Neldaq authentication expansion that still sort of works, but it doesn't. My understanding is the issues that it has to do with the single slide on. I think that's no longer working ever since we even did one of the 27 Neldaqs taken. So some people are able to still use some of the single functionality. So one of the, so the idea behind this LDAP rewrite is, first of all, to get a fully working version of LDAP authentication again. But also to create a uniform interface to LDAP services that can be used for querying the directory and to get user attributes and groups, as well as what are the other extensions? So the rewrite of LDAP authentication is on top of my plugable raw extension, which also differentiates between authentication and authorization. So I already have an existing LDAP authorization extension that will work with the LDAP authentication. So this is a complete rewrite of LDAP authentication. So the existing LDAP authentication uses camelheads. And we were thinking of reusing the name, but with LDAP we can categorize. But I do not, but yeah, exactly. And that seems like something that means some community of code just to take over the names. We could take over the name LDAP authentication with the camelheads. All of the other LDAP extensions in this week use all that all of the Facebook. We could also switch them, but the curious and mean things that's wrong, we could just LDAP us all. That's a fact. I could be pragmatic. But yeah, I use the same thing that, you know, just having a name differentiated in the case is completely wrong. Yeah, I agree. No, I would say that doesn't make sense. But if you say the old one is discontinued because right now you wrote the old one and has the old one you maintain it, take it over, but fix the spinning the sex of it. That would be one. But I also want to make sure that existing users of the existing LDAP authentication are comfortable that the new one works for them. They're going to have to change, update their interface. It's going to be different. The configuration aspect of it. And reusing the name means the other one goes away. It's currently not maintained anyways. Much. There's no pact with me. So just as an aside though, the current one is deployed to the Wiccumedia Foundation with you. So it can't 100% go away. Unless the Wiccumedia Foundation chooses to use the new one. And not likely to have had anyone just around to doing that. So this is why I raised the issue because the naming does have all sorts of implications. So the current, the old implementation is basically a patch wrote written rather hastily after the authorization system changed. And I don't think it's really stable in the ways that you can see it. So it doesn't fully support the old extent of the LDAP authentication. It's at least to the standard. It's in Wiccumedia's uses. Yeah, yeah. I'm just saying can't delete the extension. Yeah, right. It's still easy. But the question, I mean, speaking rationally, I think eventually even the foundation should move to like the extension that's even work for us. Hunt, or move to WordPress. Yeah, rewrite in Java. Ideally I can never be using all that. But that's the different digression I guess I shouldn't go into. Yeah, so we can't necessarily deprecate the old one. It's probably not a good idea to differentiate the new one and the old one only by the case of the LDAP, you know. Yeah, because Windows. For many reasons, including which tools like, yeah, I don't know, we'll even. It's fine. It depends if you're using Windows or Mac or Linux. It's Windows. Windows caused a problem. I think Mac actually is case-incessant too. It's case-incessant. Yeah, so whatever case you request is what case you'll get. But what did they do to bring this in for a minute? I know. It's like brain damage. Yeah, so that is not a good idea. But having an LDAP authentication and an LDAP authentication too is not necessarily a good approach either. So. It is better though, because at least in the case which one comes after, it's only maybe one of them gets dropped. I know it gets picked up. And then why is there two? And yeah. I have a lot of negative experience with dynamic page lists one, two, and three. Yeah, I was just gonna say that's the other example. If there's something about it that would actually distinguish it in another way, like how it goes things differently or something like that. LDAP authentication. But does it run everything? There we go. I think we're gonna just solve the problem. You just wanna push your brain. You want my word. To be fair, that might actually be a good solution. Perhaps. The old one's not maintained as a reason like why not to take over meetings and have one and kind of change it. It's a different architecture. Well, there's no reason that we couldn't just write our stuff on top of it. Basically delete all the old files and get and add all the new ones again. But as Brian says, it's a different configuration. And so if the foundation continues to use the old version. Foundation will not be happy if we delete something that currently uses it. Yeah. Yeah. I mean, as I say, but also if no one's maintaining it, I'm sure that they would be happy that someone's now actively attending that extension and you could make it kind of backwards compatible these for a bit and then kind of push it over. You get to talk about making it backwards compatible and working on that with a transition script, if nothing else. That you run a script and it converts from that. Right. And then you don't even need one extension. So that's a possibility.  But I can really affect that one too. Let it go. Let it go. I was really good tech that we're trying to find maintainers and you're obviously invested in LDAP. So it seems like a natural fit. And so the suite of extensions would be the LDAP provider, which is the glue that all of them use. LDAP authentication, LDAP authorization, which integrate political law. LDAP user info, which gives you a query LDAP, get back properties and then LDAP groups, which allow you to assign media wiki groups based upon LDAP group information. Am I missing any? I don't think so, but one reason that I didn't want to continue maintaining the old one was because it is old and it has grown and evolved organically, that would just, there's a lot in there. So while I often advocate taking over other projects and maintaining them, this is one case where I'm like, this is too much, not everyone cares about groups, for example, and so why should they pull in the whole, all of that code? Yeah, so it's easier to document and set up if it's split up a little bit. Also extensibility, so if you do integration projects, more often than not, you come across things that are not foreseen by the extension. So I don't know, a user wants you to put the organizational unit they have in the LDAP information on the user profile page. And it's rather hard to extend the old extension because of its architecture. I'm not saying, I mean, it's a very good piece of software or it was at the same, and my name was one of the best developers we had around here. But since like five years, the architecture of PHP or the state of the architecture has evolved. It's no longer a state of the art. It's a lot of spaghetti code. And authentication infrastructure within the user. The infrastructure has changed and now it's way easier to move forward to move forward by rewriting instead of improving it. Yeah, I just, this is kind of like, this is one of these things that seems like a vicious cycle of like we let something get old and then we rebuild it and then we don't get people to migrate and so we just keep building up, building new versions of things. It's like, you know, eventually you have to like build it and not build it. So I think that, I think migrating and reusing the old name would be great. What I'd want to do though is go through a beta testing phase to make sure. And so the question is, does anybody here, you know, we certainly know that it's used within the foundation. Does anybody else use LDAP, for an LDAP authentication that would be willing and interested in testing for you? I can do it. Well, you and I already have done, you know, and I already have it, I have an instance that has to do with the foundation of that. Oh, that's Cindy, we will. For anybody who has a, would be tech account, can log in after the test for you. You can, like, develop as a branch if you really want to actually take over the extension like you first have it as a branch and eventually place it past your tech account. If whoever wants to continue using version one and maintain version one, can you? You could have us leave on the branch and we then work with the auto branch and we need to release it. You don't have to. Yeah, that's the right answer. You can leave that yourself. I couldn't leave the answer, that was before I asked it. But. Ah. Yeah. It kind of depends on how the foundation updates the extensions to the variables and branch spaces. Like, when we, we don't use the release branches, but we do make, every week we make a new branch based on the master. But I don't think that's written in stone in the past. There was like central to this recent section at one point. Like, I think there have been exceptions in the past where I've heard a lot of people be like, yeah, maybe it's going to be a branch or something like that for the master. It sounds like it's a problem that's coming up, but yeah, I guess I have more branches in the description. Yeah, I'm sure it's like a two line shell structure. Yeah, I think it's the thing that comes up. Yeah, the idea was like, if this piece is actually a new branch, is it basically a new branch? Yes, ma'am. So that would be relatively easier. So if we can test. Then what do you need to do, Germany would probably use this as well, actually. I don't know what you're thinking about it. So we know somebody who can tell us what that's that.  But it could be actually testing. I assume they use it. Yeah, so that's where I'd really like to go with the stats is to try and have it test just as widely as possible. Any other? Great, so which one is the old one? LDAP authentication, capital L. And what's LDAP authentication plug-in? Or is that the old one? Or is that something even? Yeah, I don't even know what that makes sense. Which is unfortunate, because if I want to call it a little LDAP authentication, if there's something already called LDAP authentication plug-in, that's sad. Delete it. Just read your KOS link, you can see if anybody complains. I think the new one should replace LDAP authentication. There's lots of words in English that offer that, which are really important. That's LDAP authentication flow. LDAP authentication may be changed. Yeah, I do think it gets confusing when you have too many extensions that do the same thing with slightly different names. It does. Like SimpleSanwell and SimpleSanwell. Or SimpleSanwell offices. Well, yeah, but then there's those people who name their extension after the software that they're using, like SimpleSanwell, PHP. What, how am I supposed to do that? Who would do that? What are we talking about? That's why I would name it SimpleSanwell. That's because SimpleSanwell off is already taken. Yeah. It should have been Plug-BullSanwell. Plug-BullSanwell, you see? SimpleSanwell. Or just Sanwell. Yeah, take it over. Okay, I didn't ask you guys when I needed it. All here's Sanwell and all of you else. Yeah, so that's the one thing is the LDAP. We've got a session on DAPRO, we've got a session on extension management. It would be great to get everybody to join us on Riot because we do chat all the time. Yeah, and have a chat out. Absolutely. Yes, but the audience is silent slack and we're getting rid of Slack. We're getting rid of Slack until EMLU is on a Houston. And yeah, this. And we're also serving as a test bed for Wikimedia because there's no space. Wikimedia will use IRC until it dies. Yes, and there will be a bridge to it, right? It's just that the bridge doesn't work really well right now. No, because if you have it dedicated to it. You have a fine RC channel, so we might be able to use it with you to both spell. I don't think the relay will come to pick things further. That's a point here. So the reason why we are not using IRC is because we want to connect with the outside world. And it's really, really hard to convince someone from the shiny organizational world to use IRC or to use IRC client on their computers. And I guess what Mark said, and we can also serve as a test bed here, I think the migration from Slack to Riot was rather seamlessly quite well. Migration, that was just user migrating, not conversations or anything. Yeah, yeah, yeah, but I mean the switching over for users to the other systems. Yeah, and Riot is not quite as shiny as Slack, but it's more palatable to us. So if non-Chinese users are trying to use it. Here it goes. It's working on, he has a ticket to spin up a Riot server for the foundation so that they can get better throughput tires. Is it really a throughput issue? Like these protocols are actually literally, they literally have one machine for pre-node. Protocol made in like 89 has throughput issues. No, no, it's not, it's not the protocol, unless Riot was. So it's not IRC's fault? No, it's not IRC's fault. Yeah, not at all. It does weird things like, when a new person joins an IRC conversation, it takes a while for their account to be recognized by Riot, and so their messages don't wind up being bridged, and so all you see is one side of the conversation and you're wondering why this person is talking to themself. So, which is really not good. So we have one room that bridges the media wiki L. No, obviously, the media wiki. In general, I actually try to open it so the room doesn't exist. Oh, really? Yeah, I followed the link from the stakeholders page. Well, it was very well-readed to the stakeholders. Media wiki, generalMachis.org, doesn't exist. Oh, I'm in it. I just joined it. Oh, so maybe it's private. No. Media wiki, let's see, let me look at it. It's something I don't touch more. Media wiki, generalColonMachis.org. Oh, no, wait, that's MWStake, general. Yeah, it's media wiki. It's just town media wiki at colon matrix. Yeah, but the MWStake general is a different channel. Right, it is. Yeah, MWStake general. Yeah, that's working. Yeah, the only one that bridges IRC is the media wiki. Just media wiki. Media wiki channel. So maybe it could be that the link here is broken. Yeah, let's see. Yeah, it seems it was broken. So the general part is the media wiki. Yeah, the general part is the general tech channel. But that one's flaky anyways, so I'm not necessarily. It's a wiki editor. I don't have my left about, but Marcus is going to do it. So that's what the general MWStake looks like. I didn't read, so if there's something that's making you laugh, I don't know. I don't know. Pardon? It's the interface. That's because I'm a native German speaker. Oh, really? Somehow. Not really. I speak a dialect, so people, native Germans, don't understand me. So yeah. So yeah, there's a bunch of rooms which you can see listed on the page down there, which I'm beside by. Right, and we'll take off that one after the session. Yeah, we're just going to move the general. People want to try. We might want to put a banner there saying it's a little flaky. But the hope is that once we spin up a server. Yeah. So then you can see that we do have some participants there. The thing about the riot bridge and all that is we are talking with one of the product managers, I guess, at Matrix, and he's very responsive. Yeah, there's a channel that we created there just for communicating. So some of the Matrix developers seem to be, they like this page. Hey, Wikimedia is a big organization. They're using it. Yeah, so I get help. I'm sorry, now you have to pick me up. What's the relation, the connection between Matrix and Matrix? Matrix is a protocol. Riot's the last interface. Instead, XMPP, which was XML, message is back and forth, Matrix is JSON. So it's cool. So it's cool. It's JSON. It must be good. But the other thing that would be great is to have folks dialing into the monthly meetings. Do you want to talk anything about incorporation? Yeah, well, I was maybe a few sentences. I was trying to keep this out as a major thing. But of course, we do have internal stuff in the music group as well. And when it's becoming a formal body, those of you who follow the group know that we have this plan for a few years. And still, it's on our to-do list because without being a formal incorporated, like, leanly entity, we cannot process money properly. So currently, the end-up mistake, as I said, is somewhat money-less or money-runs to private personal. So one idea that, and we're working with Brian, and Brian is a guy in California, and his wife is a CPX, so she can help out with this incorporation. One thing that was suggested was that we designate, because we had this problem with EMW Khan in Houston, that we designate someone to hold an account. If it takes us any longer to get incorporated, then we designate someone. You're going to manage the account. And so join in. WSA cannot be able to hold our money. I'll probably invite it to hold me. I want to hold your money. Yeah, but the deal is that if the organization sponsors a conference like EMW Khan, and there's any funds left over, we would like to be able to park them somewhere in the interim until we have an opportunity. They could benefit the next conference. We could, if there's enough money, have a small hackathon. The work that's going on on MESA, we keep talking about organizing a MESA workshop. So that is one thing, the grant thing. We have been talking about getting grants from the market. Right, Marcus? So I recently could apply for a grant. There's the grant that was the NASA gave that I'm going to be working on, and hopefully WMF will also contribute. So that may also lend us legitimacy. You want to talk about that project as an immersed in project? It's mad. Multilateral asynchronous bidirectional synchronization. It's a media Wiki remote forget. And there's people who are interested in getting media Wiki, a working installation of media Wiki on the space station, for example, that could sync up with Houston. And then there are also people who like WikiFindy, takes Wiki, the Wiki experience, the Wiki editing experience to disconnected places and tries to get them to contribute back to Wikipedia. And right now, they have all that. That's fine, but there's no automated way to sync up. So it's cut and paste and a lot of manual work. So you lose attribution of edits that way. So this would solve that. That's it. Yeah, so NASA's interested in forgetting the copy of both Wikipedia and they're also internally used wikis up on the International Space Station. The first step in that is just to get read-only copies up. But the goal is to, the next step would be allowing updates to be shipped when things change on the ground version. But ideally, you'd also like to have an astronaut who comes in from a space walk be able to update the wiki with information. Because that's what they use their EBA wikis for, is collecting information about how tools are used. So the best example that I can, the IO of how you would update the wiki from a space walk is the Sharks, where they have a catalog of sharp points around the space station. That is not often updated.  And that's stuff that could be critical. Yeah. So the idea to use, to your ideas that you used to get? For the like, basically? To do the synchronization, yes. That's already working. Oh, it's already working. But there's a lot of manual stuff that has to go on. So I'm working on proof of concept that allows you to do it without all the manual stuff. But it is just a proof of concept. So a couple weeks ago, Darren Welch got funding from NASA to fund their work on this space station application. And then. But just a proof of concept for it. I want to make everything, you know. And then Mark's looking to fund his contribution to it. But I think it's fascinating, the wiki funding aspect, that the same technology that could potentially help to synchronize wikis with the international space station can also be used for folks who want to be able to contribute from remote villages. That's awesome to me that the same solution can help those two very diverse use cases. So is it a get repo that the entire MySQL database is in? Or do you have an individual get rebos for each article? Or how are you doing? No, as a matter of fact, it's interesting you mentioned that. SMWCon in Frankfurt, there was someone who had set up individual repos for every page. No, it's not that. The remote is basically, the API client goes and gets the changes from the media wiki API, stores them as revisions in Git. You could actually check it out onto your own desktop and edit the violence in a text editor and then check them back in and then push them to the wiki that way. OK, so Git's just a transport mechanism rather than like. Right. OK. Transporting, it helps with conflict residences. I can't say any conflict residences. OK, yeah. How are you going to conflict resolutions? Are they going to be handled in the media wiki UI? That is ultimately the plan. That is not, you know. So probably from my pilot up, I'm going to say, you know, just accept everything from this side and they win all the time. OK. But yeah, eventually you want to have a UI where you say, OK, well, one thing Darren suggested was we can use templates some more. Are you familiar with Git? How Git's are. So instead of the Git-Git conflict thing, you would say, this put a template around the top part. This is from that one template around the bottom part. This is from us. And then, you know, you could look at them manually and know which one was which. That would be the right category or something, saying that these are the pages that are not conflict resolved. Yeah, I know, it's great. I mean, I often wonder too, I just like this is like, please guys step in. I often wonder about like, since Git is like such a good paradigm, like the developers use all the time anyways, and we are doing like revisions internally, I just wonder if there's like, it's worthwhile considering like, should we change in the entire way that we're storing articles to be more like Git that way, like something like this, you just get for free, kind of, because like, if everything worked internally with Git, like Git just automatically has all these capabilities. You don't have to talk to someone besides me about that. Yeah, I know. There was a discussion on the Logitech emailing was a long time ago about that. And I believe there was some concerns like naively doing that would not be performing like the performant path for Git and perform assumption to Git are very different from performance assumptions around how Wikipedia is used. And especially for, if the idea is extended where it commonly is to have like, everyone working on their own thing and then merging it all together in like a massive distributed manner. I think it tends to get slow when you start having very big results. Yeah, they do.  I'm sure there's a lot of smart things you can do but like that naive approach is, from my understanding, probably not the core goal. But you could probably fix that, right? So you sound like, you know a lot about Git, I might have to ask you some questions while I'm... Well, yeah, I mean, yeah, I played around, like most of my development would always use Git. Like I used Subversion and I hated it. Like eventually everybody started using Git which made everything a lot nicer. Well, that'd be subversion. What? Yeah, just like checking out everything and locking and no one else would be able to do anything, which was like crazy. Oh, yeah.   Ah, true. But it was simple. Actually, what I missed most about Subversion was that before we had the code review, it was just so easy just to put my sheet code in and then it was all good. Well, yeah, but then I did that a few times and got chewed out. Maybe you just, you're kidding me, I was as bad as mine. So should I take this as the final note of the session? We should opt for, we should argue for migrating to Subversion again. Okay. I think we are, we should leave some minutes for the room to change. The only other thing I wanted to mention, briefly, is that we didn't talk too much about, and it can be a future discussion, but Meza, the installer that NASA's working on, the other NASA project. And there is a lot of promise in that, but also a lot of work yet to be done. So that's another project that we've come out of. So how can people contribute this way? There's a Meza room on Riot. Can you explain how it does it in 15 seconds? Ansible. It's a set of Ansible scripts. You've got two minutes, that's not funny. It's a set of Ansible scripts. It started with, and they run on Red Hat and Centos, and we have a project to do a Debian port. It incorporates, you know, they built their stuff. I gave them feedback based on the Ansible scripts I built. It's a picture farm aware, and so very easy to set up and make it, you know, it keeps this partition. You can have shared, you know, global extensions as well as per wiki-initial extensions. The limitation, I would say, at this point is that you still need, it's not for the faint of heart. You know, it's automated, but it's still not as simple as it needs to be to get folks to be able to just, you know, take a couple things and boom, stick that at a wiki farm. They haven't mastered the point and click yet. It's not even close to point and click. So the one thing I'll just tack on to the end of this is over the last six months or so for wiki days and wiki data, we now have a collection of dot images. That's who Lex needs to talk to. You need to talk to him. Yes, we have a collection of dot images. He's your doctor adventure. Perfect. For the query service, the query service of data, media wiki with wiki days and some other extensions which you wouldn't want for wiki days. And it can be as simple as if you have a doctor downloading one file, changing a couple of passwords so they're not the defaults and then just running the command that you have it all set up. And so for easy installation of wiki days, that's sort of the pathway down. Yeah. Is there any? So the thing I was worried about with the doctor and I know it's silly, is gender lock-in? Yes, we get that. Gender lock-in. Start, start, start. I don't know. I don't know. Let's do a couple here. So for example.


Hello, my name is Rich McCabe, I'm a project manager at the Software Productivity Consortium in the area of reuse. It's my pleasure today to introduce Casey King, a project manager at Boeing, who is currently in charge of the STARS Navy demonstration project down in Orlando. Casey is here to tell about the progress they've made on this project and to show how they're approaching reuse in this particular situation. Thank you. Casey? Thank you very much, Rich. STARS is a program to create a paradigm shift in the way we do software to reinvent the whole process to try and make it an order of magnitude faster, better and cheaper. Boeing as a STARS Prime contractor and the Navy as one of the cooperating services with the ARPA STARS program looked at two things. One, they looked at a process that embodied the STARS reuse vision and we looked at one that not only embodied the reuse vision but also its vision for process improvement. The Navy and Boeing found that the synthesis process answered the mail in both of those areas. The second thing we looked for in the Navy is a project that we could demonstrate the benefits of the STARS vision as implemented in the synthesis process. We found that aviation training vehicle systems or what we call ABTS was a particularly right candidate in terms of the maturity of the domain, the lack of risk involved in buying these. We thought it was really time to apply these benefits from the STARS and synthesis vision to this particular marketplace. The Navy designated that family of air vehicle training systems in general and in particular picked something called the T-34, which is the plane that the Navy pilots learned in. Right there you go, a flight training system for the T-34, particularly around teaching instrument, pilots how to fly instruments. In putting this project together we decided to do it in several phases because basically this was a new process for us and we anticipated some risks not only in the technology of training systems but in the organizations involved learning this process. So as a result of this we put together a pilot project that was designed specifically to touch every one of the processes within the synthesis and we go through the process, we produce the work products, we kind of figure out how we did that and then we'd apply it in a broader area. In order to do that in a timely fashion what we had to do was to reduce the kind of engineering burden on this so we could do it in a relatively short period of time and mostly touch the processes. So we took this whole family of flight training systems and we narrowed it down to something we called, at first we narrowed it down to a sliver which was sort of the navigation communications part of a training system and then we narrowed it down even to a finer area which was trying to do the training systems aspect of a radio navigation aid, primarily TACAN and VOR. So what we want to do is kind of capture the commonality across the family of all TACANs and VORs, which are pretty common anyway, not a whole lot of variation as you go from one aircraft to another, one training system to another. We basically have the problem of trying to say there's a radio emitter on the ground and as an airplane flies around it should have a little needle that points back to that radio station and if you're lucky it'll give you not just only the bearing to that but the range as well. So we wanted to simulate that behavior in a little piece of the training system. So that was our kind of pilot activity for what in fact is this demonstration project. We went through all the processes what I'm about to show you are sort of the evidence, the tracks that we laid down as we went through this process and give you some understanding of what lessons we learned as we touched each of these processes and produced each of these work products and some of the things that we'll be incorporating in our next iteration which will cover a much broader area. So the context again this is the STARS demonstration project, STARS and software technology for adaptable or liable systems. Been around for a good number of years as an ARPA program. It's in its own end game now as a demonstration project. Each of the services is paired with one of the STARS Prime. We're paired, Boeing is paired with the Navy and we pick this training systems world and we're focusing in on the radio navigation aids and specifically TACAN and VOR. Now we set this up, set ourselves up with some success criteria before we went into our pilot project so we could actually get measured as to whether we succeeded. We did this all last July, July of 93 and had a review in January of 94 and we checked ourselves off against and our management checked us off against these success criteria. We had two categories of success criteria. We had some explicit ones which were the sort of the technology oriented and some implicit ones which turned out to be all of the management and of course we had the challenges that we think we understood in the process of doing this and a lot of aspects of you know did we did we have a lessons learned process we were doing this just to learn lessons so we had to have a lessons learned process in place before we started it and had to make sure it worked and it did. Of course synthesis is a highly well-defined process with well-defined work products so we needed to check up did we in fact create all of those work products. The ultimate end of the whole process is did you produce yet another process that application engineers could use by the way we probably spent about 98% of our time in domain engineering and 2% in application engineering for this radio navets interesting kind of pie chart where the process is followed as evidenced by did we did we meet all of the exit criteria as we got out and did we meet the we had mixed bags on there we learned a lot of lessons probably around a hundred significant lessons were documented as a result of this and at the end did we produce a working system did we we ran out of time and we we finished the finished the pilot so we did meet our time and budget metrics were a challenge we didn't have what we call a strong metrics process throughout this it developed as we went through what we did collect basic effort schedule cost again the object here was not as this as a predictor of what the effort would be but just as a learn the process so our emphasis were not on this we did do a lot of guideline and detailed process and methods development during this process and that was essentially one of the questions going in is what did you need to decide on and established and in fact this this next chart over here our document tree reuse driven software process guidebook it's this we found we had to develop methods and standards and practices and procedures and if you get a chance you might want to take a look at this is representative of the beginning of a tree that we anticipate will grow as we evolved the domain we didn't have a clear view of what these were going to be going in but we have a much clearer view now I think just to finish off the success criteria a lot of emphasis here on on teaming we took a multidisciplinary approach we had domain experts and process engineers and environment engineers and the challenges of building and working a team that communicated it was the same in our areas as it is for anybody else I think Catherine's point of having to be a level three organization that underscore that several times we tried hard to behave to pretend we were one so all of these implicit criteria kind of dealt with some of those side management issues and and teaming is at the core of all of those this just shows two views this probably a very high level view of the the synthesis process one of the challenges we found is in working with with engineers that were brought on the project without the full advantage of studying and rubbing themselves on the synthesis is that just understanding the two life cycle strategy was a was an essential element and a very difficult element of doing business a new way is almost once you can get the light turned on this as a half I understand how that's going to work and I can visualize how it's going to change the way I do business you can get participation of that that's almost a top level very counterintuitive behavior in this kind of marketplace where you classically have fixed price throw over the wall money goes over the wall one way a trainer comes back the other way and and they're very expensive so so here's the here's the process we went through all of these steps as said we spent 98% of our time in domain engineering and 2% over here because the size of the application and the amount of leverage we were able to achieve and the automation we applied to it just said this now becomes a very fast process that by the way if anything proves the concept of of underlying two life cycles and synthesis and the whole mega programming paradigm for ARPA that proves that you can spend you know if you plan up front and invest okay you're going to get return relative to that investment now the question is that and we won't ask we didn't answer it on this iteration and our whole demonstration project is supposed to answer in the question is is the investment here going to get generate return you do enough of them you do them fast enough to have a business case so one of the other things I think that is a we like like like good engineers we sort of blinked it at the management process and so this domain evolution stuff we'll get to that later that's not real important that's really where we missed having the vision of the two life cycle and had confusion as we went down the path by engineers themselves of not fully understanding where this stuff was leading to had we done some better domain planning even for a pilot so our lesson learned was don't go past this it's an essential element or it's not just for your own strategic selling but to to get a shared vision of why you're doing some of these things very differently than you're used to but one of the contrast is you see this complex pattern this is kind of this synthesis process taken down a couple of levels of detail and put in a network it is one could say horrendously complex another could say typical projects you know look like this the whole process if you can stay with me on this we're trying to do is change each trainer development from this into way way over here something that kind of looks like falling off a log a simple trivial process to develop a component of a trainer a whole trainer whatever the case what may be so all the way from that level of complexity to that level of simple simplicity is you know kind of one of the true as we reflected back what did we really do essentially that's what we wound up doing I'm going to end now one of the things you'll see on this wall is is we've got kind of a top slide that said this is what we did and some of the key lessons learned we have what we think is a hope is an example of it and then the work product that we actually used or generated on our demonstration pilot is at the bottom so that's a as we go through the thread here there's one of the thread and this is probably one of the key things that we wanted to illustrate is having done this we then went back and looked at let's pick a small piece of the even the stuff that we did and and look at the notion of commonality which we've represented in blue and variability which we've represented in red so that's the key and how this commonality and variability with synthesis tells us is the heart of a domain engineering effort okay how this shows up in the various work products its relationship to each other and there is a relationship which areas are kind of variability intensive which ones are commonality intensive and just generally understanding how that rolls so that's that as we go through this I'll try and pick up where this thread is illustrated so we kind of divided it for the sake of presentation is domain analysis as you know is the top-level process and domain implementation we kind of put a little seam in here just for illustrating that design which is really under the domain analysis as we kind of considered that representationally as a second part here it helped us understand that I think a little bit better but one of the things we found for example let's start up in the beginning of domain analysis is domain definition the guidebook kind of suggested in its incremental risk of verse strategy of do a little bit and then for a while and go back we found that in this iteration it really made sense to to have very fine grained variability assumptions and commonality assumptions and to keep a record of those domain expert assertions this is where this and later in the decision model but primarily in the variability assumptions is where you separate the domain experts from the fakers from those that say they can but can't we had some experience going back very early in this project is is this is where you put a blank piece of paper in front from somebody and people who are qualified domain experts can fill out that piece of paper can understand they understand their field with enough depth and richness are they under they have the experience of multiple projects they have the experience that knows how to analyze that experience and abstract what was this what they saw our patterns and what they saw as threads of commonality and we are one of the results of this we have a domain engineering or domain expert profile that we are continuously upping the anti on you know it started out with a master's degree and and six years of experience and three systems and kind of inching up to four and six systems we're almost insisting now that people have published something which demonstrates an ability to abstract and a passion to communicate and and to think about you know that trying to find the right level of horsepower commitment talent experience so if we learned anything here and and it showed up right in the beginning of the process the talent for the making these assumptions that characterize the system is where the you really the you know if they can't get past this don't let them because they're probably not going to contribute later down the line they're not going to be the have the kind of insights in domain engineering that you can go out and sell the application engineers even if you if you say I have a policy you will do domain engineering and you will do application engineering if the quality of the domain engineering is not that the kind that would be produced from your real waterwalkers you're probably not going to get application projects to buy it so this whole notion of domain engineering takes scarce resources and and leverages them really comes out in this particular area we found that to be the case and we had some areas where we were very successful it's not that nobody could do it it just it depended upon the the depth and skill of the individual deep skilled individuals were successful to satisfy the results of the assertions they put down in the beginning lasted through the duration those that weren't just never got there so essentially your domain expert this is really where you milk them dry because everything else if you say this is a definitive fine grain statement of variability sure you'll miss some things and you get some things a little bit wrong through all the subsequent tests but the real invention and creativity part comes here we went on from there to the decision model basically the decision model which formalizes those assumptions that's really the heart of this process and we kept going back to it throughout the whole domain engineering cycle and even referred to it to understand the application engineering cycle so we think it becomes a you know sort of a baseline a durable work product that a lot of people are going to reference it's also where you find out if you've got the kind of predictable definable variability that says I can get leverage if you ask the hard questions up here and you get real soft fuzzy answers like gee I don't know how that varies I know it varies but I don't know how the likelihood of getting real high leverage mechanistic reuse is probably going to be low we kind of wired this thing because we thought we could really nail this tack hand and VOR so we didn't we kind of factored out that problem but in some areas we looked like like propulsion in training systems that's kind of a non-deterministic solution I mean that engine works how like that feels like that engine does feel rather than by any definable parameters so so you may have even within a given family you may have areas that are well behaved and lend themselves to mechanistic development and others that you can kind of cauterize and say put your code in here we can't we can't interpret it so anyway decision model the heart of what we did as we said the the expertise and insight first evidence in the the variability assumptions it was really reinforced here that you could define a ties how this variable behave what all the values were for this assertion and of course you want to work on this in in nice little bite-sized chunks you want to package your your decision modeling effort so that you can validate and verify little bits and pieces of it at a time because where you come up with the wrong answer then you've got to go back and refine your assumption so we worked a lot of these in a loop in a tight loop so again saying that that was a key area once you've got this finished you I would not want to say this but your reliance on domain expertise what you can milk out of them cuts down doesn't go away because there are other things they help you with in other stages but the that basic insight of understanding variability you've now got it bottled if you finished that product requirements I guess if there were one area that we felt was was kind of that we had the easiest time communicating it was the least difficult for people schooled in traditional development it was in the product so we just said list all your prior requirements and some of them are going to be conditional so you got a whole bunch of nested if statements in here and had a relatively easy time of relating to that at least at the level that we test that so it's a product requirements of all the phases we kind of went over that the quickest and we think we still did the right thing process requirements we were looking at a very small piece of this so this was not a major area that we had an opportunity to to learn essentially what we use this to do is to take the decision model and kind of say what's the the right sequence to ask these questions what's the right sequence to walk down through what is essentially a tree and cut off prune off various branches as you go as you go through since we were starting with a very small branch of this tack and variability we still have a lot to learn about this but that seemed to be the right thing some other things that probably ought to be begin to understood it process requirements is is some of the what's leader called the presentation paradigm you know how do people actually build this and where does the data come come from and in what sequence are you likely to get it it's one thing to say what kind of instruments are going to be in a given trainer or check that off you know where that comes from but but any kind of delay or dynamics in how needles move maybe a whole another data collection effort maybe a whole another process that tags along behind that your basic decision grouping that you established up here may not may not give you visibility into you just may not have the data at that time so so there may be some other demands of process requirements that we haven't fully understood yet all right essentially so everything we've done up to now that we've called domain analysis has given us a good rich set of requirements we've almost been able to to put our domain experts on a part-time basis they'll they'll show up again when they detail particularly process requirements but we milk them dry for variability assertions and and defenitize those and sequence them in the beginning part of the domain analysis the next part product design has three major components that we we considered architecture component design and generation design we were very fortunate on our project to have what we viewed as a very durable architecture one that part of the team Boeing in particular had a lot of experience in fact we built it for the Air Force over the last ten years and it was essentially as architectures go it was okay and very conventional not very flashy and it kind of packaged all of the functions of a flight training system into some very conventional functional parts it was a functional architecture we had all of the elements of flight station visual systems were separate architecture element physical cues which in trainers are kind of the motion base that then you gives the feeling that you're that you're moving propulsion simulates the effects of the engine the navigation communications piece does radios and radio navigation aids that's the part that we had this little slice so this give you a kind of a feel of what so we did a piece of that maybe maybe about 20 percent of what would eventually be in a total of this and this is one of the smaller pieces of the total architecture so we had this architecture going in a little bit cheating so we didn't have to build our own architecture but one of things that happened on this is we wound up validating that this was a good architecture not only for training systems as an abstraction but it was also a process friendly architecture and that became a much more important consideration because what we were able to do is to divide the work up the work packages that we were going to work on for the rest of domain engineering into process friendly pieces that you could have definable skills and a rational set of team to work on those now granted for the pilot we only had one so but as it developed to be became clear that that was going to be important when we tackled the the full scope of this we actually developed a subset of this architecture for this what we call the slice of the demonstration and wound up breaking it down into specific pieces and and here here you see navigation communications you see tack and controls and this tack and determines self-test which in fact is what all of these strings this string goes for a set of commonality that says there is always going to be some self-test or probably if there's a self-test procedure it's going to be in a package called that and the variability just to recover back here that we've established and says one of the ways that you can that self-test can vary if you have self-test is the effect of the push and hold button or when you push the self-test button excuse me does it self-test cycle just by pushing it or does it self-test cycle as long as you hold it one of the variability factors in how self-test initiation work so we made an assertion about that we kind of defend it ties that as in our decision model we put some conditional requirements against the product that you know if that were a characteristic then it had to do this we said for the process requirements to build one of these things you better ask that question and you better ask it after you've asked some other questions at a higher level and then finally put it in an architectural context of says here's a block of the in system where that's going to fit so that just picks that up and that's the commonality and the red is the variability coming down from architecture and and very closely related to this was the domain engineering notion of component design as a matter of fact one of the reactions and experience bases were that people weren't clear where architecture left off and component began so in some cases people would say boy that's a I thought architecture in the word high level were synonymous but in fact we're finding architecture can be as detailed as you need it to be or as it should be and and that design you making trade decisions if you will probably happened at a much lower level so there's a lot of looping back and forth one of the other things that that that became apparent here and this is just a perception as a result of learning this this lesson you look at this component design if you were to come up close and look at this you'd see a lot of if statements kind of looks like pseudo code is a spraying if it's push and hold do this else if it's this do something else that sounds like kind of processed stuff so we're finding that not only where the lines between design and architecture blurred the lines between process and product became blurred and helping our product domain engineers understand that they weren't designing a product in the classic sense but designing something that had the seeds of process wrapped inside it okay as well as around it what was a significant learning challenge and experience once they they'd overcome that and we'll we'll see that happen in several areas down here so so we had component design now the one area that's it's almost pure process is this generation design you know up till now component and architecture sounds like pretty ho hum vanilla software development so we when you add generation design then you throw the the the traditional mindset for a real loop and and one of the things that that is incorporated under generation design is is something that is it has always been a challenge in software and systems engineering which is to keep mapping between your requirements and solution world but also we you know we've added to that the complexity of mapping variability in both requirements and variability in solutions so this triple set of mappings architectural and component mapping being maybe product or component or commonality intensive and the decision mapping which is kind of variability intensive locks in in addition to the problem solution mapping walks in variability we found this to be an extremely effective treatment we we we had some good people on the project who understood it a lot sooner than some of the rest of us did and we were very happy to this rationalized a lot of the loose ends that had been flapping for us in earlier products because it brought commonality variability requirements and design into one tractable complex but tractable piece so this was a we spent a lot of time looking at this building kind of our own record keeping system to treat this and capture this mapping this seemed to be a very effective mechanism for us and embodied a lot of what we were trying to achieve so commend that you look very carefully at these and put a lot of emphasis on them okay so up until now we've gone through our requirements analysis we've turned the corner and and and gotten a design that didn't look anything like the requirements which is a test of a good design complex system we followed kept the variability commonality thread we've had the product process differentiate and we've you know been able to figure out how many interact with each other and how they are different now we're ready to do serious development in the implementation phase and although they're they're indicated as separate component and generation procedures and we actually had two teams we said oh they're two processes a component process and a generation process we'll have two teams go off and do this they wound up sending each other's lap not able to you know go from hour to hour let alone day to day or week to week working separately a lot of interaction it's probably one of the areas we're gonna have to rethink and work a little bit is how we organize for that because having those maybe having a process somebody with process skills on a team we're not quite sure how we're gonna do this but we probably didn't organize ourselves organize ourselves correctly this is the area where our one of our team members those Boeing's team member on the stars project to put something out there that will be the beginning of hopefully a healthy market of software engineering environments for mega programming and synthesis digital equipment corporation has been supplying platforms and and some of their common data dictionary repository based products Boeing team in Seattle has been working hard to add value to to put in the notion of how to represent this stuff this is the area where we started to use that very extensively we did some use of this earlier but but some of the key things you're gonna see is basically broke this process down into how we loaded the C up with these implemented components and generators or this you know mixture of components and generators so that then somebody could do application engineering down the line here and essentially we kind of cast this using some of the information that came in our process requirements and were designed into the generation procedure to said essentially we visualize that an application engineer when they sit down to build one of these tack hands of the future will sit down and answer a set of questions now the fact that they're not going to build a tack hand as an end product that means that they've answered a whole bunch of other questions beforehand and put it in the context of a training system and the family and named what this training system is so that the heart of this whole results of the implementation for us was this what we call a decide screen now the decide screen is something generated by camel which is Maggie what's camel stand for otherwise knows camel one humps or two one for process one for product so camel is the function that we put into our software engineering environment that essentially takes that decision model as it has been adapted by the generation design and the component design and poses the right questions in the right form at the right time in the right sequence with all the right validation verification underneath it to help capture the variability for an instance so domain engineers build something that will generate a camel screen which is a lot of clips which stands for the sea language inference processor okay which is a NASA public domain tool by the way and so camel sits on top of clips and asks you a bunch of questions a lot of engineering goes on underneath this but for this stage that's essentially the model so so this defines what the screen looks like the output of the screen takes the answers to the question and then builds a a retrieve function this is kind of like an adaptable process that is then executed and split into a retrieve function and then you get some the values by themselves which are used by that retrieve function values coming from the the decide screen and together these values in the retrieve function go get some adaptable code this is the closest thing that we have in our system to a component what people would like to think of a component but if you take a look at this in detail one of the things you'll see is a lot of process statements embedded in here of if one of the values that you got on this screen is this value throw out this code change this value that's what all of this camel retrieve adaptable code package tends to do it's part of the process so one of things you look at this and say that some of these things where there are a lot of variability dots are kind of the process intensive parts of the process and the ones with the the blue pins and threads that are product are the product intensive parts of the process the whole thing together in fact comes out the end as a process this was another key learning element is everybody we had people writing adaptable code who thought they were doing traditional eta coding for traditional components and fan found in fact that they had to think of the process they had to think of the process of being adaptable developing that awareness and appreciation was perhaps one of the more frustrating elements of and and kind of threw them off stride into some coding practices that weren't particularly good stress people whose coding capability was not strong to begin with got real stressed and and almost fell off the log so we had a lot of coaching in here and and as we go through this another time we know we're going to have to do a lot of training and coaching in understanding the nature of adaptable code and why and how it's different from regular code at least in this particular version and so through a combination of roams is our reusable object access method management system excuse me man and it's where all of this stuff kind of resides across the whole family logically there's sort of one repository it's the repository piece of this I think an interesting feature that we found in this particularly looking at other reuse strategies other reuse strategies emphasize reuse librarianship and the notion of browsing and like to keep metrics about hit ratios essentially what our process our mechanistic process does is every time we go to library we get a hit because he went there because a process said go there and go find exactly one and only one product pick it out adapt it you know in in predictable ways and send it to me so some of the metaphors that are used in the reuse community such as browsing and searching and candidate components in this is really the heart of leveraged reuse you know this is where leverage says every time I go to library I get something because I wouldn't have gone there if I wasn't going to get it simple straightforward probably makes it more investment intensive and your investment has to be a little smarter than it otherwise would be but that's real the real payback you don't spend waste a lot of time looking at things you're not going to use and so that gives us to adapted code and and all the things everything up to this point on the top these are files that these processes use and this is a screen that is generated all of this code the make function the retrieve function and the adaptable code is all in in in Rome's to begin with before you do the first amount of application engineering the things that that are created as a result of exercising this process are this decision vector and the generated retrieve file and of course the adapted code so so these are the points that that are transient for this particular system the rest of this is part of the furniture for the family and in fact that the the the process definition for doing all of this that we anticipated was that the amount of time it took to to actually execute this was actually in the order of an embarrassing few minutes setting up some of the context of the higher level questions that had nothing to do with radio nav aids but the radio nav aid part of this 10 minutes 15 minutes that was the payoff for the in this this several months of investment clearly we need to get smarter about doing the front part of this domain engineering so that there's a little less of that ratio but I think we prove to ourselves and to our community that if we spent the time to get this under control we in fact could take this complex spaghetti bowl of a project and reduce it to the simplicity of a well-behaved repeatable defined optimizable process are there any questions we actually got we actually had on this more variability than we had planned it got more complex just the the the variety of ways particularly when you're simulating faults and and in training conditions the number of different ways that some of the even the simplest instruments can behave is that's a challenge we're not sure what the total number will be and whether it will pass over the end but it did lend itself to we could define you know when we found some people at least based on their expertise you can pretty well de-finitize how these things vary and the people who are expert know there are only three manufacturers of tack and and if there's ever another one I'll know about it three years before we have to worry about it you know some of our other experiences that were not part of this pilot but an earlier trial use as I said looked at some of the propulsion areas and said there's this big box and I have I cannot give you a deterministic mechanistic way to solve that but I can bound it for you which is almost as good as where you lose is if you assert there's definitive variability and there isn't then it's surprise time okay if you assert that there is boundable variability you're still ahead if your variability is not definable or boundable those are domains you don't want to do any investment at all in and they're probably not good candidates for this high leveraged a synthesis approach yeah rich the question I'm not sure may put words in his mouth here but I'll ask the question anyway had to do maybe with what happens when you do a variability analysis up early on and then you get it wrong the first time and you get down in the implementation and go oh my gosh I've got some other variables here I haven't taken an account for yet I've got a file an engineering change request or something and go back and expand my domain or do something like that did you have that experience well you know one of one of the things that we had done we actually did two iterations you know I thought it was hard enough to describe one iteration rather than two we actually did this in two iterations in which we kind of got to about here and we learned a whole bunch of lessons such as whoops there's more variability in here or there's different variability or some of assumptions so we jump back reset the clock and start over here and we actually even plan to do that so so in the the overall process there were two iterations and that was kind of how the other thing we did that may be challenging and we're looking to our software engineering environment and it's underlying information model to accommodate is to help us with that because you're right once we get into some of these design we'll get some surprises so part of the challenge on the management side is that you were doing incremental evolutionary development even in the pilot project and of course one of the learning things is is we we didn't see a whole lot of benefit and maybe it was just the people and the perspective but it seemed to make sense we kept these assumptions we want to make these assumptions real definitive so we looped between decision model and assumptions just like we looped between design architecture or design and architecture so so we got to some pairs of processes where we kind of throw the configuration management blanket around the pair where there was particular trade-off between discovery and formal formalizing which is really what that decision model is is a formalizing year insights so it seemed like going back and forth between these pair wise was was a good strategy at the time thank you very much I'm Jerry Turner I'm a software engineer with Rockwell three years ago Rockwell's command and control systems division in Richardson Texas established an internal research and development project to investigate software reuse this project became a synthesis pilot for the software productivity consortium the objective of the project is to institute a reuse driven software development process for Rockwell's command and control systems division this would result in timely lower cost development of high quality reliable software in this segment I will discuss our experience with synthesis and show examples of synthesis work products because the work is proprietary only segments of products will be shown we have developed three domains at Rockwell CCSD the first domain was a communications management and control domain the second domain was the mill standard 1553 B communication domain which is a subdomain of the communication management and control domain our current domain is a message handling system domain before we started synthesis we realized it was essential to establish a foundation of discipline methods and automated tools discipline software development methods incorporated into the domain development process allowed us to produce reusable work products weekly product reviews enhanced communication between domain engineers tools were used to support the adopted software development methods to adapt components and to produce an interactive application engineering environment the methods used were real-time structured analysis a requirements method by Ward and Miller aid arts a design method by the software productivity consortium and departmental coding and documentation standards we modified the aid arts development process to incorporate work products created because we were using synthesis and because we must capture variations I borrowed this picture of the aid arts development process and modified it to show the incorporation of synthesis you can see as domain engineers we began our software development process with domain analysis domain analysis is done prior to other activities and iterations are made to the domain analysis work products throughout the process our experience showed that as we progress through the process the decision model changed the most the other domain analysis work products seem to stabilize our engineers needed a way to manage the changes in the decision model we added to our synthesis work products a graphical representation of the decision model that can be maintained with available automated tools we also added work products to capture variations next I will show segments of work products the synopsis allowed our domain engineers to set a boundary around the domain and identify systems that were in the domain and systems that were not in the domain this segment of a synopsis specifies the systems that are in the mill standard 1553 b sub domain notice bus controllers remote terminals and bus monitors are in the domain the commonalities allowed our domain engineers to specify the requirements of every system in the domain this example shows a commonality our domain engineers begin commonality statements with the word every to emphasize the concept that all systems in the domain must satisfy this requirement the variability is allowed our domain engineers to specify the requirements that may vary from system to system this example shows how system requirements may vary the decision model allowed our domain engineers to elaborate on the variations this example shows an elaboration on the previous example in this decision model segment we show the variations the specific decisions and the mnemonic that will be used for adapting components this is a segment from an adaptable document we added a graphical representation of the decision model to our synthesis work products this graphical representation is maintained with available tools and allows the domain engineer to manage the hierarchy of decisions we captured variations in our requirements model by creating non-deliverable variation data flow diagrams deliverable products will have data flow diagrams on the levels below based on cuffs customer requirements this is an example of a variation diagram we captured variations in our design by showing common parts of the design and introducing it overlays for the variation this is an example of how we showed a design model with variations we decided an interactive application engineering environment was the most attractive to our projects this is a screen from an application engineering environment this environment allows an application engineer to specify product requirements the user interface allows the domain engineer to bound the current decisions and to add decisions as the domain evolves


And the thing that got to me is this, Jeremy looks like he wants to go for a CBDC. He wants USDC to be that digital dollar. I don't think the government's gonna go for that, but I could be wrong. But he talks about having everything collateralized. And this was actually a statement from Custodia Bank. And this is Caitlin Long's bank, matter of fact. And she has to agree here. She goes, look, if we backed everything by dollars, would be okay. And she states right here, the US urgently needs to put in place safe business model for the banks that bank the fast moving industries, like that proposed by Custodia, which is in Wyoming. So that the Federal Reserve does not need to backstop such banks, Custodia proposed to hold $1.08 in cash for every dollar deposited by its customers. And I can see where she's going with this. I can see where Jeremy is right. CBDCs, sure. I mean, I don't think it's gonna work out.