-
Notifications
You must be signed in to change notification settings - Fork 273
January 2019 Transcription
Meeting began at approximately 9:44:36 GMT Saturday, January 5, 2019
Members in attendance:
- Connor (@scribblemaniac)
- David (@davidlamhauge)
- Jakob (@J5lx)
- Jose (@Jose-Moreno)
- Matt (@chchwy)
- Oliver (@CandyFace)
Jose] Let's begin So welcome. Thank you everyone for coming. I know it's early for some, late for some, and just right for others. So I see everyone is on the outline meeting but if you I'll post the direct link on the chat right now. This would be our first actual meeting for the past 6 years or so that we've had, so it's quite an honor, to me at least, to have you here. Thank you, thank you for being here. First of all this will be a little introduction. I would kindly ask all of you to introduce yourselves. You can talk, you can write. Particularly I would like to know who are you, what do you do or what is your expertise, and how have you been involved with Pencil2D so far so the other members can learn what you've done until now. I'll start myself, My name is Jose Moreno. I've been involved with Pencil2D for about 5 to 6 years now I think. As many of you know, I was first a user just like yourselves, and then I quickly begun to get interested in the software as a tool for my own projects. I'm a digital animator. I mostly work with digital tools, but I've learned traditional animation many years ago. And my interest in Pencil2D is to make it a software that everyone can access and that most artists, like myself, can see as a viable tool for producing animation, for creating animation. Okay I don't know if anyone else wants to continue with the introduction? Anyone raising hands?
Matt] Can you hear me?
Jose] Okay please take it away Matt.
Matt] Okay. Seems I have to put... Okay hello everyone. Can you hear me clearly? Can anyone hear me clearly?
Oliver] Yes
David] Yes
Matt] K cool I'm Matt.
[verrryy long pause]
Jose] Okay Matt, if you are talking right now, we can't hear you. I and the others could hear you clearly just a little bit before. I don't know if you're using the push-to-talk or the voice activity setting so either way let us know if you are having any kind of technical difficulty.
Matt] Okay. Right. Is working now?
Jose] Yes sir.
Matt] Okay, cool. Right so...from Taiwan and and currently working...yeah so. I can see microphone is working, check.
Jose] Okay Matt.
Matt] Alright let me do it. Push to talking right?
Jose] Yeah right now I can't hear you.
Jose] Right now it appears as if you are using or pressing the key because your icon is lit up.
Matt] Hello, okay probably I'll do it layer because I use the web browser's Discord so I'm going to install the Discord app. So probably someone can do it first and I'll do it later.
Jose] Right now I'm hearing you just very clearly but if anyone can introduce themselves, that'd be fine as well.
David] I can.
Jose] Okay, go ahead David.
David] My name is David Lamhague. I live in Demark, in the western part of Denmark. I'm a schoolteacher, 60 years old. I've done animation in a lot of my time. When I was 14 I got [?] I wanted to live working on animation and from 1981, when I was 23 and 20 years on I made animation for a living. We worked on commercials, features, informational films and so on. And I made 13 episodes, 5 minutes cut animation for kids for Danish television and it was sold to [?] in 7 countries. I worked in Greenland as well as a teacher. I was on holiday there last year and I got my old principal to make a series about Greenland. And then I started to find out what to use. I had experimented with Synfig and Krita, and they were the ones I wanted to use. But then still when I took it up after the summer holidays, somehow I stumbled on the Pencil homepage to see if it was till O-4-Ob or whatever old version. But I could see that a lot of things had happened since last time I was in. That must have been 5-6 years that I've been away from that page. So I started looking at it and I came with some suggestions and before I knew it I had made some pull requests and that's...I don't know how many I've done but I've been working on it four or five months coding while I've been writing storyboards and so on. And like Jose I just want to make it a easy to use animation, 2d animation app or program. I like the simplicity of it and I have an education in programming but it's 20 years ago and all C++ programming I know is self-taught so I have dark holes, I have shortcomings. But I think it's a good code base and it gives me the possibility to do something. That's about it.
Jose] Awesome David, thank you very much for that. I don't know if Matt is still setting up, so please someone else continue with your introduction.
Oliver] I can go. Okay, so I'm Oliver. I'm also from Denmark. I've been interested in Pencil for pretty much since Matt took over but I also knew it before that. I'm a graduated computer science student, now working full time software development for iOS and Android. I have a lot of interest in animation, 2d animation especially, but I don't have any education in it. I just done a lot of research and have several books of animation stuff and have done a bunch of old cartoons and stuff, but nothing [?], nothing serious. Just a couple of seconds and anything like that. Yeah. I'm also self-taught coding C++ and most other programming languages before I went to university. So I also have holes here and there, but I again read all the time on programming pretty much. It's kind of my hobby, as well as you know [?] in Pencil2D software and hopefully improving it sometimes. Yeah, that's me.
Jose] Thank you very much Oliver. Nice to meet you too. We're missing then Matt, and J5lx well. I guess please go ahead Jakob.
Jakob] Yeah I'll go next.
Jose] Thank you.
Jakob] My name is Jakob. I'm also known as J5lx and I got involved with Pencil2D I think 2 years ago. I'm also kind of interested in 2d animation, but I'm not really an animator myself. I would like to be one but it's a little off still. I like to work on various things, not just something in particular. I think do work a lot on infrastructure, like continuous integration and Linux packaging. I also host the forum since just short of a year or something. Stuff like that. And recently I haven't been very active since I got caught up in things.
Jose] Alright. Do you want to say anything else?
Jakob] Anything in particular?
Jose] No. If that's okay with you then we can move on. If not and you want to say something else I mean just so everyone knows-
Jakob] No we can move on.
Jose] Okay. I just want say then that it's Jakob who has generously been providing us with the forum servers. So he's effectively the webmaster of the Pencil2D.org webpage now. Previously it was [?] [@gordielachance], a Frenchman who had been fulfilling that role but now has kind of passed on the torch. So I just wanted to say thank you very much for really helping us to do the migration of the forums and the webpage. Now scribblemaniac please.
Connor] Yes, alright. [Discord starts spazzing]. Oh hang on...Hello can you hear me?
Multiple] It's fine. Loud and clear.
Connor] Okay good. I'm scribblemaniac. My real name is Connor. I live in Canada and I am a computer science student. I've been Pencil2d for 2.5 years now, mostly fix small bugs and implementing small features. I was heavily involved with the Google Summer of Code application and recently I've been working on the movie exporter and improving tablet support. I'm not an animator, like at all, but I do have an interest in it obviously. I'm mostly a programmer, I've been doing this as my hobby and it's just something that really interests me.
Jose] Thank you very much Connor. Nice to meet you. Okay so Matt are you here?
Matt] Alright so can everyone hear me just fine.
Jose] Yes sir.
Matt] Okay. Cool okay. I'm Matt, again. I'm from Taiwan and currently I'm working in [Melbourne?]. I was working on Pencil2D since 2013 or 2012, I can't remember. Since the previous Pencil animation project is literally dead. So I pick it up and try to maintain it. So currently I'm really happy, so all of you, so we can all contribute to this project. It is really a lovely animation project. So I was working in the 3d animation industry, not 2d. I'm a 3d graphics engineer, writing some GPU shading code. And now I'm doing real estate area and doing doing the 3d apartment visualization kind of work. I'm happy to see you all.
Jose] Alright, thank you really for each and every one of you to introduce yourself. Now moving on. Well I kind of flipped the order, so in order to kind of tend the knitting, next is a brief discussion on the vision for the Pencil2D project. As Connor mentioned, he was heavily involved with the Google Summer of Code application. I kind of assisted him last year. Unfortunately we couldn't make it because we were competing with bigger corporations and companies and stuff like that. But the main or key feature that we've got from there was an actual vision or mission for the project. Like before we were just working towards just making a good animation program. And while that was fine, as time and resources were continued to be invested into this project, it seems like a logical next step to think aside from our hobbies, what do we want to do next with this? So ideally this is just a brief discussion of what your intent with Pencil2D as contributors, developers, and maintainers, what are your goals for this project? How do you see yourselves in this project in the upcoming years. I mean I know this is maybe a little bit of a personal thing but it is important for us to know if we are going to be seeing you in the next 2-5 years for example. I mean notwithstanding any personal issue that you have or an accident, God forbid's it. But it's important for us now that we're involved with the project so much, to know if you would be willing to continue supporting the project as you have. Aside from that discussion, I would like us to define an actual main goal for this project as a whole. That indeed started with the Google Summer of Code 2018 realization. Well I'll begin, please let's keep it short, again maximum two minutes per member or assistant. My goal for this project is not only to make an easy to use, accessible software for everyone that wants to use it, but also to make it a transitional software so people from any kind of background, like in our case, can learn animation using it. But also so professional animators can use the software just as they would use Toonboom Harmony, which is one of the [respectable?] software projects in the market, or TVPaint or Flash, the dead Flash that noone want's to [look?] now, but it's called Animate CC now, and many other software projects. In fact I just shared recently a very unknown that is rapidly gaining speed in the mobile market; it's called Rough Animator and it's pretty good I'd say. It's for PC, Mac and mobile devices and it kind of reminds me of Pencil2D because it's very easy to use. So ideally I want everyone to be able to access it, to use it, to contribute to it, and I want my colleagues and peers to be using it as well. Just as you would use pencil and paper, I want everyone to be using Pencil2D...If anyone wants to take the lead please do so.
Connor] I'll go next. I'm just going to build on what you said Jose because you covered a lot of what are the really important points for me. Really I think Pencil2D should be first about accessibility, making sure that you know anyone can use it regardless of what hardware they have, what experience level you know. Lots of people are brand new to animation, I want Pencil2D easy enough for them to use but also something that challenges them to learn about the advanced features of animation software and kind of transition them to more professional workflows if they want to go in that direction. Yeah I think that's all I want to say on that. As for my personal commitment, I don't really know where I'll be in 2-5 years so that's hard to say but I don't see any reason why I wouldn't keep Pencil2D in the near future.
David] Should I go?
Jose] Go ahead David.
David] Okay. I share the visions that you've mentioned. It should be easy, accessible to everyone. It should be something that anyone can open and start animating on and enjoy. And if you are a professional you should be able to a small project or maybe even a feature on it. That's maybe not feasible but in theory it should be like that. As I said I was a teacher and I have this seventh graders Friday and seventh lecture. It's about two o'clock in the afternoon and they're all thinking about the weekend so for the next weeks until Easter we are doing animation in that lesson there in the math class. And we started yesterday and they were really excited, I mean there was not one that just sat there and said "ah I don't care, don't want to do this". They were animating worms that crawled and birds that flew, just some easy stuff that I showed them on the SMART Board how to do. I had introduced them to how it worked and how it was dockable windows and all that and said, "well go ahead, use the timeline to make your time and so on". So it was really a great experience. Many of these don't roll but they liked it and they looked forward to it so it is fulfilling some of the wishes already, I think.
Jose] Thank you David. That's actually great. I brief point I want to touch regarding [/] uses Pencil2D in their teaching sessions, not only for animation. I've seen musicians, music teachers use Pencil2D. Also technology [?]. So I think that Pencil2D as a teaching tool is also a very very interesting objective. And I'll leave it as that so someone else that wants to take the lead please go on.
Jakob] Oh I guess I'll just go next then. As I've said before I kind of have other things to do right now so I'm just hoping that I can get the things that I've started that I can finish them and as far as my personal goals are concerned that's it. Well as for the goals or the vision for the project overall, I think I can only agree to what has already been said. I don't think I can add anything to that. Yeah that's it for me.
Jose] Alright thank you. Maybe Oliver would like to say something about it?
Oliver] Yeah, yeah I'll go. Beside all of the things that y'all have already said, I'm not sure I have a defined goal for the application but my goal for joining programming and Pencil2D especially, was because that I thought that all animation programs were too advanced and very annoying to get into. The first program that I got into animating which I thought was just easy enough to roll was Paper Animation, Plastic Paper Animation it was. So I kind of got [?] from that one and found Pencil2D, stumbled upon that one and yeah. I wanted to improve it because I saw that the application was abandoned you know, just started improving stuff however I could. So one of my own goals are of course to complete or finish my pull request, like the undo/redo rewriting, still have some bugs here and there I have to fix. I'm also sorta working on a new brush engine. But it's all kind of stuff I'm working on in my free time. So yeah it takes time, but it's coming along I'd say. So I don't know where I'm going to be in a few years either, but I don't imagine myself leaving the project, that's for sure.
Jose] Excellent. Thank you very much for that Oliver. One last person [/] what would you answer to the questions that were proposed earlier.
Matt] I'll go next. I'm not sure everyone, do you remember the original creator of the Pencil, Pascal. Pascal he write a great article called the Vision of the Pencil Animation. I think that I copied part of the article into our website, pencil2d.org. I think this post is still shows great vision of the Pencil2D I think. I want the Pencil2D to be easy to use, accessibility, and that's why I pick up the Pencil2D and started animating and getting involved in the development. Yeah and I think the first role I join the team is I want this project to be contributable. So this is my first job, I just refactoring, make the code clear, and there's someone who is more proficient in animating who can contribute features because I'm not an animator. So I think now it's kind of now an active project and we've got a lot of people here so it is time, we can move on.
David] Could I add something?
Matt] Sure, please.
David] I [/] what I did in two-three-five years and like the rest of you I don't know but my main problem is my shortcomings as a programmer. I have knowledge of it and I can do, I mean you've seen what the pull requests I've done. It's not useless, not at all, but lot of the thing when I read the code I say, "what does this mean?" And I look at it and I say, "hmm, okay." There are shortcomings and I don't know how far I can go along the way. I was asked at one point if I wanted to look at MyPaint library, and I've started to look at it and maybe I'll give it a try, I'm not sure. But there are some things in this project that are out of my league, that's how it is.
Jose] Okay yeah. We're going to talk about the features and the rest in an upcoming part of the meeting so we'll try to treat all of that in due time and I agree. I mean there are things that we as being proficient in animation can help with but I think that Pencil2D should be a mix of well not only proficient animators but also proficient [programmers?] which is what this is all about. I really hope that all of us, if not most of us, can continue to be involved with the project, but of course I know we're human and we all have an unknown fate to fulfil. So hopefully we'll continue as much as we can, but hopefully as well I want to try to be here. I'll keep working alongside you. And to that effect I'll ask us to move to the following point. In order to discuss and agree on some basic rules for the project contributions and what I what I briefly mentioned as repository edict. So first of all, well I put here: the definition of how new and longstanding contributors and developers are given participation and access to the source code. Right now the Pencil2D team members, I think all if not most of us have approval permission to approve PRs and change a lot of things in the source repository. Right now I'd say that in order to categorize who is more sanctioned than others: well first should obviously be reliant on how much of a proficient programmer it is because well I understand about computational thinking, but I no idea how to make things work in C++ [chuckle] aside from the basic normal examples. Following line would come someone like David that know animation and knows programming, then we could escalate him right. So there's programmers with animation inclinations, animators with programming inclinations and so on. So to me, what I'm trying to propose here is that first the people that should have access to the manipulation of the source repository be those that at least have an understanding of how this git system works, or svn. I use svn personally. Second that they know how the code works, obviously new contributors are welcome to ask and the PRs can be made via fork, but at least the Pencil2D team, as it is right now, should be able to access unrestrictedly that source code right? Which leads me to the following, the reviews. There has been a lot of back and forth lately about how reviews should be accepted and made, and how PRs should be merged. This is something that definitely requires us to be a bit more structured about it. I mean, I personally as always rely on Matt, on Connor, on Oliver to do the reviews. Last time Jakob did some reviews for David's contributions. I think that's fine. I mean if possible I would like to know if there's a certain type of contribution that you'd like to review, other than the normal. I mean for example Connor has been working on the exporter as he mentioned, he's been working on several fixes for different things so he knows the codebase rather well I think. Oliver has also been contributing a lot to the graphical part of the program so I'd say he's one of the top choices in one of those kind of reviews. Matt knows mostly well the engine, most definitely better than many of us because he was the first to work on it, the first to do the fork that is now known as Pencil2D. So it's important at least for me to know. I'm trying to work here as a sort of maintainer and enabler because I can't really code in C++, but at least if I know that someone tries to setup a PR that involves I don't know, the viewer manager and the timeline manager, I'll be asking both Connor and Oliver to review those PRs. So can we try to maybe not now make the list, but maybe if I provide you with a document, or you can email me at pencil2danimation at gmail dot com, our administrative email address, which kind of PRs would you like to review, okay? Ah and info at pencil2d dot org thanks to Jakob's help. So that's point a and point c of the third section. Also, well I briefly mentioned the define what kind of contributions are allowed according to the roadmap [?] workflow priorities. This is mostly because we've been talking ever since 2016, mainly with scribblemaniac, I mean Connor and Oliver about how bloated Pencil2D should be or how much of an [all-in-wonder?] program? As we've mentioned before with our previous section, it's important that Pencil2D is easy to use, accessible, but also focused. Of course this is a CAD, computer-assisted drawing software so it should also help traditional animators to go beyond what they can do with traditional tools because otherwise there wouldn't be a point right? But for example, what kind of contributions should we allow or reject or tell the contributor, "you know what, do you're own Pencil2D". I don't know, we joke about it a lot but what about Pencil3D, you go and draw virtual reality. Are we going to accept that or maybe it's better to tell them, "you know what, do your own program. You can pull from our codebase but we're not going to maintain that." That's also something that we have to define the scope of which kind of contributions. So that's kind of the initial setup. Let us discuss, we're going fine with the time, but I know it's later over there for David, for Oliver, for Jakob, so let's try to be to be efficient about it. If you want let's discuss this little bit under ten minutes, and for any other kind of structured list we can do it later. We don't need to do it now but ideally this would be the initial setup.
Connor] Alright so why don't we just focus on point 3-a first. What defines, or how do we determine who should have write access to the repositories basically. Does anyone want to go first with that?
Matt] Okay so this the issue I want to bring it up as well because I have a feeling that I am the bottleneck [chuckles] at the moment for this project because a lot of PRs are just waiting for us to review. So I believe that most of us have the access to the Pencil2D source code. I believe that right? Jose, scribblemaniac and Oliver-
Connor] I don't think David has.
Matt] Yeah.
Oliver] I can merge at least and do all kind of stuff, just without anyone saying anything.
Matt] Okay so I would say is the PR. How do we accept the PR? So currently I think we got three people here: Oliver, scribblemaniac, and me. We are the three people who have the ability to review and give advice to those contributors. So I think rather than all relying on me, so probably we can do a two out of three? So if two reviewers say yes, we are okay to accept it. So this is the first one so it will be easier for us because if I don't have the time to review it someone else: Oliver and scribblemaniac can help. And second is I want to make a basic rules for PR. First I believe that the PR should pass all of the unit tests, although it does not have a very high coverage yet, but it is the first thing. And the second thing, if any reviewer can download the code, compile, and play it a little bit, it'll be great rather than just on the Github reviewing the code. If you can actually run it, this is a necessary step. And also you can do a basic QA to see if there is any bugs. That's it. Does anyone have any thoughts?
Oliver] Yeah okay, I think those are great points [?]. Although I do think that for some smaller changes, like one-liner changes, which happen sometimes, I'm not sure that we'd have to have multiple reviewers looking at the code. But on a more general basis, I think that's a good idea, especially for huge pull requests like my undo/redo branch and stuff. Yeah.
Connor] Yeah I agree with all of that too. Yeah.
Matt] Okay. And I've got another point for some big PR with a lot of code changes. So I think that for [if I can?] the PR is better to be smaller. Smaller is better. But sometimes I know we need to change a lot of things and make a big PR. So if anyone wants to make a big PR, it could be better to just make a branch in our official repo and you can just work on it. Evveryone can see it. And then you work on your own on your own repo with [?] and suddenly you send a huge PR and it would take a long time to review.
Oliver] Yeah.
Jose] I'm sorry I think that point kind of leads to what scribblemaniac was trying to [/] about the way that a new version of the system and a new way to handle the repository would go. So if people make huge PRs, maybe they would have to go through all of those branches, as I see in the diagram here, so maybe Connor could also comment on how a huge PR like [/] would work with your proposed system of handling the repository now.
Connor] Sure so it's much like what Matt was say there. If you had a big change, it would go to a branch on the main repository before, and then the pull request would come from that branch to master. The advantage of this is that you know other people can review it earlier and contribute to it (other people who have write access to the repository). And also I've written some code so that it will automatically upload builds from PRs within the repository, so that will allow people who don't have technical expertise to run PR before they're merged into master and you know could open the way for other people to be helping with quality assurance or whatever.
Matt] Yeah, I believe this is an important point too. Like Jose, if they animator not a programmer they want to review a PR, want to review the feature, they can do it.
Jose] Well I need my C++ 101 sure, but that would be great if we could at least play back the code using Qt. I mean I do it all the time but other people who are not as involved that could just download the PR, review it by using it and of course provide the necessary feedback to us so we can improve or approve the PRs that are required.
Connor] Yeah so I think it kind of sounds like we're on agreement that this is a direction we want to go. Is anyone have any objections to this or anything they want to add or change to this proposal here?
Oliver] Not much, I think the proposal is great. It's kind of git flow, which I use a lot at work myself. So I think it's a good idea to split up the branches so we don't always just work on the master. I just [don't?] want this micromanagement, but I think it's a good idea.
Connor] So if you don't mind me backtracking a bit here. We talked a bit about how people should contribute to the code, but for people who have write-access to the repository, that's most of us as Matt said, how should we address new people? When should we say that, "oh you're 'worthy' I guess of having write access now" and who should should have write access. Jose doesn't know how to program but should he still have access? Obviously trust is something I think is an important point, or a requirement yes. But I don't know what other requirements we'll need for that. I think that we should, new contributors should be added in by a vote from the current contributors. And also one other thing that we should discuss along with this is how to remove old contributors. I was looking at the teams today and there's still some people from, you know, years ago in the project that, even before my time, still have write access to the repository. So when do we decide to remove those people?
David] If I may say something. I'm pretty new to Pencil2D, and I have no wish to be able to access the main branch as it is now. I think it is too big of a responsibility. I would like to [?] you guys [laugh] and then let me have my own for that I can do PRs from. That's my opinion.
Jose] Okay, so what I gather from this, what David said: ideally we should first, I mean we had for example for the previous Hacktoberfest, a lot of contributors, David included. Some of them, just as quickly as they came just vanished, so I don't see a reason to include them [/] main branch permissions. Even with the new scheme that is. However, I understand what David is saying that maybe even if you are trusted, which is another very valid conditional, some people just don't want that kind of responsibility. I mean I personally would like to ask David right now, this is kind of a proposal, if he want's to join the Pencil2D team. Not just in name, but for the past months he's been such a force. In fact if he hadn't proposed the meeting, I think we wouldn't be making it, which to me is kind of a deal because all this that has been said here is very [/] so we could ask. It's okay if you don't want to be with the permission to modify the branches, but you can be in the team. As for the older contributors like Francois aka. feeef, the person who was working on the MyPaint branch before this. He apparently just, well moved on obviously, but had this company called Ethic Cinema which contributed to Synfig development I think last year or the year before that. I don't know, maybe we can ask them if they are willing to continue contributing, or else we just remove them because I don't know, maybe someone, and we've had those kind of people that they contributed many years before and someone just dropped a contribution [/] year after not contributing for years. He was just like I just want to help with this and then he flew away again. Okay, Connor says they can always still contribute through PRs. Yeah that's right, so maybe, and I'm in agreement that we should limit the amount of active members in the contribution or permissions list. Agreed, the security concerns are also important. So on my behalf I would first ask and then remove the older contributors. Of course new contributors should be observed and then if there is sufficient contribution activity, if there is sufficient trust, we could ask them if they want to contribute to the main branch or continue to work on their forks, as is the case of David here. I don't know if there's any other considerations. Maybe anyone else can think of something else.
David] Well now that you're asking directly, I don't know what it means to be in the team. I would like to be in the Pencil2D team but still I'd prefer not to have direct access to the code. I would prefer to work on the fork I have. That's how I have it. If you decide that I could be a member of the team, of course I would.
Jose] Well it's mostly a title. It's because you are as involve as most of us in the welfare of the program. You want the software to evolve and well it doesn't really mean anything. You don't [/] anything much more different than what you've already done. But in being so, and this is something that we might not be able to consider, but when the possibility of creating a foundation or a non-profit organization to handle the perpetuation of Pencil2D. Being a Pencil2D member would be akin to being a board member of said foundation. Of course if anyone rejects to being a board member, that's also fine. [laugh] I'm sorry. Yeah that's basically what it means to be in the Pencil2D team according to Oliver. So.
David] I look forward to it.
Jose] Alright. Anyway, sorry to sidetrack there. Is there any other consideration for the PRs or how to accept contributions, and/or any other repository-related stuff that anyone wants to contribute.
Matt] One thing about the write access, about Github, you can't give a person who can access the issue list, so that's a problem of the Github. For example I want to give Jose access to edit the issue text, it will give him code access as well. You can't separate it. But anyway, I think we are good know. If people come and contribute a lot, we can accept it. And I just go through the developer list, the only one who are not actively involved is feeef. So if we like we can just remove it from the list at the moment.
Connor] I'd also like to add that ElectricVision, or I believe the username used to be Spark or something like that, is also in the developers team but hasn't really contributed anything codewise. They're the owner of the Discord server but I don't remember them contributing anything recently.
Oliver] Ah he did contribute a few small pull requests regarding shortcuts I believe. So I mean try to become active but that's true that he hasn't contributed that much and he's not very active anymore either.
Jose] Yeah I agree with maybe removing them, though longstanding contributors I would like to ask them if they would consider to volunteering their time again because we could always use more hands. But other than that it's fair to keep the house clean and remove anyone who's not actively contributing as per all the conditions and all that has been said like the security issues.
Matt] Alright I'll do it now.
Jose] Okay regarding this section of the main [/] does anyone want to bring any other issue regarding the commits, the PRs, or how contributions are made or who get's to review and merge?
Matt] Even if someone can access the main repository, I don't think it's really a serious security issue because all of us just staring at the git history all of the time, example for me. So if someone put some dangerous code, I would immediately be aware of it. And even though, we are doing the manual software release, so there's no possibility that someone just put the code who has the security issue we'll release and contribute to users immediately.
Connor] I don't want to like, you know, provide instructions for how to hack our repository or anything, but one issue with write access is that [REDACTED]. You're right we'd notice things pretty quickly but I'd also like to eliminate that possibility right?
Jose] Okay now that you mention the Google Drive, in the past we've kind of discussed, but we never kind of finished talking about it, was the possibility to move those nightlies to either another repository on Github or to the SourceForge repository that we have for Pencil2D. I don't know if it's feasible, or if you want we can talk about it later. Not exactly in the meeting but as a separate point to be touched from here on because it's something that I have here noted down but I never got to bring forward to discuss with all of you. Regarding the concern that Connor and Jakob [/] well I'll leave that to you guys to get which one would be the best solution right now because any security concern that is a valid concern, I mean as Matt says we're pretty much alert on what happens on the repository, but let's not invite the devil here so to speak. So if anything can be hacked it will be hacked so hopefully we don't have the ways to delete all of the work. So regarding the SourceForge or Google Drive thing: if you want to talk about it right now, let's do it, if not let's move on to the next.
Connor] I'll just quickly address that. It's technically possible I think. I'd assume that SourceForge or whatever service you wanted to use has an API for uploads just like with Google Drive, it would just be a matter of switching the code. We'd have look into whether there's a good reason to switch and so on. I think that's something that should be left for a Github issue or something like that in the future.
Oliver] Yeah I agree with that. I do think though that we could make access to the nightly builds better. Right now it's apparently pretty difficulty for some people to access the [?] drive, find the newest file. It would just be easier if they could get a direct link always, preferably from the Github page or our website instead of fumbling around on Google.
Connor] Well it is possible to use revisions with Google Drive so the link would stay the same and you'd have the same link for all the latest nightly builds. I can't remember why, but there was some reason why we couldn't use that, or it was extra work to do that. But that's something we could look into in the future.
Oliver] Yeah okay yeah, I think it's definitely a minor point because everything takes time to do. But what I think, we should make an issue about it for future.
Jose] Alright then, Jakob. The issue on the repo so we don't forget. So let's move on with the other...Okay let's see, propose a functional version...[laugh]. Well I know we spoke in the past when we release 0.6.2 about what could be release and what not. I think there are sufficient features and bug fixes now to demand a new release version. Also there's been a lot of time between versions as well. But mostly right now it would be to discuss their release targets and at least attempt to date said release. Anyone wants to start with that?
Connor] Well I think we agreed we were going to release the version in December so let's just do that [brief but painfully awkward silence] just kidding of course [brief chuckle from Jose]. I think also that there's enough features and bug fixes to warrant a new version. I mean I'm getting really sick of answering those copy and paste questions. But I think one of the big questions, what of the PRs that are currently open should we include in the next release?
Matt] That's a good point. I think the most concern about PR is still the stability. If the feature is stable enough and doesn't cause troubles, sure we should include it into the next release. So it really just depends on the previous issue we just discussed about how we accept a PR and how we test it to make sure that we won't release embarrassing bugs like the copy and paste last time we did. Yeah so we talked about it last time, we can release a feature release every three months and follow up with fix-it release a couple weeks later, since we don't really have people and time to test through every feature. So it's good to release it regularly and more frequently and our users can test it and make feedback and we'll fix it as soon as possible.
Jose] K yeah. What I'm writing here: I think I read about odd versioning is supposed to be for fix releases. I agree that we don't have the manpower to be reviewing, even with the 2/3 proposal we've already discussed, and also well there are features that are excessively big like the undo/redo feature that is being worked. I know that it's almost there but since it's so big that we can't hope to just ship it without any kind of issue. I mean it would be ideal, but that's just not how software works unfortunately as we all know. Right now there's also [/], this would tie in with the next section which is mostly about feature and fixes nomination list that was compiled from all of your [vote?] 2017 and 2018. Of course we'll discuss that in a few minutes but it's also kind of a hit-and-miss thing. Right now there are just enough fixes along with the copy/paste fix which ironically ironically enough I've had to copy and paste the same thing over and over and over to tell just what not to download, so I would be appreciative if [chuckle] we could release [/] don't have to copy and paste that again. But other than that, if we need testing I, as I mentioned before, I have kind of made a small guide for myself to test all of the features and all of the characteristics in the software so it kind of doesn't happen again that any of the main features are left out. Of course with a little bit of formatting I can share that. Yeah of course, I'll post that to our wiki. Beloved wiki. There's also, I mean it's very different to test it as a programmer thinking about the conditionals, and it's another thing to test it as a user, so with the RCs that we've tried to, this is a point I actually wanted to make: we've released the RCs for [/] it seems that not many people use it or try it out. I don't know if they're afraid of breaking their computer or what but it's simply not something that people download right away and test it so I don't know if we should just make the release candidate [/] and let the bug report happen after the releases so we can continue with this idea of the odd versioning system. I don't know what you think about that.
David] Well if people don't try the release candidates, then there's not much point in doing it. How many were downloaded? Who knows that?
Matt] I can say that it's less than 100.
David] Yeah, so maybe we might as well make a new release and then see what happens. After of course we test it as good as we can and then be prepared to make a followup a month later.
Jose] Yeah.
Matt] Yeah okay. I want to talk about the current version. So the version 0.6.3 has only one issue left in the milestone, so if anyone can help I've [got a cold?] but I haven't fixed so if anyone can help fix it we can release it as soon as possible, that 0.6.3. And that 0.6.4 would be a fix release as we say and 0.6.3 the next version is the feature release and we're coming up with a fix release. And I think the undo/redo rewrite branch would be 0.6.5. And I think we will use this branch as our 0.6.5 branch.
Jose] Okay one thing. What about the features that are actually functional but are just getting reviewed.
Connor] I think those should also wait for 0.6.5.
Jose] Okay.
Oliver] Yeah I kind of agree because the last time, the reason we ended up with this problem with the cut and paste bug appearing right before the release was that we made a pull request a few weeks before and that unfortunately got into the release too after a period of just [/]. So I'd say that...
Jose] Alright. Okay so well if we voted for that, most of you would agree that we should just steer clear from the features for at least one more version so we can go the odd version to be a feature except that this 0.6.3 would be almost a fix version because most of the things have been fixes except for a very features, minor features if you will. 0.6.4 would be a follow fix version for version 0.6.3 and then we would resume adding features and what not on 0.6.5. This also to ensure more stability and also to diminish the amount between each version. Is that correct?
Matt] Yes, it's correct. Yeah and I'm think to make a regular release period of about 3-4 times a year. So if it is 3 times a year, we can release every 4 months. And maybe 3 month to prepare a feature release and a month to prepare the fix release.
David] Sounds good.
Jose] Yeah I don't have a problem with that so if anyone else [/] that's what we're going to do.
Oliver] I'd say as long as it makes [sense?]. That means that if we've added a lot of stuff and then merged all of the things and a release is coming up, then the new features would have to be tested properly to be sure that we can put them into a new release and put it there and call it stable.
Jose] Right. Okay so the next version would be 0.6.3. Regarding the last milestone, we're waiting, quite literally for Qt 5.12 since that supposedly would fix my issue. I still need to compile the code with Qt [5.]12 so please allow 2-3 business days to do that and I'll bring whatever feedback I can. There's been success though in that another persion, he mentioned on the [/] earlier. He was testing Pencil2D in Gentoo Linux distribution I think, and he mentioned that even though he had issues with sound compiling with Qt 5.12 would fix that as well as some issue with the tablet so I'm hopeful that we can resolve that soon enough so that we can release right away. As for the release [notes], [/] we better start writing that so if you want I can help with it, but I would be very appreciative if [/] at least assign ourselves to review or write some more so that it doesn't just fall to just one person unless it's very easy for you. Other than that, if else wants to add something I think move on to the next section.
Connor] Sure I just want to add a tiny little thing there that we are waiting on you do to determine if Qt 5.12 fixes that issue in the milestone, we're also waiting AppVeyor to update their images to the latest Qt version. Theoretically like if it fixes the issue we could build it manually, I don't know what's involved with that on Windows, but that's an option if it works and if we want to release it very soon.
Jose] Alright.
Matt] Also I saw there's a font issue on mac for Qt 5.12 right?
Jose] Ah right the issue-
Oliver] There are quite a few bugs in 5.12 that I personally would go back [laughing]-
Matt] Yeah
Oliver] I'm using 5.12 myself right now and I find the release very buggy, especially because of macOS doc mode and many changes for the rendering and such. So I posted a thing about all fonts and text being extremely thin if you don't have a non-retina display. So yeah there are quite a few bumps there and stuff and I know that they have a lot of stuff work in progress but I don't think a new hotfix or a minor release is going to come anytime soon.
Matt] Okay so let's probably just hold for mac version and only go 5.12 for Windows and Linux.
Oliver] Yeah I mean we couldn't use a different Qt version across platforms, although that could cause problems for the stability. That's also the thing about each time we bump Qt, we deprecate something and we crop another revision off of some operating system. So I'm not sure it's always a good idea to upgrade instead of trying to work around the problems ourselves or something.
David] So when I'm coding, I have Windows, Linux, and mac, and I have 5.12 on all of them. What should I have on the mac? Is it 5.11 or what?
Matt] Any version you'd like to be honest.
Oliver] Yeah I mean you can use whatever version you want David. It's only your own build so that shouldn't matter and it all depends on if you use some kind of new function or something that Qt version has added that is not compatible with older versions. So you should just be fine using anything. Two or three months ago I used 5.7 myself so then I went up to 5.9 which I find it's very stable. But yeah it's up to you.
David] Okay so certainly so what I use is of course not anything to the [?] the release is fine.
Jose] Yeah that's right, it's mostly for compiling the release version. Developing and working you don't have to worry about the version...Okay should we spend a little more time [/] or should we move on to the [dramatic exhale] the priorities beyond the next release.
Matt] Yeah let's move on to the next point.
Jose] Okay. It's kind of getting late so I think after this point, it is my proposal that the followup points should be moved to another meeting. It doesn't have to be like this, we can just write about those issues because those are [/] and [/] issues and how Pencil2D is perceived as a open source project, which is very important I think. But given the time constraints, I think we will be able to [/] section five. So if you agree we can either reschedule to another meeting like this or simply open a new forum thread that is visible to [others?] [/] here on Discord. Like we have just by writing so we know what we can do about that. Let me know if you agree to that or what would be your proposal for discussing those points.
David] I think we could postpone the crowdfunding and all that to latter or maybe just writing on Discord about it. But yes the next point five is important so we should definitely go to that.
Jose] Okay.
Oliver] Yeah I do think that we should just deal with point five. We can move the rest to some other day.
Jose] Right.
Connor] Yeah I agree but there's just one quick point I wanted to bring up that wasn't on the list.
Jose] Mhmm
Connor] Sorry to interrupt here-
Jose] No problem
Connor] -with the flow but it's kind of time sensitive. The Google Summer of Code for 2019, the registration is coming up soon. Is that something that we would be interested in doing again. I'm willing to put in the work to start the application if people don't have an objection basically, and if there's someone willing to mentor.
Matt] Sure I think I can help, I can do the mentor [?].
Jose] Okay.
Connor] Okay sounds good thanks. I'll discuss it more on Discord later.
Jose] Alright let me know if I can help again with the application.
Oliver] Yeah I mean-
Jose] Okay so- go ahead
Oliver] If you want to go forward then that's cool and all, but it kind of feels like to me that for bigger organizations, even open source. So I'm not sure we're going to get into again, but it would be nice, it would be cool to get into it, if we did. Yeah I'm not sure, I'm not sure. I'm not going to join this time, but if we do get into the [/] I would probably join next time.
Jose] Alright thank you Oliver. Okay so moving on. Thank you Connor for bringing that subject. Anyway, the fifth section of this meeting would go to the priorities beyond next release. I mean it's been quite a long time. There's been work made on the features what they call the [/] which wasn't necessarily on the scheduled roadmap, but mostly features that users, animators, colleagues of mine, and a lot of people would mention tangentially as to what they would like to see. From that for this year, I pulled another list which I call the feature nomination list, which is a collection of features and fixes which would most definitely improve Pencil2D from what it is today. As such what I want us to discuss is first, which features can and should be done this year, considering always making Pencil2D not only as stable but also more usable as an animation program. So that would be the first point. The second point of that section would be, which bug fixes would be required to [/] feedback sorry such as the Linux graphics tablet related issues, the Linux AppImage related issues, and so on and so forth. It's not only a Linux issues, but it's close to that. And also after we discuss that, how we would consider even scheduling enhancements and user experience [/] which are indeed not critical but very important for the reception and the perception of users of Pencil2D as a good program, right? Again that's not critical but maybe in a moment we can discuss how to tackle those issues. So moving on let's please discuss which [features?] [/] I mean it would be a vote or something. If anyone has a say regarding please let us know.
Oliver] Okay so we are talking about the proposals in general right?
Jose] Yes sir go ahead.
Oliver] Okay. So I definitely think that I should, or the undo mechanism should work this year and will be completed hopefully. That's at least my goal. But I also think that the brush system or a brush engine should be made and prioritized in the application because it is about drawing and the better the brushes are the easier it is to gain traction in the community and on the social media and stuff because you can actually create stuff that is somewhat or what you could say. Or I don't know make it look like pencil. These kinds of small things are pretty important for an animation tool. And [?] that's also another thing. To contribute to that, that's also that once we have the brush engine that's stable and flexible enough, it will also contribute to the vector engine because if you want to replace a static black line in vector, then you would use images, and that is basically still where you use the bitmap engine and use its features to improve the vector. Yeah so I kind of think that those two [/] quite a lot. I also want to see some progress on the timeline, but again I don't think because we the timeline and it works and stuff, I do think that the brush engine and the current systems just working probably being priority for this year.
Jose] Okay thanks. Anyone wants to take the lead on that?
David] About the brush engine. In Christmas holidays I wrote to one of the developers, I can't remember his name, from MyPaint, who had to do with that, if he could lead me in the right direction, tell me where to start. Because I think maybe I could implement it but I need to break the code, find out how to start, and when that's done, I think it would be clearer to me how to do it. But maybe it's not that easy, I don't know. About the other things, I talked to a colleague of mine who is an animator and has made a small film animation about what he thought about Pencil2D because I found out he used Pencil2D for that animation. He said the biggest issue for him, because he animated like me a lot on paper, and when he has scanned his drawings and took them into Pencil2D, it would be nice if you have the possibility to make the white in the paper transparent somehow. Because now he had to import the drawings and then trace them and then color in them. And I mean he had the tracing once so he didn't feel he should do it again. That was his main concern. And then of course camera work. The camera should have better possibilities. That's at the bottom of the list but that's a major issue as well.
Jose] Okay. I'm writing down all the things you are saying. I would like to address them after everyone has proposed their vote or proposals or what they think we should and should see in Pencil2D during this year. So if anyone else wants to talk now please do so.
Connor] I'll go next. So I think the most important thing right now, in my opinion, is the backup and recovery mechanism cause we're still seeing a few users with you know corrupted files and what not. There's always going to be crashes in the program of course, well hopefully not always but we'll see. And yeah I think that's really the biggest issue in my opinion. I'd like to see the undo/redo implementation get into not this feature version but the next feature version for sure, and I'll try to help review that if I can. The timeline rewrite is also something I'm planning on working on, making at least significant progress if not finishing it this year. Also willing to help with the brush engine, but I don't know if I'll be all that useful. That's not really an area of the code base I'm familiar, but like I said, it's an important feature and it's been a long time in the works. I'd also like just to see it finally get into Pencil2D. Yeah I think that about covers like the big issues. I mean there's lots of tiny things I'd like to work on but I think those are my, improving the stability and improving backup and recovery are the biggest things for improving the user experience.
Jose] Okay thanks. Maybe Jakob or Matt. What do you think about?
Matt] Yeah so currently. Yeah so the undo/redo rewrite will be coming in the next feature release for sure. And then I always see three big issues here. The first is MyPaint branch. We talk about it a lot and timeline rewrite, some argument comes up because of it, and the vector engine. With feature we can work both on bitmap and vector but our vector engine is not really workable. So I think this is maybe the three major issues we need to address then. And also another thing I am thinking about is if we can set up a server, and once the users are not able to save or load a file correctly, it can upload a log to our server so we can have a look immediately rather than just waiting for those users pissed off and copy and paste those logs for us.
Jose] Okay thank you Matt. Jakob do you have any other suggestion or comment on the features that have been nominated?
Jakob] Not really. I mean I haven't really been actively and I'm not sure. I mean I don't have a good idea about what is going on at the moment so I can't really comment on that. I also don't have a good overview of the things that have been brought up in that priority document. It's been a while since I've read.
Jose] Okay no problem. Basically these are just a gathering ideas of features and ideas that always come up, that users always mention, or that we have perceived as very important. Even you and Matt and the other sent your ideas on 2017 regarding what kind of features should be prioritized.
Jakob] Yeah I think I remember that.
Jose] Yeah. That's basically it, but it's okay. I mean I still have a document of what most of you suggested, no worries. Now I want to briefly address what has been said here. We started discussing about it because first. The undo/redo as I see it, [/] very very [/] Matt mentioned. It should be possible to do it on the next feature release, 0.6.5. As for the brush engine, the vector engine, it's a thing that worries me that we advertising we can provide vector capabilities when actually the vector engine is just, I mean it works for somethings but it's not something I'd use on my work right now because it would either crash or make me be efficient. So there are some things that are working and some things that aren't. I know that vector engines are [a lot] of hard work, I would [/] keep postponing that, at least it should be possible to either get someone that knows about it, knows how to fix it or just scratch it and make it again. I don't know if that's a possibility, something I wanted us to discuss as well. Regarding the timeline, I honestly I think it's the backbone of the program, even more than the brush engine. Of course if you can't draw, and you can't perceive your work in time, well you're screwed, [pardons?] for that, so both timeline and brush system, or at least the capability of drawing very important for [/]. Right now I'm not sure if it's as important to have different types of brushes, which obviously it is to a certain standard but right now, and as Connor mentioned, the stability of the program is quite important as well. Not only recovering from possible crashes but also having a backup feature at least. I know that most software, most animation software has one kind of backup feature. Blender uses numbered backup files that are saved automatically. Like it's pushing the previous save to a file of its own. Toon Boom also has one. Flash even had the autosave. I don't know how Krita does it but even if you haven't saved, which is our current problem that if we do not save, the files are lost, not even saved in the temporary files because it needs to be saved at least once. So that's something that really comes up a lot [/] times I interact with the users. I know it's not our problem to make them save or not, and I don't want to force them to save because we've already discussed and know how annoying it is to have those popups say, "hey do this, do that". But we should be able to bring that. So personally, to me the stability and the timeline are the most [/] matter. The brush system, if anyone is willing to work on that as Oliver mentioned, it is more than welcome, but top two are timeline and stability, the backup. That's my position about it. So has anyone here not disabled the autosave message?...I always set it to never ask again. Well it's mostly because if it crashes and you never saved, you lose. I know that us adults save and are secure about our files, but most of our users are children below the age of 15 I think. So they just get down and animate for 3-4 hours and well everything has been saved to the RAM so it's obviously going to crash.
Oliver] Yeah we've talked about this before, but I think it's kind of a problem because actually no I don't like all these disruptive popups throwing in your face. Especially not after 5-10 strokes. But I do think it has a point in saving the users' work. I'm just not sure it's still the right way to do it. But given that an application as Pencil where animation takes up a lot more space than say Word or something where just text in a document, I don't think we can save directly to the disk without any kind of confirmation from the user before.
Jose] Yeah I mentioned Krita because I don't know how they do it, but when you're working and you've never saved, if you're work or your computer crashes (there's a blackout or something) the next time you initialize the program it will prompt you a little window that says, "you have work that has been unsaved, would you like to recover [/]. So obviously they are saving the bitmaps to temporary files or something but it's something that would definitely at least address that case. However we have to [/] bigger of course and the most pressing issue is the corrupted files that popup from time to time because we all know if you interrupt the zip operation, it's going to corrupt right? And we even tested with Connor last time. I did some very elaborate tests and it seems that Pencil2D is packing the images first and the .xml or the .pcl, however you want to name it, last. So it always packs the resources but not the xml. So it's very weird. Of course thanks to Matt and all of your work, now we can have the temporary files as they are if the program did not successfully zip, however that just covers a few cases. Most of the time people just can't recover their work.
Oliver] I mean we always create this temporary folder hidden somewhere, some deep location on the computer, and we also clear that space before. But instead of doing that, we could of course do something like Krita does where instead of always clearing the canvas, ask the user whether they want to restore what ever was in the temporary folder before. Of course it's not that simple but it's one of the ways at least I could see that that's how you do it usually for recovering stuff. There has to be somewhere on the computer where stuff is saved, otherwise you can't recover anything.
Jose] Yeah of course. In lieu of the time, if you guys are willing to, how about making a proposal. I mean I guess Connor has an idea and Oliver has an idea. Make some proposals so we can read through that and maybe try to get to something that is not only usable [/] possible. I know any kind of backup system is not meagre work. I mean it's not work like it's really difficult but it's not a piece of cake either. So instead of trying to negotiate here what kind of features it should have, maybe just take your time, all of you, and make a proposal so we can read on it later. And of course ideally we would want to help you out with that. As for the other issues, well as Connor mentioned he was originally working on the timeline rewrite, and well he got busy and if possible I mentioned before if it was a modular implementation then maybe the others could work [/] I think it's obviously not as difficult but we don't want to continue prolonging, or how should I put it, delaying sorry the implementation of a better timeline because as I mentioned the timeline is the backbone of the program along with being able to draw. I don't mind not having a vector engine right now because well you can still draw with the bitmap right? Even though we advertise we vectors. But if we had a better timeline, we could improve on all the features that are timeline-related and that way we could continue evolving the program beyond not touching that part of the code. Even though we have, and I don't think it's bad either to allow our users to see there's evolution in the program. But it's I think a time-sensitive issue as well. As for the backup and stability, again a feature proposal of how it could be done could go a long way. I made one a few months ago, of course with my perspective, but anything that you guys can think of will be really helpful into solving that problem because really I mean it was daily before. At least right now it's weekly that we've got people saying, "hey you know what, my animation just died and I cannot recover it and I've been working on it for five months, so I'd like to recover it." I mean I even had to put that guide you saw, but still people are just having these problems. So it's a definite problem we should be able to solve. I mean maybe not for 0.6.5, but at least within this year, which is mostly what this part of the meeting was about. So I guess we kind of agreed that the most important topics are, the timeline, the brush system, the undo/redo, and the stability/backup features and whatnot. Would that be correct in my perception or did you guys have anything else to add or to mention about it?
Connor] That seems alright to me.
Oliver] Yeah sounds correct to me too.
Jose] Alright then, so we'll try then to make those be worked upon along 2019. And hopefully getting most of them if not all of them into the program by the year's end. Of course that is trying to take into account everyone's time and volunteering. Other than that, it's been a very pleasant meeting. Since Matt has to go and it's late [/] both Oliver, David, and Jakob, I guess it's time to bring this meeting to an end. Does anyone have any additional topics to treat before we end the meeting or would you be okay with the meeting ending right now?
Connor] I'd like to say just a quick thanks to everyone that's here. To all the people developing, your contributions have been tremendous to helping Pencil2D come from Pencil and I feel like my contributions aren't insignificant when all of you are helping out with that. Matt especially for reviving the project and also a special thanks to Jose for doing a great job organizing this meeting and countless other things for this project and answering all of those copy and paste questions. That's all.
Jose] Okay thank you for that. I'm honestly very very grateful to you all not only for helping with this project, for being here, but also for just being very good and ethical developers and professionals. But really thank you, thank you so much for being here. It's an honour again to meet you all. I wish it could be in person. I don't know, buy you a beer or orange juice, whatever you prefer. And eventually, hopefully we can keep growing as humans beings, as members of this project, and bring more important and useful things to our peers and ourselves with it. Thanks again and I wish you the very best for this weekend. If you need anything let us know and we'll try to help however we can. Take care and have a good night, a good day and a good evening. Here your radio host Jose saying goodbye. [laughs]
Oliver] Yup that's great goodbye.
Matt] Great to see you all, goodbye.
David] Bye bye.
Jakob] Goodbye.
Connor] Goodbye.