Baseline Protocol Technical Steering Committee, 6 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 3rd TSC Meeting 6th April 2020

Description

Baseline-Protocol.org
The Baseline Protocol is an open source initiative that combines advances in cryptography, messaging, and blockchain to deliver secure and private business processes at low cost via the public Ethereum Mainnet. The protocol will enable confidential and complex collaboration between enterprises without leaving any sensitive data on-chain.

Official Press Release https://consensys.net/blog/press-release/ey-and-consensys-announce-formation-of-baseline-protocol-initiative-to-make-ethereum-mainnet-safe-and-effective-for-enterprises/
Twitter https://twitter.com/baselineproto
Baseline Protocol Documentation https://docs.baseline-protocol.org/
Github https://github.com/ethereum-oasis/baseline

A

Yep I am recording now anyone is concerned about that. Please drop and yep, and we will. We will publish that this to our YouTube channel I think we're gonna, probably just start going towards more just immediate. You know non edited versions unless there's something that absolutely needs to be edited, we'll we'll put those up quickly on the on our channel, so I'm just checking one thing: real, quick to make sure recording is doing its job correctly.

A

Yeah good good, alright, so hi everybody welcome to the is this, the fourth or the third, the third meeting of the technical steering committee for the baseline protocol and looks like we have the the core group here. Probably a few more people will drop in as I see you I got Eric gosh Stephan. We got Nate Kyle Hudson, Karthik Johan. Is there Brian and Zach? So that's it. Let's breathe! That's a quorum!

A

We I'll pull up. Did everybody get the the workflowy with with the agenda start with that.

A

So you may not have access to them.

B

B

Actually I do not I thought. I did host that in chat. Sure.

A

Thing yeah I'll, share, screen.

B

It looks like that's a living document. Can we maybe add the link to the meeting invite.

A

Yes, it's actually in the meeting invite Oh.

B

Has a link to the github and it goes to ok.

A

B

Or you know, people that are contributing kind of their guidelines didn't go to the agenda strange.

A

I must be missing remembering by Chris Warren I put the link in there I might have might have provided the wrong link. You.

C

Posted issue 52 in there job that.

A

Would definitely be the wrong link that the intention was this thanks for the error out. I'll fix that for next time, yeah. So this this is now this. This link up here is so I've got a share screen.

A

So here's the TSC meeting, link and and I've got the share link that we just shared in the chat.

A

The and I will change that actually I'll make sure that we don't publish that to the to the web, so that not everybody has the edit link for this forever. Just realize that would be a bad idea.

A

So the we're on the third meeting and the agenda I've got here is review and driving docks and policy of final review and so Brian and Karthik, and can give an update on that review and decide on how to manage the repo and and another one is I was just talking about with somebody today was about priorities for next couple of weeks.

A

So what do we want to encourage people to.

A

To work and to focus on and do things about, look because you didn't have this and I thought you did do we, let's take just a couple of minutes to see if there are other issues or agenda items that need to need to fall in here.

A

Hello, anyone I.

B

Have nothing else add okay,.

A

Stefan you got any news or anything you want to bring up. You guys been working hard.

D

Yeah sure news there are a lot of news, but not con concerning the way we want to set this up in I, don't know in then hop or anything still need some more time for that I guess, or do you mean updates on the actual development progress from our hackathon? For example, it's just the right place, I, don't know.

A

Yeah and I might actually be worth worth talking about so update.

A

Okay, cool John.

B

I'd like to check in on the CI integration process and if there's any activity there or any.

B

Hardware needs.

A

A

Excuse me not Kovan, hey.

B

John real quick I actually did just think of something for the agenda on the roles and permissions section say: look into or actually actors and hub, epics and github issues say look into github projects.

B

Just yeah, it's gonna be right. There that'd be fine.

A

Let's say github projects versus anhum projects, yes,.

B

Because there was some issues with that: I read about from I think it was the email or the or even just this agenda about the epics and github issues.

A

Anything else Connor, you have any thoughts um I, uh one of the things that we'll talk about or Pratt in terms of priorities are eric. Helped me out with what were the three ones we were talking about the other day.

B

Actually yeah the real-world integration.

B

The specification specifications.

A

B

A

And then abstraction yeah.

B

A

You go next living document. Okay, anything else going once going twice: Johan Zack, I.

D

Think, but still might right now, Karina.

A

A

I think we'll talk about in real-world integration Johan in particular. You know I think you know you guys need a bright and some other folks are the experts in on this team on that subject, and so we can get to you on that. So, let's yeah, so let's get to it the agenda so reviewing and drive maintainer Docs and the pilot and policy Brian Karthik. Do you have a bit of an update for that.

C

Yeah we're just going through final revisions and have an update pushed out to get out, hopefully, by the end of the day. That's true.

C

Well, we've already added a couple: maintainer x' who have given us their github handles and we're just kind of ironing out the roles and procedure for the role of a maintainer and then the procedure for becoming one and what the job is essentially yeah. What.

A

Would you say the highlights are one or two highlights for what one should say, because people are asking I've been getting this question quite a bit. You know what really can mature quite a bit, but you know I still one hand, but that's you know in my day. That's that's that's enough of a signal. The people are interested in the topic. So what would you say with a couple of reasons or things that people should know to become a maintainer? What do we want to do.

C

Well, we don't quite have the merit badge approach that you had mentioned, where it was kind of an atomic level of. If I do this, then I get a. You know, checking the box for that and if I do this and there's a check in the box for that and then, if I get enough check boxes, then I can become a maintainer. We unfortunate don't have that level. It's really clearly at least not yet, but you know, but it's it's a big I'll just say it. So he has to become maintainer.

C

You just need to show consistent contributions to the code of the project can be in the form of pull requests. They get emergent, a master or say like system, architecture and related artifacts that you know guide the technical development of the project.

C

We obviously look for people who are experts in one or more fields relating to the project and.

C

That's about it, the that we're proposing the TSC meetings are these meetings. We propose new maintainer x' and then the current maintainer x' must have vote to bring in a new maintainer. We didn't figured out, or at least written down the process for the vote, and who is you know me monitoring the voting and taking minutes on that part of the procedure. Yet so I left that out today.

A

So TFC proposed proposes mm-hmm.

C

Well, people in the TSC meeting and just during the TSE meeting nests when we would someone anyone I can join the TS, those that propose.

A

So if you want to nominate if you want to get nominated- and you know you want to be on the maintainer team- get to a TSE member or maintainer, and we will bring your name up during the next TSE meeting and that will be the maintainer thing. I think um I check check me if I'm wrong. You know the Conor has other folks too done this. You know the maintainer 'he's.

A

Typically don't go to the TSC to decide whether or not somebody should be on a maintainer, they usually just say yeah you're a maintainer, and if they can't agree, then the TSE steps in that said.

B

A

Know that I disagree with your approach, what what other people have had to say about that? I.

B

Said they couldn't speak for how things that done saying led to areas quite formal, but you know III. Would you know presume that we do have a good degree of autonomy with it and yeah I'm I'm, certainly from my own personal perspective, would think in the early days sure it would make sense to at least notify the TSE of maintain is. If this is, a decision is made of ronamoon autonomously by existing maintainer x', but then yeah I've worked. You know, my experience has more been on.

B

You know, I guess pure open-source projects, rather then sort of you know suppose industry backed open-source projects. If you see what I mean really.

C

What's the main difference, your experience between the sort of the industry backed and the non industry backed open-source projects in terms of how they're managed like in this level,.

B

Sorry is that a question for.

C

You yeah, yes, that was a question when you say you want to there. Yes,.

B

I think from from my own perspective, it's more been on. You know, pure open-source, that I've been I've worked more extensively on its in we're. You know, I, guess the to me.

B

I'd say if we were going to look at I mean within the EA, for instance, it's very much so working groups within the free to kind of run things they want, but you know say with hyper ledger: I think if we wanted to look at kind of you know, I guess the other end of the spectrum, which is obviously taking a lot of leads for how things are done within the Linux Foundation. Then the the process. There is somewhat different than that.

B

You know you have UTS see the members are elected to it and so on and so forth, and this you know very clear governance around it. I'd say more broadly, the question is: is you know how rigorous do we want to be in these earliest or the bootstrapping phases for for this body? I would personally be more supportive of being slightly looser in the early days.

B

I, don't mean you know not in a way that you know it means they're, only less there's any less integrity, but more just gives people a bit more autonomy to get things done. Mmm-Hmm.

C

When you say like a pure true open-source, you mean one that isn't managed by a organisation yeah.

B

Yeah, an organisation or like a clear industry body, this.

C

Would be from in my experience what I think you mean is, like you know some person or a small team or small team, an existing company kind of open-source as a project they had worked on and it's more organic kind of grassroots development over time. So what you mean kind of sure, yeah.

B

Yeah I mean so you know where, for instance, I've spent a lot of time has been with web 3j projects which I that's that's something that I was extensively involved in for a long time, and there is you know everything was done much more organically, whereas you know if we were say to submit the project to be say, included in hyper ledger at some point down the line, then there'd be a whole load of governments that we need to go with it around like release schedules and various bits of their various requirements for it.

B

But that's because you know hyper ledger is, of course you know following the lead from the Linux Foundation, whereas if something's you know existing more as going back to web 3j has is a pure open-source project, we kind of we make the decisions which we feel a purely best for the community. There, you know, with baseline I, don't think we're trying to necessarily be something as we want to be taken very seriously in terms of you know what what the projects trying to achieve and everything else.

B

But it's just you know the the right level of governance at this point in time. You know whether the TSE has to approve people committee, so proof approve, maintain, is or not I think is I, don't think it matters too much at this point in time which approach we go to I. You know I think if it was down to me, I'd say: let's just let the maintain is choose but again I'm, not I'm, not sort of firmly wedded to to either right now.

C

Okay, that's good advice. Yeah um I II was trying to with the current proposed voting approach kind of mirror what we have in some other aspects of the governance. But it's good to know. I mean at least good to consider, and maybe we don't don't need that level at this stage.

C

A

B

And yesterday well.

C

I guess in that case, then there wouldn't be a proposal at the TSC. You might just be the maintainer x' can maybe at the weekly maintainer meetings, which we decided will be public, propose and can vote, and then it kind of be just within the maintainer group that that maintainer is come and go cuz. I guess that does seem appropriate at this stage. I suppose say.

B

Could I can I just come to confirm with like the we thinking and just that it would be actually down to a vote of the TSE for maintainer x'.

C

Well, I guess: I thought if the proposal would happen during the TSE like a meeting like yes and even be up to the maintainer x' to vote, but I guess obviously facto with that being proposed in this meeting. It would kind of be a pre vetting and a discussion about that person and what they've done, and I suppose, with the proposal whoever was proposing them- would need to help for some evidence about why they should be a maintainer. And then that could be taken under advisement by the the maintainer x'. But.

B

C

Maybe there's a bit disjointed because every maintainer is in this meeting so.

B

But we know over time that he anticipated maintains being in this meeting. All of them you'd see that that change, and I mean certainly what what happens to the EEA with working group chairs- is that they they change over time and a decision is made, and then it goes to the the board of the EI for a crew I mean, maybe if you, if we would like to have some sort of proof.

A

And we've got in the in the governance stock 40s see we're still working on the SSC governance stock. That'll be the thing for next time for next the next hour, the the there is a pretty solid procedure for that I.

A

Let me propose something in and see if we can get loose consensus on it, so we can move to the next agenda item. What what if I was listening to Connor, listen and Brian? What, if we said? Look you know you can propose during the TFC meeting you can propose during the maintainer x' meeting as TSC meetings get to be monthly as opposed to you know, weekly or bi-weekly.

A

It will probably become obvious that the maintainer meeting is the time to get proposed and that that will be fine.

A

So, but if we for now, we say: look, you know the we will review, who got onto the maintainer meeting during TSE meetings and we can propose during TSC meetings, but you can also propose and vote during maintainer meetings and if those maintaining you guys are now open to attendance, presumably by by the way Brian like folks, like myself or others who are not true, maintainer x', except in terms of all of us on the TSC, have admin access to the repo, which is another topic for another day.

A

You know how we maintain roles and permissions yeah. You know that the the etiquette would be maintainer speak during maintainer meetings. We can it attended, listen.

C

Yeah yep, definitely we want to make it very open and I think there's some models out there. It's getting a project, but I was very impressed with just John blank Harris, looking at their YouTube channel but um yeah. The maintainer meetings are, you know, gonna, be open and available to anybody, especially someone in your world John list here of all not contributing code, contributing a lot to the thought, leadership and certainly documentation. So we do want, and that I mean that's incredibly critical to the project having good documentation.

C

So we want to be able to carve-out at least what that means. You know contributing in ways that are not directly code but also important to maintaining the project, but I also want to follow up with the point you made there about the admin access. Now me unless there's a different view of admin to the repo there's, only four people who have admin access to the current baseline repo and it's a subset of the current maintainer z--, so Sam myself, Patrick McCarthy, are they only for admins?

C

As far as I'm aware, everyone else has either right or then well the new maintainer. As we added there's a maintainer role so.

A

C

The sound scenery on here.

A

B

Jory is up. We.

A

Can take it offline, I? Think in my investigation, I discovered the TSE all TSE members, as a team have, unless I'm mistaken I could be admin, rights and I'm, not sure that's correct, I, don't either I'm, not sure. That's true, nor if, if it is true I might sure that's what it should be. Okay. So it's it's on the agenda to actually discuss alright.

C

Any worth looking into you yeah.

A

Absolutely I think it's time for us to to lock this kind of stuff down the content. The only thing remaining here is: do we want a piece? Do you want a Commission, Brian, and and and do we want to set an agenda item for the next meeting to have some content can to consume for a new maintainer to get alignment so that we know that they, you know, have the basics and that they understand the priorities and blah blah blah, or do you see that as a more organic process?

A

What are your thoughts there Karthik as well.

C

I'll go now let karthika and yes, I do I mean I, think that would be useful for the community and I mean it even if it was not for maintainer z'. Anyone who contributes at the code base. We do have a contribution guide, but it is very it's more. Generic in terms of you, know, procedure, process and sort of general guidelines, but we I would like to have some kind of video I think that I guess I'm, assuming the video, would be a appropriate medium for this.

C

Maybe one or two high-level videos, like that's a little bit more consumable these days than a long document, or anything like that. Let's just my my thinking will be great to do. That would like some time this week or next we can have that up.

C

That's as far as I've thought about it Carly do you have any anything or thoughts on that.

B

I think you covered most of the important but Ryan I. Think, apart from in terms of the video, also it just wondering what your thoughts had about what should be in the video. Is it like a into a demo of how things work, or is it more about hey? So these are some of the issues you might face, and this is how you might want to fix things or is it? Is it something to that extent just wondering what to convey.

C

And it should be questions I guess in my mind it was a high level philosophy of oil based of baseline and the concepts in a generic sense and then also the high level explanation of what the baseline repo is like. So more of the specifics of like well there's this repo and then we have the radish folder and that's the POC and here's the kind of milestones that were kind of pushing or for in the next few months that and then talk about about.

C

You know what we here's, what we do, you have to write tests, you have to use linting, you have to do some of the mechanics of the day-to-day, so just kind of a like imagine if you were onboarding someone at a new company and you have like your training day, we used to sit down but okay, here's what we like to do. Here's, how we kind of like to do things like that kind of thing, I think.

A

C

Stuff is important, but probably best for automated scripts, and then that could be text-based. It's kind of learning, I.

A

Think that's a good set of activities. I wrote them down here: I'll buff scratch out oral exam. I was joking, but video, docs, page Sanderson practices. Islam I was like three high level pieces right, standard practices, high level concepts and specific folder, walkthroughs and I. As I recall, we have two of those already in some form. The Daniel and team from envision did one chef on his own.

A

Other team have done another one, and then we have our own I think we have at least three sets of assets right now, for with the high-level concepts, are we also have a specific folder walkthrough? That Karthik did you and you and Karthik did Brian as I recall, so we have those two things we could put. Those both highlight them on a page, yeah, I'm looking out and then I, don't think we have a standards and practices, one that we've been. So that would be the last one. Okay.

C

So there's not as much work as I thought is this sort of organizing it and pulling it together in one place? Well,.

A

Certainly, you know we have some stuff to start with and I think we can improve it over time.

C

Great so um I guess I'll take that on as an action item for next for next week and that my next next week for update here at the TSC.

A

Right now, okay, so on to the next item, without descent review and decide on how to manage the repo so- and we had a little highlight of this and a second ago, zhen hai, epics and github issues.

A

There's a question of how we wanted to handle this Zen hub specifically creates no item in the repo full or projects in the Zen hub project thing. So if I go over here and I start up Zen hub which, by the way, should work for everyone now, but only people who are in the org- and this is something we have to talk about- a second can can be assigned to anything or do anything with any of this stuff.

A

So you have to have at least read access, not just few access, which is what every you allow allows you to fork and clone and pull and stuff look. But you can't and contribute. But you can't you don't have read access the you know in the github style, so here in the Zen hub. If you go into room ode map, these big boxes, TST, maintainer governance, hosted base. None of these show up and get hub unless I'm missing something Frank. Can you confirm I.

A

C

Yesterday, alright, there is what I don't actually can't come on. Let me see.

A

So, like SSC governance, I can't find that I thought they were, but I can find right, SSC, governance, doc, which is an epoch, and those are issues with a epic label on them in github. That's how Zen hub handles it.

C

I'm sorry so this one says: SST governs them which went right: SST, governor Docs I, so I should see right as I seat that government governance, doffing.

A

Se govern Docs is, is I am 65, but SSC governance has no object in in github.

C

A

I see that yeah.

C

So I seem right: SSC sixty-five, whereas ratify as a CS 66 implement a 67 yeah. No.

A

No, no high level project level thing: okay, the the net of the question at hand is: how do we organize to actually to start executing and and in sort of focusing fire of the community and being an effective force.

A

Two basic approaches: right put it all in one repo and try to manage it with the risk of becoming a mess or put it in multiple repos and edge it with the risk of becoming a mess.

A

And you know it choose your poison right. So this is a time to die. I'd like to allow for ten minutes of discussion with no intention to close the issue, but rather just start some thinking that we can close in in the next meeting.

C

That's a great idea: yeah I hear what you're saying about I think you know one where it becomes. A master that becomes a mess.

C

I mean entropy is inevitable, so it takes people to kind of keep them in line and if there's no one there as a steward but I mean you have that the chaos it's just the natural state of the universe. So fighting that it's a lot of effort, so.

C

I, you know I think the other thought that I don't like to say about that one. So I don't actually know the answer to that one I say maybe managing in two spots. If it's the same person could be challenging, but if it's two different people- and they have two different ways of running and managing the work, then that might be okay, I think for github.

C

You know the the actual work items that the end result of using github issues is a ticket github parlance an issue, and that is a unit of work that a or a group of people can take on and bring to completion. Three setups set pipeline stages and things like that, whether it's like you know, aim up the backlog in the icebox. We won't.

C

You know using sprint parlance, but at some point someone takes ions, assigns it to themselves I'm going to do this and that's their responsibility to to complete it to the satisfaction of the author, so I wonder it with a lot of these ones and are more high-level. Like specifically like write the SSC governance dog, you know the end result. What is the unit of work, for that is? Does that get broken down into a set of tickets where it's like? Oh right, the intro is one ticket and right the I.

C

Don't know. Process and procedure is another ticket and then get it. Reviewed is another ticket and are those things that anybody can do or engineers maintain errs and things people who would typically look at the issues or is it a set for a specific group of people?

C

So I guess I have two questions from that was kind of rambling, but like is it is the issue, the appropriate level of granularity for the high level, epic kind of project management level tasks and are those something that everyone, including engineers, would take on and be able to work on. So.

A

I think it's gonna depend on what what the actually.

B

Well, it's actually in the issue. You know, I.

A

Mean I think I think a lot of times. An issue is going to be, it is gonna, be broken out into many.

B

Many stories- or you know many stories that fall under an epic.

A

Issue yeah I mean if we were following straight up, agile practices right an issue should be something that's containable with this sprint. Sprint's are an interesting concept in community work and something we should be looking into more, but the the in this case I the way I. The way I like to think of it is if it starts with an accident. It's probably a task in we've started with the notion.

A

This is a variation on the methodology is that you know, epochs are the land of topics and buckets and stories and issues are the land of engineering tasks, and if you want to know which one you've got our engineering or just kind of do stuff tasks. So what you want to know which one you've got look and see if you've got an action verb at the start of the sentence.

A

If you do, then you probably have a task, which means it should be an issue, and if you don't, you probably either have a story or some level of epic and because Zen hub allows you to nest epic with an epic. It allows you to create kind of a compartment or a pretty flexible plastic way of boxing things up without forcing engineering into figuring out. The ontology of every single task they have to do was.

C

Yeah and then one of the benefits of breaking things down into tasks, is you kind of break them up by specialty? You know you may have someone who's doing Oh. This feature requires a design, change, some logic chain, business logic, change, some deployment changes and you can label them and sort of subdivide by specialty with a lot of these high level ones. Are we gonna have that same level of breakdown we're like Oh?

C

Only one person is gonna, be able to write the SFC governance and the only another person is going to be able to do to their specialities. You know not doing and the reason that there's experts and that one thing you don't I mean yeah.

A

I should think that that, on a good day and I think you, as you said before, entropy rules. Ultimately, so you know that we don't move, we don't always have good days, but on a good day, for example, this is an error. I think I wrote it right. Ssc governance stock is not an epoch. In fact, I changed a couple of these already where they were there. You know it starts with an action verb. It should be it's an issue and it it should be within some other.

A

It should be an issue pointing to some higher level thing like governance or SSC governance, and then you can say yeah. In fact, you know we need to break this down, because that issue is too big. You know right. The whole government stock in one small period of time, maybe not possible. Let's break that work up into chapters right, so you could have chapters yeah.

C

I mean even think about like what you're just saying: it's like yeah, you don't sit down, I mean just thinking about the writing process and I mean I'm. Not you know, I'm not greater per se, but you know you. You come up with an outline and then a draft, and then you show just some folks. You get some feedback and then you do some other versions, and then you have a meeting about it and then so it's like there's pipeline up like that.

C

So right, yeah I, think for something like oh right, SSE government Docs would be like okay. Well, what? When we're writing a ticket for development? It's like it as US so and so so I have a whatever yeah I need this. You know, I, don't know if that's appropriate, to apply to this case, but it might be something to think about. It's like the description or the title indicating like. What's the value and in every US work.

C

You know we have templates that work for other for the code, issues for bugs and features, and things so know. If that's would that be helpful. Applying here at the epic level, yeah.

D

I would have a question question concerning this as well, perhaps to make it a little bit clearer to me when, when last time you show them John, you show the Zen hub project, management or timeline, or what's it called tap, I understood it more as a planning tune as a tool as a higher-level planning a tool, and then, when I tried to understand what kind of sub steps I could provide or proposed for the system of record integration tools and then, of course, I.

D

Don't have the actual ability to do so because, for example, general integration, our API or a unified services is already on issue level. So the question is: who would be the right right person or the right role in charge to first builds something of like a high level structure of so to so to say, epics within epics that should be tackled in the next weeks, and that could at some point hold a lot of issues that might be broken down into smaller issues.

D

But before we get to that step, I would like to have a tool where I could propose some kind of generic development or architectural outline regarding to a system of record integration in the current setup. Also, given my github user and The Associated role with the sin hub, I I can do this because I don't have any any rights to to provide something. You've.

A

Brought up an important topic that we've also just about were that's the next topic. In fact, okay, is these kinds of rights.

C

There was something I'd popped in my I mean I worked at the last I sorry I was employed, was holding off on creating epics until an issues, then that matter and breaking down the project until the various as late in the process of ideation and design as possible. So you know you would start off, maybe with one high level like you have in your other previous view, before they become epics, where it is SSE, government, Docs and then inside there you put all the details.

C

Maybe instead of creating epics, you actually write the mess text and then you just when you actually then say: okay, we've planned enough that we can actually go execute. Then you turn them into epics and issues and then you break it down, and then you assign work and you kind of put it in the queue.

C

So you actually use a you know, standard word or text based document with bullets and headings and things to scaffold your work and add color and context and and share it with folks before you then kind of press it into a template. That is more rigid. Like epics and issues you know with specific labels and projects and milestones and estimates and all that stuff. That's like we found that to work very well because it didn't clutter up the the repo with a lot of like no I have an idea.

C

Let me just create an epic for it, but not like thinking it through. You start with a document, then you make sure everybody who's going to be potentially working on that part of the project reviews that document as common and then flushes that and then at some point, you're like okay. This is ready to go and then we're gonna cut all of our issues and ethics out of it. And then then you know people can do the run with it and whatever the.

D

Perfect, that would also be the perfect answer to my concern so to say, because when I understand it right, currently, the SLR integration tools is a project and it's not possible to create any sub project that do not mess up the the git repo but are more like structuring tool. First of all, and so I think this is not possible to have projects within projects. So this is why we are directly on epic level now under the SOR integration.

D

Integration tools, and perhaps the way you just outlined would be that we first have some some edge documents so to say for each project where we outline the set up of potential epics and then when, when a large enough group said that this document outline is okay, then we can actually create the epics around it. So I think.

A

It's a good idea: yeah that sounds good I.

A

Wrote down what Brian said and I think that the lists memorialized that let's do some thinking about it and let's resolved that by the next meeting, we will have a worked out and written down approach that everybody can can get behind in terms of planning and organizing and and then managing the work and managing and checking that the work is getting done. I mean.

D

For now, perhaps it would be a good idea to just include something like a Google Doc link into each of the projects that don't have any issues under them. For now so at least there's a everybody who can read the the Zen hub roadmap can already click on integration tools. Then he would find in the description of the project. He would find a link to some kind of Google Talk, where we at least start to collect arguments and discussions before something template issues in in place, perhaps to.

A

Yeah, what if what? What if during planning- and we first of all, will said I- will get you access to the to create these projects right. So there should be an integration project in here and I. Do like the fact that these these can create these nice big buckets, right, health care and other things, and we can as easily get rid of them as we can move them around and one of the things we can do during TSC. You know, meetings going forward in SSC meetings is drag things up and down.

A

Is you know which ones do we want to? You.

B

A

Higher priority and that sort of thing which ones do we want to point out to the community or high priority, but that what you could and then one epic right so one epic below that. So instead of this all this stuff, we'd have one epic to Brian's point that we can use just the epic description and comments or we can in that link to a Google.

D

Doc good at good idea, yeah.

A

I, listened to start with just the epic itself and see if that suffice is that way we don't have a third and another tool to go out to, but if we need it, then we can go to a Google Doc as well. Okay,.

D

And father for the definition who can contribute to that epic definition and finding arguments and structure, it would be about the next topic on the on the agenda concerning the roles and permissions. I. Guess yes,.

A

I couldn't for.

D

A

So, just in the interest of time- and we have do- have a hard stop in twelve minutes- see I integration process, I, assume that we we haven't, made a lot of progress on that yet and in Jory's died here. So do we? Is this a topic for next time? Perhaps I.

C

Can give a quick update so I can check I'll about it, specifically the details of what we tried out for the CI system, we're going to experiment with github actions, because that's kind of baked in Jori had a call with circle CI and but we did not connect last week or I could find out the details of of that.

C

So we're moving forward with looking at github actions. We still some outstanding questions about. You know how and where the CI aspect of it is run and who guys we can pays for that and how much we are going to end up call charging against the theory of Oasis github account with those types of role in Grecians, but so it's two thousand minutes did we get four years yeah we get.

C

It says the free version gets mm, cortical minutes of execution, so that gets us about a I mean just some rough envelope back of the envelope. Math will give us maybe a hundred builds. So we.

B

Just started just using master, it yeah.

C

And then we yeah we just build and run CI against master, instead of which we didn't hit instead of every pull request, which was every poll. Cress is probably the ideal state, but for now just the the master branch and see you can see where we go from there. Well they're gonna try to meet up with jory or virtually obviously to get the teaches of the circle CI column. Maybe that may change our direction a little bit. But at this point it's I.

A

Think I'd be in a good position to like actually looked into the e, the actual work behind the CI process, whether it's get out of actions compatible or circle CI compatible as soon as this, this Bank found branch is I. Think it's you logical next step, okay and Brian, and it sounds like Kyle. You guys are budding up on that and make sure that sounds like that's a well handled.

A

Shall we move on to the next.

A

Eric Jimmy other questions and I know you you want to bring in them. Yeah.

B

I just wanted an update on that and if, if anyone ends up having hardware requirements.

C

I've put together a Google Doc and shared that on the TSC private channel. So just.

B

Hit me up and we'll arrange hardware for that: okay.

C

B

C

Some general questions around what that meant, but we can take that offline yeah. Well, we'll take it offline.

B

C

B

C

A

Okay, so I on the on the accesses, you know: did some sleuthing around and figured out that yeah, as you was a little silly for him, forgotten this, but but the you know so the the Zen hub and github permissioning is, you know, unique and and one of the things, so you know we have a public repo. Anybody can fork it. Anybody can do stuff, but in order to mess around with issues and epics and stuff you have to or issues is all you can get up of different types of labels.

A

You have to be able to have read access or above so that means that we need some kind of and again this is not for resolution today. This is only for discussion very quickly. At this point, I'd like to bring up the fact that even people who are regular contributors right now find themselves. You know frustratingly not able to do to work with the projects or the epics or the issues in a meaningful way. You don't want to open up that up to.

B

A

Public because then you get like the equivalent of zoom bombing right, you know, so you don't want you know what that so. There's you know there's this balance between. You know the fact that we want to be very opened again and not have insiders and outsiders, but we also want to have some assurance that people that are that have access to write things in the in the repo are are with you know, on the issues, side or they're, not gonna, be pulling shenanigans right. So.

B

There's a issues: do you mean a github issue like as it is today correct.

A

A github issue, or in Zen hub they just kind of put an overlay on top of issues, ring okay,.

B

Cuz I've never really accepted this one time. I've, never seen a repo issue bombed that happened like a year and a half ago for some aetherium repos, but yeah. That would just be just blocking them basically, and if they come up with a new account, you contact github and they take care of it pretty quickly. Well,.

A

That is certainly a way to go.

B

A

We we could ask jewelry to make on the public. You know we could. We can I think we can make that you know everybody. You know the world right access that would reduce. But that's that's a you know. That's a decision. That's a policy decision yeah with implication. Let's.

C

Pull off on that I mean there are ways to throttle in through github folks from things, so we could leverage we have before we opened the floodgates there. Good.

A

Idea, all for next time and and I'll take it on unless anybody else wants it is to is to have a well-articulated and well listened. So you know: go out and listen to everybody, get some more on ones and develop a approach to that reduces the amount that keeps the amount of of effort required to get somebody into the group of people that have that a level of access make it easy, but also balance the other factors and and actually should have fun.

A

If you can't would you offline, would you check to see that you aren't able to create a new project or up in here like this.

D

Of course I checked, I cannot add, I cannot edit. I cannot reduce.

A

Weird, okay, so so that's the other action I'll take is to make sure it with Jory that we have normalized the permissioning. Everybody on the TSC should have total access to do them. Yes,.

D

Often forget everything I said before I thought it was part of a bigger role, discussion process or something no.

A

That that that is, that should be working so so I'll take the action to debug that problem. Thank you, um okay, move it. Let's move on to priorities and it's good. We have five minutes left without objection, priorities for the next coming weeks. I mean this, isn't a company that we can tell people what to do, and you know this is a this- is a community that can decide to do for itself what it wants to do, but we can focus a people's attention on things and I.

A

Think that's a good job of anybody who wants to play a leadership role in a community. That's that's really the thing right. So it strikes me that and I will propose that to get momentum set momentum and keep it. There are some things that we have to get serious about soon.

A

Sooner than other things, and let me just throw out a straw man for discussion and then we can take it up later or in fact I'd like to just anybody that has a sense of this being wrong. Let me know: first thing is real-world integration and you know we we need to find. We we, you know, we need to kind of ask the universe that we get it, that we find as quickly as possible some examples of using baseline to integrate a real thing with another real thing you know in the POC.

A

We use to databases that are resident so in the in the next step clearly would be to to see an S AP and an oracle apps, or something like that, and you know, Johan and Stefan have particular powerhouses for doing this sort of thing, but others have that as well, and it strikes me that this would be a good thing to let the community know is is on everybody's mind: does anybody have a disagreement or a thought about that.

D

I mean basically, this already covers the heck of an update and I mean if we just come to something that is valuable to show to the world, and it will start all these processes for the for the community to pick it up. So we do in our hackathon. We do an example with one specific integration case and one specific setup so to say, and everybody can can watch the the walkthrough and check the code and do continue for himself.

D

So I would think that these things evolve as soon as we are like four weeks in the future, then this will be way more easier than telling it now on the more theoretical level right.

A

Now so yeah, and and given our time frame right now, I guess we'll leave it at that. I have three minutes left and we do have a hard stuff. Specs are the next thing and then use cases and those three things add up to abstraction and generalization right. So if we, if we were just run off and do abstraction and generalization of the current POC without a few use, cases like I think it's. Ninety issue, 95 is Balaji, is working on on a co.

A

Vyd idea, I made a comment in there for him on that over the weekend. Take a look. It's I'm, an interesting thought if border line deals with identity in a way that makes me a little uncomfortable but I think it's kind of cool and could be workable and I, like the idea of you know like using a one password for that, but in in those are use cases and that and an extended did, the idea of what baseline would be doing on a practical basis.

A

Do a couple of things that we haven't thought of in the original TOC, so different use cases that we can apply and say well, what else did we miss in the in the baseline stuff is important so that we can have a good spec that we can then abstract and generalize the POC into that, so the order of operations seemed to me to be get you know, get real-world integrations, get more companies on board. To this thing, the integrations are going to show them that it's exciting.

A

The addition of more companies will also show excitement getting there's aspects, dock in the docks already, and we should. We can start to build on that starting right away and we can start to accumulate more use, uses and and see kind of through those lenses. What other things in the spec need to be there and that should all create a recipe for the abstraction generalization. Does that sound right.

D

This sounds perfect and I think it's just the way that it will happen so with every packet on each example, project. Of course, one result should be to take out some of the findings and check whether there are valid for put in the abstract protocol and not only the concrete use case right.

A

Now we are at time and I you know, is the convener I will take responsibility for not managing our time better this this week, and so, as penance I, will follow up with everybody with a digest of what what we discussed and action items, because we can't recap them here. So look for that note, and with that thanks, everybody we'll see, let's assume two weeks from now or do we want to go next week.

B

Doing signs good, familiar I note.

D

A

Two weeks, two weeks, two weeks, two weeks, chilly, alright, please thanks.

B

John 1.7 thanks everyone Olympics. Thank you.