 Great. Well, welcome everybody. And I lost my agenda again. There we go. This is the thing with go to meeting is like it holds. If you try to minimize to look at something else, then you can't find the window. Anyway, so welcome everybody. I guess on the agenda today we have the election results from the TSC chair election hackfest planning as usual. And then I think we're probably ready to have Mark review finally the performance of scale working group charter. We've been around the block a few times people on vacations and so forth but we're ready to go with that. Then we have a proposal that's I think somewhat related with hyperledic caliper proposal. There was discussed extensively in the document itself, but Dan said I know this morning I think echoes concern that I had which was I didn't see a whole lot of discussion about the relevance of this project proposal with the performance and scale working group. So we need to have that conversation and then there's another proposal for hyper ledger inter ledger Java. Which I think was sent out yesterday, and then we can get a security team update and project reporting discussion rejuvenated if we have time. Is there anything else anybody wants on the agenda. Okay, if not Todd kick it off. All right, sure thing. So the TSC election concluded two weeks ago we moved into the chair election, excited to announce Chris Ferris has been reelected as chair. So congratulations Chris. I'm excited to continue working with you on that. All right, moving into hackfest planning Chicago hackfest is coming up in a couple weeks here. If you have not registered, please do so as soon as possible. We will hit a cap for that and have to wait list people so get your registrations in now. We also had a link for the draft agenda for the Chicago hackfest any topics you want to see get covered anything you want to present on anything you want to collaborate on please get that dropped in there. We'll get that all mapped out on the morning of day one. And then the second agenda item is related to the final hackfest of the year in Europe. We did get that narrowed down to two dates. We had a doodle poll and also kind of looked at the other events in the blockchain landscape, and it really looks like the, the preference and what works best with all the other events is to lock in the dates of December 5th and 6th. In Lisbon, there is space available for that. So this is pretty easy to move forward with so this is really a call for any objections or concerns to lock that in as the final hackfest of the year. Sounds good. We will get that confirmed and we will get a registration site up for that and some more more details out on that shortly. And with that, I think we're onward to Mark and the PSWG Charter. It sounds like that group approved everything and now it's really back to the TSC. Sure. So, I mean, we've been through it a few times. And I think last time the TSC was happy with it, but the PSWG hadn't voted on it. So I don't know how you guys want to proceed and, you know, for a timing perspective, do you want me to go through the whole thing again or? What do people want to do? Do people need to have a refresher on the Charter? We, you know, I guess Mark, you captured, I think, well, we had gone through and discussed a draft that you had presented to your work group, but they had not yet worked on. And I think, as you know, the consensus was this looks good, but we wanted to get any last minute changes from the work group itself. So given that there have been no changes, I think, is that right since then? I think we're probably ready for a vote unless anybody wants to object and wants to dig in a little bit deeper. Right. I think the only change since the last time I talked with the TSC was I've added this short paragraph, which is an italics because it was the change that the PSWG will oversee the work and direction of any performance and scalability projects within Hyperledger, which was based on feedback from this call. All right, then, Todd, I think we're ready for a vote. All right, sounds good. We'll run through the list quickly. Arno? Yes. Saha? Yes. Bin? Yes. Chris? No. Dan? Yes. Greg? Yes. Hart? Yes. Jonathan? Yes, totally. Kelly? Yes. Nick? Yes. Nathan? Yes. All right, that's approved unanimously. Awesome. Okay. Thank you. Thanks, Mark. And so next up is the Hyperledger caliper proposal. Is Victor on? Or somebody want to present this? This is Victor. I'm here. I think we have discussed about the caliper last week. And I'm not sure if everybody has been clear about what the caliper is and what's the output of the caliper. I just got received an email from Dan. And Dan may think the output of the caliper is overlapping with PSWG. But I need to give some explanation that the goal of the project and the working group is completely different. The output of caliper project is the project itself as the output of PSWG is the definition of the matrix under the use cases. I think in two days ago, in PSWG regulatory meeting, we have fully discussed about the relationship between PSWG and the caliper project. And that is PSWG will be in charge of defining how the matrix are and the process of how to benchmark this matrix. And the caliper will implement this matrix and following the procedure. Yeah, Sara, I was trying to pull up the proposal. I think it may have evolved a little bit. I think there's some inherent linkage without getting the proposal in front of me directly. But I think there's some inherent linkage in the matrix that would be output by caliper or any sort of test harness. And what the definitions of those metrics need to be as defined by the performance working group. So I think the timing here is a little bit awkward. It's great that you've got this caliper project started. But I wouldn't want there to be a hyper ledger project available today that was then sending an inconsistent message about what we felt meaningful metrics were and how those metrics were to be generated. So what I would prefer to see is giving the PSWG an adequate amount of time to create those definitions and create specifications so that there are then requirements for a project, be it caliper or any other project to actually adhere to those guidelines. I think today caliper would be in an unfair position that it's defining something without those requirements in place. So I'd prefer to see caliper come back in whatever the appropriate amount of time is for the PSWG to have created those definitions. I think for project entering incubation to it goes, it takes months, even years time. And I don't know when the metrics can be fully accepted, can be well defined and fully accepted by hyper ledger community. And I think it also takes a lot of time. So I don't think starting the things running in parallel would deliver different messages to the users or the readers. So if we had to start the project after the definition comes out, I doubt it could be too late. I think if we want to help the customers to pick the technology as fast as possible, I think better to do these things in advance before they accept the technology. My interpretation of this, the last couple of weeks ago when we talk about this, and I did comment it on this, was that caliper is a framework, regardless of what metrics the performance group finally agreed upon. But this is a framework. Certainly, as we know, it requires a lot of work, how to set these things up, because currently our hyper ledger projects are quite complex. I'm talking about from fabric, for example, to set up a network, they have these things actually defined in such a way that one can ascertain performance would take quite a bit of work. So because of that, I thought that this project is to try to define that framework and try to set that up. And then what does tell with the performance work group output, the implement specific use cases on the metrics. And because of this framework, we would have a infrastructure in which we would be able to measure the performance of our current projects. So that's the separation that I thought I came out with two weeks ago. And that because of that, it seemed to me that there's still a lot of walks from logic fixed point of views for Caliper to continue without having to have any specific use cases on metrics at this point. So I have a question. Sorry, so we're here for the decision. So I'll get you out on that first. So here's a question. I think we have two things here, right? We have the performance accountability kind of working group. This is kind of one thing that we don't have the requirements and demand it yet. And we would like to get fitted from all projects, not just fabric and not just so just to get like a charter that we just approved like a few minutes ago. And then we'll have an output and it'll take some time to kind of iron out the requirements and then they set up, okay, this is what we want to do. And now how do we implement it, right? So this is one one one track. The other track is like, Hey, let's have a framework that is generic enough extensible and we'll be able to harness it to specific needs. And maybe some other projects will contribute to it because some of the maintenance will know more about this project. The question that I get that the question I have, do we need to make the call now? Like, can we try to revisit this in a month or two? Is there any downside in working in parallel without accepting it yet? Is it the time we think that's what I'm asking? Because we think you get a little bit more clear, I think in a month or two. That's what I feel like. What do you guys think? Jonathan. So the other question that I have here. Oh, excuse me. The other question I have is why wait? Is it okay that we do it as an incubation project and an incubation we don't need to set such a stiff requirement? Or do we think that the question is twofold, what's the value in waiting and then also what's the harm in waiting? So, Nate, and I think that for me, performance is a really sensitive issue and it's going to be very easy to mislead. Look, if performance were central to what we were doing, we'd all go back to using distributed databases because they're way more important than we're going to get out of blockchains. The messaging around what constitutes the metrics and how the metrics are reflective of a particular usage has to be baked into what we're doing. We are a hyperledger, right? So, having some expression of metrics, even implicitly in a project like this, there's a statement about kind of values and a framework for comparison and priorities, right? So, the danger is that we are dealing with something that's very sensitive without having thought through it. This is a little different than a lot of the other projects that we've looked at in that sense. So, the question is twofold, right? Whether to start working on such a framework and the other question around sensitivity comes from publishing the results. So, according to me, those are slightly different questions and in fact, it will take quite a while after you start working on the framework to come out with any public results. So, if the sensitivity is around publishing results, then we should be saying that coming out of this incubation project, these results will not be published unless there's a thorough review by PSWG first and then by the TSC before any results are even made available to anybody. No, no. So, two weeks ago, we discussed that very point of publication of results and I think we had agreement, at least among the people who were on the call, that this project should stay away from publishing any results. And I'm glad to say that at the end of the motivation section, there was actually a paragraph that was added on that front, basically saying we're not into publishing results. This is really just building the tool so that people can do their own evaluation. Now, I think I had the same concern as what Dan expressed with regard to a bit of the timing challenge because this is supposed to leverage the outcome of the PSW working group and we don't have that yet. So, the question becomes, can this group already do any work that would be useful without the input from the PSWG? And my initial reaction was, well, they should just wait and I thought, well, there's probably so much work to do already to even build a framework that would function with two of the frameworks we have. They can probably work on that without getting into the details of what the matrix are. At the same time, I'm concerned that for practical reason, they're going to develop some matrix just to play around with this and be able to develop and test the framework. And then we fall into this issue that has been raised, which I think is valid about having already some matrix in a hyperledger project published and that people are going to think there's some form of endorsements behind them when they're at. So, there's been some discussion in the chat and this was the point that I was going to make as well in the sense that even though, to your point, I know that the proposal says we won't publish any numbers, the point of Caliper is to let people do their own measurement and I think the concern that's being expressed and I share it is that people are going to run this and either they may not use it appropriately or they'll abuse it and they will publish the numbers themselves, whether it's in blog posts or press releases or whatever and then all of a sudden we start getting into a situation where something that is hyperledger branded is making an assertion that we don't necessarily have full agreement on in terms of is that an accurate measure and so forth and so I share the concern that has been expressed. I do think that Victor, to your point, that it is important and others have made this point as well that we get moving and start the process of developing some of this stuff. The challenge here is that the PSWG hasn't yet sort of done the work of defining what a measure is, how it should be measured and so forth and I think barring that, having a project that's doing measurement is going to be or can be measured through its execution could present problems and the other concern that I would have is that I think we need to be in a situation where all of the ledger projects that we have, whether it's fabric or sawtooth or in these underlying fabric, need to be in a position that caliper can be used effectively with their runtime environment and so that we aren't sort of, you know, so that we aren't putting ourselves in a position where we're able to measure one but not others and so therefore people are going to draw different conclusions from that. So I think that, you know, given that we just approved the performance and scaling working group charter, Victor, that the right way to approach this would be for those who were, you know, sponsoring this proposal to engage directly with Mark and the team in the performance and scaling working group and, you know, and we can, you know, we can do show a tell, you know, the code is there, it's out there, right? I mean, people can see it now. The challenge is when is the right time to bring it in for appropriate branding because we are going to have to deal with this very carefully. We're going to have to put all kinds of constraints on who can say what. Ideally, you know, we get Brian and Greg and so forth from a branding perspective to make sure that it isn't going to be abused and that there are certain restrictions or guidelines that are published about how people talk about performance measures through something like this. You know, we just have to be very careful, I think, and deliberate about how we go about this. So, you know, again, I think I share the, you know, the sentiment that's been expressed in almost all of the discussion that, you know, this is a good start on a good piece of work and so we don't want to necessarily diminish what has been done. That's a good thing. The challenge is how do we get this integrated correctly and thoughtfully into the Hypervisor umbrella itself and I think the best way to achieve that is probably to work directly through the PSWG to get to a point where then the working group can make a recommendation to the TSC that says, yeah, we're ready for this. Does that make sense? Yeah, this is Mark. I think, go ahead. I just have a quick question here is that whether, you know, the performance group is responsible for defining the framework as well as the metrics or only focus on the metrics, but not the framework. Because to me, Caliber is a framework and in my mind, it will take a long time. It's not like it's ready out there and it's ready to go. It will take us a year to get these things ready as I remember folks in IBM develop their own framework to do their own performance work. And today it's nowhere near there, right? It will take a long time. So that's only my comments there in question. Right. So my thoughts on all of this are ideally I would have waited a little bit for Caliber, but I think, you know, it's also a very good driving function for the PSWG. People can see, you know, I've started discussion. Okay, you know, you want to measure transactions per second. Let's define a transaction and we spent, you know, a lot of cycles and comments and documents and stuff on, you know, and people realize there's no simple definition of a transaction because it depends on the use case and things like that. So I think it's a good driving function in that regard. And I think also by making it a project in incubation, people can come in and they can, you know, if they want to do something with performance, they can contribute to a project that's there versus coming off in, you know, two months and some other group wants to do their own proposal because they don't see one already existing. As far as publishing results, you know, I'm not a lawyer, but I would think we could put something in the software license until we're ready to make a decision on how the tool can be used. That says this tool can only be used for internal measurements. The results cannot be published. I, you know, I don't know if that will fly, but, you know, that restriction can be removed later. But I think overall, you know, we want some common tool based on the feedback I remember from our meeting in Washington when I first proposed this was, you know, we want a common tool that can be used to fairly judge different implementations. And, you know, but there's also not a, I guess a requirement's a good word that, you know, we need to be able to say, hey, for this, you know, if you want to do asset tracking, this is, you know, the key things you're looking for, this is, you know, the transactions per second latency, whatever, you know, because different environments are going to have different, you know, different key parameters and, you know, different implementations will address those. So, you know, I remember Brian saying, you know, it would be great if we could come up with some kind of chart that would show, you know, fabric is good at these three things. Satu's good at these two. Go Ethereum is good at nothing or, you know, these four things, whatever. So, you know, I view that as like one of the long-term goals of the PSWG is to be able to pull together results and do this stuff. So, Mark, if today they do not, the, there seem to be quite a bit of controversy about starting the incubation today. So, if they do not, I mean, it looks like there is no consensus on that starting the incubation today. So, if they do not start the incubation today, will the Kaliper project still go ahead without publicly being available as an incubated project in conjunction with the PSWG to do the things that you just described so that you can do, you can start incubating it later. I think I don't see why the PSWG would not work with the Kaliper people if they continue, you know, if they choose to continue to work on it. Yeah. They're members of the PSWG as well. Right. And that was actually what I was recommending, Mark, to see that the Kaliper team and any others that want to engage in pushing this forward, that they engage directly with the PSWG and, you know, to Vippen's point, I think work towards alignment of exactly what the requirements are, what the measures are, and so forth, so that we can be evolving this to a point where it does, I think as Dan said in the comments, that it does meet our requirements for it to be incubated. You know, this is different than a lot of other, you know, I mean, you know, another platform, you know, even another platform that was, you know, sort of, you know, let's say another Ethereum platform or something like that wouldn't necessarily be a problem. But with something like the sensitivity, I mean, there's a reason that spec works in secret, right? And that, but the challenge is in open source, is that we really can't work in secret. But I think at least in this context, if we can work collaboratively and keep the code unbranded, as it were, until we're ready, I think that would be the best alternative. I mean, it is, after all, it is open source. It's under Apache license and so forth. And so I think if we can continue to work it in that direction, align it with the requirements as specified by the PSWG, that is going to get us close. You know, again, other than that, I think, you know, I shared Dan's comment in chat a little bit further up that you can't sort of put in a license. You can't use this, right? People are going to do it and they're going to do stupid things and then, you know, we have to go stamp it out and that'll just be... But can I, I would like to add something because, I mean, as Borough, I think I can completely state that we have like over 100 transactions BFT over a global network. I would even say 400 transactions confirmed per second. That by my overview, that is at least a decent performance within the Hyperledger community. At the same time, there is not necessarily... What I would recommend, I would actually just want to build on the idea of putting some sort of elaborative proposal for it, namely that instead of putting in the license that it cannot be published, maybe there should be a strong recommendation that it needs to include all Hyperledger projects because, and I will be frank here from my perspective, I mean, the Hyperledger community does not pay me for my job so I have to do full-time work and on top of that, single-handedly and support an entire blockchain client so you will have noticed that there is no progress anymore because there is an overload of work and there is no contribution from the Hyperledger community. So it is very much a question of what does the Hyperledger community want, right? I mean, for me, this is almost at a breaking point. I can do different things with my life but if you're going to propose a measuring tool, I very much welcome it but it needs to be equally measured and then there needs to be a commitment from the Caliper team that it works with all projects because I cannot take this on additionally to integrate it myself into Caliper so that is my objection. I think we would perform very well but I would not want it because I do not have the time to do this so I would want that commitment from Hyperledger that it says to Caliper project like if you want to go forward then you need to work with all projects to contribute towards all projects. Another question that I have for the Caliper people is are they giving up some of their brand authority or some of the reputation of the benchmarking tool by becoming part of the project itself? I do not mean to propose this as joining Hyperledger is a bad idea but I want to ask the question to make sure that they have their own answer to it because it is like the NoSQL benchmark framework that compare various tools across one another one of the values that usually they have is that they are independent of the developers of the project so they can say the really bad things that developers would not want them to say like you are not doing partitioning correctly or that you have fatal flaws in terms of your replication things that happen as you do benchmarking and you find where the software falls over and fails in interesting ways. I think we are open sourced that means we are truly trying to have everybody involved in the development of Caliper and listen to everybody's advice and we have connected with developers of all supported or to be supported frameworks invited them to join to Caliper and giving their advice and the inputs to the project and to help the project to produce acceptable to help the project to produce acceptable benchmarking methods so I think we are open and not trying to control everything. Victor can I just ask a question on this when you think about what sort of the principal value is a Caliper is it repeatable execution I mean one of the critical things that you have to have on your measuring performance is you have to be able to repeat the execution a second option would be the set of metrics that are a part of it that are kind of descriptions and a sensible framework for building metrics or is it really the ability to compare and what do you see as the kind of principal value here I think the motivation of the project is that when we are talking with our customers we often they were just to answer the question which one is better which one is suitable for my use cases and sometimes explain these questions just by words is difficult so I think maybe provide a tool for users may help them to make up their mind more quickly so that's why Caliper came out but to be fair that I think Caliper should provide a very clear and easy understanding metric definition and since WG is doing that and Caliper and I think Caliper developers are very active in PSWG work and so and we are trying to push the work and help the definition comes out so we can use a unified definition between PSWG and Caliper project so I think that the most important value of Caliper project is to help customers to make up their mind more quickly sorry I have another question so in terms of development to touch on something that Ben was saying how do you imagine development of Caliper and kind of porting it to different framework do you expect that to happen from the main contributors to each framework currently so like from Borough and and so on or will you provide people from Caliper working on Caliper currently that they will learn the project and will port Caliper to those projects Yes, like for fabric Bing suggested that we reach out to Doming and for Sotus Tan suggested me reach to James from Bitwise and for Iroha I think we also have a developer get involved and who would help to integrate Iroha with Caliper and also every time we are trying to support a platform or framework we will ask the main developer of the framework if they are willing to provide some resources to Caliper so that they wouldn't say that because we are not very familiar with the framework so make some bad integration or bad settings of the project so I think for it is better to have this framework developers to integrate to the framework with Caliper and that would be more convincing and more acceptable and you can refer to the resources part of the project as you can see every part of the framework we are supposed to support have one man contributor in the resource list Thank you I think again I don't want to presuppose but I think we are sort of at the place where Caliper is going to work with PSWG and get to a point where everybody can be comfortable with incubating Caliper but meanwhile we work with it sort of independently hosted is that where I think everybody is? I think Caliper developers are working closely with PSWG I wasn't suggesting otherwise I'm just saying that the continued model is where we go until we get to the point where the PSWG is comfortable recommending to the TSC that we incubate the project maybe I could get a vote on that Todd so can I get a vote on having the Caliper team work closely with the PSWG until the point that the PSWG can make a recommendation to the TSC? Yeah we can do a vote or do you just want to call for any objections from the TSC on this project? I don't think it is appropriate for the TSC to vote on whether the PSWG should work closely with Caliper I mean why is that even relevant? The question is whether we decide now yes or no or we decide to postpone the vote because many people are saying for various reasons among the TSC members that's what I hear we're not turning it down either Let's have a straw vote it's not a real vote I'm trying to sense whether there is consensus and I can't necessarily tell that there is this is where I realize not everybody has spoken so why don't we do this why don't we just have a straw vote Todd to the point that I was anxious to make before which was the Caliper developers work closely and in the PSWG until such time as the PSWG is ready to make a recommendation to the TSC that the project proposal go forward close with PSWG and until it is happy to recommend the Caliper to TSC that don't need a vote so that could be a suggestion from TSC I think vote is used for make decisions whether Caliper should get incubated yeah that's why I said a straw vote a straw poll is just a system of the group it's not, there's no decision made no but I think it's important to clarify that point it seems to be some confusion because what I'm hearing is what the TSC is leaning towards is nobody is ready to quite say yes now but at the same time we don't want to turn it down forever and so we're trying to find a way in between where we say let's postpone this decision I encourage you to work with the PSWG and when the PSWG feels this is a good time to reconsider we will do so but let's say that we did take a vote and we voted not to accept a project Caliper or any other project as an incubated project there's nothing that would prevent those contributors from coming back with a revised proposal in the future signal everything is volunteer here the question is about these developers whether they come back the next time or not things are it's not like people are eager to work with us there's a big difference between saying no don't come now but maybe later and saying go away and that's what we're trying to talk about I don't think anybody is saying go away exactly nobody wants to say go away that's the thing we're trying to be careful not to shut them down so that they feel they have no room here Arno no matter what you say the users are already starting especially among the so-called consulting companies KPMG they have measurement projects going on whether you say to these guys go away or not it doesn't matter the whole point is that what we that means me and Victor are here and say that voting on this topic on this particular point is not necessary we hear that the TSC nobody is saying go away we know that already but they are not ready to incubate at the moment that's what we hear the fact that KPMG is working on some tool that they will publish at some point to some people for some payment that doesn't I don't feel any pressure to accept or reject another project somebody is doing something somebody is competing with us that's not what I meant it's a practical thing that means two of you are already 1.0 and people who want to use them are already measuring maybe they will publish to a select group of people there are already measurement efforts going on so that's beside the point what I'm saying is in terms of this particular topic of course you can go ahead and take a vote but the point is no incubation currently but maybe later on the message looks like they got right and so I think that's sort of where we are we don't have to take a vote I think what we're really doing is tabling the proposal for another day and I would suggest that that's where we are unless there's any objections so that we can move on to the interledger proposal not an objection we're just in one line most of us are going to be in Chicago very soon and we can also discuss it in person that may help as well I think the thing I would ask is and we can discuss this in Chicago figure out what the main objections are right now to putting it in incubation is it just too early or are there just concerns over how results would be used I don't think we're at the point where there's any code that once it comes in people can start running this this tool against fabric or whatever and get results right away I can tell you in one line what mine are just very very briefly I think that it's easier for me to evaluate the tool against the requirement so once I have an requirement I can find the best tool for the job very objectively and I don't feel like you have that yet I think that was a succinct way let's table this and we'll have a discussion in Chicago how does that sound we can move on if we haven't scared the interledger people away hopefully not guys don't take it in a negative way seriously we need to catch up there's a couple of things left and we have another proposal for the hyperledger interledger java proposal and is somebody on to pitch that I think Isaac from Everest is the one that dropped it on the list Isaac are you on anyone from the interledger java proposal okay that makes that actually a lot easier for us to have whoever to present it Dave you want to give a quick Before we go to the security team update it looks like there's not an understanding of what was disagreed upon I think that from the chat that they need to be clarified what is happening with the caliper and the pswg so I think it's that you know we're encouraging the caliper contributors to work with the pswg and at the point that the pswg has formalized its requirements it is ready to make a recommendation for the psc then that would be an appropriate time for caliper or any other performance related project to propose themselves to the tsc in that direction Victor does not make sense to you okay I think we can discuss again inside the pswg to see whether it is suitable and whether it is suitable for pswg to recommend the caliper to tsc thanks Victor Dave so security team update is pretty straightforward are there even though Isaac is not on the phone are there any comments or questions about the interledger proposal have people csc had time to read through the proposal and is there something that I could forward to it so that I can talk with them or would you like to move past it and go to the security update well Marta I'd like to just move to the security update and let the interledger team make their pitch first before we hit them up with a bunch of questions I think that would be best make sense thank you go ahead Dave so security team update is pretty straightforward we have had a couple of issues go through our confidential system related to some of the security auditing but nothing serious up to this point on fabric we are dealing with one infrastructure issue where the confidential security bugs are leaking to rocket chat but that should be resolved here pretty soon in the next couple of days I made some updates to the security wiki pages tightening up the security handling policy and some of the other recommendations for secure coding and let's see what else we have members from borough and Indy now integrated into the security team and then the last thing I wanted to say is that Nettitude the company that hyperledger contracted with to do the security audit of fabric is planning on being at the Chicago hackfest they are going to do their report out on what they found and recommendations in Chicago I have also reached out to their 1.0 estimates because as part of their 1.0 we are going to work with Nettitude again to have those projects evaluated as well that's it we are looking good so far nothing serious is being found and the infrastructure is going into place we have a branching model with fabric at the moment that's on JIRA if you want to jump in with your opinions I would like to the reason I am reopening it is because we are now looking at GitHub as a potential solution instead of Garrett because there is new DCO integration at GitHub the solution in the past to adopting the get flow branching model was that Garrett didn't handle feature branching very well but GitHub does and it's a tool that a lot more people are more familiar with anyway we have reopened that discussion I would like to invite everybody to join in if you care anything else I don't want to take up too much time any questions? I think we still need to agree on whether we want feature branches I was happy to find a hybrid way not to do every 2 people have their own feature branch but we have a pretty restricted set of feature branches for example we want to talk about Jonathan can we take this to the thread I didn't want to take this into an argument about feature branching sure sure yeah sorry is there any other questions besides arguing about feature branching on the call alright I'll hand it back to you and then finally Tracy in the last couple of minutes the project reporting discussion that sort of well you went on vacation everybody went on vacation for the month of August is sort of a black hole I think we probably should think about resurrecting that and so maybe I could ask you to sort of start that on email and let us bring it forward again yeah sure Chris I'll bring it to the email I'll just kind of bring that email back up to the top with everybody's list and we can look at project reporting I think it's really important based on some of the things I've heard on this this call today from some of our projects and their current status so let's make sure that we bring that back up on the email list and then talk about it in next week's yep thank you very much yep thank you everybody and hopefully we'll see you all next week cheers cheers have a lovely day everyone see ya