[Protocol technical on-boarding series] How to prosper in the world of open source (March 2nd, 2023)

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:00

   give me one second okay there we go all right um I'm starting the recording so you can go ahead whenever you're ready Cool all right thank you very much Sarah thank you very much everyone for joining um so I hope you can see my screen and and here we fine so I'm gonna talk about a little bit about what kind of tools we use to work in the open and and what are the different open source philosophies we have and how can we be how can we do

2. 0:41

   engineering uh in the open while uh encouraging uh Community involvement Community discussions and so on and so uh there's no or anything these this is just like a to-do list for me to follow to make sure I cover everything uh feel free to interrupt me to ask questions uh you know there's uh whatever questions you might have uh a lot of this might seem like a repetition if you've been around for some time because I may have already discussed some of this with

3. 1:20

   you um all right so I'll just start jumping in I'll just dig into it so first thing is we have two platform forms for chatting and talking with each other one is slack and one is Zula why do we have two well zulet is something it's a it's considered very it's used very often in open- Source uh projects it's used by rust by many other big open source projects it's sort of like GitHub

4. 1:53

   in many ways where if you're open source you you should have a zulip stream for for discussing the project and so on and our ZIP is open to the world anybody can join it uh our open streams are open in a way that Google can crawl it and you know Google and search engines can crawl it and they can if you search for specific things about near you would even get hits from our zulip stream and so on so that is all intentional we want all of our engineering discussions to be

5. 2:27

   in the open um so whenever you want to discuss something engineering related you should it should be happening on zulet and whenever the discussion is about something that does not impact the security of main net of like an existing Network main net test net like if you're not discussing a security issue that is on the network right now now it should be on the public channel right so only if you're talking about something that you know oh there's a bug

6. 3:07

   on mainnet right now and I want to discuss it then it should be on private but if you want to discuss engineering things about anything about the protocol and so on it should be in public channels so the rule of thumb that I use for zulip is um if it's something uh about our private lives so if I'm if I'm discussing with my team oh who's available next week or who's taking time off next week and so on we don't want that in the public right so

7. 3:40

   if we're discussing uh taking time off vacation blah blah blah those kind of things are in private and if we're discussing security issues then those are in private otherwise everything is in public we uh even if sometimes we're sharing documents that are not available publicly that is fine just share them on uh public right there's no harm you know in doing that it's just a link and people might not be able to open it people might but that is fine you know it is

8. 4:13

   noisy it is chaotic uh the average person outside of our team or outside our protocol will struggle to follow our conversations if they just start in the middle of it but that is okay we are not it is about building the muscle memory to have everything be in the open and work in the open for the eventual future so maybe I should have start off with this right um currently we are the main we are the main uh Engineers working on the

9. 4:52

   protocol and in many ways we see ourselves as the owners of the protocol of near core but the future that we imagine is that we are just one of the many many contributors to new core the future that we imagine is the best analogy for that is imagine you work on you're part of the Russ team at Microsoft right Microsoft is a big company they have a ton of different projects and you're working on a team whose job is to make

10. 5:27

    improvements to the r programming language and somehow through some weird IND direction that helps Microsoft make money that helps Microsoft's business but your focus is to just improve rust that is what you're working on and somehow that helps the company and that's why you're employed by the company and so on and you're just one of the many many contributors contributing to rust and currently we are the biggest

11. 6:01

    contributors to near core but the goal we're trying to reach is we are in this place where we are just one of the many contributors and so that is how we should think about it whenever we're thinking about working on near core you know how can I how can I help enable that future how can we get to that future you know what when we are working in that future and say the feature that I'm working on the project that I'm

12. 6:32

    working on not everybody working on this project happens to be at pagota happens to have access to the same Google Docs jira whatever tools that someone at pagota does can they still contribute to this project can they still follow the progress on this project or not and those are the ways to think about it that's what we should do so this is how we think about zulip uh everything should be as much as possible should be in

13. 7:09

    open we also have slack we use slack for company chats um this is where you know we get updates about the company HR people Ops updates from the rest of the teams at Pagoda who are not like protocol who are working on their own specific project they are not working in the open they do not need to be open sourc so they do their own thing on slack and we have overlap with them so sometimes we are on slack for them but all the open source

14. 7:45

    protocol work happens on Zula um here are some slack channels that everybody should be part of if you're not part of them uh please let me know and I can always help you join uh General should be you should have been added to that by joining slack protocol is a closed Channel this is one that we have on slack this is where we sometimes discuss things like oh when is the next offsite going to take place or like when is the next uh happy hour going to take

15. 8:20

    place and those kind of talks we sometimes do end up discussing engineering stuff in there um I would ideally have those things take place Zula but from time to time that happens that's okay um I hope everybody knows about the donut Meetup Channel Please join if you haven't um this is a way for us to because we're uh completely remote and we always uh we do not always uh see each other very often or we could go an entire day without talking to people and

16. 8:53

    so on this is a good way for us to get to know each other better so if you know about human time or any other similar tool what donut does is if you join this channel then you will be uh randomly connected with the someone from protocol every week and one of you will be encouraged to set up a meeting for half an hour to have a chat and you can get to you can talk to them about what they're working on about anything private whatever um and get to know them better

17. 9:29

    so on uh there are quite a few zulip streams to list uh that you should be part of these are some of the public ones that you should be part of um yeah all of these I guess here uh pagota private should so if you're not on all of these streams uh as part of protocol you should be on all of these streams and if you're not please let me know or please join and if you have trouble joining any of them let me know

18. 10:01

    and I will add you to them uh each team within protocol has their own private channels you should also be part of those Channel like if you're if you're in the not team or in the court team you should be part of their those private channels and depending on what projects you're working on sometimes you'll get added to private channels for other teams as well um yeah so these are the uh things that

19. 10:25

    you should be joined be part of um I'm sure most people uh maybe other than soon I think have been around for a while so I think everybody should be part of the new organization on GitHub make sure you have access to this repository uh this is where all of our Cod lives this is all open source uh and so on I don't think I need to give a lot of uh introduction to this one um we also have a private Fork of this repository called near core private this

20. 11:06

    is only for security sensitive issues so the same thing I was talking about earlier near core is where we do all of our work in open anybody can see all the issues there anybody can see all the PRS there but if and when we do find security issues on the main net or test net where we need to work on them need to track those issues and so on we use the near core private repository uh if you do not have access to this repository let me know I will

21. 11:39

    add you to it uh but I believe everybody should have access to it if you're part of the new organization the open issues here are all known security issues that we know of that are currently impacting main net or test net and we may or may not be working on them uh you can do pull request here uh to fix these security issues but do not merge this pull request on this repo because that

22. 12:09

    doesn't make sense right because if you merge the pull request here and then we try to uh sync the fork again from the public repo that doesn't that will break um once you're ready to fix a security issue you have your PR that is ready then you would typically work with the note team to figure out how to release that and how to create that copy of that pull request on the public near core

23. 12:40

    repo uh get it merged there and so on so that you can eventually close the issue here so the pull request you would just create here just forine uh for to be able to discuss the fix with your peers you know oh I want to fix this issue here's my proposed F people can give you feedback on it and so on so forth so that is why we create pull requests here and the issues are here so that we have a single place to track all of our known security problems and we can discuss

24. 13:12

    them there and so on so forth any questions on what I've shown so far I think I saw some chat messages I don't know if there were any questions on uh Alex I'm not sure what you mean by plan for protocol discussion are you there Alex where do you see that it's to the presentation sorry I asked this before it started it's about protal discussions in in an hour okay okay so do you have a question about that or should I continue no no please continue I don't have more

25. 14:03

    questions yeah um we have a suggestion on how you should set up your username or your profile name and so on on slack zulip and GitHub a lot of people for anonymity reasons or for whatever reasons have nicknames on GitHub and they have not put their actual names on their GitHub profiles so it might become difficult for me to know if I get a poll request from someone on uh so for example a good example here is uh marson's GitHub profile is just

26. 14:48

    called mm near and he hasn't put his name on it so when you first see mm near you do not know who that person is so for that reason we always propose that uh when you set up say your zulip uh profile or so on you put your GitHub uh name in Brackets there so that and you can do that on zulip and on slack similarly so that way if I ever see a message from someone on GitHub I can go and correlate that with with slack or zulip to figure out who I'm actually talking to and sometimes

27. 15:33

    that's good to know who you're actually conversing with and so on so this is a suggestion that we have for uh how to help us find people and so on because for various reason people do not want to put their full name on GitHub um so I think think that yes I think Nikolai that is a good point I think we should you know I typically do not I also typically do not refer to people with the actual names on GitHub so if I need to refer to them if I need to actually ping them then I would do add

28. 16:12

    mm near and if I do not need to Ping them or just refer to them I would just say mm near so yeah like I think if people do not want their real names exposed then we should respect their privacy and try not to do that um the next point I want to discuss are are anys um like does anybody know what NPS are I think some people might be familiar with them now I just want to get a rough idea of what people think what people know about npz I see roswan shaking is that

29. 16:51

    that's good so some people don't know um so n is the simplest way to explain nmp or the analogy to any PS are uh rfc's in any other project right so if you have an open source project that you want to propose a change to you would typically create a proposal uh you would they often called rfc's RFC stands for request for comment and you would create that and you would say I would like to

30. 17:22

    propose adding a new type of compiler optimization to rust or a new feature to standard library or this or that and you would create a proposal you would explain the proposal you would say why it's a good idea to do this why um what are the benefits what are the pros what are the cons what are the impact that existing users will have why it's worth the additional complexity and so on and so any stands for near

31. 17:54

    enhancement uh process and uh that the idea here is the same so we have a GitHub repo called neps and it contains a bunch of stuff not just any PS but uh the main focus for us for now is anyce um so if you haven't had a chance to read this NEP here I can strongly recommend taking some time to read it it is a it is not that long it explains how the process works and essentially any time you are going to make a change to near

32. 18:42

    protocol that is going to change the API that is going to change the way people interact with it then you will have to go via this NEP process in order to have your change be approved and be mered Ed into near core so as an example Alex and a few Alex and Anton and a few others are working on flat storage right now uh while they're working on flat storage they are proposing to change how

33. 19:15

    we charge for reading uh the fees the gas fees that we charge for reading from storage and this is going to impact every single contract on near core that is running on the near protocol uh that's why they need to go by any process so if we look at the pull request there is one for uh flat storage here that they've been working on and um and this is making progress and so on and this is going to go on for a while and so what we see here

34. 19:57

    um these are some of the recent neps that have been merged and if you were at the protocol allans meeting last week I also talked about what are the open neps that are currently most interesting for us that are actually being worked on that are uh that are relevant for us the most recent one that has been merged is called uh meta transactions that we talked about in various meetings and so on um so

35. 20:29

    but as an example of a project that doesn't need an NEP is Cold Storage so vs and Paulina and few others are working on coal storage that is a project where we change how the archival nodes store the state so uh so that they can store lots of State more cheaply and in a more performant way this does not change the any API to any of the smart contracts it doesn't have any visible impact to actual users of the protocol

36. 21:06

    so that's why their project does not need to go by NEP if you were to make some changes to the internal of say if you were to make a change where you replace Rock DB with another database um that would also not need to go by NEP because that is not changing the API at all you're probably making that change to make things more efficient or so on so that is totally fine uh in future once we become more decentralized once we have more contributors maybe we will start

37. 21:39

    requiring anys for additional stuff even if you're not making API level changes but for now we require them for um API level changes and not for anything else um I already talked about this earlier right so we always want to work in the open source and um it is very important to maintain this EOS it is easy to fall back to you know for efficiency purposes and so on to say you know hey

38. 22:18

    um I need to make quick progress I'm going to uh I'm going to do some of the work more in private and examples of that are you know uh we often have meetings to make progress on projects right so we have regular meetings to discuss flat storage and when we have a meeting to discuss flat storage and we discuss design and we take decisions there if we do not actually reflect those decisions somewhere open then someone outside of that meeting will be will struggle to

39. 22:57

    follow the progress on that project now many times that is okay you know if you're trying to make quick progress on a project or something or the project is only been worked on by a couple of people that is fine um it does take a lot of work to keep people updated to keep updating zulip and so on but the benefit of that is that the next time say a new person in protocol in pagota actually wants to join that project so again taking flat storage as

40. 23:26

    an example you know we have people who have come in like men who joined in the middle of the project near the middle of or late last year she worked on a project for a few months and then she left to work on something else and having had good documentation and good description of what the project what the current status of the project is how are what are we working on what are we doing and so on that helped her onboard onto

41. 23:55

    the project much more quickly so it is more work to keep things to do things in the open but it has a lot of benefits to other people can follow your progress it gives you a lot of visibility to see other people can see what kind of progress you're making they can understand the purpose of your project they can understand where it is what the rough the ETA is for when it might be done and what to expect and if they if

42. 24:28

    uh if they're asked to contribute or if they choose to contribute then they know how they can get involved and so on uh R how do we keep track of the Milestones or time uh estimates of the of every project do we do them in do in a do or do have a tool for it that's a very good question um so I think there is no clear alignment between all the different teams within protocol right now on how we do it uh

43. 25:05

    currently I believe the core team and the runtime team are using something called tracking issues on GitHub and the note team uses uh jir quite heavily and so actually you know what let me just get that your question is related to the next Point here so let me just get into that um so we we currently have two issue tracking tools we have two tools for tracking issues we have GitHub and we have

44. 25:36

    jira um we in the beginning we used to have just jira and then there was a bit of a push to move things to oh sorry in the beginning we had just GitHub and then we had there was a bit of a push to move things to jir and the reasoning for that was that we we wanted to have highlevel project management like okrs and so on on jira and then we wanted to have stories or issues that we create on jira

45. 26:09

    be connected to with the okr so that we can say oh you know when I finish this particular story or this issue on jira then that will automatically show that I'm making progress on this okr and so on and my team level okr is attached to the division okr which is the company okay so we would have this nice project management happening if everything was on Jura that works well for teams and for projects that are not open source but

46. 26:41

    that doesn't work well for the protocol that doesn't work well for near core because we are open we we want to work in the open source so when we when we are creating or doing stuff on jirra then people outside of pagota do not have access to it they cannot use it they cannot work with it and so on uh so there was a lot of disruption last year where we kept moving back and for from jur to GitHub to J to GitHub um

47. 27:11

    currently as far as I understand most of the protocol near core relevant issues are created on GitHub and we use a tool called exelate to sync them back to jira so exelate is an automated tool that will whenever you make an update on some issue on GitHub it will create it will make the same update on the relevant issue on jira and um soon as why do we not open soura issue um it is complicated it's uh

48. 27:50

    there's it's not possible to just um uh we've tried to look into it and there were various reasons why we cannot do it I think the best person to answer this question would be Arthur Who maintains jira and Confluence and all of our atlassian tool chain uh he will be able to answer that precisely but uh uh and the other reason also is there's also this um uh like what is the standard way that

49. 28:22

    open source projects work and a lot of them like like to stay on GitHub so we want to be uh have a similar working style as other open source projects so that people when we hire new people who have been working in open source world it's easier onboarding for them or someone external who wants to contribute or work with us they have an easier time onboarding because they're using we're using tools that they're familiar with

50. 28:53

    and that they're used to and so on um so now to answer the question that raswan asked uh specifically um let me find if I can so we have this thing called tracking issues let me see if I can find a little documentation on it so this idea of tracking issues we actually copied it from rust and some other projects use it as well and um so here is a little post on how rust uses it so here's an example of a tracking issue in Rust so this is a pro this is a feature project that they're

51. 29:54

    working on Russ and the idea for this tracking issue is that let's say you're working on a single project again I'll use flat storage as an example so whenever you start working on a single project you should have a single tracking issue for that project and this tracking issue is centralizes All the known information about this project this tracking issue should contain links to all the GitHub discuss sorry all the zulip discussions that are

52. 30:26

    happening should contain links to all the Google Docs or design docs wherever they might live they should all be here it should contain a list of what are all the open issues that you need to do contain a list of what all the issues that you're finished working on and so on and the idea is that you would create this description once but you would keep evolving it over time right you do not keep create this description once and

53. 30:55

    you add comments below it because then it becomes hard to follow so when you first start working on say flat storage you say Okay I want to work you you create a tracking issue and it's very Bare Bones right you do not know how to split it down into smaller issues you do not know what different issues you need to work on and so on so you just say Okay I want to work on flat storage here's the initial design document here's a link to it here's the initial

54. 31:20

    link to the zulip discussion that is happening on this project and so on and that's it that's all you have then you work on the designed and you figure out okay I need to I need to create uh another another column in rock DB I need to track the Deltas I need to do this that so now you have some idea for what are the different breakdowns for the different issues you create so you would

55. 31:42

    go and edit the edit uh the description you would add those things and you would create maybe sub GitHub issues saying okay you know add Delta tracking for flat storage add a new column in rock DP to do this do that and once they're being done those will get getting update updated and so on so that the idea here is that whenever someone new wants to work on the project so what you can point them to the tracking issue they can look at it

56. 32:16

    and figure out okay what all are the interesting design documents that I need to read in order to understand this project how much of this project is done so far how much needs to be done like what are the next issues that need to be done and so on so forth does that help answer your question ran yeah thank you so this is all aspirational ideal case right I will admit that we're not using

57. 32:49

    tracking issues as well as we could and it is partially on on the more senior engineers and on the EMS on the managers to encourage all of us to get better at these practices um and the better we get at it the easier we will have the easier time you will have um onboarding new Engineers into protocol onboarding other Engineers to work on your project and so on so it is a very good uh it is a very good habit to get into and so

58. 33:31

    on um the next thing I want to talk about is a development philosophy so as part of being part uh because we're part of the near uh organization on GitHub we have the ability to create branches on near core when we want to do PRS this is not how the average person outside of pagot who wants to contribute to near cor would work they would have to create a private Fork of near core in

59. 34:10

    order to be able to create PRS against near core and this is why we encourage everyone you know it's the idea of like eat your own dog food right so if you are not putting yourself in the same shoes as how the average external contributor would have to go through you will not notice what challenges they face what are the potential issues they can hit and we would not optimize for that we would end up we would not

60. 34:43

    discover them and we might not fix those problems so we strongly recommend people to have their own private Forks of near core that they should uh that they use for development and um so what you do is you create your own private Fork you create a branch on your private fork and then um you create a PR from your private Fork saying I want to merge this Branch into near core and that

61. 35:17

    would create a PR and create a here like that and so on um Alice Alex is asking about Bill Kite and nck issues that is a very good point yes there we have had issues like that in the past and that is precisely why we ask people to do this so that we can discover these issues and we can fix them right if we people were not doing this then we would not have found these issues so this is why people should absolutely do this and

62. 35:56

    yeah so and I think if you look at our documentation we also describe it in the contributing file here so yeah so uh yeah so Fork the near cor repo create a new Branch there uh yes and here are some guidelines here these are another good set of guidelines that every should follow not enough people do that um and as a reviewer I should ask people to do this but yeah um this is another good way for people to prefix their PRS and this is a very standard practice in many projects and

63. 36:41

    this will help reviewers understand very quickly what is the impact of this change what are you trying to accomplish and this also helps with uh searching for Relevant PRS and so on and and when you're looking at G logs right if you want to do a bis sector if you want to go back and look at like what was the impact what was this commit all about like these are all hints that help you understand what was this comit about so

64. 37:14

    that you can put yourself in right mindset and so on um code ownership and and PR reviews um so we have tried few different ways of having so whenever you create a PR right some code owner needs to approve it and the way we've tried different ways of doing that and one way you might be familiar with experiences is that different teams would own different subsets of the repository and when you create a PR

65. 38:01

    so you might have the case that um no team owns these five uh directories here core team runs these directories runtime these directories and if your PR just touches these directories then someone from not team needs to approve it if your PR touches these directories then uh both the teams need to approve it and so on so forth um that is very standard practices in many projects we used to have a practice like that too what we figured is that that did not scale very well for us we are still

66. 38:43

    relatively small as team um and many times people were creating PRS that required approvals from two three even more people and that was slowing down our velocity development velocity a lot and as such we decided to take a different approach where the code owners own the entire repository so if you're a code owner for near core and you approve a PR against near core then it is ready to be merged it can be merged now so you own the entire

67. 39:25

    Repository so with great power comes great responsibility right so if you are if you're code owner you know you do have a lot of power you should use that carefully so please be careful when you are approving PRS it is on you it is your responsibility as a code owner to decide I am I do not feel comfortable approving this PR I do not feel comfortable I you know you can always review a PR the reviews are always welcome but if you are a code

68. 39:59

    owner and you need to be then be careful when you approve a PR you know if you approve it and you trust the author right if the author is your colleague or someone you know then you can say look I'm approving it but I do not feel comfortable enough for it to be merged yet please get a second follow-up review from another person and you should specify who that person should be and so

69. 40:25

    on um and yeah so this and but if you do not trust the author right if the author is someone you've never worked with if they're an external person then you do not know whether they would actually wait for the second approval or not in that case don't approve review and say I think they should only be merged once I don't know wat or raswan has also additionally approved it and only then it will be ready to go

70. 40:57

    um so that's how it works uh I can show you guys how what the code owner looks like uh so if you were to go to Team and near core code owners so these 12 members are currently part our code owners that we have uh and once you've been part of call for a long time and you have built up a good understanding of signin code the protocol you can you can also be added as a code owner um the other thing we do here is we have a differentiation between something called a super code owner and

71. 41:47

    a code owner and it's not you cannot tell them apart by looking here in order to look in order to tell that apart you need to look and I don't think everybody has this access so I don't think everybody can look at it but essentially whenever you create a p one of the super code owners will be assigned to review it in a round robin Manner and they can at that point either review it themselves or they can decide I do not

72. 42:19

    comfortable enough reviewing it or I do not have enough time to review it and they can delegate it to someone else and that someone else will usually also be a code owner and then they would review it they would get the notification they would review it and once they review it then it will be approved and it will be merged and so on so that is how things usually work so here you can see the the names that are not selected these are the super owners and the names that are selected they are

73. 42:52

    not super owners but I don't think this view is visible to everyone and you need to be in the group and so on in order to see it um issue triaging is also a big item here where we're not very good at issue triing I'll say it right now we do not have a process for it uh people are doing it randomly uh when they uh find some time to do it but whenever a new issue is created or a new PR is created sometimes as well uh we should develop a process for that so

74. 43:33

    that contributors to near Court they're having a good experience so if I am an external person and I find a bug uh and I create an issue out of it uh currently we do not have a good process for making sure that they get a timely response that we thank them and that we look at it and so on uh this is something we absolutely need to work on and improve and hopefully things will get better over time um

75. 44:08

    this is our Forum that we use occasionally for discussing things with the with the community so if you were to look at the NEP process then whenever you have a new idea or you you want to work on a project project that requires an NP as part of that you are also requ to make a post on this forum and to explain the idea here to gather some initial feedback and uh discussion um in practice there are not a lot of people who are interested in

76. 44:46

    core protocol discussion hanging out here so many times you do not get a lot of feedback from this Forum uh but hopefully it's a bit of a chicken and egg problem right because we're not as active on the not as many people hanging out on on the Forum who are interested in this kind of discussions so the only way to solve that is to have more of these discussions and then hopefully over time more and more people will

77. 45:15

    join so if you're ever seeking user feedback uh if you want to get if you want to engage with the people who would be interested in um the changes that you're proposing this is a very good forum for you to try out um another thing that is worth mentioning is the protocol community group this is something that um has been started recently um so protocol community group is we have a quite a few different

78. 45:54

    Community groups uh that we use to uh encourage participation in the near ecosystem and the protocol community group is one for people who are interested in the development of protocol making improvements to the protocol and so on so this is another very good place for you to keep an eye on what is happening in the space you know what other proposals are being made if you want to make a proposal yourself

79. 46:26

    uh you should be you should look at it you should if you want to get some user feedback user input this is a good place to go to get it uh I help organize it right now Orie and I work on it to organize it uh we have regular meetings once a month we meet and we have a call where different people come and talk about different things um so and we advertise the meetings on this zulet stream there's also telegram group there's also Twitter

80. 47:00

    uh and so on the different ways to keep in uh stay involved and get up to dat information when the meetings are happening and so on um finally um the documentation so just like our issues and our PRS are't open we should try to make as much of our protocol documentation open as possible right in the past we had a lot of back and for on what is the best platform to have our documentation and their pros and cons

81. 47:40

    for using Confluence versus GitHub versus something else and eventually it was decided that no uh we are going to keep our documentation on GitHub it is open people can submit PRS to change it to improve it and so on so any protocol relevant documentation should be on GitHub we used to have a lot of we still have a lot of documentation on core on protocol that should be moved to uh GitHub that hasn't moved to GitHub yet for example when I

82. 48:24

    open uh our conference page I see a lot of discussions here some of this is duplicate some of it has moved to GitHub but the conference page has not been deleted yet but in some cases uh we just haven't moved it to Confluence yet H sorry to GitHub yet and so this is something another another thing you can work on improving and helping out and helping improve our open source uh

83. 48:53

    ethos um these are all the different things I wanted to talk about uh does anybody have any questions comments feedback all right I'm happy to see that everything was crystal clear or everything was super confusing one of the two so if nobody has any questions then we can end here uh thank you very much everyone and see you folks in the next meeting thanks AI that was awesome thank you bye

84. 49:50

    by