Okie-dokie. Let me find the thingy with the agenda thingy. There it is. Okay, welcome everybody. Hopefully those of you in the States had a nice Thanksgiving break, and it's good to be back after a few weeks hiatus for me. So on today's agenda we've got a New York Hackfest update from Todd. A note on the White Paper Working Group that Hartman Gummary is now the workgroup chair, elected, I think, unanimously by the other members of the working group. I'd like to thank Mick, I'm sorry, for David, rather, for all of his work and wish Hart some good luck. And that actually triggers the last topic, which is a working group charter discussion. Not just for the White Paper working group, but I think for all of them, that Mick will let you, if you're on, open up. If not, I'll try and vouch for you. We have had an ongoing discussion about the project incubation exit criteria, and I'd like to get that to a vote. And then we have, I think on the 10th, there was a review by Bawa of Project Cello and the proposed incubation of that new project, and so we need a vote for that. And if Brian is on, I think we should get an update on the effective working group. So, any other topics for the agenda? Somebody's typing, he's on the phone. Okay, thank you. If not, okay, Todd, I'll let you pick it up with the reminder of the Hackfest. Yep, sure thing. So, if you have not already registered for the Hackfest, please do so ASAP. As of right now, we have 77 registered. We're continuing to see that climb. We will hit a max of 100, and we will stop registration at that point. So, please get that done as soon as possible. And then the other thing in the agenda that went out, we have a draft agenda for the Hackfest. I'm copying both of these things into the chat window. If there's topics that you want to see get discussed or if there's things that you want to present on, please drop it in there. If you have a workgroup that's looking to hold some sort of session, please get that slotted in. Otherwise, like all the previous Hackfest, we will run this in on conference format, spending the first 30 minutes or so mapping out the two days based on the group that's there and the variety of interests. Any questions on that before we move on? No, but I would like to get a sense of... So, I know that Richard, I think you're going to be there, right? And I believe that Dan, you're coming Tuesday, right? Yeah, that's correct. I'm wondering if we could think about maybe having a session that just sort of talked about where do we go from here on Tuesday with the various top level fabric, you know, DLT, whatever you want to call them, platform projects, and the potential of Corda, obviously. I'd like to have a conversation that sort of talks about, you know, where do we think we want to go from this? Do we want to think about consolidation at all? Do we want to think about component swapping? Do we want to think about sharing functionality and so forth? I think it'd be worthwhile to have maybe 90 minutes to sort of think about where we go from here with the projects that we have and explore different ideas about how we might be working a little bit more collaboratively. So I'd like to add that to the schedule on Tuesday if others agree that that's worthwhile. I mean, if people think it's too soon to have that, you know, we can put it off, but I think having it face to face would be better than having it on a call. So I'd do it for that. I think, I mean, we may not be able to reach any immediate conclusions, but yeah, I'd love that. So I mean, we've got, I mean, I won't rehearse it now, but we've got, there's various things we've written that we think might be reusable by others, and there's probably more we should be doing to look at what's in the code bases, but yeah, I'll do it for that. Okay, all right, I'll see if I can find a 90 minute spot in here. Okay, thanks. Any other? I just joined. Oh, hi, Nick. Hey, Chris. Sorry. Anything else, if not? Okay. If not, then I guess next up would be the incubation exit criteria discussion. And Todd, could you paste the link in just for everybody? Sure thing. I always want to click on the link. It doesn't do anything. Thanks. I wasn't there on the 10th, but I believe in, and again, others can weigh in and just sort of agree if I'm capturing this correctly, but the way that I understood it, and I meant to update this, but I haven't had a chance to as I've been traveling, but what I took away from listening to the recording of the meeting on the 10th and reading the minutes was that the requirements as stated for the minimum requirements seemed about right, and that when we got into the additional requirements, that those were deemed basically more about the maturity of the product, not the project, and so they didn't, I mean, they're important. Obviously, we want to factor those in, we want to capture them and not lose sight of them, but by the same token, they aren't really relevant to exiting incubation from a project perspective. So if everybody is in rough agreement with that, then what I would propose is that we take a vote on the exit criteria as written and stop at just before additional requirements and basically take that section out and just record it someplace else in the Wiki for consideration of going to general availability or whatever we want to call the formal release of a product, or have I talked to that correctly? Yeah, I think if you leave out the additional requirements, then I don't really see a big difference between incubation and an exit, so what does it really make sense then? I'm sorry Tamash, there was a little bit of static in the beginning. You're saying if we eliminate additional requirements, then if you eliminate additional requirements, then it is much more left than what is actually being put into place for incubation. I'm sorry Tamash, there was like a feedback thing in the middle of what you were saying. I didn't hear it again. If I eliminate the additional requirements, then there's not much different than what? Than incubation. Yeah, I think what Tamash is talking about is what is the difference between entering incubation, what is required to enter incubation, and what is required to exit incubation? Well, so the requirement for incubation is basically described in the life cycle document where you just have to have a proposal with a clear description and a well-defined scope, some resources, identified maintainers, and to have it be vendor neutral. I mean, there's a pretty low bar. I'll just let him try to just join. Yeah, the key word you mentioned there, one of the key words is scope. And we decided that scope as given for what's being developed is sufficient to get out to exit incubation. If we look at the additional requirements versus the existing requirements that are part of the overall solution, that's enabled by the existing solution, can we vote on the scope to deem that complete to exit incubation? For example, we may find that looking at the existing requirements, there might be a very important gap that needs to be addressed. So that's the sort of decision I would do and say, you know what, we do have a well-rounded scope, and at the point we are, we should really exit incubation. Just some consideration here. Okay, so maybe we're not ready for this. I thought we were, but maybe I misunderstood what I heard in the discussion. But then again, Todd, I'm very new to the process. I've wanted to see you to join the team. So it's going to be a consensus as to whether we're at that point that we all agree we should exit incubation. But to do that, we need to look at the additional requirements and ensure that the scope is decoded of a solution that can exit incubation. Okay, so again, let me see if I can capture this. There's a distinction between the project and the product. And again, I'm not talking about a product in terms of something you sell, but as much as the product is the output of a project. A project is the collection of individuals working collaboratively on a product. And the function of incubating a project is to be able to essentially pull together a team, get to the point where the team basically is operating within the norms of what we describe in this document here, in terms of their GitHub or Garrett, as the case may be, has been created. They have mailing lists. They're using them effectively. They have a continuous integration pipeline. They've got adequate test coverage. They're doing documentation that essentially we're looking for the maturity of the project in terms of do they know what they're doing and are they doing it right or is it a complete dysfunction? And so that's what incubation is really all about. Incubation is about pulling together and growing a diverse community of contributors and collaborators working on a thing. Now, the maturity of the thing, the product, is an independent thing from incubation. It has nothing to do. You could bring something in that's fully baked, but it still has to go through incubation to demonstrate that the project team, the individuals that are working on it, are operating in the mode that we expect of a project within the hyperledger community. And that it's a different discussion about whether or not something is ready to be anointed as 1.0 and so forth. And so again, that's what I thought I heard on the previous call. And so I just want to make sure that we're all on that same page. Yeah, so Todd, it's just for some clarification. What would you consider the purpose of scope as in a charter for a project? And that also applies now to intubation here at the project. What is the purpose of scope in that intubation, you might say, project or in the hyperledger project? There must be some significance regarding scope. Is it defined to the point that we can say yes, we can get out of intubation? And that's the only concern I have. Have we done that due diligence? I agree with what Chris elaborated there. The additional requirements to me are very much the requirements for majority of a product. At the point where we want to say that, you know, we are releasing 1.0 and we have to have these criteria seem to be suitable. But for incubator to exit, for a project to exit incubators, we have to demonstrate that we get the process down, the process of developing the project within our community. And it seems to me that, you know, the minimum requirements section define just that. So I would agree with the minimum requirements but not the additional requirements. That's a very good point. So I think if that's the case, the scope should cover just the minimum requirements. As long as we agree as a team, this is the point where we've all agreed that yes, the minimum requirements constitute the scope of what we need to do also. So I think that's what I'm trying to establish. But then Tomas said he wasn't clear. And maybe I misunderstood you, Tomas. But then you were saying that what we've described here, you aren't really sure of what the distinction between entering and exiting incubation is. But to be able to enter incubation, you expect what is an enumerator that's a minimum requirement. So besides building the community, what has happened during the incubation? No, but Tomas, I don't think that's accurate. For instance, sufficient test coverage. I don't think we have that as a requirement to get into incubation, right? So I think if you put the two side-by-side, you'd find that this one goes further. Yeah, it goes a lot further. I mean, legal actually, you know, the code entering needs to be a patchy license as well. That's actually, you know, I think, you know, but exiting obviously we need to be a little bit more particular about making sure that everything is appropriately licensed. So that needs a scan or at least a desk check. You know, the test coverage, the documentation, you know, the alignment, all those kinds of things I think are determined based on the output. Whereas we've incubated things that had no code at all. Like we incubated the Python SDK. We incubated the blockchain explorer. We incubated, you know, some of the projects that we've approved didn't really have any or had minimal code documentation testing and so forth. And it was really based on what they described that they wanted to be building and how they articulated the scope of that activity that we agreed to accept. It into incubation and then it's a function of them building a community of develop a diverse community of developers, getting the process in place and, you know, using the tools effectively building continuous integration and so forth that are required to exit incubation. So everything you said here constitutes high level requirements that are part of the scope. So if we have agreed that what we've done in terms of the minimum requirements that you've very well elaborated on constitutes a complete scope for exit and incubation. I think that probably will get us to that point. I don't think this has anything really to do with scope and requirements. I think that's a very different set of things that we haven't talked about before in this context. I think what we've been consistent about in these discussions is what's the maturity of the contributors, the maturity of the team, rather behind the project. And if we need to add more specificity to that in the document then maybe somebody can propose that. Otherwise as written it seems sufficient unless somebody can suggest some harms or risks of not having it more specific in terms of those maturity levels. Yeah, I agree with Dan on that one.  I, you know, Chris, I would like to us to kind of get back, I feel like we have derailed a little bit. I mean, the status of the document is that we have these two sets of requirements because we already had these kind of discussions early on when we were trying to establish this exit criteria. And, you know, what we ended up with is these two lists with the idea. I mean, at least that's what I tried to convey in the text is that the first one is the thing that we all agree we must have for all projects that want to exit incubation. And then there was this notion that, well, in some projects the very goal of the project might be to set a certain goal in performance, for instance. And it doesn't make sense, you know, to get out of incubation unless you have established a structure, an infrastructure to get to measure, you know, that goal, whether you're reaching that goal or not. It doesn't mean you've made it already, otherwise you'd be out of active probably by then.  And I think the text says these would be defined at the onset of the project. So, and, you know, by default my assumption is these additional requirements do not apply. They are like, you know, this is up for consideration when people get into a project they may define their own additional requirements and those were just listed as examples of things that might show up in that list. So, last week you weren't there, but Brian was, we started having discussion, you know, on the security aspect. You know, the point was made rightfully that coverage is not the right measurement for security or ensuring security. And so that led to a discussion and then Brian said, you know what, this whole additional requirements section shouldn't be there. And we kind of said, yeah, maybe you're right. And I pointed out, I say, wait, this is kind of a compromise that we have here. So, if you remove that list from this document, you know, make sure you don't completely lose it and you already have to have it somewhere else. And so that's where we are. And I'm afraid that we're kind of going in a circle now between people who want to rather have more and people who rather have less. And, you know, I think maybe what we have is kind of like the right compromise. And if not, I think it's possible, technically, to move out the additional requirements to some other documents that would expand on, you know, and maybe it cannot be mandatory, but it can be like, you know, kind of recommended requirements that projects might take into consideration. This is Brian. Can I make two specific proposals? Because I, you know, definitely, you are correct Arnaud in characterizing both the conversation when we last talked as well as the one on the 10th. And I'm also looking at heart female from the 11th as well, which I know Chris responded to. And what we're all converging on is some degree of comfort with saying that the additional requirements should simply be rephrased additional consideration. And we suggest projects may want to look at this, these these ideas and at some point it may make sense to move those out into something else that is more about, you know, things that projects want to be thinking about throughout their lifespan. And certainly as they, as the, maybe we think about that in the project life, product life cycle, you know, and the naming convention kind of doc. But getting back, the specific proposal I would make, rename this section additional consideration. And then I've got a second proposal, but first let me just set that out there, see what people think. That kind of makes sense to me, because if you look at one of the most efficient real world usage, I think certainly in some domains or some industries, you won't see much real world usage until a project has graduated. You can't simultaneously be incubation and be production ready, even though we need to distinguish between team and project maturity and product maturity. But at the same time, there has to be some view as to whether the thing is vaguely credible or not. So that kind of works for me. I know it sounds like a fudge, but it works for me. So I've actually made that change. And Brian, I think that's a good compromise. Okay. And so if you refresh the page, if you're looking at it, I've done that, I've made that change. But now Brian, I think you said you had another proposal. Yeah, because there were some concerns about security, code scanning, that sort of thing. So my second proposal would be that the project aim to implement the core infrastructure initiatives badge for secure processes. And if I can direct people's attention, I'm not on WebEx, but if you go to coreinfrastructure.org, this is a Linux Foundation collaborative project. It's the one that funds the OpenSSL development. One of their programs is a badging program to basically establish that a project has achieved a best practices badge around being able to take security notices and treat them separately from your other bugs, for example. And so maybe this is something we can defer a week to look at later, moving forward on the first proposal. But if we're trying to evaluate how well this team is able to respond, well proactively look for security issues and then respond when there is one, then the badge is the only thing out there in the open source space that is a benchmark for measuring that as an attribute of the team, not of the product. That certainly seems reasonable to me. How would a badge program get your badge? There's only one badge? Only one threshold, yeah. And you didn't have to answer those questions. And that's basically having the processes in place to be able to accept security critical vulnerabilities and so forth offline, work with them, and then use the appropriate notification processes to roll them back out to the communities, essentially, with that saying? Yes. I don't have a problem with that. Hi Chris, this is Ali from DTCC. One of the feedback I do want to add, I like the idea of the badge, but I think it's very important that we be very objective. I'm good with the minimum requirements, but these have to be implemented or tied to, we should tie it to some objective metrics, right? Otherwise, this may not mean a whole lot. What is sufficient testing? What is sufficient user documentation? What is continuous setting up for continuous integration unless you're objective? And we can start with some minimal, you know, bar in terms of implementing it and we keep raising the bar or have the badges. But it should be driven more objectively rather than. It's a good starting point, but I think we should keep the implementation and objectivity in mind. So how would we defer that second proposal till later and get agreement on this document as it stands with that as a potential addendum later? And we can go back and review the criteria. They are more extensive than just a reporting process. I was just looking that up and I cut and pasted the criteria into the chat window for the go-to meeting. I'll send it around to the TSC mailing list as well. So I think deferring that so we can all review that and see what it would take. But it's designed to be a self-adastation as well. So it's kind of how strict do we want to be about it? But we should try to be consistent, if you think. Brian, it's Wipin. I read over some of the criteria and they are not vague. Many of them are very specific and it seems like a good idea what you proposed, but of course people need additional time to absorb these criteria. I agree with you completely. So, Wipin, I tend to agree. I think maybe the one that you could potentially put some sort of objective measure around would be test coverage. But I think we actually had this discussion in the past about not putting some sort of percentage or something. Because, again, we're talking about the maturity of the project, not the product. And so I think what we said that we were looking for is, and that's in the clarity below, but is the project must include a comprehensive unit and integration test suite, document its coverage, and provide potentially additional, for instance, skill test capability as being a desirable thing. It's not really saying that it has to have a certain threshold, but it is saying that you have to be able to measure it. And it's saying that you need unit and integration test coverage. And obviously I think there's security and performance and pen testing, various other things that I think from a product maturity perspective you'd want to see. But, you know, again what we're talking about here is the maturity of the project, which is really the individuals that are working on it, and are they doing the things that we desire to see them do. And so in this regard, I think these things are describing the things we'd like to see them do, and not a measure of what they have done. Does that make sense? Well, in the cryptography, for example, they say things that are very specific. So that would be a good thing to have.  No, no, no, okay, I think there's a little bit of confusion here. So in the context of the badging, I think the badging is you're basically going through and answering, do you have these things? And would Brian have a disagreement? I haven't done it. I will do it. And I think it makes sense to add something like this. Do we have a process in place for being able to handle security, incident reporting, and so forth so that you're not freaking people out, but that you are doing due diligence and managing the incidents, doing the remediation, and then effectively communicating this back to the community and applying the patches and so forth so that you aren't putting people, you're not exposing people who are who may be using the software unnecessarily. I think that's, Brian, what you're getting at is to be able to answer the question that you have those things in place. And I'd be happy to add that. I think that's something that's objective that we could add. But then I think, Vip and what you're referring to is the additional considerations, which is I think what everybody was getting hung up on in terms of scale and all those things below, those things possibly do need, because it's got maximum transactions per second and so on and so forth. Those things I think maybe I would agree that if we were using those as a measure of, is the product ready for prime time, much less production usage that I would want to be able to measure those kinds of things, and that maybe we do need to be looking at potentially having an objective set of criteria that we're using to measure, whether or not something is baked yet, which is again why I was initially considering just dropping that whole last section, simply because it was confusing. But again, the additional considerations I think is a good compromise, because while we might be considering these things, it's not necessarily that we're looking to actually objectively measure them as a specific set of criteria that we're looking for to grant a request to exit incubation. So, Chris, just a comment on that. When I read the additional considerations, and I like the section in principle, precisely because it's not requirements, I was looking at this more as can we use this document as a tool to help projects articulate what they're about more clearly. And thinking about, I'm not in favor of somebody saying there has to be a minimum transactions per second standard, but a given project should be able to say, hey, we're about high performance transactions. We should hold ourselves accountable to a particular criteria. And I would suggest a similar kind of thing about security. We need to encourage appropriateness, but the requirements for something like Navigator are likely to be radically different than the ones for Fabric or Ohar or Satu. I agree. I don't think it's a one-size-fits-all criteria. Yeah, I guess what I'm saying is it should not be prescriptive. It should not be limiting. It should be like some kind of consideration. In fact, that was the whole spirit in which we started out all these projects that people would look at what each project has done. And then if they want to use it, they will use that as a guideline in order to actually use it. Instead of just saying, oh, this has to pass the threshold in order to be released as a project. I agree with it, leaving it as additional considerations, because having some other metrics, whatever you can release on the project will force people to basically come out with some kind of metrics on their particular project. And then the adoption will depend on that particular output rather than somebody saying, no, we cannot do this. You cannot release it into production without whatever. Exit incubation without passing these criteria. I totally agree with you, Mick. And I think we are all sort of in the same page when it comes to that. We don't want any hard criteria because not every project is the same. Chris, I hear a lot of support for this document with the modification that you made with the additional considerations. Is it time to just vote on it and put it to bed and move on? I'd be happy with that, Mick. So I suggest, Todd, you want to maybe call a roll. Again, if people are not comfortable yet, then please vote no and say we need more time and more consideration. But I think I agree, Mick. Can you just be clear then that it's just the document as you've updated it today and this discussion about badges is a separate thing from later discussion? That's correct. Okay, we'll run to the list quickly then. Arno? Yes. Ben? Yes. All right. Chris? Yep. Dan? Yes. Hart? Yes. Mick? Yes. Morale? Yes. Richard? I think you had a drop. Yep. Okay. Sheehan? Yes. And Tamash? Yes. All right. So that's unanimous. Thank you. I'll start a conversation right about the security badge on the TSC list. That sounds good, Brian. Again, I think that's a good idea. I think Mick is right. We should probably just sort of get this done and move on. Okay. Thanks everybody. Next up is, I lost my place holder here. Next up is the cello proposal that Baha went over. There was a little bit of discussion, I think, on the mailing list. I weighed in when I got back from vacation. And so I think we left it as of the previous call that we would take a vote today. So I didn't see any other discussion on the list. So I would suggest that we just put the cello proposal to vote. Well, I think some of the verbal discussion we had during the proposal was whether cello would have a better chance of success being merged in with the Explorer project, rather than having it be an independent project. And so that's kind of working on things. So a few people were going to go away and take a look at things and see what they thought of that. And I think the Explorer working group or project team might have had some discussions or I was left with the impression that they were going to. Some of the folks that I interact with that work on that team took a look and that seemed to be the direction that they were leaning towards. Ah, okay. I didn't catch that subtlety and I apologize. If that's the case then I didn't see the other discussion on the mailing list and maybe I was looking in the wrong places. Yeah, I don't know. Is there anybody from the— I think it was more verbal. That wasn't captured in the meeting notes on the 11th, posted on the 11th, from the November 10th conversation, which I think was our last one. Yeah, that's why I was saying I didn't catch that. So thanks, Dan, for bringing that up. And if that's the case, is there anybody from that working group or from that project rather that can share with us what they discussed? So hi. Yeah, this is Partha from GCCC. We actually wanted to talk to Bo. I bought the tele-project because of the synergies that are present between the Explorer as well as the tele-project. But because we were busy with the SDK, a common SDK spec, we didn't take that discussion further. So I think that we are on that same idea that both have, since both have a lot of commonality, maybe we should find a common place for them to be hosted together. But it's not at finalized. It's not finalized because people are working on other things. Okay, that is fair enough. And in that light, then, what I would propose is that we defer this until that conversation can be had. Does everybody agree with that? Or does anybody disagree with that? Because it sounds to me like maybe not all the people need to have that conversation around this call and move. In which case, I think we should just try and work this offline and come back when we've had that conversation. Chris, this is Bofa. And I guess if we have time today, we can just make the conversation for whether we, how we can integrate, like, shallow with blockchain Explorer. And actually, there are also other suggestions from my side, like in the proposal. And I guess I would also like to ask you guys from Huawei also suggest how to let, to make shallow support the OpenStack platform as the underlying platform. I guess those are also very good questions and we can discuss them here and how do you think? Well, so, Bawa, I don't mind having that conversation now, but I think the point that I was on is I'm not sure all the people that need to be having that conversation are on this call. And so, I think probably the best thing to do would be now that the SDK is settled down a bit and we're in the process of looking at that just from a review perspective that maybe we should just pick this discussion up, put it on to either the technical discuss list or the TSC list and mailing list or in the forum and start having that conversation. That would be my preference at this point. And if we need to have a call, we can certainly arrange for something or we can maybe even have a conversation next week when we're all together. But again, I don't think all the right people are on and I think it would be unfortunate to have the discussion and then have to go back and revisit it because somebody missed it. So that would be my proposal is that we just sort of take this offline, put it on the mailing list, and if we need to pull together a call, I'm sure that Todd and Brian can help facilitate that. Okay. My session is like next week we can discuss because we'll be there in New York City. It will be much easier, I think. How are you? Bawa, were you coming to New York? I was not for this time. Okay. But maybe we can bring it out. Maybe arrange it. We can have a call. Yeah, we may talk through a call. Yeah. Okay. All right. Well, thanks. And apologies for not catching that bit. So the final topic is the China Technical Working Group. Brian, I think you were on the hook for like a charter or something. Right. And I think there's actually two more topics. So I'll try to be or at least one more after me. So I'll try to be efficient. But given the positive response, I just did a little bit of wordsmithing on the proposal from a few weeks ago and created a Wiki page for it with a couple of determined items to put in in terms of links to the conversation tool that they decide to use, whether that's to the WeChat page or to some other place, that sort of thing. And then they really just reframed what I'd said before and proposed three specific individuals as our working group to serve as this bridge between China and the TSC. So thought it'd be worth proposing. And two of those three have accepted Bala and Victor. Charles had mentioned this before, so I'm pretty sure he'll say yes. I just hadn't gotten confirmation from him yet, but I feel like we could probably take a vote on this, adopt it if he needs to change. I can come back and propose another name. And then we revisit that in six months. Okay, so let me just sort of recap. So the governance would be that the TSC would name the chairs or the leads, and we revisit that every six months. And where was the proposal? Did I miss an email? Thanks. An email to the TSC mailing list a couple of hours ago. Oh, and I've been offline all day, so that's probably why I didn't see it. Okay. Okay. Yeah, so if you go, just look earlier from today, five or six hours ago, and it was in reply to my original thread. So if you're using a threaded mail reader, you've blended it in with others. Problem is, I'm my threaded mail reader. When I search for people and it's coming from a list, it doesn't search, right? You can't just sort by date. Hold on, I can't get way too much email. China Technical Working Group. I don't see the note. Oh, to the technical. Yeah, I sent it to the TSC mailing list, and it's called, Technical Working Group, China. Looking in the wrong place, that's why. I have too many mailing. Got it. I see it now, thank you. Okay, so the proposal then would be that, based on the charter, which looks good, that we would take a vote then on naming these three? Yeah, on approving the charter and naming those three. That sounds like a plan to me. So Todd, you want to take a roll? Everybody clear on the proposal? So the proposal is accept the charter is written, and accept the three nominees, Bawa, Charles, and Victor, as the initial leads of the China Working Group. So Todd. All right. Okay, running through Arno. Yes. Get in. Yes. Chris. Yep. Dan. Yes. Hart. Yes. Mick. Yes. Morali. Yes. Sheehan. Yes. And Tamash. Yes. All right, great. That passes unanimously. Great. And I'll go on and on with you with those names and get this rolling. Awesome. Thanks, Brian, for driving that. And thanks to the three, congratulations, I should say, to the three chairs. So, co-chairs. So the final topic is Mick. You sent, I think it was a private note to me and Brian and Todd, but maybe you want to sort of recap your point on the sort of the need, potentially, to have formal charters for these various working groups so that we have clear direction as to what we expect of them and so forth. Do you want to maybe recap that for the team? Sure. Yeah, so, you know, I'll say just in the context of the White Paper Working Group, you know, we've been working on the White Paper for, well, on the order of 10 months now. We've had more or less two complete drafts. And in each case, when we brought the White Paper back, there's been such an incredible diversity of opinions about what needed to go into it that we kind of threw up our hands like, okay, you know, how can we possibly be successful in this? And one of the things that seems pretty clear that's come out of that is that it's very difficult for a working group, I'll talk from the working group side, but I'll talk about the other side as well. It's very difficult from the working group side to make progress when we are trying to meet the requirements of absolutely everybody who's out there, meet every requirement of everyone who's out there. And so for the White Paper Working Group, for example, I know the thing that the heart is driving right now is to get clarity on an agreement on a specific outline. So the charter becomes, if that group becomes, write this paper with this outline, because in that sense, that gives us, as working group participants, the chance to be successful and actually completing the delivery of something that meets an agreed-upon set of requirements. The flip side of this is from the foundation and technical steering committee perspective is it's not obvious to me what's going on or what the deliverables are or what the outcome, expected outcome is of any of these working groups. And as a result, it feels like it's just another meeting on our weekly schedule that we have to participate in without having any clear set of deliverables. For our projects, we have required a proposal with a clear set of deliverables, a clear scope, and participants. We have not held the working groups to the same kind of rigor. And yes, I understand this is an open-source community and we all have to, many of us are doing this voluntarily. And at the same time, for us to feel a sense of progress and purpose in those working groups, both from those who are trying to consume the output and from those who are participating, having a little bit of clarity around what the expectations are, what the outcomes are, and what the deliverables are would make life a lot easier for both sides. That's just observation in working and, you know, Rah, I don't know if Rahm's on the phone today, but Rahm could talk about similar kind of things in the architecture working group where we've had fantastic discussions, right? And I think both architects, both of the fabrics have been influenced by the architecture group discussions. We've had similar good discussions and identity, but there isn't an end in what we're doing. So anyway, I'll leave it at that. It feels like we need more of the kind of charters that Brian wrote for the TSC. So I want to thank you for bringing that up. I tend to agree that if we actually sort of had formal charters for the working groups, that that would help derive a certain amount of focus. I know that there's been, certainly, and it was commented in the chat there, that the other groups have these, essentially the same issue, whether it's architecture identity. And probably the one that is probably the clearest is the requirements, because we all sort of know and understand what requirements and use cases are all about. But of course, knowing when they're done is also a different thing. So I actually tend to agree, I think it actually would probably be useful if the working groups could document what they were all about. We started these things, and it was largely somebody saying, hey, we should get together and we should talk about architectures, and so that I let Ron sort of drive that. I think that's a good thing. I do think, though, that maybe it's time that we did get a little bit more rigor around some of these things, and I think actually having a charter would be a good thing. And so maybe the thing that we do is that we should sort of let the groups go back and drive a short process of bringing forward a charter, let's say by, I know it's, we're in the holiday season here, but maybe if we can sort of request that for the beginning of January, let's say, no later to bring forward a charter and we can have that discussion amongst the TSC and with the members of the working groups and then leverage that going forward and if people need to change the scope of their charter, they can do so. But then I think you're right. I think it would help people understand what it was that they were expecting to be doing and how to declare victory and it would also give people an understanding of what each of these things was. So I think that's really a good idea, Mike. Thank you. And, Todd, this is Lennon's time to say I certainly agree with both of you. I mean, it's certainly without the clarity in terms of understanding the purpose of each of the working groups because a charter must have scope and the scope defines the area of the focus, whether they be criteria or high-level requirements or input or exit strategy. So that is certainly a good thing to have. So I'm very happy with that. We all agree that that's a good standard approach we have to adopt with all the working groups. This is Arno. I've got to run, but I totally agree. Yeah. I think we all have to run. We're just past the witching hour here. So I'd like to thank everybody again and so Todd, just could we put in the actions that each of the work groups is expected to pull together a draft charter and present it to the TSC before, let's say before the second week of January? Great. We'll do. All right. Awesome. With that, I think I'll thank everybody and we'll talk to you. Hopefully we'll see many of you on Monday and Tuesday. Yeah. Thanks, Todd. I'm trying to make it. Thanks, guys. Thank you. Bye-bye. Thank you. Thanks, everyone. Thanks.


things. The things that I want you to kind of get out of this is that if you want to do this, how do I recommend it? If you start with a little cool, you work on the tech that you want to, and hopefully you can make some money today, but at least work since then, that's good as well. There are a few simple things that we kind of need to learn, and they are all very simple. There are things that I didn't know that kind of taught, and it's difficult to see if you have any good ideas if you actually have a business idea. Besides, I work for a company, so this is kind of stuff you don't even know. If you don't even start a startup, this stuff you should know about the company that you're ready to see. It's going somewhere and whatnot. Why should you listen to me? Because my vast experience with a single startup isn't even done. I'm just going to share some of the details of what we've done. That becomes exceptional and what we haven't. Hopefully this will be of help. The first thing to know is that ideas for businesses, or any ideas, are really cheap. Instructure is my startup, and we do software for education. I'm going to take the class of the university that's going to train the scientists, that's going to get course content, message your teacher. I think everyone who has used that software at school taught, this is also going to have to do better over the weekend. Am I right? This is not a new idea everyone had, so it's not going to keep secret. And you'll find out that this is a case of business ideas. There's really nothing secret about the idea itself. It's actually the execution of the idea, and you can write people and all the time. How I got started is that I wanted to do a startup. I think you do a startup for two different reasons. One is to change the world. The second one is to make money. Hopefully you can do both of them. I was in grad school, and I took an entrepreneurship class. I was going to study what I was going to do with my life. I was going to go work for a big company. I wanted to work in Ruby. I wanted to do something interesting to change the world. I came to this, I took a course with my co-founder. All of the ideas that we brought to the course, as soon as we learned how to outweigh them, it just got shot out of the sky really easily. The first one that really suits all ideas now is good questions.  Essentially, all this is saying is how much money is being spent on what you want to build, and you actually need to find out this number. The number might not exist, but you need to do some type of research to come up with something you can justify and defend. In our case, it was very simple because the main competitors in our market were public companies. They had to guide which how much money they made. It was very simple to say, okay, this person has 50% of the market. They made this much revenue. This is how much people are spending in our market. It was very simple. A lot of the ideas that we had were just too small. There was nothing we could do with them. So it's all the advice of Paul Graham. There's a lot of good advice. One of them we took was he said, if you're a technologist, you know how to code, you know how to build technology, you just think of the suckest offer that you've used, and there's probably a business idea there. Now there's one caveat. You don't remember that you're pretty weird. So a lot of people are like, here's this cool plug-in to, yeah, like developer plug-ins, or you need to think of ideas that are painful to you that you can use that normal people use, too. And then depending on those, you look at the size of the market, and then you can kind of look at the two main tasks that you can take with Starlight. So what I'm about to call a lifestyle business, for them is adventure Starlight. Now I'm a big fan of three-sit-and-signals and a lot of what they're doing and stuff, and essentially a lot of their advice is to say, build a lifestyle business. It's a great business, and you can do really well. And then adventure capitalists are going to say, oh, it's rough. So the difference is, lifestyle business is a business that can make you some amount of money.  It's got a lifestyle business. Now adventure Starlight is the one that's going to change the world. It's going to take a lot of resources to do that. So the adventure way is a lot more risk, a lot more money to lose a lot of control, but the path could be bigger. It's a bigger potential. So I think against lifestyle businesses, I think they're cool. I just couldn't think of an idea like that. It was cool for a lifestyle business. The moment I came out with it was more in the adventure line. It was one of the, like, you should fail on the side, right?  I think it was really cool. If you can't, there's some ideas that that's not suitable for. You need to be full-time with, you know, a team for like a year in order to have a client that's going to do that much to profit. So in order to do that, well, you have to have money to last for a year, which is potentially a higher reward. Okay? So, okay, so what we did is that, okay, so you gotta, whatever your idea is, is you have to find out how big the potential of it. And depending on how big it is, then you can go these two routes. Now, even though you're going for lifestyle business, well, we went for the venture startup route, but the same things that are valid for a venture startup or the questions that investors will ask, is that you should be asking yourself in the lifestyle business, too. So even if you're not going to have an investor, just pretend that her name is Ashley and pretend in your mind what questions she would ask. All right, so a couple of things is that you need to know, if you're ready now, if you've got a market that's big enough, I'm going to repeat this thing. Rule of thumb, if you're a market, you say that all the money spent in one year is less than a billion dollars, that's a lifestyle business. And that's one that is probably not suitable for a venture startup, because at least these are not going to be interested, because there's not enough payout possible in it. But if you've got an idea of where people are spending more than a billion dollars, you know, like a billion to a billion and a half, which is like, of course what it is, then that's wet on the cusp of a venture startup that's something bigger for us. Okay, so that's kind of the rule of thumb, but if the market is under a billion dollars, that's probably a lifestyle business. So you can still have to really be fine with the lifestyle business. It's just not enough that the outpouring investors do something well for you, too. Okay? So we pick the venture way and then you've got to do your research, right? In our product validation. So you need to know where the competitors, right? Why aren't they at it? What's the pain in here? The pain is an opportunity. And then you need to know if you're building the right solution for the lifestyle you're acting in. So in ours, you know, we were students, it was, you know, it was just terrible when I had the software. We could do better than this little problem and then the advisors will know because students aren't going to buy the software. It's the schools. You have to know what schools need, right? The software needs to go upon it all. You need to know if what you're building is the right thing because it doesn't matter how good your development team is. If you're building a wrong product, you'll never succeed as a company. So, in ours, it was very simple because we were going to sell to universities. And so we needed to validate our product. So what we did is we went to Google. We started finding all of these schools that we could go to where we had like family where we could, you know, just sleep on the couch for free. So we decided, we're going to go on a road trip. That's how we're going to do our product validation. We went to a conference, we were going to do the beginnings. I don't know if you've ever seen this picture before. But that awesome load, that awesome sign is our booth. And then gas was super expensive like it is right now. So we borrowed my brother's Geometro and we headed out on the road and we could like 130 degrees in base and we just spread it and went in and out.  So we would count, we'd introduce ourselves to this what we're trying to build and we would just full talk and say, we're going to build the next great system and we'd help us design it. Either that or we'd just walk in and pretend that we had an appointment and it worked really well. So we'd say, sure. So then we came in and we'd say, okay, here's these pain points that other schools have expressed about their solution and this product. Now the first time of course we made these up and we just made them sound reasonable and we said there's another school that says they're having this pain.  And then we say, what other pain do you feel that's not all? It's terrible.  So before we wrote any code is that we mocked up our application to PowerPoint. So, and the idea is that in a PowerPoint we can get feedback from the people about what they want in the product and it's something more valuable than even code. More valuable than reviews. So I'm going to show you a couple of slides that we used to do this. There's our old logo and all this kind of fun stuff. Okay. So this is what we mocked up in PowerPoint. I say, okay, this is our scenario. I'm going to create a course. It's like here. We'll take you to the screen where I can manage my assignments.  So a lot of this was actually in the user interface. It was that we nailed what was the essence of the task that they were trying to do. This is how we assemble our shortage. And we just used the user interface to define it. Okay. So are these elements on here? And this was a little bit tough for us. Michael Hunter, his advisor is how I've met these building forces. He said, well, they never, ever give a screenshot to a potential client because instead of telling me what's wrong with the interaction, they'll argue with you about the space to be over here at this rate to be sort of wider or something like that. But I think you lost them in detail. At the same time, we couldn't go to someone saying, well, here's the sketch on the board and what's the next generation of running management systems that you're going to pay $1,000,000 for. So this was our kind of, you've got to walk around type ropes. This is what we did. And so some people were confused. They thought this was an actual application. So it just, it had to be enough to say, this thing could be real and we'd shake ourselves, of course, we could do it HTML and the same as that. And then, you know, we would make sure that we had the essence. That's what we're trying to get out from there. I don't care about that assignment and the types and whatnot. And so we kind of walked through there to kind of say, seriously, we had something concrete to actually send back stories about. And so we'd say, I saw on my calendar, over there, all the cameras on top of each other.  This is all slides, one piece.   But you really don't know how much people are suffering because people would almost like stand up and tear up and give us applause. It's because we used to, like, we pick good tools for us, but we're not like normal people. And people actually use terrible, terrible, terrible tools. And something like, as simple as a drag and drop, is, you know, so simple, and it's not gratuitous, it's just intuitive. And it's something that they didn't even know was possible. It's ridiculous. But that's good, because that means that there's an opportunity there. It's so simple. It's a seemingly great idea. You just have to be confident. And so what it is that we, you know, we have that one scenario kind of song. We've got a bunch of, we've got three or eight month slides or what, because it's not that quick, but I'd like to show you. And then from that, then we, I would present and then Brian, member of my co-founder, saw the pictures. He would just curiously type all the notes. So we took the transcripts of everything that we had. So we don't prefer them like, well, I always go back to it. We would go back to find out that we had forgotten something that was actually said during the conversation. And so you keep those transcripts. And our first time we did it, we went down to Bay to guess. It was my sister and we met with a couple of schools. And, you know, no one was like, awesome, we got some good ideas. But, you know, you don't know this and don't know that. And then we came back and we talked to our advisor at the time and we read that our idea is done. And he looked at it and he read it and it was good and bad. And he says, you know, this right here, this is gold. And I remember being surprised at that. And I go, why do we think this is gold? Because we have done the work, you know, exactly what they need and the pain that they're having and you know all this information about no one else in the market knows. And then we just iterated on the clock. We took all that feedback and put it into our PowerPoint slide deck and we did it again. And we just kept doing that where each school, we saw about 17 schools until our design didn't change anymore. That's when we knew that the essence of what we're trying to build was the right thing. Okay? Now, the thing is, is that, you know, is a real love. Okay? Because I think there's a tendency to say, I've also had an idea of something. That's obviously a good idea. And, yeah, you should do that. Okay? That's not hard. Okay?  So, I'll show you a few of the exercise that we have in the net. Let's say, would you pay for this? PowerPoint, would you pay for it? How much would you pay for this, right? And then we asked, of course, how would you pay because we're trying to figure out our business model, how would you charge it for it? And so you can ask, would you pay for this? Sure, no or no. I mean, but you know, it's not like, I think that they would buy it, but they just ask it. Because you got it all.   And it's okay to be bold and just ask. Okay? Then we asked the mother of Paul questions too about how to do the straps for the collie. This is our gut check. This is how we presented ourselves. How are you hearing it? How are you interpreting what we're presenting? How are they describing it? And then also, you know, is this basically a double line just to kind of gauge the excitement or not excitement? Which is also very interesting. Okay? And this actually worked really well. People will be candid.  And then you get the same and good information. So towards the end of our meeting people say, should I go on a trip? And then we get it in there. We've got half that's valuable almost. And, you know, it does the information we need to know. What is this person actually going to do? Is there a product that needs to be directed at? It's actually that we knew that the product that we were building was something that people would buy. We knew that if we built this thing, if we built it, we'd buy it. If it existed today. That's where I'm explaining that it's not a real app, you know, that we actually haven't built it yet. This is before we were able to do it. Right? And so, at that point, you know, you've got to get to that point. So these are all pushy steps. You've got to find out are you actually going to build the right product? Are you going to make use of what's happening with it? So, okay, so let's say that we're defining our market and let's say it's big enough. Define some pain in the market. So if anybody, if they talk about pain, like, oh yeah, that's such a bother and it takes me like two weeks.  And then let's say that we've already gone and validated and thought, are you that? And the answer is absolutely not. We need to do a business model. Now, the business model is, what you're trying to do is that you need to make a machine. Business is a machine of itself. So in addition to its software, you got to, you know, the business has to say, okay, we have this customer, we have a way of getting him and we can make money from it. We've got to make a machine. There's a bunch of different types of machines. If you're a monkey, you can make the best machine, which is the Instructure Con. I showed it to, we have this at our office now. We have a designer connection built Instructure Con.  All right, so, the business model is a machine. And you have to create it, like, virtually before you actually put it into the mind. Okay? And so I'm going to do that is, you're going to pull out a step, and then you're going to do a ton of different models. You're going to have this wicked spreadsheet that includes everything, okay?  And then you're going to say, okay, well, we need two developers in March, and then another three in December. All right, you have to map all that out, and see how this goes, and how we look for our customers. Okay, so this business model is catered specifically to what you're thinking, right? So, one, it could be like, we actually have to talk to every customer. But maybe another business that it would be, it's a freemium model, so I'm going to do some advertising, because we're going to use it for free, so you can model how many people can we get to sign up for free, and what percentage of those we're going to convert. And then you model that out, and you're actually putting the conversion rate in this big, batch spreadsheet. So I put in a picture of a spreadsheet. This is a super, super simple one that I just googled up real quick. This one is just that one employee, and the other one employee, too, and assumes that that click through rate is stopped. So you make this huge spreadsheet. This is where you have your brother model to a business school, and he has an MBA, and you don't know what he's used before or anything. This is what he'd feel for you. So... So, you know, you're going to have eight catalogs of your spreadsheet, and it takes hours to dig into this, and then you're going to, the best thing to do is sign up for the free new model, and you're going to be able to identify all the different knobs that make your company go. So if you're in a free new model, the obvious amount you're going to have is what percentage of people coming to my site that are going to sign up for the free new, and how many of those are going to convert. So that's, like, a little knob, so you just put it right there in your spreadsheet, and you have all your graphs, and then as you tweak those numbers, you can see how it affects it. And so, at this point, I'm going to report by revenue and gross margins and operating margins, you know, just the simple things. And you can see, can I make that model as I need to make it reasonable, but it has to go to make money. And if you can't get that to make money, then don't do the company. That's the kind of key there. If you can't make a work on spreadsheet, it ain't going to work. And so, if you can make it work with reasonable assumptions in it, that's the key. So, so this is the part, this is actually the crucial piece. So, I was never once asked by any investment analyst or any investor for a business plan ever. What they wanted to know was they were going to meet and give a little presentation of who we are, what market are we in, what's the pin in the market, and how are we going to solve it. This is how we know and here's our model that says that we can make money. And that's it. And then if they want to go further, this is the only thing they want to look at. Is your model. Send over your financial model. Send over to that spreadsheet. Now, I think that our spreadsheet on these slides, even though they've been more useful for you guys, because your business model is your business. And so, if someone had a business model, they can do new business. And so, that's actually the essence of your car company, is your financial business model. So, you don't just give it to anybody. Right? Okay, so, and then, I guess some other points up here. I had some misconceptions about investors as well when I started. I kind of had the feeling that an investor was this totally rich dude and you had to, like, make a tent and come in, and just give you the money. I hope this business doesn't work out. And I don't know why I thought that. Do you know what I was thinking that way? So, it's not true at all. Okay? Specifically, venture capitalists, they go out to other really rich people, like universities, and huge funds, and they raise money from them. And so, like, a good size venture fund is like they'll say, we're going to raise a billion dollars. So, if there are all these other investors, these institutional investors, then you give me a billion dollars and they have to invest it into small companies. And then those companies are going to grow and go public and make money. And that's how they give, they make back to the people that they're making money for. Okay? So, actually, an investor or a venture capitalist, it is their job to actually invest money in companies. And they're actively looking for good companies to put money in. So, it's not like, you know, you're not, you're doing them a favor. It's not, you know, they have to be usually they're actually looking to get to the best point of good companies. And so, and that's true of other investors as well. I mean, you can angel investors, you know, wealth individuals, they want to put some money, the term of the use of that, I'm going to put my money to work. Right? Because I was going to sit down, let's get a good return off of it. Because if you're starting to successful, then you're going to make a lot of money. And so, that's kind of, and so, this is how you prove it to them, is how you're going to put their money to work. It's going to be in your model. So, you give me this much money, that's going to allow me to hire three people and a PR guy and according to my model, my inversion rate, if any of you are close to that, then you're going to make this much money by next year. That's what the national law should tell you. The other question is like, well, how much money should you raise? That's actually from your national law too, is how much does it tell you to need to raise? You just run it to say, I have the money right now, and you should go with the negative. And you say, how far do you go to the negative if you're close to making money? And that's the exact amount that you're going to actually need to raise. So actually, I'm going to give you an offer about that. Okay, so, there's a couple of funding options. So, this is a good point too. The top one there is closing credits. Don't be really careful with this, okay? So I don't suggest that anyone drop. You can start out by moving out a ton of loans. You have to know that what you're doing is actually going to pay off.   And of course, there's an alloy. You talk about angles, and you go to the VC ramp. Or if there's even a grant from the government that you can get, they might encourage you to do some more. Or you can do whatever you want. You can actually use the revenue to go off. So, I want to take some questions. Let's ask the ministry of structure. So, essentially, let's have some ideas. I'm going to get some questions. What do you guys want to talk about? Please. Number two, I've been through, well, actually, a three-year start-up. Okay. And there's the objection of, okay, so give me your references. I'll talk to you. You'll buy yourself one. That's number one. Number two is, okay, you projected three years, you know, 6,000 man-hours. And that ends up being, as usual, 25,000, 30,000 man-hours. So, how do you deal? Okay, so the first one you said how do you deal with was with a customer. I did customer and they wanted three references. So, what we know about that is that you build a kick-butt product. That's how you deal with that. You're going to find someone who's going to say, if I get off your product, it's going to save me this much money and it's going to save me this much time and this much headache. And all this pain in my experience is going to go away and you'll find someone that doesn't matter if you have a reference. At least in the product. And that's the only way that I know how to deal with it. Okay? Yeah, but you've got to find them. Because those are the early adopters. And if you don't get those, then you won't get any adopters. And so, that's a good thing to discuss. If you can't get someone to do that, then you're not solving enough pain and your product is to focus enough. And the second part was development is always, you know, taking the number of the product Okay, so the idea was that your estimates are completely way off in your development. Okay? I think that's, you know, it goes back to the development of the product.  We actually put that as part of our kids. So we actually looked this up. These are our ideas. Here's a huge fact feature list. And we'd say, but we can't do that at first. And so we take them away like, this is what we think if we can do within the next six months three months, is that good enough for you to buy? And they'd say, no, I need that feature. I need that feature. You're going to be like, okay, if there's $100, how would we allocate that process to teachers? And if I wish we should actually do it before which was the half of an hour. So that's how we kind of did it. You get the minimum liable product and you iterate that crazy. Because you see in a pattern in how far in the future the investors wanted to see in a return on investment before they were going to get a pattern of how long investors wanted to see how far out in the future before they would see in a return on their investments. Okay, so how far out of the future would we need to ramp up for the investors to make the amount of money? Well, before they were interested. Before they were interested, okay. For an adventure person, is that you need to hit about $40 million in revenue for a year with about $45 million. $45 million. Because that magic number is $40 million a year is when you can have a successful accurate. And IPO is where public and buyer shares can stop and that's when everyone can get their money out including investors. So if you can't be showing somewhere between $8 to $12 million a quarter within the four or five years then that is not interesting for an adventure guy. They'd rather take more risk to get more payout. Can you talk about from the start-ups that I've done I've seen, you know, where you ask people flat out would you pay for this product and I find people will almost always tell you yes but that's not the case in my experience. I've had products where people will tell me yes and then they don't and other cases where literally people told me no we did it anyway and they still bought it. Okay, so the question was in his experience where they would ask point out if someone would buy the product that they built it and they would say yes but then they wouldn't buy the product and then you'd have the opposite of two where they'd say no but then they'd actually need the product. You know, I don't know if that's the specific instance I guess but I can tell you with some of the faults that we had that were kind of difficult to mitigate was in our specific case is that person who was telling us to buy it or not was not the actual person who would make the decision. So they'd say yes but then they had no power to make the decision so their answer really doesn't matter. So you've got to make sure you're asking the right people. So that's one thing that we did. I don't know if that helps anything. Yeah, I mean did you see that where it didn't noise? Did you have people that said no or was it pretty universal but well, part of it is that the best case scenario is that you actually do a pre-sale, right? Yeah. I mean that would be the best case but a lot of times that's not possible it wasn't possible for us either but the thing you're after is that with someone reasonable in their position that you're trying to market to and make a product for would they buy it? Because in the end, like other people that we met with no one bought our product yet I think a good person would have it not all but it's a lot of people in and it's a lot for them to do. Alright. Is your mockup looked real nice? Did you have a designer or something to put that together to use this particular tool for this? Okay the question was is their mockups look half decent and do we have a designer do that? Our designer was Brian Whitmer in PowerPoint. Builder actually does PowerPoint squares. My other question is you were approaching kind of corporations or small businesses where they have like one skilled person like a doctor or dentist or plumber or whatever or something like that. Would you bring in several at a time or would you talk to each one on one and how would you approach them differently from going to big universities? Okay so the question was we went to universities so they're big entities what if you go to small businesses and it's just like one of you guys how do you do that? Do you bring them in?  I don't know. It just depends on your specific case. You just need to know are you getting the data that you need out of it? Are you getting the data of what the pain points are on that mark?  You just need to get the data one way or the other. Okay Andrew said it was pretty tough. What is the problem? Do other things have almost a mechanic's sermon that can actually really become a bigger product? I couldn't hear you on the microphone.  So what Andrew is saying is that when you get to the point where you need to raise money then there are some great resources online venture hacks, Angel List a couple of those that people that are more experienced can help you navigate through it. Yeah, there's some sermon to pitch that. There are some things that kind of help with that but the key part is that you can't be chatty and you can't when you go to raise money you've got to be focused. You've got to say this is what we're doing this is what we're going to kick about and I've got the model recruited and the data done and then you can make a lot of mistakes and still be okay. When you get that to that point people take you seriously and they actually help you out. And so there's a lot of resources as soon as you get that. So I'm way over so sorry let's talk later. Thanks guys. Let's go make some cool startups. Let's do it.


Welcome to the Pyramid Insider. I'm Tyler Patner and today we are looking at the SIG Rattler BB Gun. This is SIG's first BB gun with select fire capability.  Let's dive in. So the Rattler is a replica of SIG's Real Steel Rattler and this is an SBR by Nature. Obviously in the airgun world we don't have SBRs so this is just your run of the mill BB gun. The cool thing here is that you have semi-auto and burst fire three-round capability which is neat. Not full auto but that's all right. Three-round burst is plenty fun, trust me. So starting at the front you have kind of your three-prong flash hider setup here. Obviously there's no flash to contend with here on just a five and a half inch barrel. It's very short, very compact but they do rate it for 300 feet a second and obviously we'll put it over the chronograph and see what it actually does in the real world whether it lives up to that or not. The gun overall is under 24 inches so a very small package and it has a folding stock.  That's a very, very small backpackable package. Overall really neat setup here. Coming up to the top of the gun we have a full-length Picatinny rail here. We have a elevation adjustable front sight. If you can see it there that does flip down, flips up as well obviously and then we have kind of a two aperture AR style rear that is windage adjustable and again that flips down at will. You can obviously mount your lights, lasers, optics, red dots, all that sort of stuff and you do have M lock slots on both sides and on the bottom if you want to accessorize to your heart's content. You also have sling studs up at the front so if you are looking to run maybe a single point sling or something like that you can do that with the Rattler as well. Now running back a bit we'll flip open that folding stock. You do have your bolt catch here which is functional but you don't have a flip up port on the other side to let you know when it is actually locked back to the rear. So it can be a little tricky to tell at least in my use thus far when you might have that bolt lock back. Obviously when you are changing your mags is going to be probably the most prime time for that to happen and you do have an ambi mag release which is kind of neat so you've got that over on the left hand side as well as the right so same thing with the selector switch you got it on the right hand side and the left hand side. So again kind of real steel functionality there with a lot of SIGS guns being ambidextrous this one is no exception. Diving into the mag a little bit this is a unique magazine system I've not seen anything like this before. You have a 30 round capacity that follower pulls down you do have a slot at the bottom that the follower locks into and of course loading BBs right there in that port very easy to do no issues with this so far in our testing.  It's really easy to do no extra tools I love that SIG you get a big thumbs up from me on that one. Now one of the cool things about the Rattler here that I've not seen before on any other kind of like AR variant stuff is that you actually can't put the gun into safe unless the gun is cocked that's how real AR works. So if we pull that charging handle back then we can throw it into safe obviously flipping to semi or all the way to the rear is that three round burst very easy to do and the fact that they've made it ambidextrous is nice and easy as well now we don't have any CO2 or BBs in it but trying out the trigger the trigger on this gun is actually quite realistic. Got to take out the mag to actually get it to function but I would say this is like a three and a half pound trigger which again for a AR style variant BB gun is probably the most realistic IFL to date which is really nice and that says quite a bit. The other cool feature before we head out to the range on the Rattler is that you can take this down just like your real steel AR so we go ahead push on those pins I'll use a pen here because well I like making my life easier get those pins out and they do retain themselves so you've got your detents in there and you can actually just take the upper right off sneak it around there and the hand the handy thing about this is that if you need to clear a jam you need to get to the barrel you have something a BB floating around in there whatever might happen to you this is going to give you the ability to clear that on your own so SIG not only keeping it realistic but also handy for the user to self-service if necessary. All right that about wraps it up for our in-studio segment here with the Rattler but let's head out to the range now see how many shots we're getting what kind of velocity we're getting in play around with that burst fire mode because I am eager to do just that let's head out. One quick thing I wanted to mention before we get to our accuracy shot counting all that stuff in velocities the gun does have a blowback mechanism inside of it and I'll show you kind of how much it moves here you can see it jumping but you're not going to see it obviously because there is nothing open here on the side so just know it does have a little bit of a recoil impulse aiding in that kind of realistic feel not as strong as some others out there but blowback nonetheless. All right friends so performance on the SIG Rattler let's talk about shot count first so off of a fresh single 12 gram CO2 cartridge this is about 70-75 shots somewhere in there on semi-auto obviously if you're running this thing on three round burst you're going to get less shots than that but that's pretty decent shot count temperature dependence a little cold here in Cleveland but not too bad at all in semi-auto they're taking you know a shot a second so pretty darn good there velocity wise we then put a new fresh CO2 in it before we did accuracy you are running a 5.1 grain BB at 330 feet per second which out of a little tiny barrel that this gun has is very solid and they only rated at 300 so to be outperforming that is always a good thing to see now as far as accuracy goes you are looking at about a two and a half inch group here out of the daisy BBs these are their standard steel BBs not too bad or zinc rather but not too bad you know you got a lot of those going in the same hole and honestly if you didn't have this one down low here you got a really nice one inch group so accuracy is there but the inventory is overall out of those 10 shots performing just a little bit better and this was kind of on par with everything we saw everything was in that like inch and a half two inch group size there which is this is right at about an inch and a half so solid accuracy overall and it's really aided by the nice trigger on this gun this is like a high-end AR trigger so SIG's done a really good job with this it's going to aid in your accuracy and if you throw a red dot or a low-power variable optic or something like that to enhance that realism factor it's also going to aid your accuracy so something to keep in mind but a ton of fun three-round burst semi-auto it's all running good just make sure you're not over filling the mag that is one thing we noticed if you do go over that 30 round mark because you can buy a couple BBs you may run into some jamming issues but outside of that all good out of the SIG Rattler good stuff all right wrapping up the SIG Rattler this gun is a lot of fun I think it's meant to be a lot of fun and really nothing more but for me this represents what in my opinion is the nicest and most realistic AR variant BB gun on the market to date obviously the select fire versus full auto you guys have your opinions of that I think this is a ton of fun and the fact that they're giving you a really good quality trigger is something we really haven't seen in a replica of an AR to date so they're doing a great job with that and again it's a ton of fun that's what's meant to be you can backpack this thing just by folding the stock which is really easy to do the fact you could take it down I mean they've added a ton of realism into the system and you're only using one co2 cartridge per magazine you still get that nice realistic 30 round capacity things a good time you guys are going to enjoy it a ton and well for well under 200 bucks I definitely think this is one that should be on your wish list this year if you're cruising around the website for a BB gun as always we appreciate you watching thank you we will see you next time of course don't forget to like comment and subscribe and we'll catch you next time


The Ministry of Health, Wellness and Elderly Affairs on Wednesday held a press briefing providing the nation with an update on St. Lucia's COVID-19 situation. The country has recorded an increase in COVID-19 cases and is currently experiencing its fourth wave. The increase in cases has peaked concern as to St. Lucia's ability to effectively manage this fourth wave. Medical Director of the Respiratory Hospital, Dr. Alicia Eugene Ford, provided insight into the current standing of the island's primary COVID-19 care facility. The medical director indicated that the Respiratory Hospital has a bed capacity of 123, 15 of which are in the intensive care unit ICU. The ICU manages critical and severe COVID-19 cases. The majority of the cases come in, they come in with comorbidities. So in addition to the oxygen therapy that we give them, the antibiotic therapy, the chest or lung rehabilitation, we have to treat them for the other comorbidities, whether it be hypertension, diabetes, and all other complications, sickle cell disease, and cancer, etc. So we have to treat them from the other illnesses as well. Dr. Eugene Ford noted that from February 2021 to date, the hospital has recorded 1,460 admissions, 20 of which were fully vaccinated. As of September 8, 2021, after a thorough verification process, the deaths of two fully vaccinated individuals have been recorded. These individuals suffered from underlying conditions. The management of the Respiratory Hospital has adopted new protocols to improve patient care and comfort. This includes a new visitation policy. We would allow these individuals, their family member, their husband or their partner to come in and see the baby and mummy. We also have persons who are critical or we know they actually have a terminal illness. We would allow these individuals to come in and see their family members, which is different from what happened in the first few weeks. We have a drop-off service that we've started where we allow persons to drop off items for their family members who have been admitted. We allow for the logging and the verification of these items and sanitation. So staff members are assigned to take these items and bring them to the different wards. Dr. Eugene Ford encouraged the family members utilizing the drop-off service at the hospital to avoid bulky unnecessary items. Other measures enacted by the Respiratory Hospital include bolstering the staff contingent, improved communication systems, viewing of the body of deceased patients at the Respiratory Hospital's morgue and outpatient clinics.


How are you doing with the roller coaster ride of 2020? The Bank of England is the latest central bank to take action to support the economy during the coronavirus outbreak. The U.S. weekly jobless claims jumped due to the coronavirus layoffs. The Federal Reserve is likely to significantly boost its government bond purchases beyond the $500 billion minimum it committed to. And the Trump administration is considering intervening in the Saudi-Russian oil price war with a diplomatic push to get the Saudis to cut oil production. Welcome to the Tick-Mail Update. I'm Kiana Daniel, the founder of the Investiva movement. Make sure to subscribe to the Tick-Mail YouTube channel and support us by liking and sharing this video with your forex trading friends. We have entered a new level of uncertainty and doubt. However, there is more opportunity than ever in the forex market as long as you can tolerate the risk. The U.S. dollar continues to remain king. Today, I'm looking at the dollar yen pair, which is following a similar path as the dollar suicy pair that I covered yesterday. The pair has just broken above the daily Ichimako cloud after bottoming out at 101. However, if you look at the big picture, you'd notice that the pair has continued to create lower highs since 2015. These are not ordinary times, though. So we could see a break of this trend if traders continue to turn to the U.S. dollar during the pandemic. That could bring the pair up to the recent highs of 112 or perhaps even higher. Now, which direction do you think the dollar yen pair will take next week? Head over to the comments section and let me know. Of course, trading in the financial involves a risk of loss and you should only trade the money that you can afford to lose. If you like this video, give it a thumbs up and subscribe to the Tick-Mill YouTube channel. I'll get back to you with more updates next week.