Hello, everyone, and welcome to the July 2023 Hyperledger Foundation financial markets mortgage subgroup meeting. Before we get started, I'd like to express our appreciation to the financial markets special interest group and the hyperledger foundation. I always do this at the beginning because we are very appreciative of their ongoing support and making this possible. As always, please note that this meeting is being recorded and it's under the umbrella of the hyperledger foundation. So we ask that everyone abide by the antitrust policy that we're sharing and the code of conduct. The antitrust policy states that we avoid discussions of specific pricing products and projects. We don't make negative remarks about other companies or products and the code of conduct means that we treat each other with respect, never discriminate and communicate constructively. We fully support hyperledger's policy of openness, equity and inclusion, and for new participants, welcome. And if you'd like, please introduce yourself in the chat. And if there's anything specific or any areas of interest, please include that in the chat and we'll definitely try to include the in the discussion. We'd like to make these meetings as interactive as possible. Here's our agenda for today. Excuse me, James Hendrick will provide an update on developments in the mortgage industry, and we'll discuss AI and blockchain in the mortgage industry. Today we had an introduction to these topics, then in June we had Devon Daly, the chief revenue officer from two, and we delve deeper into it today we have Sanjay Kumar Nishok, the COO from Intane, and he's going to be going deeper into their products and into this project area as well. And we will also have Mark D'Angelo speaking about his latest publication as well. We had not had a chance to add that to the agenda. We always covered the slide in each of our meetings and this is to reinforce that we're all on the same blockchain journey, but we may be at different points along that path. So today's topic of AI and blockchain this is particularly applicable since we're all still learning about AI and blockchain and today's sessions and the ongoing sessions will really focus on education. We want to educate everyone within the mortgage industry about the possibilities of AI and blockchain and to demonstrate the feasibility of both technology using mortgage industry use cases and define potential implementation paths for the mortgage industry. Okay, I'm just going to go through the next three slides very quickly. For those of you that are new to the group or would like more information this slides provide different resources. I'm not going to go through all of those but we do highlight the second one from the bottom. That's the link to our hyper ledger wiki, and we'll go into that in a bit more detail that mortgage subgroup link contains the meeting notes for our group recording some sessions and curated articles in the mortgage industry. These are great resources and we offer them up to you guys to get more educated and to learn a bit more as well. So to access the resources you will need an LF ID. I'm not going to go into how to get those but this slides gives you that information, and all of this is free. In addition to getting that LF ID. This is our blockchain training slide. This is how I got up to speed and blockchain. This is free training that's offered by the hyper ledger foundation, and I highly encourage you to use these resources. Okay, with that I will turn it over to Mr James Hendrick and he'll walk us through the state of blockchain. Marvin, thank you very much and welcome everybody. Let's go jump into the first slide. So you know we're always trying to mix up the information that we give to you guys actually back up one more of them. Sorry, there we go. Yeah we're always trying to mix up you know the information and communications we're getting used to this first link that we're highlighting is actually from CNBC it's a video. Jenny Johnson is the CEO of Franklin Templeton investments. She talks about the two biggest disruptors that we're beginning to see in any industry and those are blockchain and AI and we're hearing this message pretty prevalent out there. She also goes on to state that Bitcoin is the greatest distraction from the greatest disruption, which I thought was a pretty interesting quote. She's not saying that Bitcoin has no value, but she really focuses on how blockchain allows a payment methods smart contracts and a general lender to provide a single source of truth. She comments on how big banks, for the most part still rely on large batch processing overnight, and by having a single source of truth it drives down costs. She goes on to discuss different case studies in various industries so if you're looking for bite size information this is great it's about a five minute video. In addition, CNBC has done a great job of including other videos on the side that all relate to blockchain and AI, and most of them are in five to 10 minutes segments so they're you know very easy to consume. I also want to talk a little bit about crypto and the crypto mortgages. It's been a while since we've actually touched bases on this one. This next article came out of the National Mortgage News. And really what it was talking about is despite you know criticism and controversies talk of regulation, cryptocurrency doesn't appear to be going anywhere. We've had a big mantra that crypto is not blockchain. It's just, you know, application running on top of a, you know, very valuable underlying resource of blockchain. What's still uncertain is where crypto will wind up landing in the mortgage ecosystem. So in previous presentations we've reported on various mortgage institutions that have released crypto mortgage products such as Milo Credit and Moon Mortgage. This article covers those as well and we actually have links in the Wiki and our archive that can take you to information on both of those companies. Some of them are still generating loans while numerous entities actually decided to reverse course. But for the time being the article discusses the role of crypto and home finance really looks like it's becoming a specialized niche geared towards investment purchases. GSEs have expressed limited willingness to improve or move the needle in these cases and policies still prohibit consideration of crypto income in the underwriting process. In addition, there's consumers limited understanding of how the volatile asset can be used in the origination process so advocates of crypto of crypto. Not deterred by headlines such as the bankruptcies of exchanges like Celsius networks and FTX or the wild swings of the asset take for these customers volatility might actually be the draw to these type of products. So Milo Credit CEO, Joseph Rupina, she's quoted as saying, most of our clients that are in the crypto mortgage side tend to be more fluent from a crypto network perspective. You know more to come will continue to see how crypto plays in the market but again right now it's seeming like it's really associated with those that are looking to make investment opportunities and are knowledgeable in the crypto space. Marvel let's go ahead and move on to the next one. So Bank of America is speculating a significant transformation over the next decade fueled by the development of blockchain and asset tokenizations. Specifically the bank points to private permission distributed ledgers and blockchain subnets as the key enablers for this transformation. The tokenization of traditional finance financial assets, you know, basically the digitizing of assets and representing them as tokens on a blockchain is projected to revolutionize how these assets are issued and transferred, effectively reducing costs and inefficiencies while increasing transparency and security amongst all parties. So the bank highlights a crucial point in this article that despite the current regulatory turbulence in the crypto market. It's important to maintain site of the ongoing technological revolution beneath the surface with this underlying technology so great article to see what you know some of the big banks are looking at and how they are evaluating blockchain. And then the last article we've got on this slide. Mark D'Angelo's been writing a series in AI. We've actually got him here in attendance I'm going to turn it over to him because he can do a much better job of summarizing it, then I would ever be able to do. Well, I'm not sure about that James you are very eloquent on this but I started writing this series this is actually a four part series part one was released in May of this year. And it's really focusing not just on the AI technology we discussed that but what about the organization what about the culture what about the consumer and that's often what we forget about in our quest for AI the technology, you know, generative AI with what we have you, and what you have on this diagram on here on page 11 is really the major boxes, you know, and, and, and again in the old world of paper based it automation. We used to look at people process and technology I kind of took that in a different viewpoint and said, What about customer what about the industry and what about the changing ecosystem that everybody participates in, because that ecosystem is very different from the traditional financial approach, and especially within the mortgage arena how that's all changing and becoming more digitally native versus digitized of an automated paper process and so that's what that diagram is. And the four part series basically then part one is kind of the general overview, looking at the various high level value chains from a consumer point of view. And then part two focuses strictly on the consumer part three focuses on the industry and that came out here in July. And part four is coming up here the first of August, we'll talk about the ecosystem and, and you can look at all the pressure points and, and if we look at AI strictly I think it's from an industry standpoint be you in the mortgage or be you in retail financial. But just from the technology standpoint or the, you know, just automating the data ingesting that information, then I think we fail. It would be much analogous to the cyber currency, you know, we, we can go down that path we can chase a shiny object but if we don't understand how it impacts our consumer then I think we have a real issue. And actually we, we brought the mortgage bankers in to talk about this in June. Part of my role is also I am the associate director for x labs which is part of Case Western Reserve University, the Weatherhead School of Management. And, and we brought the chief legal counsel from the MBA and we brought Thompson Reuters in. We brought a AI focused consumer investing startup in as well. And those are available if you want to look at the recordings they're available through my LinkedIn website you can find these articles and, and what have you. But it was very telling because when we were started talking to the MBA specifically on AI and inclusion, you know the pages are being written and I think that's the message is that if we look at this from a consumer standpoint, versus a technological standpoint, and oftentimes we talk about skills and what have you. The idea of ensemble learning and basically AI talking to other AI systems and the impacts, let's say on the mortgage processes themselves the 80 some processes that exists within the industry. And that is a different ordeal a different set of processes a different customer focus, because what happens when AI gets it wrong. What does that do to your brand what does that do to the product center offering what does it do to the downstream effects of securitization and even servicing so these are the types of things we're talking about and I think Marvin's telling me get the hell off the stage. Yeah, but that's really what this whole article series is looking at it from a different viewpoint, asking different questions, and trying to say not one size fits all. Mark. Thank you mark that was not a hint for you to get off the stage there was siren driving by I was trying to hit mute, but my fat fingers hit the wrong button. So, and if you're really interested in this there's a different. I'm releasing a different series and other four part series that's coming out on Reuters media here at this end of this month. Thompson Reuters Institute will actually be part of their think tank. And this will actually then be backed up it's not AI this specific thing again but it's AI enabled regulatory technology so we're taking a specific tech implication and we're bringing in noted leaders from some small names like KPMG and Grand Thornton from the accounting and tech side. So we're looking at it from the transparency the repeatability the art ability of this and so I continuing on this vein you'll see more of this from me in the future months. Thank you very much. Personally, I loved how part one addresses it from a consumer point of view. You get very in depth I love your writing style you're very in depth in your detail but you do a fantastic job of summarizing. I'm actually in the midst of digesting your part three right now. When can the readers actually expect part four to the series. Part four will be out the first week of August. It is the final touches it'll go into the the editors over at the NBA. Probably last week of this month and then it gets into the cycle for print. You can also find these articles like I said on the X lab case Western site they are replicated there as well. And part four will show up probably not the same time as the NBA. So we do do release to try to get as as much eyeballs and much comments and thoughts, as we can across the industries. Fantastic thank you for joining us today Mark and I appreciate it. Marvin. Next slide. Alright and yesterday Marvin and Pavan are the well CEO of Sun West mortgage held a discussion and AI and blockchain and the real estate industry. And Marvin, I'm actually going to pass it over to you. Thanks James, this was a really interesting and exciting session with Pavan. He's a person that I have a lot of respect for that. The man, Pavan is really doing with AI and blockchain what we've all talked about. Making the two work together and providing a seamless and you converting it into what he calls empathetic technology that tries to interact with the consumer in a more empathetic fashion so that it's not as as automated or as dry as what we would expect. He walked the, I gave him an overview of AI blockchain and real estate and then he spent half the call going through a demo of their application called Angel AI. I highly encourage you guys to take a look at it. It really hints as to what is possible with the technology. And we'll provide a link to that as well. I really enjoyed speaking with them and speaking with the audience. Marvin, thanks. It actually was a great presentation. It was very entertaining and yes, I did guess the correct. Wonder Woman article that Pavan was looking for. Oh, okay, okay, great. I don't want to give it away to the group. Okay. Moving on to the next slide Marvin. So just as a reminder, this is our wiki page for the mortgage industry subgroup. We've been doing these presentations. We're actually coming up pretty close to a two year anniversary and about November. So if you'd like to see any of our previous presentations over on the left hand side you'll find links to the recordings for those, as well as the actual presentation themselves over on the right hand side the articles that we've been talking today. We've been doing them. We've gotten archive over the last two years we've gathered roughly around 200 different articles so if you guys are looking for information for research feel free check out the wiki side. Look on the right tab here go over to the archived articles on the left side. And as Marvin mentioned, you know, please set up an LF ID, it's free. And by registering with our mortgage industry subgroup, you'll be getting automated announcements when the meetings are occurring when we're posting new articles, things of that nature. So, Alma was kind enough to drop the link below into the chat go ahead and click on that link and save it as a favorite. And Marvin I'm going to pass it over to you to introduce our guest speaker. Always great information. Next, I'd like to introduce Sanjay Kumar Nishant, the Chief Operations Officer at Intane. Sanjay has co founded to been tech startups. He's delivered multiple digital transformation rollouts of enterprise platforms across the world in the domains of capital markets mortgage retail banking and investment banking. For the last three years he developed a deep hands on expertise and provided services around the technology blockchain AI consulting design solution training and different POC use case implementation so he is very knowledgeable in this area and we're very thankful and appreciative to have him here and to share his knowledge so welcome Sanjay. Thank you. Thank you Marvin. It's great to be great to be here in this platform talking about what we have been doing for the last four or five months and four or five years. Now as you. Thank you for the introduction as well. So we actually so before I go on to, if I can share my screen. And then I'll stop sharing and you should be able to share. So, before I start talking about what we have been doing in the conversing area of a and blockchain within 10 probably I'll just take half a minute to introduce our company in 10 ft was set up around April 2018. So when we started when I and sit hard the other co founder joined hands to sit up a company where we thought that, and both of us, where we thought that using both of the blockchain and technologies we can actually build something industry which we have been working on for a pretty long time so I have, I have close to around, around seven or eight years of experience in the mortgage industry before I started this company said that was said that was responsible so that was the CEO of one of the last ops group of a of a of a large bank based out of India so we thought that blockchain and AI technologies can be used to solve quite a few problems of this industry. So that's, that's where we started in 10 in in April 2018. In the last four or five years we have developed three products. We started with developing the first product which was in ten admin. For that product what we intended to do is, is that we actually tried to get the complete workflow of a of a more case lifecycle and build, build flows on that backed by hyper laser fabric platform. We did once we developed that product we we took around, we took around a year to develop that product. So we actually went to market around August or September of 2019 when we reached out to the large trustees, because we thought that you know such a product can be pretty acceptable or can be sold to sold to some of the anchor players in the industry so as for a small case industries concern trustee. Trustee is is an entity which actually plays an anchor role in the overall life cycle so we reached out to quite a few last trustees. And we are able to reach out to, you know, two of the top 10 trustees in the US, who were ready to use our product. But, but since these are all pretty large organizations and mortgage industry is pretty is old and it's a pretty old industry. So they, they wanted to use only the investor reporting and analytics features of our product and that's where we got started. So, so that that was the first product which we actually put into production like I said we asked. So those, those trustees actually started using our product around December 2019 for for investor reporting and analytics in their production environments. And so they did that then we kept building on the top of that we started realizing certain other issues which we could have, which we could handle using our platform and then we kept building on that. So as I go through the presentations now presentation now I'll, I'll probably talk about how we started and what we kept, kept adding to that. Since the beginning, like I said, you know, both of both of us both the co founders of intense since we came from the industry we actually spend decent amount of around 20 years in terms of providing and deploying enterprise wide applications for the financial services industry. So we always started from the context of what is the business problem and, and what can we do to provide a solution to that rather than actually trying to figure out that hey we wanted to do something with blockchain or AI. And that's why we, we actually had one product and then we kept building, we kept talking to the client and we got some feedback and then we kept building on that and based on that we have, we have now three different versions of the product. And to the extent that the last product the version that we built we are actually launching that as completely a new, a completely different product. So, if I can go through, if I can go through my presentations now. Obviously, we know that, you know, so the initial problem statement was that there is huge amount of money which is being spent by the finance by the structure finance industry. There is a variation on the transaction and the transaction expenses for which are, which were primarily being done using Excel sheets and emails. And as we know that they're close to 12 or 13 entities for a typical structure finance life cycle, which actually is taking the assets right from the organization stays till the time that those assets gets converted into some structure finance instruments they get advanced and they get sold out to the investors, and then month after month. In some periodic intervals, the services keep getting that keep, you know, keep collecting the the installments and then. And the rest of coupon rates, usually being passed on to investors so there are, there are in a close to 12 or 13 entities. Usually takes a takes decent amount of time. And since there are so many number of entities that are multiple systems which are being involved by individual entities in terms of maintaining data in terms of passing on data between different different players. So all of this, but the usually, you know, when we actually get to a structured finance industry the minimum deal size which which gets structured has certain thresholds of which, so which is around $100 million cost of transaction is around one or And the transaction itself gets around takes around 8 to 12 weeks to completely consume it and and the status reporting whereas the investors would probably want the status status of each one of those Francis or each one of those investments to be reported to them on an online basis but it never happens. Even after being even after the installments being collected by the services, the trustee usually takes around three to seven weeks to report on them to the investors. Essentially the problem statement that we started working with is that we wanted to reduce that deal size which can be which can be which can be issued using a platform for around 8 to 10 million. The cost of transactions should be should similarly come down and the transaction timeline can actually be cannot actually reduce even if we will not be able to reduce the use of Excel email and the coordination between different entities, let's say between servicer or between servicer and the issuer or servicer and the trustee. We should be able to reduce the timeline so that was our initial thought process based on which we wanted to build this platform. So like I said we actually started working on this product in December 2018. Sorry, April 2018 and we had a workable version of this product which we called Internet been flow. We actually renamed this product at that time we actually called it just Internet been in production we had Internet been flow in production around December 19. And then, when we took it to the trustees, then there are a couple of other issues that they face or Internet been flow just it encompassed only, only the, only the life cycle where we could take the deals, we could, and then we couldn't, we could on board the assets, meaning the loans. And then we could allow, we would allow the trustee to set up the deal, we would allow the servicer to get the, get the monthly information on each one of those loans into a platform, and we would allow the trustee to generate the investor report and share it to the company. So that's, that was the scope of Internet been, but then we realize that before, before the servicer before the trustee usually on boards that they also wanted to do the due diligence of the individual loans. Similarly, there are, let's say multiple loans, which is part of a single deal they wanted to do the due diligence of that loan. So we built another AI, AI component so that that can be used by the trustee to do the reconciliation to do the digitization of the document do the reconciliation, and they non vote those loans onto the platform. So that was one component that we added where we used AI. So that's that's part of IA is and the second component that we also added that is is is on the loan tip cracker, because usually the trustees work with multiple services, different services, maintain their loan tapes in different sort of formats. But once they get in, get all of those, all of those loan tips into a platform, unless they're completely standardized, it's pretty difficult to, to actually extract those information from the loan contracts. Firstly, and secondly, to actually aggregate all of that data into a single report and share that with investors because investors obviously don't care. You know where the loans are getting originated or how many services are servicing the loan. So that's a second component which we added. So that these two components are being added to IA flow to to form IA is then to IA is then we again realize that, you know, once we have all of these loans, unless we tokenize the liquidity part is missing. So the tokenize isn't part is what we added to IA is to form to form a product called So these are three, basically these are three evolutions of the product that we have had in the last three and four years and like I said, we always just we started with the IA flow where we started to solve a business problem then we took that to the market, the trustees started talking to us about something else. And then we added a couple of more components to that and finally into markets. So in terms of, in terms, so, as far as intent admin is concerned, which is the, which is the platform which we have actually built using hypervisor fabric. So that saw quite a bit of traction as, as we can see from this diagram above so we at the end of 22 we were managing around $6 billion of software structured finance instruments using our platform. And which was being used by a top two trustees, you know, two of the largest 10 trustees in the US so we're managing around $6 billion of structure and streams on our platform. Now, this diagram essentially just, you know, simply talks about how this intent admin takes care of different entities and how the pools are formed but I'll actually go through this as part of some of the demo that I have, which will be coming. The other important part about intent admin is also the fact that using intent admin, we have been able to allow the trustee to codify the payment waterfall rules, which are essentially coming from the intensive documents. So the trustee usually can, can code all of all of those using a chain codes. So we use, so we have close to 75 or 80 chain codes which we have built over the last four or five years to cater to payment waterfall for calculations across different asset classes, asset classes, including residential real estate, commercial real estate and some of the ABS deals. Now, like I said, intent admin is essentially adds this three components to intent admin flow. The one of them is this automation of contract verification which is it, which is a typical function which is being executed by a verification agent in the overall structure finance life cycle. The second one is this payment waterfall automation and loans tracks where usually the trustee or the investor usually demands as far as a particular transaction is concerned, you know, which are the different states from which loads are coming in what kind of icos course people have other borrowers have in terms of the underlying loads, how many, you know, in terms of delinquency status and all of that. And of course, the third component that we have added in intent admin is as compared by flow is the services summary. So, so essentially what we have tried to do is the integral overall integrated platform can actually be used by verification agent for due diligence of the loan documents and this is where essentially we use the AI component to do the dd of underlying loan documents. So this is a long tape standardization, which is being done by long tape cracker. We actually use 2019. We use the smas standards which were issued in 2019 in terms of standardizing the loan tapes. Once those loan tapes have been uploaded by the services data modeling and payment waterfall which is, which is a typical function being undertaken by the thing isn't and like I said, you know, this is being done using chain codes in the high policy fabric environment. Loans for ads and portfolio insights, we have to use another another tool to provide the loan stratifications and portfolio insights as far as a particular deal is concerned, or the different branches of the deals are concerned. And of course, you know, based on all of this we will definitely as if now we do not have any rating agencies as part of any of the platforms, but then we actually have that capability to allow the rating agencies to go through all of this loads, all of the loads and assets. Now these are some of those screenshots but then we'll, we'll go through the actual demo when we, and then we can go through this. The first one is, so this is a verification isn't a screenshot where somebody can other verification isn't a VA can actually go through the digitize loan contract document and then see where there is a match or mismatch as far as the data between the contract document and the elements of the loan management system data is concerned, and then he can make the, he can actually do the reconciliation and enter the edited data into into our platform. Loaded cracker we are based on the asset class and based on the data which is extracted from the, from the elements data which is uploaded by a servicer. We, and we actually provide the standard loaded names, but of course it's up to it's up to the trustee or the servicer. To make all of those changes to the standard piece. Now I'll go I'll go through this as part of the demo. Now this, the screens are just essentially talks about what kind of stratification or asset like analytics that a load a load data isn't can actually view as part of the platform. This is one of the screen which essentially talks about the payment waterfall calculations for a specific deal, which is being done by paying isn't. Okay. Like I said, so the third third product that we are currently working on is adding the token adjacent component to this overall internet platform. But once we have all of this instrument structure finance instruments, they are on our platform, the services are reporting, the trustee is reporting on those assets on those instruments, month and month to different investors to provide liquidity to those instruments And then we will build some additional process flows will build as a medicine company so that those individual instruments can actually be tokenized and they will have some so now essentially Intel markets is a platform which we are trying to build using as of lunch and not hyper as a fabric as of now. So, so that's a, that's, that's a little different system that we are currently building. Now. Yeah, I mean, there are, these are all some of the benefits, you know, one of the important benefit is that is the first point which is we have, you know, since the in the last three or four years we have been trying to build a digital solution, not, just talking about using a blockchain technology to form the solution but digital solution and automated solution. So for that automated solution, whatever is required is what we have tried to build and so initially we thought that, unless we get all of this assets into the platform, nobody is going to actually trust the quality of this assets so which is why we got all of those assets, into the, into the platform and save those into the blockchain, but then we realize that unless somebody can actually verify those assets, there is no point in getting all of those assets from an excellent sheet into a blockchain and that's where we started building the solution so. So the important part is it's a digital solution not necessarily a blockchain solution. So these are, these are some of the benefits that that we have been talking to our clients and which is, which is kind of appreciated by the clients and, and this is why we have two of the top 10 trustees using our platform, you know, for the last two and a half years now. Okay, so I think at this point, I can probably stop for a bit, and then I can move on to do a brief demo of two of the platforms of the first demo that I will do, I will actually go through the internet mean demo, which is just essentially talk about the process flow and how it goes so that can give a view to people about about how it works and the second demo I'll just talk about which, which is this, which is the process flow step where we actually use the AI component. So I can, so I can take some questions right now if people have some something to ask otherwise I'll just start with the demo. Hi, Sanjay, I don't have a question but I do have a comment just the very last bullet that you have on this slide, taking a plumber like approach to building those technology components. I think that's exactly what's needed within the financial services industry specifically mortgage, because that's what blockchain is intended to do, or that's where it's best utilized. So it provides the fights for mortgages and the at that asset related information to be funneled between different entities so I love the way that you worded it and I love the analogy that you provide there. And as a matter of fact, actually, you know, nobody, when we talk to the clients and even the new clients, nobody, you know, people were probably accused with blocks and technologies. You know, I have been, I have been, you know, kind of working with blocks and technologies since 2017. At that point in time people were pretty fascinated with all this but in the last, what I've seen is in the last two years nobody actually cares whether you use a blockchain technology but if you actually give a solution with the fact that hey I am also using blocks and technologies for non reproduced and tamper proof and a golden source of truth and probably that's what strikes with most of the most of that. Okay. So, so this is, now this is the, it's a pre recorded demo so I'll just go through this and I'll probably talk and talk through the demo. So this is essentially the Internet been Internet been flow. So where, so I have already logged in as a trustee as a trustee I will have. So I will have all of this different options it's a dashboard of a trustee where I can, I can add new report I can, I can get a service of data from the, from the store and and so there are two parts, as I said, again, probably I can stop, stop a bit here. I can add when we actually, once we get the data from service or we save that initially we actually save that into a MongoDB as an intermediary database. And then once all the data has already been verified in terms of the services summary by the trustee then we take that data back to back to blockchain. We have done consciously because we know that, you know, in the current system, most of the issuers, or the trustee would have the data existing in some kind of platform or in some, some way, but then we cannot just take that data as is, and then allow those to be saved into blocks as we know, you know, once it goes into blocks and we cannot make some changes, we can delete that. So, so that way we actually use some intermediary database which is a MongoDB and that's where, so we get the data first into a database and then, then to a, then to block it. Okay, so essentially what we do is the trustee has to set up a deal. So there are some, there are some static fields, there are some dynamic fields. So in this, in this demo, so we are showing as to, you know, how many transfers are there for that particular, for that particular structure of finance deal. You know, how many, you know, how many nodes are there, how many types are there. Once we set that, once we set up the deal, then for a particular deal for a month and a year, we actually choose the, we actually choose the LMS Excel sheet, which will tell us about all the loan data that I'm going to use as part of this deal. So, so that's what I will, as a trustee, I'm going to, I'm going to get all of this, all of this data, LMS data into my system. So these are all individual loan related data. So I'm going to first onboard those into, into the platform. And I'm going to onboard that based on a particular deal name and month and year. Once I, so this is where, once I do that, you know, based on, based on the logic that we have built as part of the platform and based on the header names of that LMS, LMS data sheet, we are going to provide some standard field names, which we have already defined. And like I said, all the standard field names, so we have actually taken out of this my standards 2019 is my standards, we wanted to follow certain standards, based on which we are going to derive the codes. So it's, it's going to the system is going to keep all of those wherever it actually finds a match between the header names of the LMS Excel sheet and the standard fields which have already been defined. It's going to, it's going to give you a match otherwise the user can actually add some of the additional standard fields also. I'm sorry Sanjay are should we be looking at the demo now because we're still looking at the slide. Okay, sorry. Sorry about that. Really sorry. Let me just. Let me just reshare my screen. Okay. And now we're at that add a new report screen in entertainment is that the start of the demo. Okay. So let me so with whatever I have already mentioned, since I was not able to share it so let me just quickly in a half a minute. Let me just go through this. So this is the trustee dashboard. So in the trustee dashboard, the trustee can actually add to port and now it can actually define the report it can upload the service of data. And that service of data gets saved into MongoDB and from MongoDB gets it to set into blockchain. That's what I mentioned so this is the dashboard for the services. I'm sorry for the trustee. So now we'll probably go through this demo. All right, so we just trying to show what all the trustee can do as part of the dashboard. When we say view services data from the network we mean the blockchain network, otherwise it's from the database. So before the trustee can do anything he has to set up the set of the deal and that's where you know there are some static fields there are some dynamic fields so he has to keep adding all of this information. First to set up the deal. So this is the setup page. And most of this, most of this information actually comes from the pre placement memorandum of the team. And then the trustee usually selects the name month year and then the LMS data or the actual underlying assets data file from his own systems because so that as part of the onboarding stays. So this is the extension that we are trying to onboard so this has the list of all the all the underlying loan assets which has to be uploaded and which will be included as part of the deal. Once it's uploaded then we need to standardize like I said we use 2019 SME standards to standardize the standardize the load tape. Once we standardize we can actually save it and when we save it, it actually gets saved into MongoDB like I said the first in the first I recently get set into MongoDB. Now, as far as the once we get the LMS data or the underlying asset data on boarded into the system, then we can actually we can get the mapping and then change all the mapping if we want any of the standard fields which has been suggested by the system that the platform is not acceptable to the or is not the right one as, you know, as, as defined by the trustee then we can actually make changes based on that we will get a servicer loan summary so essentially this is where we actually first do a bit of calculation to show the servicer. So in this case trustee is actually acting on behalf of the servicer. So once we show all of this, all of this services summary if that's all looks fine to the trustee then, then he can actually onboard the complete data to the network. And if there are certain other information that he wants to include then obviously he can enter all those details. And so at this point, once all of the servicer data generated services summary data is generated then the trustee report, which is usually mandated in the in the VPN so he has to generate the trustee report. He also has to define each of the investors he has to share this details with so that's where he gives all the investor details to whom these reports are going to be distributed. There are some other changes that he needs to do. All of these changes. So, so this is another section where we actually allow the trustee to customize the report and then add the different sections to the report, we have seen that different trustees have different sections in the report that they want to have as part of the phase one or phase two or phase three. So, this is also another flexibility or configurability that we are providing as part of as part of this report generation. So, once, once all that is being saved and customized then the trustee can actually see the actual report how it looks like. And, and once if and like I said, you know, all of this, all of these details that all of this concentration limit or all of the payment waterfall calculations at this point, you usually get gets calculated using those chain code libraries that we have built over a period of time so there are around 70 chain code chain codes that we have built for different kind of assets for different kind of trading for different kind of trigger events. So, which actually give, give out all of these numbers. So, as of now, all of this data is being retrieved from the from the ledger from the hyper ledger. Once the trustee is satisfied then he's going to publish this report and when he actually publishes this report this reports gets available to the to the investors that he wants this report to be published as he had defined the general trustee report success. So I as a trustee since you guys are using chain code to calculate the interest payments and then all of that lives on the blockchain I can go ahead and see the calculation formula for my portfolio. All of that is is public on the market. Yes, yes. And at the same time it can also be downloaded so we, we understand that quite a few trustees and investors actually work in a PDF mode even now so we have been facing issues in terms of bringing people onto a platform so we have given the choice of downloading all of this in a PDF format and then looking at all that data. So the second part is about. So this is the monthly trustee report, which is generated by the trustee now the second part is about this loan start analytics. And ad hoc way of actually, you know, giving an access to the investor and to the trustee to slice and dice on the data that we have already collected from the elements, Excel, where for a particular deal, we can actually do the slicing based on principal balance average loan size, different states FICO scores telling consistency status, wax, weighted average and TV, CDS and CPS, and all of that. So this is an ad hoc section where any investor or any trustee can actually make changes to any of the, to any of the parameters and based on what parameters they want to see the data. I really like this reporting insights page so is there drill down capability so because I understand that this is all at the portfolio level. If I click on a portfolio, can I drill down to see what are the different assets that comprise that portfolio. Yes, so there are ways in which, in which you can actually get to the individual loans so let's let's assume that you know you saw that there are 100 loans which, which have a FICO score between six, let's say, you know, 615 to 625. You can do a drill down based on that you can define the range. Let's say you can define the FICO range between 615 and 620 and then you can actually see the complete list of loans which follow within that FICO score. So that's also possible. So, so this is, this is that section where you can actually get to get to the nuts and bolts of the, of the analytics where you can actually do it at a D level or at a portfolio level also so when I say portfolio so the portfolio is the portfolio belonging to that particular trustee or belonging to that particular investor. So if the trustee has three deals be on boarded onto a platform the portfolio will talk about those three deals. And yeah, and we can actually see all those details here. It actually talks about specifically at a low 90 level also so if you could see. So, so that's, that's how it actually and the other thing is, you can also download the map LMS Excel sheet so that, so that you can keep it for your reference and understand what all data has gone into the system. So this is the overall internet platform which can be used for the overall, you know, end to end flow where is structured finance deal is on boarded onto the platform till the time that the reports are being generated by the trustee and published to individual investors. Month after month. So this can actually work during the lifecycle of the deal. Now, I'll just share again. So the other part that I wanted to show is about the AI component. Right. So, so this is the, this is the other part where usually like me, like I mentioned in the, in my presentation that the verification agent is the guy is that you which usually does all this reconciliation and due diligence. So this is the, this the dashboard of the verification agent. So it talks about the deal ID is an asset class and who is the issuer and how many number of loans have been there as part of each of the each of the deal ID is on what date the deal was created. So, so this is the point or this is the flow. This is the step where the verification agent comes in as part of this dashboard once he logs into the platform. As part of this, he can so this. So this is a screen which actually, you know, drills down into the complete setup loans which was part of one particular deal. So in this case there are some 1300 loans which was, which was there as part of the platform. So once you log into this, the admin of the platform can actually log into the system and then, you know, define the fields which has to be extracted out of the contract. So this contract status when it shows digitized so meaning those particular fields have been extracted from the contract and the contract has been digitized and LMS data status. It's it's the Excel sheet which has been uploaded. So this all this. So there are specific loan ideas which are being assigned to individual loans so that as we can see there are some 1300 loans as part of this deal. Although, all the loan contract documents for those 1300 years have already been digitized and the LMS data has been uploaded so digitized using the AI, AI data, AI engine. So if you can go a little further, and I can actually go into individual individual section individual loans, and then I can see that whether there is whether those five fields that I wanted to be matched between the LMS data and the contract PDF document data have been matched or unmasked. That's where this one, you know, I can show that status, I can see that status has been mastered unmasked. And if I want to find out what exactly, you know, which are the fields that I have been, I have been trying to extract so this is what I could see that these other fields on the left side is what I have defined to be extracted from the loan contract document and I'm sorry, the right one which is coming from the contract document. And the same fields are being extracted from the LMS Excel sheet where it's doing a match, it's match or mismatch. So if I can just, so I can, I can keep once I take my focus into individual screens then I will see what are the values. So I'll keep going through the contract document on the, on the right side which is the digitized contract document, and I will show me what values, what are the corresponding values of those fields from the LMS Excel sheet. So Sanjay, if I could just interrupt you really quickly. We're two minutes over our allotted time so I wanted to be respectful of people's time, but you've gotten to the point in the presentation that I think is unbelievably interesting this is what a lot of people wanted to be able to see so I would like you to keep just to be respectful of people's time at the people that have to drop off, Sanjay, could you put your contact information into the chat so if they have to drop off but do have questions and would like to reach out to you that they will have that information. And yeah, we can keep going as well because I think this is really interesting and just points to the AI capability that you guys have built within the Intane product. Okay, thanks Sanjay. Yeah, let's keep going for those people that can stay. And for those of you that can't we are recording this and we'll have links available from the wiki later. Right. So, so as we can see so in this in this particular case there was a mismatch and the contract document, the monthly payment amount was 89.13 which was extracted out of the contract document but in the LMS, which was, which was applauded, which was applauded by the verification, which was applauded by the servicer and made available to the verification agent for the due diligence was 89.14 and that's where the verification agent can actually reach out to the servicer and then, and then can actually tell him that hey, you know from the contract document, which is which is kind of an old document because the contract is usually being signed by the borrowers at the, at the start of start of the loan cycle. You can actually mention hey, the updated monthly payment amount is 89.14 but it was pensionized 89.13 so the servicer can actually correctly advise the verification agent as to what the appropriate information appropriate numbers are and then he can actually make changes and do a, do a match, which is what is being allowed here. And at this point, this also shows the pages being processed so what this means is, so all these seven or eight fields that we have mentioned here as are being extracted from different places of this 13 page loan contract document. So that's, that's, that's what it means. So once we have that again we can also be also allow the verification agent to take a download of this overall overall reconciliation document where there will be. And then finally at one point in time so as we can see so there are this monthly payment amount, quite a few differences between the discrepancies between the LMS exit sheet and the data extracted out of the loan contract document that's why most of them at this, yes means match or mismatch so no meaning mismatch so that's where that's what it means. So for this out of this 1300 loans that are around, you know, 50 or 60 loans where the monthly payment amount actually doesn't match between LMS and the contract document. So, you know, based on this exit sheet, obviously the verification agent, like I said can reach out to the service or to the trustee to figure out what are the actual numbers and then can make changes in our platform and then do a match and then go ahead. So that's, that's where the due diligence actually gets completed. And, and based on this, the trustee can log back into the system as I had shown in in 10 admin, and then generate the investor report and publish those report to individual investors. So that is, that's where I stopped so so as far as we are concerned. What we have I probably just want to want to take another half a minute just to talk about what we have tried to do. Where all we have tried to make some changes based on the feedback that we have received from different clients over the last three or four years. And what we have been trying to work on in the last six months or last nine months also. So as we know, when we talk about saving data into the blockchain, it's always invoking or doing an invoke, invoke request will always take time. You know what we have seen if the number of records is more than 5000 it takes decent amount of time to save the data into blockchain. So, so, so then we also started getting some kind of feedback from the client that hey take so much of data and you know, even though this actually as part of the process, usually the trustees admin users do not do this. It's more than once or twice a month because these are all, you know, these are basically you upload the data and then you generate the report this happens once or twice a month unless you actually want to make some changes to that data. So, but then based on the feedback and we actually save the data is the intermediate database for some of the reports we actually wanted to. And as far as the stratification reports are concerned we, we wanted to, and then we make changes so that we could generate it out of the intermediate database rather than from the blockchain. So there are quite a few changes that we have done over over the last nine months to 12 months and which is where we are kind of seeing some positive feedback from the, from the clients now. So, apart from that, of course, UI and UX has been extremely important for individual clients, even if you have huge amount of data unless you can give access to the clients in terms of, in terms of slicing and dicing on the data, it doesn't. You know, they will keep relying on the PDF report rather than coming to your platform and starting to use a platform. So that's also something that we have also seen and which we are currently working on and that's where some of the other things that we want to incorporate into the platform is based on LLM models also. So for example, let's say if I can get, if I have all these 1300 loans, loan documents, loan PDF documents, digitize and saved as part of my blockchain, blockchain legit. I actually allow the users to do a natural text based search for certain type of loans or from certain kind of type of counties or for certain delinquency loans. So that's a delinquency statuses. I think that's, that's what we are also trying to work on but that obviously is going to take some amount of time. There are two or three areas which we are currently working on, apart from the fact that we have already built this token as a capability on the top of our top this and for which we actually used avalanche. We primarily took avalanche because it gives us a good mix of private and public subnet. This is out of the box, which is why we did that but yeah, I mean, we post all of this Celsius and FDX kind of issues. We have seen all those discussions dragging on for quite a quite a longer period of time. So we, we have also built some option solutions. We initially we built completely all chain solution for that, but then we have started building some option access to that. So those, those are four different areas that we are currently working on as far as our products are concerned. So actually just had a follow up question for you on that I was thinking about those PDFs the loan level contract plan so do you guys store those on chain or off chain the actual document itself. Yes, so the documents are being saved into IPFS. So once we take the documents, usually we allow the users, the clients to upload the documents to an SFTP blob store, once they upload those documents to SFTP blob store. And we take, we access those let's say those 1300 documents we take those into into our Azure file share based on the Azure file share we actually digitize all of those documents so let's see each of the document has 13 pages we digitize those. And at that point in time we actually save those document to document into private IPFS cluster that we maintain for each of the questions. So, yes, and so that's also another important area where we are trying to build something around. You know, which is called evolved, you know, there are quite a few evolved players who actually just work in this concept of providing stories for the contract documents and providing security around that. So, you know, it's just an extension of our product because we keep hearing about all of this asks from from our clients where they say that hey I also have to use another evolved solutions because because they will give me all these documents, the individual documents when I need. So that's also another solution that we are trying to build and integrate with our platform. I had another question that we can open it up to the rest of the audience as well because a lot of people stayed. This was very interesting. You guys said that you're only writing at once a month to the blockchain. And then one of the things that you guys are working on is being able to do text searches within the blockchain. So what I'm inferring from that is you guys are writing all of this information to the blockchain. It's not a half of say a portfolio of loans you're writing all of that information. Is that a correct interpretation. Yes. So, we take all of this information once validated by the trustee. Once we have given him access to make some changes once validated we actually save all of those into into the blockchain. And it's not so difficult for us right now like I said it's not it. It's not that we actually have to keep writing this multiple times and retrieving all of that data from the laser multiple times and it's a. So the trustee has to report this once in a month so because of that it's a little easier I mean at least for our use case. It, you know, there is not so much of time pressure on this, unless it actually takes a day to save the data so it so. So that's why it's, it's, it's okay. He might the trustee might actually want to make some changes to the loan to the limits data but that's fine. So the end of the day we save it to the blockchain. Okay. If anyone else that's still on the call has any questions, please feel free. This is the q amp a portion of the presentation. I know we've gone over but I did want to give everyone in the audience a chance to ask any questions or participate in the discussion. Okay, if there aren't any other questions, Sanjay, thank you very much for presenting. I think you guys have a really interesting product and that was a great demonstration. If you guys would like to follow up with Sanjay, he did put his information into the chat, please feel free to reach out to him. Sanjay again thank you and thank you to the intangible form participating. I think this was a great session. Thank you everybody. Thank you, Sanjay. Have a good day.


Give me six reasons why software development doesn't suck. So you can't do it. Everybody agrees that software development's. And there's a lot of reasons for this. One is like technical. Getting computers to do what you want them to do can be very difficult. But mostly, it's humans. Humans are really strange people. You got to deal with managers. You got to deal with meetings, scheduling, deadlines, all the stuff. And that's really what makes software development tricky. It becomes sort of a problem to have to deal with all this sort of stuff. And people have come up with ways to deal with this as best as they can. These are things with agile, waterfall, pair programming, BDD, TDD, all that stuff, whatever is popular at that given moment. And I've tried all of them. And if they're work-free, that's great. Because software development is hard.  Because I want to be that guy who's really into their process and into their workflow. Because if you're going to identify with something that works really well for you, that's amazing. And for the longest time, I thought I was just weird. I still do. And I wanted something that really works well for me. And I think to the point the last year or two at GitHub, we've sort of come down and figured out a development process that is really interesting. It doesn't feel like process. It's really quick. It's really fast. It scales really well. And that's what I want to talk about today. So this is not the safari. I'll sort of this. This is how GitHub uses GitHub to build GitHub. The secret here is that this isn't really about GitHub. Online, I use GitHub three times in the title. So it's sort of about GitHub. But what I mean by that is that this is not about GitHub the tool. I'll talk about GitHub the tool, because it's easy to use it as an example for stuff. But I really want to talk about our workflow, our process, and how we use our tools, and how we choose our tools, and why that makes for a really fun development environment. So I don't think this is really about GitHub. If I worked for Twitter, I would give the same talk. If I worked for Facebook, I wouldn't give the same talk. I want this to be a talk for making you think about how your company can use the processes and workflows that we use to improve your own product. So I'm Zach Holman. I'm Holman on Twitter, Holman on GitHub. I do work for GitHub. It's a social coding site. Employee number nine. So I've been there for about a year and a half now. And we're now 46, 47 employees. So we've grown a lot. And I've been able to be there for a year and a half and see what hasn't worked out for us, how we've changed our workflow, and more importantly, what has worked for us. What assumptions have we made in the beginning that we've been able to keep with us the entire time? So first of all, I want to talk about a little bit about how we work. Otherwise, this talk will probably sound insane. The big part of what we do is we work asynchronously. So what does this actually mean?  I read real edgy dictionaries. But what's so important for us is that getting people in the zone is really important. This is the difference between going to work and you're not in the zone and you're trying to constantly battle and trying to force yourself to write code. And it's one of those cases where throwing hours at the problem doesn't solve things. With software development, you want to be in the zone. Because when you're in the zone, you can do as much in an hour as you can 20 hours out of the zone. So we want to get more people in the zone for our employees as much as possible. And to do that, we have no meetings, no deadlines, no managers, which is kind of insane. You can do it, too. Fire all the managers, you can tell them I said that. It goes back to this really works for us. It's a very fun place to work because it gives people in the zone as much as possible. So what do I mean by that? One, chat rooms. We do everything in a chat room. This sort of stems from when GitHub was a three-person company. They did everything online. We didn't have an office for the first two years. And this really brings us through everything. If it's you and me at the office at 2 in the morning, no one else is around. We're at the same table. We're still going to talk in the chat room. The reason for that is that, firstly, let's everybody see what's going on. There's a lot more visibility in the company. I can go out to lunch. I can go to Kansas City. And when I come back, whenever I got internet, I can see exactly what happened to the company in the specific areas. And it's a much easier way of letting everybody get involved. And there's no more secret projects where only, oh, that guy knows that project. You'll have to talk to him in a range of time because that sucks. Do you actually do that? Do what? Do you actually do three days involved? Yes. It depends. So as an aside, we have a bunch of campfire rooms. We have like 20 or 30 now. I don't read the danger room because that's all the animated gifs in Cuba at Rain Supreme. That's insane. But specific ones where I'm really involved with, like get-to-have-enterprise, I'll go back and read the transcript from the last few days and stuff like that. We want to break out as much as possible in separate groups. And then it becomes much more manageable to see what's going on in your domain of responsibility. And then lastly, time flexibility. Work when you want to work. This is really important. We have a lot of people coming to the office at six in the morning. That's definitely not me because I'm not productive at that point. We want people to be productive as much as they can. And some people are super productive in the morning. They cannot do work at night. And that's cool. I'm totally the opposite. And mandating that you have to come in at a certain time, leave at a certain time, just damages that. It brings people out of the zone. So I wrote about this three parts and stuff. You want to check that out? You can. But I want to get on to actual other stuff. Let's talk about pull requests and branching. I think this is a huge part of white GitHub, worse as well as we do. I want to talk about issues. I want to talk about OAuth as identity, hooks and hubot, and secrets. So first, pull requests and branching. This is the most interesting part of GitHub, I think. You guys have really weird branches. And I see the support requests come in. And someone details their process. And your job just drops in each paragraph. Like, how do you work in this fashion? And by this, there was one company I saw who has a master branch, makes sense. Then they cut a deploy branch every time they want to do deploy, makes sense. But then they just cut a deploy branch off of each individual deploy branch.  This is just insane. It's overly complicated. You don't need to do this stuff. More likely, I see this a lot in large enterprise companies. You have a repository that you work on, and then you have a group of trusted developers. These are the guys with full rewrite access to the repo, and they can do whatever they want.  And they're trying to set up all these arbitrary guidelines, and it just seems really insane to me. So what you have is they all have to forfeit their own project from the main repository. All those forks then have to go back to the trust developers for them to figure out, OK, is this good to go back to the real repository if it's not, then you've got to send back to the shitty developers, and then they have to pull down new changes to the repository.  Keep your branch as simple. I think this is really important. This is fundamentally important. This is sort of the foundation where you build your product. All right, I'm trolling you now. It's just like there's so much in you as that. It's not a solution. You mean the stuff I was going to cover in the next minute? You know, you haven't talked yet.  So keep your branches simple. Branches should be simple. Let me talk about how we do branching, because I think obviously we have a perfect branching situation here, Dr. Nick. What we have is a master branch, and then we have a branch where you work on a bug fix or a feature or anything like that. When you're done with that, that goes in a master. This is it. That's the entire branching strategy. We don't really branch off of separate branches or do anything more complex than this. And it becomes a lot easier to bring on somebody new and just say, oh, you cut a branch. When that's ready to go in, push the master. Along with that, everybody can push everyone to deploy. Our designer on their first day can deploy to GitHub. We have a lot of automations surrounding deploying to the 50 plus servers we have now. And that's good. We want people to have responsibility over the code that they actually write. Too many times, you have something where like a release manager, where you push it to the release manager, and then that becomes their responsibility for the stuff. We want people who write the stuff to be responsible. This also frees yourself up from micromanaging other people's code, but the trust developers and the shade developers part, you want people to be responsible for their own code. For us, master is always deployable. This is like the one hard rule that is constant at GitHub. If you push the master, assuming it can be deployed as soon as it passes CI. The reason we do this is because we deploy 10 to 40 times a day. We like very short changes. And if something breaks, you know exactly what breaks really quickly. If you're nervous, you can deploy to staging. We have a separate staging environment. We can also deploy separate branches, and test that out, and then deploy to master afterwards. You can also deploy to a subset. So if you could say, let me just deploy to two boxes right away, and then see if anything blows up. If it doesn't, then merge into master and deploy from there. This is also sort of Twitter-driven development, because you guys are way more on top of things than we are sometimes. And people will tweet constantly if something breaks. Now, we have grass and stuff where a number of exceptions and then deploy is really marked on the graph. And then we mark that against ad replies to GitHub on Twitter, and it's actually very proportional to if you break something, people will talk about it. So keep your branches simple. That's really important. I know what you guys are thinking. What about code quality?  They do weird stuff. So how do you keep up code quality? And our response to that is pull requests. This is central to everything we do. Pull requests are a code review. What are pull requests?  It's a simple discussion about a piece of code, a distinct piece of code. It's a discussion about codes, a discussion about that particular feature, a discussion about that particular strategy. All of this stuff comes together. You can do a bunch of different stuff to it. You can reference issues in it. You can reference other bits of code diffs in it. You can write code comments. It's all about figuring out how you make a discussion on a piece of code. And then from that point, you can figure out, do you want this in the actual code base? All this stuff happens on a separate branch. So none of this stuff ends up being dangerous, because it's separate from your production code until it's ready. This is what it looks like.  But it's title, description, bunch of commits. Once those commits are done, you can discuss on those commits, and discuss them more, and then you commit, and then you get merged back into the master or whatever branch that you're trying to merge it into. The pull request itself is broken out into a discussion where you can actually talk about the changes, the commits, where you can show all the commits, and then the diff, where you can actually see what has actually changed in the code. And this is really cool, because we're really large GitHub at this point. And no one person can really dig into every line of code that's changed. But it's important that you have a lot of people who know what you're doing. So for a lot of pull requests, I won't look at the actual code. I'll just look at the discussion and see the title description. And that's a good way. It's like an RSS of what development is happening without having to sit down and do a stand-up meeting or anything like that. I can just see it in my inbox as it goes by, and it's very simple. So I lied. This isn't actually our development strategy. It's more similar to this, where you branch off, send a pull request, and then merge it into master. And that's the guard against getting really shitty code deployed accidentally. So big secret number one, you don't need to fork anything. This is sort of our common misconception. You can do pull requests between branches on the same repo, and that's what we do consistently at GitHub. We don't fork the main GitHub repo all the time. We just do pull requests between individual branches. And then you have to set up weird permission strategies to let people under your different forks and stuff. It's just a much simpler way to do things. So wire pull requests actually rad four reasons. One, they're asynchronous, no meetings. Everybody's had that time where you're in a code review in person, and you're projecting code on the wall, and you're trying to figure out, OK, you're running it through your MRI in your head, and you're trying to figure out, OK, this compiles to this and does this. It's a terrible way of reviewing code. With pull requests, you can easily pull down the diff and run it locally. And you can do that whenever you want. You don't have to have a separate meeting on that stuff. It's really helpful to have it broken away from some sort of synchronous, like, this has to get reviewed right now, and stuff like that. Secondly, email is a good interface for this too. When I wake up in the morning, I can see all the pull requests that have been generated from Europe, for example. And so again, it's just a quite easy way to figure out what's going on in the company without mandating some stand-up, which doesn't even work when half your team is across the world. They're also really accessible, and we use this a lot. Designers evolve entire mock-ups in a pull request. And that's really powerful too. It's version control for mock-ups. You can see, as you go along, what the mock-up has changed over time. You can discuss on that too.  We have a shipper who ships out all your beautiful shop stuff. And she can go in and check out a pull request. This is going to change to the shop.github.com site. Can you actually say, does this make sense? Yeah. She doesn't have to go see the code diff, but she can see what's actually happening and check it out. They're also historical. They can be experiments, and they should be experiments. We have a lot of pull requests that are designed not to ever get deployed because we want to see, OK, what do you guys think about this interface? What do you think about this API? Does this make sense? If it does, then I can just close the pull request and then actually build it for real. Don't be afraid to try something out, throw it away, because github retains the history. And they should be really fun to make. You should not have to fear about doing some insane experiment when you're drunk and seeing how it works out. So I want to show you just a couple of quick pull requests that we do at github. It's a little bit more context. Status.github.com, there was a problem a while ago, again, where you guys caught stuff before we did. Or more correctly, we would get the notifications that something is down, but it took us another couple of minutes to actually update the status site. So I added something just real time pulling of different services on github.com just to see if they're up. And this is a pull request. I started out just with a bare bones interface, and I just dumped this on a page. It would check this, and I didn't have to care about styling or anything like that. Because I knew once I posted this, somebody would come in and be like, I want to design that. And that's where we have a lot, where designers are just going to see what's happening to the company. And when it's ready for them to come in, they'll do a design. At that point, I have a design, and I can build on that, I can commit to that design and then just match it, and it's very easy for me. I never have to worry about that in the slightest. And there's no upfront meetings. It just all happens very asynchronously. By the end of it, we close it, merge it, ship it, and that's it. It's very simple, very easy. You should not be afraid to mix your designers and developers. They should work together. Just like pull requests are kind of scary from a designer's point of view, but they don't have to get into the nitty-gritty if they don't want to. It's helpful for them to get into the discussion section. Don't be afraid to post screenshots a lot. You can use this in the Markdown, which I'll show you in a couple of seconds, but it's very good to be very visual, even on back-end stuff. You can also post gifs, because they're funny. We do that a lot. We also have something called code editing, or it's a syntax highlighting in your code editor. And this was earlier this year, and this entire pull request.  It doesn't work. We can't do it. Close it, and that's it. That's important. That's still really good, because they're cheap as hell. You shouldn't be afraid to experiment. That seemed really kind of a bummer at first, because we really wanted this to work out. But the library we were using didn't work out. Don't be afraid to toss it away. This was great because five or six months later, we found a different library that did a lot better, and integrated that, and worked how we wanted it to work. And we could go back to the original pull request and say, what was my design decision here? What did I want to do here? And then you don't have to reinvent the wheel every time. So really play around with pull requests. This is a pull request that started in the beginning this year, hasn't shipped yet. It's got a bunch of stuff in it. And that's really cool. We can hire somebody tomorrow. And if they're asking what they want to work on, we can point them to this. There's no back alleyway deals about communicating between two people that then you'd have to chase down somebody else, and be like, can you please tell me what your thoughts are on this? It's all right here, and we can go back later and check it out.  This is something that you have to constantly worry about. Can you improve your workflow? Can you make it a lot better?  So recap, use pull request more. They're awesome, ship a lot more. I think they're really great. I think they're really important. And if you are able to do them in your company, I should investigate them. I want to talk about issues. Everybody has issues in different companies. I'm talking about tickets, bogs, stuff like that. So everybody's seeing a screen like this, like a new issue create screen. The problem with this is there's a lot of stuff going on here. And something makes sense, and you're like, OK, yeah, that's cool. And then they just layer more and more stuff on there.  And you try to figure out what is the point of all this stuff, duplicating priorities and stuff like that. This is the one on GitHub.com. And this is not, again, about GitHub. This is the tool we choose internally. All it is is title, description. And we do away with the whole bunch of priorities and craziness, because for the most part, you don't need them. Ask yourself, can you survive on simpler tools? Can you work better and faster on simpler tools? I think you can. Merlin Mann, I sort of have a man crush on him, Twitter crush. He's amazing. He wrote this awesome post on email priorities. And he said, priorities was not manufactured or signed. Otherwise, it's necessarily not a priority. Making something a big, red, top, top, big, highest number on priority changes in nothing but text styling. If it were really important, it would already be done, period. I think that's really important. He's talking about email, but the same is true for stuff across the board. Issues, prioritization, dragging, dropping, like all these issues to prioritize and stuff. Think about it if you actually need that. If you do, that's cool. Then use it. But if you don't need that, you're wasting a lot of time. Look at all the stuff that we have as developers. Ask them to get rid of all of it. Resist, adding meta work, it gets in the way of real work, the real work will get done. Quickly, we use issues for three things. Should something broken? Something's broken, that gets fixed in a few hours? That's it. We also use issues a lot for, wouldn't it be cool if, and then it's another place to have a discussion. This is prior to the floor request, because you don't want to throw it on code yet, but it's fun to talk about. We also use this to-do list sometimes. That's just kind of an easy way. You don't have to set up a weird issue tracking, to-do board or something like that. It's all just in one issue. Do you need more than that? Really think about that, because most of the time you don't. Sometimes you do, which is fine. But most of the time you don't. Simple tools means a better product, because you can build it simpler. OK, all off his identity. This is fun. I love Ruby. I really love Ruby. I'm not talking about the speed of Ruby, because it is slow as dicks. I'm talking about how fast it is to build something. Like, it is really fast to build something. So I looked through my development folder about what projects I have in there, and I have one called Secretary of Labor, All Caps. I was really drunk when I wrote this, and I saw in the next morning it's just a single Sinatra app, and it's got a stuff-referential sim link called What That Points to Itself. I have no idea what it does. I have one called Unmarked Van, which tracks people's physical locations. I have one called Trace, which is a real-time stats graphing in Redis. The point is, all this stuff was really fun to make. It was fun to experiment. None of this stuff is ever shipping, especially not that first one. But it's fun to try stuff out. And we do this stuff at GitHub, too. We have a bunch of internal apps. We probably have more than this at this point. But some of them are more fun. Some of them are very serious, CI, stuff like that. We have an internal Twitter, which is more fun, status updates, and stuff like that. The point is that we want people to experiment. It keeps things really fun. It keeps things interesting. The problem with all of this is that outsiders aren't welcome. Like, we're a really open company, but you don't want some people just trudging through all your stuff. So yeah, that's some authentication layer. For us, we use GitHub for that authentication layer. We have all of our teams. We have our orgs. We have everything in GitHub. So we just use OAuth to attack that and use that as our authentication in all of these separate mini apps.  Allow them to check out your profile. Yes, no. You can use this in a bunch of different ways. There's a whole bunch of different Ruby OAuth libraries. This is one done by Atmos. All we have to do is just check whether or not they're a member of the GitHub org. If they are, let them in the app. It's very easy. If we hire somebody, we don't have to update the 30, 40 different apps we have. It's all in one place. It's just a nice, consistent way of doing things. Think about if you have this problem, can you pawn it off on somebody else? And that means GitHub. A lot of people have Twitter now. You can use Twitter's authentication for that.  It's good to use a consolidated feature for all this stuff. Okay, let's talk about Hubot. Everybody know what Hubot? So three. So Hubot's our friendly campfire bot. He's cool. He can do some stuff. We have like 300 commands for us. You can deploy over GitHub app. This is important when you have 50-some servers because you have no idea how to deploy all that stuff. So we just say Hubot deploy X to production and he does it. It's great. You can run branch-level tests. So if you push a branch up, that will just run automatically. You can play music in the office. You can tell us who is in the office based on their Wi-Fi presence, on their MAC address, on their phone, or their laptop. You can build usage graphs like you can chart all those exceptions versus deploys versus Twitter mentions, send received text messages. You can mustache every image posted in chat, like that. You can track who swears the most every day. You know, we can do all this stuff. And it's more fun because it's a shared side project. Again, it's fun to have experimentation. Use cool technologies. Stupidity is not open source. I just thought it was it. He's not open source. As of last week, it's awesome. We have tons of adapters now. You can use them in IRC, Campfire, XMVP, and tons of stuff. So check them out if you haven't already. This is a really fun project you have inside your company. In terms of how we use them for GitHub, we use them in a bunch of different ways. Specifically, we use them for branch status a lot. You can ask him who about what hasn't been deployed, and he'll return it at compare view of what hasn't been deployed yet. So you know, if you're gonna deploy this, these are the concrete disks that haven't been deployed yet and be worried about these if you deploy them. We can do this on a different branch too. So if you're gonna deploy a separate branch to production or you want to know what on that branch has been merged into master yet, you can do all this. And it all stems from the shot, which we know what is the currently deployed code on GitHub because it's all in this one site. It's just an endpoint and you can use this all over the place like CI, stuff like that. It's just a nice helpful way of doing that and you can build it into compare views and it's fun. You can also use a lot of the API in GitHub too. I can ask one of the pull requests on my particular repository and I'll send it back all the pull requests. Very simple, very easy, and it becomes a nice way of setting up a to-do list. If you're ever like, what should I work on today? This is a nice way to start. We also have the same thing for issues. We have bug days every like second Thursday or so, just as a way to clear out old issues. And this is kind of fun. You can ask it how many issues do we close today and respond back how many issues you close today.  It's fun to be like, oh, can we do more issues knocked out this week than we did the last time? It's fun. Think about what you can automate at your company because the stuff that really sucks are the things that you have to repeatedly do over and over again. And we're developers, it's fun to over engineer stuff sometimes and like you'll spend way more time automating something than you think you'll get out of it, but you'll actually get a lot more out of it than you probably think. Plus it's really fun to do. So the moral of story, who by knows where you live? I don't know, he's freaky. Finally, I just want to talk about some secrets. I want to blow through these because GitHub's got some funny secrets. We talk stuff away sometimes, our bad. Here's some fun stuff you can have. Emoji, all those fun things. We do these on pull requests all the time. We just plus one stuff. We say heart. I don't know, it's fun. It's a fun way of getting people involved on stuff really cool. Go to that link to see a whole list of emoji and stuff like that. All my slides are up on my site later. You can check out these links and stuff later. Shortcuts, if you guys don't know all this stuff, W will bring up the branch selector on a Rebo page. T will do the finding projects sort of like the TextMate finding project really quick. And if you press question mark on any page, it'll bring up the help dialog.  Issues, for example, has a whole bunch of quick access to issues. Images are awesome, especially when they're animated. This is the markdown format for posting an image into issues. This will post the image. Unfortunately, this only works if your dorky dodgeball team is the image. I'm just kidding. That's our dodgeball team. Check out those shorts. Amazing. The other one is, what? Who won dodgeball? I can't remember. Is that some Heroku guy who asked that? Heroku won dodgeball. We raised 50 grand. It was great. For charity, not for Heroku. Also a different patch. I mean, Git was based on a mailing list point of view. So all of the stuff that we expose on GitHub is also available in text basically. So just add .git, .div, or .patch after most URLs and we'll spit out a nice thing that you can directly need to get later. The other thing we have is friends code. This is sort of a, you get the formatting of any code that you paste into issues, pull requests, stuff like that.   It's nice to have that syntax really highlighted. Mentions, we use this a lot. If you're gonna open a issue, we'll usually add like cc, add technically or add defunct and then that will notify them and get them to put their eyes on your pull requests. It's a nice way of just having communication amongst your pull requests issues, stuff like that. White space, you can add question mark w equals one to reduce white space and diffs.  Quick and easy way to do that. Rebo references, you can reference issues and pull requests across different repositories. So you just, in your issue body, you just say like user slash repo number sign issues and then that will bring in the link on the referenced issue and it'll just connect the two visually in the webpage, it's kind of nice. I have a pseudo announcement right now. We have a URL short that we've been using for a while now. I'm announcing this here because I can. So if you have a really long URL, you can shorten it to a git.io URL. You do that via this, it's a very simple service. The red URL down there is actually a gist that actually shows you how to set up a shell script to do all this for you. So if you ever want to tweet something or have some shortened URL or if you want to snag one for your vanity URL, github.com slash holman, stuff like that, that's a nice way to do it. Check out all these links in my talk later slides. So as the recap, really think through this stuff. This is the stuff that will bite you further down the line unless you really think it through each time. And the problem is that you don't notice it being a problem until it's too late. And at that point you can't go back and fix it. So it's gotta be a constant battle of like, what can I improve? How can I make my developers happier? Do I really need all this extra stuff? And then I think you can make cool products. So thanks.