 So, good morning everyone. Good afternoon, good evening. And I know it's beer 30 for some people, but not for some of us that are still trying to get our coffee down. So, on the agenda this morning, we have the usual hackfest planning. I think we've got, I thought Chicago was done deal. Didn't I just register for that? Sorry, I pulled that from an old one. Let me update. You know what I was going to say. I'm looking at it and saying, hey, wait, wait. I think I registered for that. Anyway, so we have, right. Hackfest planning, then we have the annual TSC election process. And Todd will remind us of the links for the proposals and all that kind of stuff. And for those of you who, for the process rather, and those of you who are eligible to vote, you should have received an email. And so anyway, Todd will go over the process there. And then Dave is going to make a proposal for setting up a new repository for educational materials, sample apps and code snippets and stuff like that. And he will also give us a security audit update and then, and talk about the security team. And then I'd like to have a discussion about starting a bit of a task force to look at how we're using GitHub and how we could use GitHub potentially for all the projects. I was looking at it again last night in response to Dave's request for the education materials repo. And just thinking about, you know, again, a lot of the hurdles of using Garrett and so forth as a bit of a barrier to participation. And I guess very recently that GitHub has added some new features to allow fine grained control over who can or should be reviewing pull requests for particular parts of the code base, which actually is better than what we can get with Garrett. So anyway, so I'd like to just talk briefly about setting up a small task force to take a closer look at how each of the projects is using GitHub to see if we can't come up with a consistent approach for all of them. Any other topics for the agenda? Okay, Todd. All right. And really quickly, we are at quorum now. All right. So in the hackfest planning, I dropped two links in the window. Chicago Hackfest is confirmed. If you are attending, which we highly recommend, please register as soon as possible. Also drop the draft agenda in there, any topics you'd like to discuss, connect with people on, looking at further collaboration across projects and whatnot. Drop any thoughts into there. We'll run this on in unconference format, as we always do. Onward from there, the Europe hackfest is looking very likely 1028 1029 in Berlin. Marta or Brian, if you're on, I want to add any more color there. But that's that's what we're looking at right now. And we should have registration live for that in the next couple of weeks. Only that there is a sync up call between us and SAP on Friday. So we'll have more details in confirmation of of the venue and everything else. Unusually, it'll be over the weekend. We'll have a meetup on Thursday prior to the hackfest. So if you'll want to fly out a bit earlier, you'll most encouraged to do so. It'll be a very fancy venue for the meetup. And that's more or less it. It'll be fun. It'll be Berlin. Berlin is awesome. Great. Thanks. Any other questions on hackfest before we move on to TSC election? All right. So we did collect all the nominations over the past week. Along the timeline, we received I think it was 31 or 32. So really, really excited to see such healthy interest in serving on the TSC. So shortly after this call, the election process will begin. I will send out an email to everyone that's eligible to vote in that election, as well as the list of all the candidates with their bios and pitches. A unique ballot will be sent to each person. I'll send out a few reminders over the next week, and that will close next Wednesday at five PM. And we will then announce the new TSC shortly before the TSC call. And then from there, we will open up the nomination and election process for TSC chair, which again, will be one week nomination, one week election. And then we'll announce it on that TSC call. Any questions there? All right. So onward to Dave then and the repo for educational materials. Dave or Brian? I'm on. Okay. So the Hyperledger has contracted with an outside firm or outside people to create a MOOC for hyperledger education. Part of that process is to develop sample applications for fabric sawtooth and a roll off that are loosely based on some of the examples from those projects. They would like to store that code somewhere in a repo. And as discussed on the mailing list, Brian had some concerns that we should probably never create a repo that doesn't have an owner. And thankfully, you know, we've got people who are willing to volunteer to be maintainers of this repo. So anyway, I recommend that we set up a GitHub repo just for this kind of stuff. Because it won't be just this MOOC. It'll be, you know, other things in the future as well. So that's it. We just want to want a place to help storing educational materials and so that we can manage that as an open source project. So I have a question. This is Otto. I mean, I think it's great that we have resources being thrown in to help with education material. What I don't really understand is why this requires a new repo and how you see this existing with the efforts that are already underway in all the different projects. I mean, you said it to yourself, we have samples already, right? Why not contribute to the existing repos to further develop what's there? I agree with that, Arnaud. The thing is, is that this is going to be an online, potentially online educational program. And so they want to have files that are stable over time so that the text, you know, in the educational material will accurately reflect what is, you know, the files that are available online. I don't know. Brian, you were going to say something. Yeah, this isn't intended to replace or compete with samples that are being built by the development teams closely associated with the content if, I mean, it should hopefully complement it in the long term and we can think long term about whether it's a sample code that's referenced by the training materials should belong in the projects or be maintained independently. I kind of like the idea of an example that is implemented across different frameworks so that you can see the differences between them, for example. But the actual training content, which will be a mix of text content and some videos, you know, perhaps some other, you know, system images for people to download as they're working their way through examples. It's probably best to maintain that on a separate development track and have a consistency across. So that's why we kind of approach this way. And the proposal right now is just to create a repo so that everybody can see the work that's being done. We can start to version it and then we can decide long term kind of are there other better homes for certain pieces of content and also along, you know, kind of in the midterm, is it better to run this as a working group or as something that looks more like a software project? So, yeah, I intended hopefully just to complement what the projects are working on to address our next point. OK, and just to be clear, I don't, you know, I'm not worried about competition per se. It was more a matter of, you know, are we just going to spread the resources we have because now they are working on samples for the education material in the repo there. And then they also have still to work on, you know, the samples for the different projects where they already engage. And when I see like Jonathan God bless him, you know, volunteering to be a maintainer of the new repo, I'm like, oh, shit, you know, how is he going to find this time to do this? And is that going to take him away from working on fabric samples and education material? So that's my concern. But, you know, I think he did also bring up some value points. Yeah, and also to address concerns about, you know, are we splitting or dividing efforts, you know, everything will be CC zero licensed as content, all the code will be Apache licensed. So, you know, hopefully we can, you know, make it easy to move code around and content around and make everything additive rather than duplicative. Yeah. So, I mean, I think, I mean, what this does, though, especially when we think about code snippets and fragments, you know, they have to be tagged, you know, are bound to a specific and released for a specific version of the software that they are targeting. And so there's coordination there. And then, you know, the concern is that, you know, if nobody is paying attention from, you know, fabric or saw tooth or or burrow or whatever, to the samples that are in the educational material, and they make a an API change or something like that, that this kind of thing would slip through the cracks because it's not formally considered part of what they're, you know, obsessing about for getting a release out. That would be my, that would be my one concern is, I mean, I think, you know, I think if we had a work group around educational material that would try to provide a set of guidelines for the kind of material that the hyperledger community is looking to have consistently across the projects that it hosts and, you know, helping with providing, you know, the right sort of tooling and and or, you know, services or whatever that are necessary to host that kind of material and and produce it and so forth. I think that's that that would definitely be a good thing. But then, you know, again, if there's samples or if there's documentation, then it seems to me that that should really be, I think, the responsibility of the projects to keep up to date and consistent with their releases. I don't know if it helps. What we do to go exactly this problem with with Coder, Coder, as I guess every every every code based us, we distinguish between samples, documentation and and and other things that that we insist the developers keep keep in sync as as as new commits go in. So you can't get a pull request in if the associated documentation hasn't been added or updated or if the samples break. But then for education materials, which are obviously a much bigger investment and they have to be they're refreshed less often, we align them to a particular release. And in those cases, we're making it very clear to people that for this for this training material that may actually be one milestone behind, but it's expected to last for a few months. And then there isn't expectation on the developers that they update the education, the formal education as they as they as they as they update and add to the code. But it does mean that the education sometimes likes the latest updates in the code base. And the way we fix that is to at least make it possible that you can update that the education subsequently is is we assist I guess like as all code bases do a very clear release notes and change logs so that when we're reviewing the education, we've got somewhere to go, at least the starting point to figure out what needs to be updated. But I agree with you, it's it's got to be thought about carefully. And I'm not sure we get it completely right. But that's just one approach. You know, now that you've thought you've all brought this up, I'm kind of being convinced otherwise, I think it might be wiser to keep this material for each project in the repos for each project, because then that really opens up the possibility of doing, you know, if you do a new commit and we do a CI pass on it, one of the CI passes is our steps in the CI passes to run through the, you know, the scripts for the education material to make sure that it still works, right? So you can see if you actually broke, you know, the link between what the educational material says and what the source code does. That's my main concern is that they need to stay in sync. And, you know, I don't know that I think that makes more sense to break it up and put it in there. And my point earlier, the online materials needing to be linked to a specific version, right, they want it to be stable over time. Well, that's easy, right? You can just link to that specific tag or revision of that file in the repo. So well, I still think I still think there's a need for an independent repo is there was content being created that is hyper ledger, non specific, that is, I mean, it's not particularly a project. It's generic across the project. Things like kind of an intro to enterprise blockchain kind of content. I also so at least for that, we should create either a training or education repository. And if we want to formalize it with a working group, I'm all for that as well. But I do also want to make, I believe pretty strongly in the Unix philosophy of small pieces loosely joined. And I, you know, keeping everything in sync is a terrific ideal. I don't want that to come at the cost of somebody feeling like if they want to add a feature or fix the behavior or something, they've got to touch 20 different places to, you know, to make that move forward. So I, I'm sympathetic to all things. So I think the very least, we should just get started with a repo, start putting things in there, and then let us figure organically out where we're the appropriate place for certain samples and certain demo content might be. Oh, yeah, my two cents on that. I agree. And I think, I think it would be useful. So it's good to have a top level kind of educational stuff that isn't, is not project specific. I think it's going to be useful to reuse maintainers, right? So if you already have maintenance that know the code and can make sure that things make sense, they should be the same maintenance that will actually try to help and make sure that the sample stuff works, which is similar to what they said, what Richard mentioned. And we should always link to a version. Even if we have an online class, we could say this is fabric one zero zero one, you know, otherwise, we will not be able to be forward compatible. So yeah, my two cents. Yeah, I mean, I, I think, you know, linking and targeting the specific version is great. But then again, these things are going to move in pretty fast. It's not like, you know, I'm sorry about that. You know, it's not Gretel. I felt worried for making coffee. I didn't want to make noise. You know, it's, it's, it's not like they're all standing still. And, and, you know, again, I think that, you know, the point that, that, you know, I was on and that I think Dave sort of re, you know, reiterated is that, you know, I think it's important that we make sure that these things do stay in sync and in some sense of sync with one another. And so I'm all for, you know, sort of there being general education material on what's a blockchain, how do they work, what's a miracle tree, all that kind of stuff. And then, you know, when we drill down into the specifics that we're actually linking to the maintained set of samples and versions and things that and documentation, I should say, for the various projects and just try to build a certain consistency across the, the presentations, maybe just so that it again, it feels a little bit more like a community. Hi, this is we can work through that, you know, again, I think having a repo for the top level stuff to start with, that's good. And then I think when it comes time to figure out where samples and so forth go that we can collaboratively work with the different teams. But in terms of ownership, Dave, you said you, I mean, I know Jonathan stepped forward in the email, but who else? So we were going to ask Robert, one of the main guys producing the educational material, if he would like to be a maintainer, even after the contract, we were going to ask for that. And then I think we were just going to call for volunteers, people who have shown an interest in this stuff, maybe somebody from a working group or something and see if we can get a few more lined up. And Tracy is still on vacation, but this is something I'll expect our community architects to be doing. So she'll be, she'll be on that, too. Okay. Sorry, I forgot about that part. So, okay, I have to say something, I think. In fact, this is Bippin. In fact, you brought forward a tip point that since it's an overarching ripple, maybe the working groups, you know, outputs could also be part of the ripple. And that would add to the value of the educational material. Maybe the working groups is where, you know, outputs is where you tie the different projects together and then have links in them to specific projects, you know, and be able to look at it from a different perspective, like from the architecture or the identity or the performance. Yeah, I think I agree. And I, you know, the thought that's for me in my head is that this is really a project. And just like, you know, we were discussing a couple of weeks ago, in terms of, or actually, I guess it was maybe about a month ago now, in terms of the relationships, you know, the interrelationships between projects or the dependencies and so forth, that we really, I think would want to run this as a project within Hyperledger, you know, formula project to educate people about blockchain and, you know, and also about our respective projects and so forth. But that as a result, it really does need to have formal, you know, it needs to have, you know, just like fabric or sawtooth or bro or any of the others, it needs people to be responsible for it. And then it needs to be making sure that it's interacting with the other projects accordingly to make sure that there's broad agreement, you know, it's got a, you know, the educational materials, you know, that talk about what a blockchain is should probably review with the architecture working group and the various top level projects to make sure that there is agreement that the material is correct and so forth. So I guess Brian and Dave, I guess I'm sort of suggesting that maybe what we need is a formal project proposal. I don't have a problem sitting at the repo for now, but I think we probably do want to make sure that we have, and then just like with all the others that there's reporting and so forth to make sure that it's still vibrant. Well, there was a good point in chat that the white people working group repo was approved to move over to GitHub. And why doesn't why don't we use that as the starting point because that gives us already maintainers. It's already a project and then they could just work with the white people working group to get the educational material folded into that repo. That might be a easier sell, I think. Or not to worry too much about semantic overloading. Let's do this. Let's create a repo now so we can start loading content. Let's come back next week with a proposal for a corresponding working group that'll have ownership on that repo. And I really think the white paper working group and other working groups should also have repos as they see fit as they see need. So repos are cheap to create. We don't want thousands, but having one-to-one correspondence between that and our other organizational structures is completely fine in my opinion. So could we could we do that? I'm supportive, certainly. Do we need a, I don't think we need a, well, I guess to set up the repo, we probably should just take a quick vote. So Todd, you want to just sort of run through it. Yeah, sure. I'll run through the list quickly. Arnau. Yes. Ben. Yes. Chris. Yep. Greg. Yes. Hart. Yes. Mick. Yes. Morali. Yes. Richard. Yes. Shihan. Yes. All right, so that passes. Okay, great. And we'll come back next week with a proposal for a working group with a certain named participant in that group. Excellent. Thank you. Dave, you're up again. Thank you. And thanks for that. I'll take that as marching orders and we'll get on the working group stuff right away. Okay, so a quick security team update. We have formed our security team. I have volunteers from Fabric Sawtooth Rohan Bureau. I'm seeking volunteers from Indy and all of the other projects. Composer primarily. So we have mailing lists. We have confidential bug handling in JIRA and a way to report them. And currently we have an outside firm called Netitude conducting a security audit of Fabric. Now, so far they haven't found anything, but they are just starting to dig into the meat of it. And the plan is is that they will report security issues to the security team as they find them to give us a chance to fix them before they report out. They won't report out if they find something the day before they're going to wait until we fix stuff before they make any public email. They'll make a confidential report to us, but not publicly. And then the plan is that they will send people to attend the Chicago Hackfest and there will be a presentation by Netitude on their methods and results and what we did to fix all those things and harden the platform. So anyway, I just wanted to keep you guys caught up on the security front. Things are moving along nicely. Any questions? All right, sounds good, Dave. All right, so the last item on the agenda is in response to Dave's request, as I mentioned earlier, to create a GitHub repo and talking about how reviews and stuff would be conducted. I started taking another closer look at GitHub in terms of how it can manage pull requests. I don't think that it... I'm still trying to figure out can we support sort of a two plus two and non-author code reviews. I'm still not quite positive that it does that explicitly. You can be very fine-grained in establishing who is responsible for what parts of the code base, which is actually something... Certainly in a project as sprawling as some of the projects we have, could actually be a good thing to help sort of give people a solid footing of what parts of the code they're responsible for and ensuring that there's reviews and so forth. But again, I'm still not clear. How are we tracking to make sure that part of CI is checking to make sure that there's a sign-off for the DCO and so forth, various other aspects that we currently have Garrett checking for and forcing, and at least for fabric. I know not everybody's in Garrett, I understand that. But again, one of the consistent pieces of feedback we get is, oh my god, Garrett sucks. We get that even from the people that are in the project. But thanks Mike, I have to check on that. I didn't see it as a plug-in, so I know I have my little stupid bot, but I'll have to see if I can find that one. Yeah, that's what I was going to point out to when you were done, is that they do have DCO stuff now. Okay, good. And so, you know, again, and we have, you know, so, you know, the other thing we have, of course, is that we have, and I've heard this feedback as well, is that, you know, there's multiple projects at Hyperledger, but they all use different forms of governance, and it's hard to understand how, you know, how to engage and work with them all, because they're all so different. And so, I thought maybe the thing that we should do is set up a task force working through, I don't know what you want to call it, I think it's a short-term kind of a thing right now, to look at, okay, so if we were to adopt GitHub across the board for all projects, what would we have for a consistent approach to enforcing DCO, you know, code reviews, and so forth that all agree to, or at least agree to a set of guidelines that we're consistently applying across the projects, even if they're not all identical, so that it makes it easier for people who engage to move from fabric to sawtooth to burrow, and so forth, and also for the various projects to be a little bit more collaborative in how they work across and between each other, so I'd be interested in sort of taking volunteers to come and work with me and looking at this over the course of the next few weeks. I'm on vacation the last week of August, but I'm certainly willing to start looking at that over the next few days. Chris, I volunteer. I'll jump in. I'd also like us to at least take a moment to revisit the branching model stuff. I don't want to dig up old corpses, but if we are going to move to GitHub. If we can do that as part of it, I see what other projects are doing and so forth, but yeah, of course, but this gives us a good opportunity. I mean, our main objection to the proposal was Garrett, right, you know, so if we're going to move to GitHub or seriously consider it, we can see if that is a reason to do it, you know. Anyone else? This is Arno, I'm actually interested in this too. How about somebody from Sawtooth or Borough or one of the other projects that are out there using, currently using GitHub, so I'd like, you know, input from those teams so that we get a better appreciation for how the other teams are using. Currently, Fabric is the only project using Garrett, right? Yeah. Well, Fabric and Cello. Okay. But yeah, I mean, to get Composer and, you know, not getting along here. All right, what I'll do is I'll send a note to the mailing list and if you can get some more names back, I realize that it's the doldrums of summer and we don't have a full contention here, but I'd like to get that off the ground and maybe come back to the TSC with a proposal for what a set of guidelines would be for all projects to adopt as they, you know, come on board and that the existing projects can work towards over some period of time. I wouldn't expect the cold turkey kind of thing, but I do think it would be good to have consistency across the project and quite frankly, it seems like, you know, the expectation was the choice had been made to switch to Garrett and then Fabric did it and the others were expected to do the same and then there was this kind of like passive aggressive attitude of like, no thank you very much and so, you know, maybe that's the way to get back to all on the same boat. Yeah, well, I know from talking to Dan, you know, his field was that the decision to go to Garrett was by Fiat rather than by vote and I certainly don't recall a vote for using Garrett as the base for it and I think each project has come out of some culture behind and I think that that would be brought those cultures in here and it's certainly a good idea to re-examine where we're at and what the process would be used to see if we can make some consistency to it. And I wouldn't hold a consistency as the overriding objective. I think developer productivity multiplied by legal coherence, so that's the DCO side, is really the thing to optimize for and there's many paths to developer productivity, you know, a better way to explain to new users how to become contributors is just as important I think. I second Brian here because Hyperledger being an umbrella project, the umbrella should shelter different ways of working and it should be pretty much as long as you know the methods chosen are not completely antithetical to sharing and to the whole legal infrastructure that you know we should be able to use any methods to do this and GitHub of course is a very widely used tool whereas Garrett I get the feeling that not that's why you use GitHub. Oh yeah, Barrier to Entry is a big deal for open source projects and by using GitHub you know I think a lot of new for people new to Hyperledger will just go oh great it's on GitHub you know that'll be one less thing that they'll have to overcome to become a contributor to the project and as for like complex behaviors I have been heavily involved in several projects in the past and I still am like the rustling which they have a very complicated I wouldn't say complicated but they have a sophisticated bot that integrates with GitHub that enforces their review policies and their merging policies and all that kind of stuff so if we do decide to go to GitHub but there is a feature that doesn't exist I know that it's not impossible to add it so anyway decide to throw that out there. Yeah look you know there are pros and cons right like what what happened when we started working with Gary at the beginning honestly I was under impression that we have to move to Gary I don't know why somebody told me look let's just do it and I tried it out and it was not that bad you know you have to get used to it it took you some time to set up but it's okay a nice feature that you have in Gary just just very quickly is that you can have an inline kind of comment right I can highlight a piece of code I can say hey what is this character is this extra which I couldn't do in GitHub at the same time and I suffer from dyslexia I can always edit my reviews in github something that I cannot do in Gary right so it's really it's kind of preference uh I I never had anyone complaining about github you know so so we will do them I don't mind Gary I like Gary actually but people that didn't like a tool never complained about github because that that's kind of it's considered kind of the fact of kind of tool today right so every developer student is like trying to but it's also well understood and well known that for large projects it sucks now it's getting better but it still sucks I mean the fact that the fact that there can't be one issues that transcends a a set of repositories that sucks right and and and to have dependencies we have this nice dependency graph right so I can approve a few things and then I say hey Chris Gary can you take a look at that I don't approve it completely and then we merge it only when everything is ready right so we can stack them up and have a dependency between six issues with different specialties right different familiarity with code yeah yeah of course Greg you know from my perspective you know I've done a lot of Linux kernel contributions in the past and everything's done at least back when I was doing it on LKML and and people send a patch into the the mailing list and then people respond to the patch in the mail you know in line with with inline comments and submit it back and the patch is refined and that's really what Gary is promoting the so the the one thing I rena to that was awkward with the old GitHub model and maybe it's fixed was that if you have that iterative process which is what big projects tend to do like kernel and the way fabric is becoming and whatnot is that it is iterative until until that's a smooth process it makes it really awkward for the both the submitters and maintainers to manage it so I just want to make sure that's addressed no I did have actually GitHub actually supports this right so I I do maintenance for the rest toolchain and when I submit a patch and I put it out for review they'll comment on GitHub and then I will take those comments and make the changes in my branch right and then I'll push the branch again back into my fork of the code right in my yeah my personal fork on GitHub and it will actually update it'll see that it'll update the pull request automatically and it'll not only show what I changed but it'll mark and notify everybody else that have commented on that change that I have made a change and then that sort of signals to them that hey come back and take another look at it right it seems to be a much cleaner flow now the problem is it doesn't though at least historically back when fabric was on GitHub it doesn't work well and they're set in from the perspective of like you know projects like LKML don't want you to submit a history of changes to the patch they want you to submit the patch in its final form as as reviewed and accepted so in the GitHub model when you wanted to do that what you ended up having to do is do a force push to your branch to actually update it in place as opposed to make it work on top and that's awkward and that's that's you know generally against get best practices and the alternatives well the Git flow model is to to squash your patch your branch all down to a single repo or single revision before merging and we can build a bot to enforce that right if we do that's why we solve the problem right and and I and you know to the to the point of sort of addressing you know comments and so forth I did note that there have been some improvements made there um there's a an add-on a plugin that you can get that actually tracks the comments and then you actually have to check them off when they're addressed and so forth so you know there may like I said I think it's getting better it's not necessarily getting worse but I you know I think that we should evaluate where we are and certainly from a fabric perspective I'd like to take a look at at all of this but you know just from a somewhat of a consistency perspective I think it'd be nice if the projects were all using consistently and that we're making sure that we have dco and so forth all covered in part of sort of the required you know minimum required to declare a victory when you're setting up a repository that makes sense the other comment I would make too is if we're going to you know look at Dave's branching suggestions you know we we need to relax the limitations we have around maintainers managing the branches I think if we want it to be sane yeah in what sense do you want to limit the number I would think of limiting the number of branches a little bit so that we have sub sub branches that are relatively fixed not not like 50 because no that's that's I I agree with that too in fact the way things are going right now is that branches are not in favor of current you know kind of like the continuous integration model of things right right that's right so we want we want few branches but if we're going to have branches I'm just suggesting that having maintainers be able to actually merge between branches and push those merges back we'd go towards the problems that we have now which is that you know nobody can push merges out so it's really all right and so we just have to address that yeah I agree I agree and but you know to your point on CI you know the way we have Jenkins set up basically it's looking at a branch and responding to that and if we just turn it over and let anybody create branches willy-nilly then it gets a little bit out of control there as well yeah yeah oh I think needed if we go to github then the need is reduced because github more naturally supports the the get flow right like where I for me to contribute my first step is to fork the project and then if I have a a branch that I create for a feature and I'm working with several other developers they just fork off of my repo and we all collaborate on my repo and then when we submit to the main project it goes as a single pull request Dave I mean have to set up CI on your repo and how do you set up CI on my fork no you don't you don't because you just I mean the model is you don't have a branch a feature branch that lives forever it's you know it's a sniper's bullet it's usually just a small thing sort of a separate environment for us to try something out right I think that's the understanding the problem is the following right you have the the kind of the go long kind of build that passes and then you can have some test but you have a very custom kind of set up right so we have different tests and integration tests and all that stuff that's what Chris is asking you like how are you going to build that custom CI for your branch because you have to link to it somehow right so if it's on your own fork you're not connected to our Jenkins if it's like a formal branch and we push to that branch before we integrate to the not master but the main trunk then the CI will kick in yeah that makes that totally makes sense we're not arguing that's exactly what I have in mind sure so you'd have like an integration branch that's actually in the main repo and that's where feature branches that are developed often to other people's forks when they come in as pull requests they'll get staged in this integration branch and that will trigger CI and then we can that's what I'm offering the select set of branches that we know that are going to be the integration before we go to the main trunk and then we can have the CI link to this but you don't check into them like every 10 minutes yeah exactly yeah I mean that was in the branching model that I had originally composed but I think we're getting off track I think we're getting off track on this one I think we should get back to whether we should investigate GitHub or not yep so I hi this is Leonard I just want to say quickly if you are going to stick with GitHub could we start documenting a set of how to have best practice methods for you to get up across all the projects so we get that you might say alignment and synergy in the use of the tool in the best ways that some of us can recommend that's if we all want to stick with GitHub so I wanted to add well I've got some names you know ping me on you know rocket chat or whatever if you're interested and I don't know maybe we should just make it a working group task you know slash task force or whatever Brian as you suggest I don't think we ever had a mailing list or anything um but maybe I could work with rye to have one set up just so that we keep some of the traffic I I think a working group is a very good way forward because we can certainly use that to look at every tool that we have some privacy around we'll start with GitHub to find the best methods best ways to use in things that's all part of the process and the efficiency within an organization all right can we uh okay Chris can I just I'd like to counter that actually can we just think of this as a task force or a strike group with the very explicit goal of producing a a recommendation one way or the other and a very short time I don't think we need a formal working group for this this isn't something we should chew on for a long time I think we can revisit this in the future but I think we should have a very specific goal and it should be something we get to get through very quickly I agree I agree I mean we could use the you know the technical or the whatever mailing list if if that's okay with people or we could set up a separate one I'm I'm in favor of either one I don't really care I'll get all the traffic anyway so I'm not hearing any keen interest sorry we'll use the technical list I'll send out a note kick off the thread and see who's interested and then we'll take it from there sounds good all right thanks everyone I'll unless there's any other items I'll give people 10 minutes back have a nice one see you later thanks thanks