Status Core Developer, 11 Feb 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Core Devs Meeting

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

All right, I guess we can go solid. Are we loving YouTube yet.

B

We are live on YouTube right.

A

Awesome, thank you so welcome to the 12th critical I just thought. We'd sub start because we've been changing the format, but sometimes I just would would want to go around and let everyone sort of speak your mind about what they think. The purpose of this meeting is and just make sure we're on the same page. So it's as useful as it's possible for as many people as possible.

A

Send me. Maybe we can stop Eric. What sort of your take on on what you would rather talk about and not talk about during these calls, and then we can go around.

C

Personally, what I like about these calls is that it helps me keep up to date with what the other teams are doing know that there is a bit more separation between the different areas of development and yeah. That's I'm, I, don't know what I expect more or less from it. It's already valuable enough for me, I guess on my side, I I'm, looking into participating more because so far, I have not contributed much to these updates well and yeah. That's all fine.

A

And Julian I guess maybe yeah you know or if someone has something specific they want to say like yeah just speak up, especially if you don't usually speak up. That's extra useful.

D

Yes, I would say something as your I was supposed to say to talk so yeah I feel like there is kind of redundancy between the various talks. We are course we have and channels so I guess what I expect from this code is to have maybe a very high-level understanding of what every swamps is working on, but not not so interested in details in general, I guess and you haven't really. If there is some decision to be made across engineering back things related to pull requests or workflow in general, that type of things good.

D

Otherwise we already have like steam course. So we can already discuss technical details per team, so yeah just in general. If we could have electro talk or I think it would make sense.

A

All right, cool I guess we pull too too many to go for everyone, but just someone else have something. Do people generally agree that, like do we want to have some updates in these calls or or not, or the people have other views on what these codes should be of us.

E

You think one area where these calls might be good for is for announcements like if something changes. Those could be something like.

E

Related to continuous integration or some tooling aspects that everyone needs to be aware of, we might discuss this synchronously know both before taking to the decision and after to elucidate some aspects. It's nice to have the synchronous aspect. As long as people are, you know they voice their opinions and concerns.

F

Yeah I mean from from my side, I completely agree like if there's something that sort of application wide or something that needs to be discussed or made aware of by by all teams- and this is a great forum for it, as opposed to aside from that, in sort of like any ways that we can improve, like our workflows or what we know is working well as well as just keeping everybody up to up-to-date engine and on the high level is pretty available.

A

Cool does anyone disagree that we should have like high-level forum updates in the course.

F

I disagree: if it's a if it's covered in the recent Town Hall or in some other form, and unless it's actually, it's absolutely necessary for other people. No.

B

I think it's too repetitive, there's normal to information in a lot of different places, but again, if it's something that's like application wide or hasn't affecting other teams, that can be important to bring up.

A

All right cool any other thoughts.

A

Another question, I guess, is to what extent people think the focus of this call should be purely technical versus maybe discussing things that might be slightly identical. So one example would be things like fee structure and these types of things which might touch more on I, don't know like more product business. Design kind of things to people have any thoughts on that.

G

I guess it's more of a question: if we don't discuss those things on this call. Where would we have a discussion of Gotham because, like the general town halls are, are not really like or like not really discussions, they're just sort of an update? So if we don't discuss those things here, where would we discuss them?.

H

Yeah I, agree, and also one more question is that we don't like we don't have like fully like, like don't have a lot of things to discuss. Sometimes so it's I don't know if we need to filter it like that early, because it's not like that. Each def call it's like four hours and we can finish it so I, just maybe everything that seems more or less sensible and related to these kind of discussions.

H

Company-Wide. It's it's okay to be here as long as the time it is okay, I.

F

Really enjoyed was in the previous death call where we thought we had too many agenda items but like we all kind of compiled them together and then voted on them, and then we just went through them all I I thought that worked really well. Unless anyone ever disagreed, Kasich could be improved.

H

Yeah I mean, if anything we have to read all to discuss. Sometimes it's not much, but the previous one was good. Yeah.

F

A

All right, cool, I guess unless there's any other thoughts, we can move on with actual meeting and then I mean if people have any thoughts on waste. These calls can be improvable, be more affected and placed on test day to erase it. Then we can talk about it, but it's yeah. Does anyone have something else you wanna add before we get started.

A

All right cool, so the first item is around better pull requests and the context here is that we had this discussion a few times, but we we tend to have very long-lived, pelu quests and it's kind of a problem because it leads lots of rebasing and you don't have a lot of integration and and so on, and previously we decided we want to use the feature flags, a lot more liberally, which means you can hide features and only to have one pull request. We actually toggle on screens or whatever, but it seems like.

A

We have fallen out of practice with that.

A

So I guess yeah any thoughts on that or any additional comments. I.

I

Did so I think I have to say I, don't think we have fallen out after there. It's just like. Sometimes the rule is. If the touch is like existing functionalities, then essentially like it cannot skip you a Meccano use feature cards, I mean we can use. Obviously, but it's you are fixing a bug. You want it to collapse, it away. You don't keep the bargain and and so I feel, like the the subset of features that we can actually use feature.

I

Clouds is not it's a bit limited currently and so I think that's one of the problems and also another issues that when there is the release, PRS accumulates very much for good reasons. Of course you know because the testers are, you know busy casting the release, but I think that is actually the main problem there. If there is a release, you know I'll answer that everyone is testing. You can see now how many beers there are in the testing queue and then leads.

I

Inevitably, two people adding code to existing pies rather than creating new ones, because it's just so difficult otherwise yeah.

D

Yeah and another thing related to big PR is that, then it really becomes very hard to to make a good review of the pro requests. If I have a pull request with like 35 fire face changes, I know it will be ready hard to to just invest time and energy to to make sure I provide a good feedback. So eventually I guess most people, they just quickly glance and put request and then accept it'll just make like some random users comment, so I think that's kind of the the main issue here.

D

So in yeah, in my opinion, it would almost make sense to prevent pull requests bigger than 10 fires or something because the menu should end is otherwise. They were. It's really easy to to came up with an excuse to to just create a bigger per request. So it's kind of a vicious I cycle here, I think.

E

We should be able to ask ourselves regularly, you know: does this PR needs to be this big or can I break it into smaller pull requests? I. Think, there's a lot to be said. If you all, your colleagues know that your public requests are small, they will be working on quickly responding to ripple requests.

E

So if we knew that's all those palooka somebody, you are small I think things would be much more fluid.

I

But this relies an assumption that these viewers are merged in you know, in a timely fashion, if I split my PR into celebre RS and each PR takes three days to get into the code base, you know, then no one will ever do that kiss. Just like so long. You know waiting. Yes,.

E

There is this problem, but maybe at that point we could try to identify where the bottleneck is and see. If we can do anything about it, you know whether it's testing or whether it's continuous integration or just people not responding.

I

A

Just a thing I mean I, agree, we'll set about small piers I. Think that it's also maybe the question of how you this, how you code this world, because maybe the easiest thing to do is to change code like you have some function, and then you may want this different argument or whatever you want to change the logic of it, but there's a different style of coding. Where you you, you don't remove existing code as early at least not initially. Instead, you create new code and then you can isolate the behavior.

A

You usually you can isolate it. Even if it's like a long multi screen flow, you can still create new screens, and you can add comments and saying these should be gone. And then you can just have a simple flag in one or maybe a few places, and then you can doesn't matter if there's a release as long as the thing compiles, it's not actually being called anywhere and I feel like we're not being creative enough in terms of adding new code and then just isolating.

A

This is exactly how it's gonna be called and then having a small p or that just toggle flag or change the stuff, and then you can always remove code after the fact. Once you know the new path works perfectly and if people have any thoughts on that.

I

A

I

Know like I, understand what you're saying and I know that that's possible, and you know they I think any of us have done that to some extent and the feast comes as we discussed this, but the fact that we keep having some problem. Certain problems is also because the system we have in place does not help you with that. I mean I. Think there are some underlying issues that we are now addressing again. You know every no we're getting to do with automated tests are much more reliable.

I

I am for some POS, regardless whether they should skip QA regardless. Whether the ad things are no he'd ever need. Much. For example, I fixed the back with mail servers that was nicely now, and you know it touches some.

I

It is an impact on the code ways, of course, so she go from the minor create, but it says move it super small fix and I, don't think he should go for is from Anarchy a so I think we should relax those rules because certain PR I should just go for it even without having minor K, because we make the judgment call Ted. The impact is so small and it's more useful to have inside and outside bugs get through I mean you know like we get. We seem like Knightley's have loads of bugs.

I

So not because of the you know, man, okay is doing a bad job. Quite a quiet rate. The Box do get through I. Think we be too kosher on that side.

H

Yeah III tend to agree with Andre here because like if you want small pr's, that means we'll have more pr's. That means that means, if we will have manually on HPR, it will just take forever that there's also one of the reason why you want a bigger PR, because well, you want all the feature to be tested like once and yeah, instead of like five or six times so it's yeah. So so maybe we should relax a little bit.

E

Those two things enhance if they are smaller, it becomes easier to understand and to reason about them and see if it makes manual to you a or not yeah,.

H

We should probably relax it only on the smaller PR so visit like if it's just one line change, that's regression, scope is pretty obvious and especially if it's already covered so essentially like imagine, if you change in something that will, if you do it wrong way, breaks all the chat functionality, then I'm, pretty sure, auto test will find this selves.

H

A

So I agree with Sophie I. Think we've had this discussion a few times and the conclusion has been that we need automated has to be baseline, reliable and they block, and once that's done, then we can serve relaxed. His disciple now I believe doll made, as is are in that state. So I guess, what's stopping us from doing that now being more quick, so I mean the goal would be.

A

If you have a small pea, odd, like you should be able to assume in so let me just run and people make a judgment call and a code review. Then you should be able to merge it. So you have this quick feedback cycle, I'm, not sure. What's is there anything Block in there I know just Q I have some perspective here. There.

J

Is one problem from having a lot of small cars it's like when, if we are to make some changes into the product, I need to update those tests and right now, I have a queue of that hours like three hours and Q, because I just can't update all of them. It's really hard to update big pairs like, for example, like a volt redesign pair, where you need to update like 100 tests, but it should be easy to update small pair so from after test perspective.

J

I go a to have like small cars, make sense.

H

Yeah and for some of the smaller peers like if they don't touch you ice, maybe we won't have to complete anything because yeah.

A

Maybe I'm naive or something but like talking about this specific wallet thing, which is a good example of a big pure sorry to call this not specifically, but but to me, that's that's an example of something where you could leave the thing as this and then design the new screens and literally have a flag, that's a dead flag and then all these parts, all these partial problems would already be in in the in the repo and then it would just have a tiny p or where you would actually activated by default or or where you would remove the old screens and that's where so.

A

This additional work would be. You wouldn't have this 40 file diff, and this like huge update. Job is the reason we are not doing it that way. Push in this specific sample I think it generalizes to lots of other peers.

K

Can repeat that part Oscar, no.

A

I mean like if we have a PR, that saint is a lot of complex UI flows like. Why are we changing the flows as opposed to adding new flows and then toggling being off by default for using these new flows? And then you would gradually get the changes in through codebase and and and you would decouple the sort of automated testing and you would just have one tiny PR that would toggle the flag on by default and that will double. So, if that's where the QA work with what be and so on.

D

But I guess I traced, mostly related to mindset and and just changing the way we work but actually yeah is. It makes sense.

K

Because on the 14 teller zone, we retry to give us few peers openness as possible. Oh one thing: one thing: I person really really hate is work in progress, PRS and the reason is because typically, those just type of yours are done to give a sort of illusion of work and- and they just tend to to anger and ground, they need constant, constant maintenance, only exception we make. So we actually have a rule that we don't allow work in progress. Prs.

K

The only exception is for things like bounties and things like that, and even those you can see that people would doing work in progress PR with something I, don't know like copy pasted from Stack Overflow just to give a lesion or delusional illusion of work as I call it. So if there's a PR open, it should be with the intention of merging ideal in the same day or in a few days, depending on on what app you the PR is and the longer PR is open. The word sitter is like.

K

If, if a PR is open for a few months, it's it becomes really really hard to maintain and it could constantly constantly rebase constantly keep up with changes and it becomes more likely. That is not even going to be merge. So the PR is brain. Well, you might as well just just close it and the person then will should open it one day or they think that actually ready to be to be merged.

K

The other things in terms of the code reviews it's important also, that the the code reviewer be reasonable and, for example, sometimes uncle reviewers have a tendency to to ask for changes that are not related to the PR itself. That should not should not happen. If someone does a PR, for example, for a feature, the PR should be related only to that feature, and it's so you should the reversion ask.

K

Well, since you touch this file, you might as well factor this whole thing that shouldn't happen and if, because unrelated changes, this should just be done in a different, different PR or if an ID or feature or even a new bug is found within the contact. At PR that should also be done. I don't mean about and introduced by the PR, but just a bug that happened to be found because of the world of that work. That should also be done in a different PR.

K

So it's important to keep things as isolated as possible and and not, and to visit just reduce that mental workload, because the more careers are the the worse it becomes so I I mean. Ideally, the workflow is really by the end of the iteration or whatever. That iteration is that to aim for most PRS at least to be to be to be merged. Sometimes that's not possible. Sometimes it's like big changes in the code base and things get delayed, and that's fine, but having PR in my opinion, appears more than two weeks is really big.

K

You might as well close them. It just becomes a maintenance nightmare. If there's a PR open that I've no intention to emerge in the same day, then it's there's just not really ready to be revealed in the first place.

A

huh Definitely agree, and just I'll curiously like have a look at Stan's direct and look at the peers that are open that have been over for a long time and compared to them bark yours, the oldest embarked PR is 11 days old, they are nine open and they are more activist abstract. So I don't see what's so special about Sazerac that we couldn't do the same thing.

A

K

Is you see some of them? You still actually see five days old eleven and the reason is because we did a big change by moving to learner and we so and that's what that's one of the examples, like that's a big code change, so that could delay things but other than that we really try to keep it even less than that. I'm.

I

Not really married during the comparison is a fair comparison. I mean I've opened a PR 17 days ago. I stopped, checking out has been reviewed and hasn't been selected for QA.

A

So this is not like a blame game. Anything it's not like Oh Deb should whatever it's like the process is wrong. There's something wrong in how we do things.

I

Our problem, because I mean we do open it, but I think I only open it just to create a bill, so I can get the artifacts or Jenkins I. Don't think anyone uses it as a system like you know that we we open up working privately out when pushing to code I think it's just not to up. If I do we want to have bills, yeah.

H

Way to get see I built there, that's why I guess most of the PRS that are because, of course, like again it's I mean I've, been doing different types of like CI environments and it's very hard to compare like a web app or anything like written in pure JavaScript that you can joke arise and make I dunno auto test at run like in three minutes like yeah, because I mean I've been working on like a per code base that had like three thousand and two and tests, and it was all this old like cycle of running.

H

There were like five minutes on my machine and then you cannot compare it with like a testing cancer and a mobile app that you can, but you can only run on there like some either simulators or real devices that I run in a cloud. So you have to upload it somewhere else and there are lots of things that can go wrong in our tests like there, they run like 20 minutes just for end-to-end tests. So it's it's very different.

H

It's like it's very simplistic argument that if it works for some code that it will definitely work for another. So it's why.

F

H

Sucks for all the mobile things, all the CIT so.

D

Actually, I also feel like it relates to discipline and if you create a pull request in my opinion, it's your responsibility to have it reviewed to make whatever changes to to have it tested and ultimately merged and yeah I guess we are lacking a bit on that side, but.

H

I agree that if we relaxed- because it's not everything that we can do there right now with the current workflow but I agree that we probably should relax things on manual tests and can just instead of having the skip manual QA label, maybe we should inverse it. I just put a label if we think that manual QA is needed for for this PR and for by default just put if the smoke test passed, just watch them and see if happen, what happens? I mean it's.

H

You will be input, an improvement but I'm not sure that it's exactly Weibull to just close all the peers that older than two weeks and I think that's that's a viable process here.

A

Could explain like when you think would make sense to have a PS open for longer than two weeks to say.

H

Well, when we were trying to release one version for four weeks, for instance, and we had to release like at least two hot fixes along the way for different cases, so it was like zero to a resources for almost like two weeks, so yeah some of the PRS definitely will stay longer. Yeah.

E

But, for instance, you said you compared to within Barca I, don't know what the keyway process looks like for embark. You know if this is also in like an impediment for them, because for us at least during these last two weeks there was a shortage of QA resources for for a lot of peers.

A

Maybe QA has some here someone.

J

Here or I can speed up well, basically, yeah we've been focused on realist.

J

Last half-hour shaped like two weeks for sure, and this is fire hazard to and first it's lack of key a resource and complexity of our application. Like that, you have iOS, Android desktop and several platforms on desktop right. You need to make sure that a pair is not breaking any scent of it. This is the biggest problem. I. Think hey is the complexity of the whole product whole set of things that needs to be tested also.

J

Yes, of course, we can skip money on tests for some peers if they changes a little, but we should wait for tests run. It is like forth 558 tests, Simon t-test, because we had like bad experience with reverting syrup. There are hours during these two weeks and just keep calm and wait for tests to pass.

H

You know one more issue is that we all also have our tests are essentially only on Android. So if you break something specific to iOS or specific to desktop and we'll just like only yeah looking at manual pr's looking at automatic tests, then we'll probably lose those changes like yeah. We also be built, like HBR touches, usually like five platforms, which is well also not a very simple thing: that's I agree with them, so well we can improve for sure, but they just it's again.

H

It's a very simple point of view too, to think that will be just on the same way or like that, like a new like web app or like even web 3 app or something like this, we will never be with the same speed, but.

A

I feel like that's, not really giving embarq credit, because it's not sure it has all these platforms, and so on, but I mean it sounds a bit like there's nothing to learn which I kind of disagree. It I mean it seems like I, don't know it doesn't seem like there. It is something it's something we can learn from how they work. Is there something we can change and if so, what would that?

A

Well, what would it be, for example, in terms of the QA process or how, how we block things and and so on, we're related to flags I, don't know, is Goran here, maybe I.

G

Just add one, maybe one counterpoint to I think what Eber just says it that this, when you see dabs that are developed quickly, I, don't think it's because of the tooling it's in spite of the tooling that the tooling right now for adapt development is still very raw. It's very it's! It's definitely not at the level of like more traditional development. So when you see the apps being developed quickly, I think that's in spite of the tooling, not because of it.

H

I mean it depends on what the hell the tool may be. We have a tooling like for for iOS and Android to run tests, but if the student like fails 20% of the time for the reason because again platform vendors didn't make a good enough student, they might put a checkmark that they have this or that. But trust me, the tooling.

H

There is just if you compare like, of course, if you, if you look like the simplest example of what to test, is any kind of cloud service and I, don't see like any point why there shouldn't be like good end to end test coverage, the trans very quickly and the tooling there and super mature, and things like that, but like for mobile I, wouldn't say that it's like it is kind of I mean it's a very rare case when you actually have good CI process for mobile apps in general.

H

So the point that we have like end-to-end tests that don't fail all the time is already a huge huge accomplishment for our team, because I haven't seen this. Like you know, quite a few companies like I, know yeah. Well, we can tell the K Facebook helped them like and Facebook. Don't have like one automation engineer. They have like, probably a hundred times more, maybe a little bit more. So, of course I mean we can just hire more people or just focus more on automation and will help.

H

But it's like yeah, it's totally different and also the tools that I used for automation are not the same of the same stack that we use for development. So it's like it adds more languages and frameworks. So our like mix- it's it's like. We don't have you know, but sure all.

K

Right so two questions so from what you guys said. The reason the real for the peers is one is to get, is to actually trigger the CI and get certified and so on and the other one. The other other reason that they stay longer sometimes is because it's waiting for a release. So you cannot merge because whatever sin that my main branch needs to be.

H

There I think, is that each PR is being tested manually and if all the manual creates, are busy testing the release and we have three trees just to point it at one automation right. So it's like. We just have four people there and if everyone is testing the release, again five platforms to make sure that it works. Then there is no one to test this PR. It's not like. We don't have a release branch, that's yeah!

H

We don't have a problem of merging something into into the develop or master while release is happening, it won't affect, but what it just. We don't have a human resources to test in our current and we don't have probably the biggest things there is that we don't have any smoke test and cons platforms other than Android, because otherwise, if you would have, it would be much easier to to just test everything like automatically to.

B

Make sure that effort.

H

This doesn't crash.

H

K

Now that regard, because when Oscar asked what would be, what is the can, you think of a reason for it for PR stay open in two weeks and the releases was like, we specifically said releases and hot fixes, and so on that reset has been trying to go out for two three weeks. That's why I thought what.

H

K

Was this referring to then no.

H

But there that was an infernal bid for almost three weeks. There was zero case available to test.

K

H

K

That case I mean dude, so obviously it's our I guess to the QA is but I mean. Can the PRS be just like a a smoke test and that particular ality and then or is.

J

It already like.

K

That actually I mean.

H

Whenever we eat an arrest for Android but like for other platforms, I guess it's not, it wasn't done just yet and we started doing something for iose. But there was this restructure happens just in the middle of this and I think that we just ran the first test and then just the person who was doing this was laid off. So there was no one to continue so.

A

How could we have manual to be less of a bottleneck without adding additional resources? Is there anything we can do in terms.

B

I

A

How we do things many.

I

Things we can, for example, whole thing is that we can move from a model where we, instead of testing each TR separately, some of them might still need manually. Of course, we.

A

I

Knightley's, for example, that.

A

That's what we kind of decided before when we introduced automated tests. That's why it was such a big push to having them be hundred and passing, because that would be the first test. So that was the reason says: I agree with you.

I

B

Are we not doing.

A

Done so then, the question to Q is why are we not doing that? Okay.

J

First of all, we don't have capacity to power every each scenario, which is headed by development team in intent test. For example, when we had the ad block user I have three person queue to be reworked in order to pass like the whole set of tests to reflect actual new behave, introduced, bats in pairs and I. Just don't have any time to cover that feature, and this blank spaces might be covered manually but like we are planning to cowers of tests in future, but the future never comes because more and more they are so current.

J

Same for iOS, we have started I, also, we've been working on it and in future we are going to support, but we also need that battery consumption support. We need to add network consumption in supports extra performance tests, and it is never going to be done because of getting more and more new parts. We just don't have enough capacity on the entrant automation side to cover every single piece that flows.

K

A

No I mean we don't have to cover everything like I I mean. This is also why you have feature flags, because if you introduce like a whole new flow and it turns out, then when you're testing Knightley's- that is it's it's it's not idea. Whatever you can say, you can turn it off quite easy right. If you do gradual changes and you don't just change things all the time then I I to me- I, don't know, maybe it's a, but it sounds a bit like an excuse that we need more resources to make this work.

A

I, don't I have all time buying it. I don't know. Yes, sorry, you're. What you want to say.

K

Good question I mean I present previous experience, working on a large project that it's actually if there was bugs that would be like it would be big consequences. Basically, there's like money on the line and so on, and it could be a big issue and what happened at that particular type of workplace was very kind of like a blame game type of workplace. If you know what I mean and as a result, the testers were too much.

K

The keyway was excessive, basically I'm talking about. If we change the color of a button, they would still do like the whole. The whole testing, because- and that was because that was a distrust- would the developers and because then management words would would would blame them. Essentially, if there was a it was a it was like a park and and then and they and they then they would blame the developers and so on.

K

I saw that that type of thing so to attempt to reduce this I, try to break the software more into different pieces and introduce acceptance, testing and this kind of thing just to building increase the confidence and the trust between the QA and the developer and developers.

K

So my question is it's a bit of awkward question is that is that the sort of playing game here like if there's a bug in every release goes out and there's a bug? Is there like a blame game that causes the you know key way to be a bit more I, don't know somehow excessive? Then it should be or that's not an issue at.

H

H

J

Is no blame game and we are not going to aggression testing for a PR, although regression testing is done by automated test. We are testing. : is a feature introduced by a PR and possible artists which might be affected and we are not spending like five hours by retesting care each possible flow in order to pass testing for the PR right. We are doing regression testing only for releases and optimatus regression testing for each nightly, like it's much more extended set of tests and ranked against bear.

J

But there is no like over helm reactions against each like.

I

On a good day, if you PR goes to you know, like your guy, gets reviewed in a half an hour an hour just the time to basically in the developers and then if we go straight to the QA an hour and is in, like you know, like yeah just time you know like it takes, you know a good day. Just statics takes very little, it's just like when you know they pile up, sometimes, especially during releases. Maybe.

H

The problem is with the releases then, and not with the PRS themselves, because if, if they work normally like in a normal days, then we should probably rethink about. So we should be. Maybe shouldn't be this all hands on Zack release testing. Maybe it should be just longer. We should expect release testing to be much longer, but then for people to keep looking at PRS unless, because usually I mean it's also a bit weird, because sometimes this releases they have this.

H

What why they work hands on Zack, because first time there was this inferior issue that they communicated super poorly and it turns out that they, it was very like we had to upgrade our project IDs, essentially like very quickly within a day, but then it turns out it was necessary, but yeah that was weird and a second time there was some crasher. If I remember correctly, that we found out internally and then we had to fix it before it went to any public channels. So it was also like it was a quickest release.

H

It was like six hours between finding a bug and pushing the release. Button like it was like super quick, I think for a mobile app and then yeah and we were trying to release at the same time. Another release that supposed to go with some changes for is Denver as well, so it was yeah. It was a little bit of perfect storm last week. I was on last two weeks, so maybe we shouldn't just think about that. Maybe you should think about releases a little bit more than and yeah it.

H

Just if you test on the night is for instance, then no one should install night list for desktop because unless they are tested like, if we stop testing PRS or this no one should install them and think that, oh it crashes, it's it's bad or something like this because well we don't have photo tests for desktop just yet. So it's a it's. It's a little bit hard circle to square, but yeah.

A

One suggestion because we've been talking about this for quite a while, maybe if someone who hasn't spoken about this topic has something do one AD and then I think we'll probably can go for a long time with this. But yeah like anyone else in Spokane. I wants to say something about this topic, so.

D

I just wanted to add the once more thing is we focus a lot on testing and QA, but also realistically, we lose a lot of time during the reviews and we need more people doing reviews and once you create as a developer, app or request it's not it's not done it's just the beginning, so you have to to be on top of things and and talk to people and pushings.

J

C

Maybe something am I a muted, no.

A

Sorry, quite okay,.

C

I was thinking something that might help also is to limit the number of requests for review to three or four every time and like so that it's clear to everyone that when you're asked for a review, you really need to do it. Otherwise the PR is going to be stalled because yeah often there is peer with a lot of reviewers, but only to our needs to actually pass. So maybe we just in two or three reviews always other than six seven and yep.

A

B

F

To discuss post just so like we can keep this conversation going because I'm. If anyone can present any more ideas, you have.

A

Anyone who feels particularly strongly about this as a specific view of how they would wanna change things or what a specific problem is that wants to do this.

I

I think we're saying that we should relax minor QA and we should move to a system. My sense as its cus testing in that night leaves or maybe features in batch. You know they did essentially give more responsibilities developers this Bush no code without bugs dad. You know they were supposedly dissing them to make sure that it's up to stands there to be merged, rather than just throwing the PR today.

H

So should I write, it discussed post was just an please folder possible all the problems we see and all the possibilities and then just probably come up with some conclusion. Some ideas about how to fix it, which one to choose yeah.

I

I'm happy to do that.

A

Awesome yeah I agree and you critical in Singh if someone discuss who wants to argue against that viewpoint, because I would agree that that does make sense to do things testing things in nitrate, especially if you isolate the features, so you can turn them off and so on.

A

Anyone else hasn't spoken.

A

All right cool, just.

F

Ajust a question: is it possible to pass arguments to all the platform binaries to essentially switch flags on and on without having to rebuild the entire thing.

H

Yes, to some extent to simply run ten plugs yeah yeah. Well, we can always do them like in settings if we just need to be taken care of, because it's still some code enclosure that just reads this into some kind of constants, but then you just still read them somewhere in the code. Probably you can change them, maybe with restarting the app it should be possible. I.

A

Think we did that for some things you can yeah, you can just have some you just force restart so.

H

They are not like C++, macros or semen occurs. When you don't compile some part of code, everything it.

A

Might be might be some I, don't know if we still have just like we used to have some flags to wear a bit Kali but I guess most of them aren't I, don't know someone polyester there.

J

A

Okay, cool: are we happy with that? The state of the topic and then take it up on discuss and as well as thanks call.

A

Right awesome, I guess we had also around except secretary and the son review. I, don't know if we that that's under the general banner of better peers do. We were not touched on that to go to the next one.

A

Because it's slightly different, so I don't know if someone wants to add something on that.

A

Yes, sir, maybe.

A

Just about design review, except this criterion, design, review and PRS we've talked about peers a lot, but maybe if you want to mention it briefly, some people are aware of what that refers to.

B

Yes, I'm not originally a person who put it on the agenda, but my thoughts are just in general when anything impacts, DUI to add one of the designers as a reviewer just so that they can check whether the implementation fits with the original designs. That would be all I have to say about it. I.

F

Think there was it exactly there, there's another slight addition to that in the sense that it's I'm not sure. If in figma we can do responsive, layouts or not, and if that would be useful for for developers. If that's the case, because my understanding is there's, like you know, minor design tweaks that might be able to be resolved because they're not entirely pixel perfect on in in a real-world application, I may have that miscommunication won't work.

B

Yeah I, don't think it like that automatically happens in pigma, but I mean obviously it's worthwhile for the designers to check on the responsiveness, so they can probably create a view for the different different devices or layouts.

B

That's definitely something that needs to be done. I do I think yeah. He is like if the designer is added as a reviewer. It's a communication thing they'll get a ping so that they can actually check when there are deviations or when something might be different from the implementation from the original design.

A

Do we have any specific, dev or designer on this call that had some issue as a fell factor? That was some friction in the process between PR and and design review. That wants to speak up I've.

B

Just been observing a lot of back and forth on PRS, where the design doesn't match quite exactly with the figma designs, it seems taking the amount of time the designers just double checking things, and some of it seems easy to fix, but yeah I'm not quite sure, with the friction of.

A

Its a specific PR you were thinking of maybe I would help if someone is under quote.

B

No, it's more general there's been at least three or four lately, where there's just like long comments from matcha. It's like things that have been emphasized, I.

B

Definitely really hope that figma workshop helped end out as well, because it hopefully it makes a bit more clear like where to where to find this specifications. I know Eric already did a lot of good work in implementing components and all the way as well. I do know the designers try to stick to the components that are already there and they try and limits introducing new components.

B

So I'm hoping let's say that imbalance between implementation and design will so phase out at some point because of the use of components, but if there are no developers or designers who feel like this is a problem right now, it's probably not a problem.

F

Another potential issue here is I mean we just spent a lot of time discussing QA sort of contributing to to longer PR times so, adding adding design reviews to this that we should be mindful. That also could add more time to ease things.

G

Just one thing that I started on the Sigma work: Shoplet I, one thing that it's like a recurring theme is there: is this the I got also from that workshop, because I thought is, there seems to be this continuous recurring theme of this one disconnect between designers and developers, which is the components for the way designers lay them out in figma, is, is different from the way developers implement them and so really they're, two different to two developers.

G

It seems like figmas, almost just really like pictures that they then have to eyeball to come up with responsive designs in the application and I. Don't know to me: it's it's almost like puzzling that there doesn't exist a solution out there, because this this is like status, can't be the only place where I know it's not the only place where this is an issue and like there can't just be a solution out there that allows designers to lay things out using responsive formatting, so developers can plug that in it.

G

It just seems like such a big need. I can't imagine, it doesn't exist out there well.

H

There is a huge discussion in the UX community about learning HTML and to shoot the designer actually use HTML to do that. So, regarding what what I see but I I've seen these things for mobile before and it's like, there used to be this course composer that works quite well. If your platform is iOS or Android I guess your best bet is that Google's, responsive toolkit for material design took it for like HTML, essentially for the web pages, but yeah. It's a I think this question is very pressing right now, but yeah maybe I'll just.

H

G

My way out, they do lay it out already using like CSS they just it's like lay it out using like fixed style.css right, like the exact number of pixels, which, if you change the screen, it's gonna, it might look bad on a different type of viewport and it's just I. Don't know why I think I figure things out using like flex box or a grid, or something like that, so that it always maintains that those proportions. Regardless of that, the view port that it's displayed on it's.

B

Not definitely not possible on Sigma or percentages at least I think there should be a specification. Ndp's should be possible rather than pixels do.

A

We have any designers on the call. It would be useful if.

F

Another line of thought- that's probably worth exploring, is maybe how we can reduce the the barrier between code and design. So, for example, many moons ago when Andre created the fiddle, the Andre designer got really excited because Airbnb design house was working on this basically automatic code generation. I realized this is out of the out of the out of bounds of our capacity at the moment. But it's definitely worth thinking about keeping in mind.

H

I mean one of the goals of the this component-based design was to simplify this process without like having the cogeneration, because if you have like I, don't know 20 standard components that then they can be reused in both designs and code. There should be much simplified things. That's why we kind of Andrew had the idea that, to standardize that there are designs to sort of reduce them to like a very small subset of all the components that I reduced all over the place.

F

Forgive me I'm actually, how far along we are an onion in that process.

F

Is largely the UI component base now I.

H

Don't know if it's component-based yet but new features that we are implementing and I think this Eric and Roman and the others they are just trying to also like it either tweak or create those components that are in in these figma documents. They are usually on the top. If you look at it, figma layouts and you scroll all the way to the top, above the say, the screens they're, usually components and their States and things like that. Not that many of them but I, don't know how many were implement.

H

I know that the bottom sheet was implemented by Roman or for the Wi-Fi or for the cellular sync options, but then the others I wasn't tracking this. That much okay.

F

So it sounds like it'll get it'll, just naturally quite unquote, improve over time. Well,.

H

Yeah, that's what we thought. That's the only like. We won't have any time specifically to just implement those, or at least there would be look like a bit weird on the roadmap to just spend time to just refactor a component. So it's so that the most viable idea would be to just whenever there is a new feature that requires some components they should be implemented. Then the next feature reused and things like that.

F

Yet make sense thanks.

C

But we need somewhere to synchronize, on which component have been implemented already, because I've seen that these items have been implemented twice already, but not necessarily the same aspects of it. There is some overlap.

B

H

You should just invite some three, the designer and just talk about it on the next core default, to just have this discussion and see what's already implemented? What's not, oh.

C

You know we can do a conference specific call quite short where people involved joint, so we discuss what has been done and and how we could reunite the efforts yeah.

H

So yeah we can create a separate call about what's the progress on this and who who's doing what.

B

A

Alright I'm unmuted cook anything else on that one or should we move on.

A

Cool so protocol, discussion and and Q&A and and and suggestions on the context of this, is that give a brief presentation at Town Hall. But there might not have been enough time to sort of have a discussion about things and then coming with thoughts and questions and and so on. So this is just a space where people get some thoughts feel free to share them nuts or questions anything.

F

There's a recent message: I think this morning from Fox ma at the workshop that says, she's gonna have a draft of a.

B

Summary I guess, like a summary article of the whole workshop relatively soon, so we'll kind of make that available to everyone to see what happened there, if they're, still kind of not up to date on things.

A

All right: cool, yeah, okay, so we don't there's nothing specific, tend to talk about right now, Eric you had some suggestion about push notification navigation. Is there something you want to talk about.

C

Actually it's about notifications and about navigation, it's not the two together! So but it's it's again, it's more!

C

It wasn't necessary for for this call, it was just that I need to talk a bit with Pedro to figure out what we can do with notifications, especially in the case where you block a contact. That was in your contacts and to whom you send your SEM token. So you want to be able to block this person.

C

Maybe change your token or something and the other one was the navigation yeah, and it's a maybe just maybe just next time, because first I need to look at it myself to see how to do navigation for some screens where the origin is different, like the profile, depending on whether you come from the chat or from the profile screen user profile screen yeah, so I don't have much to say for, for this call.

A

We talked briefly about the push navigation flow on the core that clog call, I, think yep, it's it's it's it's kind of it's a bit complex to write, because, logically, what you need is, you need functions to register it because it's tied to device or not to a person per se, so so really to do properly.

A

You need to have object to register and D register devices, and then that should be probably triggered when you, when you block someone and also when you log out and in all these kinds of things mmm in a traditional architecture that would require a central server and previous proposals was based on sort of this all-in-one mail server, which might not be the right instruction. So I think it requires quite a bit of thought to to make distance of some decent wise fashion. It's not the simple volunteers, properly, I think an absolutely regarding.

E

Blocked contacts we can ignore them at the recipient device right now we have completes latitudes over all what we display in terms of push notifications. So if we receive a push notification- and we look up in the database- and we see that it's blocked contact which can decide to just let it fall and not show anything, yeah.

C

That's what I did already but I think the issue is when the database is locked and then you get a notification and when you log in you, you have nothing and you don't know why.

E

A

Does that work on iOS, if it's, if the process is spended, how do you, how is there for control I mean it's awesome if.

C

The database is large, no.

E

E

So yeah iOS doesn't have support for at least in the react native firebase documentation. It says, iOS doesn't have some for waking up the app and doing that processing. So what is recommend is to once you start up the app. Then you process the push notifications and you show them to the user. Yeah.

H

But it's well I mean I was trying to take a look on the next iteration that we'll work on is so it there is a possibility, but it should be rewritten and in nature, because obviously the reason why they can't wake up the app because well, they can't wake up there, but it will be like for five seconds and it's not enough time to spawn up the JavaScript engine and load our closure script there and do anything useful there, and so this just priors it just should be nature, because then you can theoretically open a database or something but I think that the list of blocked users like the blocked keys.

H

We can just store them well, in whatever shared preferences or without. Why do we get to encrypt a level or something like this.

E

Already anonymized, so we could just store the anonymized keys, yeah.

H

Database and somewhere in the same simple place like shared purposes, that easy to read from the native code, then you can, just you know, do whatever the Eric suggested and we just ignore the notifications or what usage as we've noted on client side and then that they should be simple enough.

A

Would that also handle the case if you have two accounts in same device, yeah.

H

We should also do something to store something which account was signed in last, the last one if it wasn't signed out. So if we, if the app was cute, but the account wasn't signed out, we should store well something that will help us to filter messages. It shouldn't be like just public key plaintext. It might be like a hash of hash of hash of hash of plan of the public key right, so it might work still or refresh refresh refresh apply state symbols of last advice of the public key.

H

We just need something to compared with one one string, two traces which is to whom to which public key this was addressed, so it it should be also but I guess it's already solved on the on the current implemented. It just doesn't work on background to the IRS right.

H

No I mean if you're, if you have two accounts and you signed in an account a but the identification comes for, the account B right.

E

Initially, when I implemented the pull request, it was showing four for any account that you had on the device, but the decision was made to only show for it. The last active so.

H

It's already implemented just doesn't work when I use in background.

E

A

Okay, awesome, so in that case we we don't actually need any kind of registration or flow unless we want a switch at firebase, which we probably wanna do at some port. But it's not.

H

It's more related to what we sent inside the push notification, so it doesn't.

J

H

A

What I mean is if you are on EFT or something, and you want to use something else, then wouldn't you need a different token to be reached, and then you would have to communicate that to your contacts.

H

That's true, but as soon as we had additional support of something, yes, that's it we'll still found.

A

It's not even it's not needed right now. Okay,.

H

C

Yeah I think right regarding what you're saying being able not to use firebase. The first step would be to not have to have Google notification on your device to to rent status. I I think it's still the case. Yeah.

A

It is Dustin suggesting and Brussels.

C

So that, for a start, yeah that would be more urgent case and I like the it seems like the simplest, want to just maintain the list of banned hashes and outside of the DB, so that you can filter the notification beforehand. I think it's. It looks simple enough, so we can reasonably implement it in a short amount of time. I.

A

Grate some second assertion all right cool next one. This is judge Fred on key management and wispy decoupling. um I guess you wanna add something to it. I.

A

Think this is if there are any thoughts on this things that might have been missed or or general talk. Yeah general thoughts on on this problem. I have.

I

A question so I, you know, like I'm I know if I do the background material, so I understand the need of separating the Bullock chains so that the Bullock he is separate from the child, I did I totally get it in the post is was mentioned, and that was to my understand was the first time and I'm not sure, maybe a mystical message, and that also, for example, like you, have a different key for each shot, which is interesting, and you know they can explain how to propagate incidence of work.

I

I was wondering in early okay, so, first of all, what's the problem that we're trying to solve and with having different IDs, we do a different job and then another performance like this is kind of you know like and as I understand, is to partially eat sort of like reveal your again, so you have power over who you reveal your identity chip, which is which is good, and but this is more general problem that you know you notice the status that okay, so we have all these identities as soon as the Commerce, and you know, don't reveal it to people that are not in context.

I

But then again, if I'm in a chart, everyone cause nutrient refers to be, which is a bit of a problem. I mean is understandable that we don't have mansions, and so we've mentioned you can sort of like alleviate their problems to some extent, but I feel that if there is the reason, then we need to solve that problem a bit first or something like that. Yeah.

F

So those are great questions and great points. The the reason for separating out the the keys for contexts I think it makes a in the general case. It makes a lot of sense because if you start thinking about these different contexts as there are in particular silos, whether it's a wallet where it's a chat or adapt, you might as well have that generic mechanism there anyway.

F

But the real reason I was addressing that in in the current post is because there had been a lot of thought and even UI flows to basically reveal an individual identity to a chat. So you could have different identities, but I think it was done through your profile, your settings or something like this. It would pop up before you enter the public chat.

F

So sir I I was basically trying to mitigate a lot of that UI flow, while it's still achieving the the underlying goal of what whatever was I. Don't actually understand the necessary reasons and I agree with you that there is even that sort of more social aspect of it where some of them I just mentioned you in passing, and if your apply to that and then the person can glean that identity is your regardless I'm, not sure. If that's something we can solve barring some kind of censorship.

F

But in any case, I I do think that, like having the ability to automatically join a public chat and selectively relieve reveal yourself is probably a mechanism worth having.

F

Even if this social aspect is is too problematic, because it's not going to be every case that you enter a chat where all your friends are in a right like you can enter a document. Market chat, for example, and you would want to have some some guarantee that you enter and converse in that. That's not tied back to your your main identity.

I

No Alice that makes sense, yeah, I, just yeah, yeah interesting yeah, be interested. You know with the UX point of view, because you mentioned that there were some problems some work done before, so that would be interesting. Thank you.

F

I mean this is so basically the the what I was putting out is basically an aggregate of everyone else's thoughts, we're just slight tweaks to have how to think about certain things.

F

The main one was instead of thinking about key key pairs as their their inner logical distinction, more just thinking about them in the in terms of their security policies. So, for example, when we've been talking about whisper decoupling, we've been talking about, you know separating a wallet from the from the from the key from the whisper key, which is what we currently have at the moment and that's definitely a noble goal. But there were some paths of thought in where we've created backwards incompatibility is where it's like.

F

Okay, you would not, because it was a whisper key. We are not treating it like a wallet there for you. If somebody had sent money to that, then it would not be whisper key. Then it would not be able to be retrieved so.

F

There's being this idea of like a hot wallet versus a cold bullet? It's you know it's been around since Bitcoin days, but essentially the idea is that if a private key is in memory, then it's basically a hot wallet or if it's it's unlocked in some form, that's I mean you can unlock them disk.

F

If you, if you're feeling crazy, whereas a cold world or a cold storage, would be sort of a physically separated key pair and then all air-gapped in some way, and you would sign transactions and you'd, move it over QR code or by some other means in status.

F

Like I said by extension, like we can trick, we can use those policies and status, but there's this intermediary stage where you can have sort of warm wallets which still gonna be signed relatively easy, but they, the hot wallets and status, are purely in memory and so they're all derived off.

F

What is currently the whisper key right and the reason we do that is because you can you want, you, don't want to be signing every message that you send in a chat manually so but at the same time we want to still be able to access these key pairs if they do hold a balance.

F

In any token, whether it's airport USC 20 s, so so that's basically the reasoning for separating separated, key pairs into a hot warm and that cold sadness doesn't actually manage any called a key pairs, but it's definitely worth having the ability to receive or create a QR code or request on to cold on to cold addresses.

F

Yeah. That's that's pretty much it. Then it's more about derivations how you how you derive keys from those it's pretty simple! You just do you use the private key and you do some deterministic thing. Then you can derive off the public key, so you create a hardened derivation of that. An original child I am of the position that we should continue to have the existing derivation of one of the I gonna realm in the post, but I think Andres had corrected me.

F

We should keep that, as is for now, but then, like every sort of subsequent chat you join will be under a new new one. We can do a transitionary period where the existing public key is too happy to to directly converse, but then we can switch that off after a certain amount of releases and the sort of a fanfare and telling of user base that that's the case, and we can still receive messages on that public key, but we can also send them out to older clients.

F

Then it'll just look like a new new identity and random response there. So this is probably a better offer. Async discussion, but I just wanted to make everybody aware that you know like we're thinking about this stuff and I certainly would love more feedback, and it would probably it's important because it keepers are fundamental to what we're doing and they're going to impact many things within the application.

F

So it's and they worth thinking about I, also made some other suggestions for for other things in the wallets, and then we could also probably even play around with. Since we changed out, we changed out the way that we did our recovery to make us more compatible with other applications. Then we should continue doing that work to make the derivations we do compatible with other applications, so we should be able to support different derivations, so in every other.

F

Application has a slightly different structure and we should go to support that in in recovery and ideally do it automatically. Anyway, most of that's in the posts. Certainly a lot more coherent I'm currently eating my dinner, so I do apologize if I don't over the place.

A

Cool just a random photo question. Would it make sense to have this, because if you can imagine that you have it very tied to cost intelligent as well? So if you meet someone a close friend, then you would see their identity in multiples of context. But someone who is just like a friend the contact in a certain context would just be that for that specific, so child key and then when you, for example, add mention them it would. It would just render differently, but it would be a UI concern where you would see.

A

This look privileged as opposed like where you the highest up the chain that you have established, trust which might be different for different people in different contexts. Maybe that's implicit but yeah.

I

F

I

They Yun worked on notification or dimensions before, and that was the idea that you you just act. You know this is just code and then whoever you can see the name. If you have contacts you don't see the name. If you don't have contacts.

A

Cool cuz I mean I, think would be pretty awesome if you could have the same account and you could use the same stealth account and then, if you were also in a document market, you would not know it if you were just normally added, but maybe if someone else was also in this talking model, they would know that there was the same person. But honestly I, don't know.

I

Yeah that works as long as people are disciplined enough to use the act. Oh you know like to do you know? Basically it's up to you. It's not up to you. That's the problem. It's up to the other person, but again, as I've mentioned, that might not be a problem. I.

F

Think if we made like acts just work really well, then people will naturally start using it and I.

F

Imagine the more proficient you get with the application, the more likely you are going to use it, which might not be so bad, because if you are a new user to status when you, when you first start out, you probably don't have that much of value, and you probably have much exposure to the network view, though, and there's other things that we can do on a social psychological level where we we created this sort of culture or all of these memes to to like.

F

If we end up doing like a welcome party is for in onboarding, like you could basically say hey. These are some pro tips that we've learnt and you can get them to sort of pass that on so while we can, we can certainly take the technology to a certain level. We can. We can continue the writing the human software so to speak.

A

Awesome I guess anything else is topic so once you say, I have.

H

One super small topic, then I just I just want to ask for opinion. So we know that status doesn't work on public Wi-Fi and that's because poor sub blocked, so I have already a PR and we have an infrastructure down to essentially put a whisper traffic through the typical HTTP 4.3.

H

Is there any reason why we shouldn't do that.

F

Can it be an option.

H

Wow well, we will have both ports but yeah, our all our whisper notes and mail servers and boot modes. They all reply on both ports so but right now, this PR is super simplistic. They just recite the sports with 443.

H

But we don't have anything else on this servers of course and discovery if it finds something on the port. That's not 443, it's obvious. We'll add it still. There is no limits if it's accessible.

B

Point of discovery, I'm, not sure if you can use low-powered some discovery protocol might just you know like not pass the notes which has lower parts that it has been tested. Well, it works.

H

And receives, but it's interesting right now, but I tested it on a few devices and I bought ports on my local firewall and it looks like ok.

B

Ok, yeah I just should confirm whether it's discovery version 5 that that provides us notes or it just our rendezvous. It's critical because I mean some.

H

B

H

The our fleet, config so yeah.

B

Yeah they're definitely gonna be from from becoming just just that's called as Khalifa.

A

Awesome any other announcements.

F

I've been working on that self, updated thing on the weekends and I decided to turn it into a showing points game.

F

So that's kind of cool I'll, probably I, don't know uh notes that maybe in a couple of weeks, but the idea is that you basically commit a hash of everyone commits a hash of what they think is the latest release when we're cutting a new release and then you, once everyone's committed and staked, suddenly matter S&T towards it, then we all do a reveal and everyone's kind of rewarded or penalized, depending on who, who has the majority votes and who committed and revealed the fastest meaning, whoever whoever gets a, who pushes a release out fastest, would probably profit.

F

So yeah, it's a little coordination game and it should be kind of fun to play. I also incentivizes getting lots of signatures on releases.

A

Good stuff, all right anything else.

A

Cool so yeah thanks much for joining the call. If you have some thoughts on ways we can improve, it just add it and status code. Eps cool thanks for want to see in two weeks, five.

B