[RFC][Discussion] Change terminology to ExcludeList

php.internals

Michał Brzuchalski

6 years ago
Hi Internals, I'd like to start a discussion period for my RFC which proposes to change the use of "blacklist" in Opcache configuration with better self-descriptive terminology. The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist Discussions should remain on the list. Any emails sent directly are likely to be replied to on the list. Cheers, Michał Marcin Brzuchalski

Dan Ackroyd

6 years ago
On Tue, 16 Jun 2020 at 13:15, Michał Brzuchalski <michal.brzuchalski@gmail.com> wrote:
> > Hi Internals, > > I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology.
Hi Michał, Thanks for posting the RFC. In my opinion it costs very little to change. Having 'white' == good, and 'black' == bad is not a good thing to have in the English language. You can argue the cause and effect of whether racism led to that meaning, or whether that meaning could lead to people being racist, but it costs so little to change it, we should. cheers Dan Ack Maintainer of Imagick

Mark Randall

6 years ago
On 16/06/2020 13:14, Michał Brzuchalski wrote:
> I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology.
IMHO this RFC should not come to a vote, the current RFC process is ill-equipped to handle such a vote. This RFC, disguised in a cloak of wanting to improve readability, is clearly political. Not political in terms of the inner politics of the PHP internals group, but in terms of the larger world. At the time of publishing, there are currently countless riots, protests, counter-protests, harassment and criminal acts surrounding this issue. It cannot reasonably be argued that the timing is anything other than a political statement, the commonly accepted term would be virtue signalling. In this climate, it is likely impossible to hold a meaningful vote on the issue. Internals on internals are not hidden behind some corporate monolith like Github / Microsoft. Our names are our own, our contact details readily available. Anyone voting against this RFC on the proposal on any of the perfectly legitimate grounds to do so, such as the BC issues, will still immediately be labeled a racist and is likely to receive threats or harassment. Anyone voting for it is likely to receive harassment too. As I said, the current voting system is ill-equipped to handle such a setup. If you expect everyone who wants to have a free say, to have a free say, there must be an element of anonymity that simply does not exist in our current processes. The RFC author has already stated in R11 that they have started receiving harassing emails in relation to it.

Kalle Sommer Nielsen

6 years ago
Hi Den tir. 16. jun. 2020 kl. 15.15 skrev Michał Brzuchalski <michal.brzuchalski@gmail.com>:
> > Hi Internals, > > I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology.
I disagree with this statement, and I do not believe that just because you think it is a better terminology, it should be justifying the BC break that comes with this change. Like I expressed in the PR when it was originally posted and the other topic currently active on internals that it seems much like a change for the sake of change. This is clearly a political change and something we as a project should refrain from doing. If this RFC comes to pass, are we going to change the PHP.net logo to declare our political allegiance to the cause in America? Attempting to change something which has no correlation to racial remarks but using it as an argument that it can be is an absurd argument to me.
> The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
The pull request in the linked RFC does not seem to reflect all the details of this RFC, the PR also changes the whitelist to allowlist, something that is not noted in the RFC itself among other things, or did I miss something?
-- regards, Kalle Sommer Nielsen kalle@php.net

Michał Brzuchalski

6 years ago
Hi Kalle, wt., 16 cze 2020 o 14:35 Kalle Sommer Nielsen <kalle@php.net> napisał(a):
> ... > > The RFC is here > https://wiki.php.net/rfc/change-terminology-to-excludelist > > The pull request in the linked RFC does not seem to reflect all the > details of this RFC, the PR also changes the whitelist to allowlist, > something that is not noted in the RFC itself among other things, or > did I miss something? >
I've updated the patch, the PR description and a title to reflect the RFC proposal. It's true that there were things not reflected in the RFC, now they're gone. Also, I've accidentally pushed some files which shouldn't even get there and they're also gone. If we decide in the second vote on the right name, I'll update it respectively again. Cheers, Michał Marcin Brzuchalski

Daniel Rodrigues Lima

6 years ago
+1 for this, exclude_list better explains code intent than blacklist.
-- Cheers, Daniel Rodrigues. geekcom@php.net https://twitter.com/geekcom2 ________________________________ De: Michał Brzuchalski <michal.brzuchalski@gmail.com> Enviado: terça-feira, 16 de junho de 2020 09:14 Para: PHP Internals List <internals@lists.php.net> Assunto: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList Hi Internals, I'd like to start a discussion period for my RFC which proposes to change the use of "blacklist" in Opcache configuration with better self-descriptive terminology. The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist Discussions should remain on the list. Any emails sent directly are likely to be replied to on the list. Cheers, Michał Marcin Brzuchalski

Claude Pache

6 years ago
> Le 16 juin 2020 à 14:14, Michał Brzuchalski <michal.brzuchalski@gmail.com> a écrit : > > Hi Internals, > > I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology. > > > The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist <https://wiki.php.net/rfc/change-terminology-to-excludelist>
Hi, I object that the proposed term is in any way clearer. “Blacklist” is an idiomatic term with a well-established meaning, so that it is immediately recognisable, and it couldn’t mean anything else that it intends to mean. On the other hand, “exclude_list” is less common, and since I am not accustomed to that terminology, I have to analyse the expression, or rather, since English has the unfortunate tendency to stack words without specifying neither their function nor the precise relation between them, I have to guess what it could mean, with good chance of getting wrong: “exclude the list”? whereas “blacklist” means in fact: “list of items to exclude”. —Claude

Lester Caine

6 years ago
On 16/06/2020 13:14, Michał Brzuchalski wrote:
> I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology.
Since there will be a higher level change to all these terms - in all likelihood - trying to push yet another term that does not match the current discussions elsewhere seems somewhat premature. The NEXT RFC will be to bring this in line with the 'new' industrial standard, so is there any point jumping the gun before the international debate has finished? "blocklist", "banlist", and others all have appropriate application but like "excludelist", they all imply a narrower usage area while "blacklist" is accepted generally across all applications. What ever alternative to "blacklist" is adopted elsewhere is going to cause confusion and adding to that confusion with a different 'translation' just makes the situation worse?
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk

Chase Peeler

6 years ago
On Tue, Jun 16, 2020 at 9:55 AM Lester Caine <lester@lsces.uk> wrote:
> On 16/06/2020 13:14, Michał Brzuchalski wrote: > > I'd like to start a discussion period for my RFC which proposes to change > > the use of "blacklist" in Opcache configuration with better > > self-descriptive terminology. > > Since there will be a higher level change to all these terms - in all > likelihood - trying to push yet another term that does not match the > current discussions elsewhere seems somewhat premature. The NEXT RFC > will be to bring this in line with the 'new' industrial standard, so is > there any point jumping the gun before the international debate has > finished? "blocklist", "banlist", and others all have appropriate > application but like "excludelist", they all imply a narrower usage area > while "blacklist" is accepted generally across all applications. > > What ever alternative to "blacklist" is adopted elsewhere is going to > cause confusion and adding to that confusion with a different > 'translation' just makes the situation worse? > >
I agree with this 100%. Without offering an opinion on whether or not we should change it, I do think it makes sense that if we do change it, we at least wait until a more standard term has been decided among other developers and projects. It would also provide another justification for the change, if the change was being made to align with industry standards. I also want to point out my agreement with others that have posted about the current climate not being conducive to an honest conversation on this topic. The current climate in the US is such that often it's not enough to agree on what the end goal should be. If someone doesn't agree with how we reach that goal and why we should reach it, they are treated as if they are against achieving the goal altogether. This topic is very susceptible to those kinds of reactions.
> -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com

Michał Brzuchalski

6 years ago
Hi Lester, wt., 16 cze 2020 o 15:55 Lester Caine <lester@lsces.uk> napisał(a):
> On 16/06/2020 13:14, Michał Brzuchalski wrote: > > I'd like to start a discussion period for my RFC which proposes to change > > the use of "blacklist" in Opcache configuration with better > > self-descriptive terminology. > > Since there will be a higher level change to all these terms - in all > likelihood - trying to push yet another term that does not match the > current discussions elsewhere seems somewhat premature. The NEXT RFC > will be to bring this in line with the 'new' industrial standard, so is > there any point jumping the gun before the international debate has > finished? "blocklist", "banlist", and others all have appropriate > application but like "excludelist", they all imply a narrower usage area > while "blacklist" is accepted generally across all applications. > > What ever alternative to "blacklist" is adopted elsewhere is going to > cause confusion and adding to that confusion with a different > 'translation' just makes the situation worse? >
Isn't that the more narrow term is used it's easier to understand? We can easily vote on the right name. I chose the "exclude list" cause the INI setting which changes name in this proposal is a glob path to filenames. These files are then parsed as a list of glob paths for later file exclusion on opcache run. Another term in my mind is "ignore list" which then suggest a list of files ignored by opcache run. Regarding the "blocklist" I have to admit that it was my first thought but after thinking IMO it's inappropriate. There is nothing in the opcache what blocks files from being cached and optimised, they by themselves are not trying to be cached, cause the flow is from opcache extension. For me to whom English is not a native language first association is with blocking service access to the clients which interacts with the service and try to get access to it. That's why I think it's inappropriate here and I've changed it in the original patch. The same goes for the "banlist" for me my first association is with the client who had access to the service but due to some policy reasons (like fo reg. destructive intentions or overuse), the client lost access rights and get's banned with assignnment to the "banlist". Therefore IMO we should choose a new name wisely so it can be self-descriptive. What I can propose is update of RFC with a note regarding the second vote for the right name. I'd like to put there an "exclude_list" and "ignore_list", but if my reasoning about not debating on the "banlist" and/or "blocklist" is not enough then please let me know then I can add those two also. Cheers, Michał Marcin Brzuchalski

Alain Williams

6 years ago
On Wed, Jun 17, 2020 at 11:46:12AM +0200, Michał Marcin Brzuchalski wrote:
> Therefore IMO we should choose a new name wisely so it can be > self-descriptive.
Also: important to choose words/names that are being adopted elsewhere; thus people will recognise it as they have learned it elsewhere. I cannot predict what new words will become the replacement for blacklist - if it is indeed replaced. No one can. I would suggest that this be put into the cooler until (and if) there is general agreement elsewhere -- we would not want to change again in a couple of years as we had chosen the 'wrong' term. Regards
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

Chase Peeler

6 years ago
On Wed, Jun 17, 2020 at 5:46 AM Michał Marcin Brzuchalski < michal.brzuchalski@gmail.com> wrote:
> Hi Lester, > > wt., 16 cze 2020 o 15:55 Lester Caine <lester@lsces.uk> napisał(a): > > > On 16/06/2020 13:14, Michał Brzuchalski wrote: > > > I'd like to start a discussion period for my RFC which proposes to > change > > > the use of "blacklist" in Opcache configuration with better > > > self-descriptive terminology. > > > > Since there will be a higher level change to all these terms - in all > > likelihood - trying to push yet another term that does not match the > > current discussions elsewhere seems somewhat premature. The NEXT RFC > > will be to bring this in line with the 'new' industrial standard, so is > > there any point jumping the gun before the international debate has > > finished? "blocklist", "banlist", and others all have appropriate > > application but like "excludelist", they all imply a narrower usage area > > while "blacklist" is accepted generally across all applications. > > > > What ever alternative to "blacklist" is adopted elsewhere is going to > > cause confusion and adding to that confusion with a different > > 'translation' just makes the situation worse? > > > > Isn't that the more narrow term is used it's easier to understand? > We can easily vote on the right name. > > I chose the "exclude list" cause the INI setting which changes name in this > proposal > is a glob path to filenames. >
Please stop using the term "glob." As a person that is above what many would consider an ideal weight, I've been called a "useless glob" on multiple occasions. This term is harmful to me as a result.
> These files are then parsed as a list of glob paths for later file > exclusion on opcache run. > Another term in my mind is "ignore list" which then suggest a list of files > ignored by opcache run. > >
When I grew up, I was often ignored by other people, causing me to be lonely and depressed. The term "ignore list" triggers those same feelings, so please avoid using this in the future.
> Regarding the "blocklist" I have to admit that it was my first thought but > after thinking IMO it's inappropriate. >
My father often called me an "ignorant blockhead" so the term "blocklist" triggers negative emotions as well.
> There is nothing in the opcache what blocks files from being cached and > optimised, > they by themselves are not trying to be cached, cause the flow is from > opcache extension. > > For me to whom English is not a native language first association is with > blocking service access to the clients > which interacts with the service and try to get access to it. > That's why I think it's inappropriate here and I've changed it in the > original patch. > > The same goes for the "banlist" for me my first association is with the > client who had access to the service > but due to some policy reasons (like fo reg. destructive intentions or > overuse), the client lost access rights and > get's banned with assignnment to the "banlist". > > Therefore IMO we should choose a new name wisely so it can be > self-descriptive. > What I can propose is update of RFC with a note regarding the second vote > for the right name. > I'd like to put there an "exclude_list" and "ignore_list", but if my > reasoning about not debating > on the "banlist" and/or "blocklist" is not enough then please let me know > then I can add those two also. > > Cheers, > Michał Marcin Brzuchalski >
None of the above are actually true (except for the fact that I'm overweight). The point I'm trying to raise is that context matters, and changing terms because some people refuse to understand the context is not justified. Otherwise you open a pandora's box where you either have to change everything that someone claims offends them, or, you have to pick and choose which people or group are allowed to be offended and which are not. If the term blacklist had racist origins, the discussion might be different. However, it does not, just like glob does not have origin in fat-shaming. I have no problem changing these terms if they are changed industry wise and the new terms are needed to keep up with industry standards. I might not agree with why they were changed in other arenas, but, at the point new terms become standard, the reason they became standard doesn't really matter. So, as others have said, this and other discussions about renaming terms because some might find them offensive is not something we should be doing. Renaming terms in order to align with changes to industry standards, while something we should do, is premature at this point as those standards have yet to change.
-- Chase Peeler chasepeeler@gmail.com

Alain Williams

6 years ago
On Wed, Jun 17, 2020 at 10:22:02AM -0400, Chase Peeler wrote:
> None of the above are actually true (except for the fact that I'm > overweight). The point I'm trying to raise is that context matters, and > changing terms because some people refuse to understand the context is not > justified. Otherwise you open a pandora's box where you either have to > change everything that someone claims offends them, or, you have to pick > and choose which people or group are allowed to be offended and which are > not. If the term blacklist had racist origins, the discussion might be > different. However, it does not, just like glob does not have origin in > fat-shaming.
There was a similar brouhaha a year or two back in the folk dancing world. Some display dance groups paint their faces black as many of the dances were done like that a century or so ago. There were cries about this offending people with dark skins. In fact the origin was where some would dance around their village, drink a lot, cause mischief - the purpose of blacking up was to make it harder for them to be recognised. Walking back (to shower off) after doing this I walked past a black family; they looked curious, I explained, smiles all round. Context is all.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

Jakob Givoni

6 years ago
On Wed, Jun 17, 2020 at 4:22 PM Chase Peeler <chasepeeler@gmail.com> wrote:
> > Please stop using the term "glob." As a person that is above what many > would consider an ideal weight, I've been called a "useless glob" on > multiple occasions. This term is harmful to me as a result. >
Though I know you're joking (and I laughed out loud!) I think you are misunderstanding something: Calling someone black is actually not offensive! To repeat what has been said many times over now: It's when "black" is associated with "bad" in a composite term like "blacklist" we should consider being considerate of a group of people who actually have skin of that color. If we, hypothetically, happened to be using the term "obeselist" (for whatever obscure historical reason) to mean "list of things to be blocked", would you also think that was totally fine because context is everything and nobody's saying you're worth less because you're overweight? Best, Jakob

Bob Weinand

6 years ago
> Am 18.06.2020 um 00:36 schrieb Jakob Givoni <jakob@givoni.dk>: > To repeat what has been said many times over now: It's when "black" is > associated with "bad" in a composite term like "blacklist" we should > consider being considerate of a group of people who actually have skin > of that color. > > Best, > Jakob
TL;DR: Can we please do terminology changes for the right reasons, just like the RFC itself is proposing. Thanks. --- You can also define black as what pure black really is - void of everything - no light - nothing. Things we don't see. And white being light. Things we see. It does not necessarily need to have a connection with good and bad. You can also blacklist legitimate things, but you just don't want to process them right now. The issue is rather that we are talking about "good" and "bad" inputs and then connect that to a white- or blacklist. (Because usually the things we do not want to see are bad things) There however is no innate connection from something being black to it being bad, rather a coincidence via a couple hops. And only applying in most cases. For example: "I want to whitelist undesired inputs for logging." While I see that there is a case for a more unambiguous wording like opcache_file_exclude, this matter shall not be about the good-ness or bad-ness of the color black. P.s. And to be honest, I've never heard from a dark-skinned person that they felt actually oppressed by words like blacklist. And here my personal opinion, to be taken with a grain of salt: This whole white- and blacklist discussion is mostly "hey I want to make black people feel more welcome, let me call blacklist bad and condemn everyone not agreeing. Then I have done my good deed" - without having any actual impact on the well-being of dark-skinned people. - That's what it feels like for me, but I'm open to being corrected by those who are actually dark-skinned and impacted by it, in which case I'll immediately retract my last sentence. Bob

Lynn

6 years ago
On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand <bobwei9@hotmail.com> wrote:
> P.s. And to be honest, I've never heard from a dark-skinned person that > they felt actually oppressed by words like blacklist. > > And here my personal opinion, to be taken with a grain of salt: This whole > white- and blacklist discussion is mostly "hey I want to make black people > feel more welcome, let me call blacklist bad and condemn everyone not > agreeing. Then I have done my good deed" - without having any actual impact > on the well-being of dark-skinned people. - That's what it feels like for > me, but I'm open to being corrected by those who are actually dark-skinned > and impacted by it, in which case I'll immediately retract my last sentence. >
Hi Bob, Nobody is talking about oppression when it comes to certain "technical" terms. Please look my post from earlier and look at the tweets I link: https://externals.io/message/110515#110574 I can recommend everyone to expand their bubble, as a lot of replies in here show that the bubbles are homogeneous. Regards, Lynn

Bob Weinand

6 years ago
> Am 18.06.2020 um 20:24 schrieb Lynn <kjarli@gmail.com>: > > > > On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand <bobwei9@hotmail.com <mailto:bobwei9@hotmail.com>> wrote: > P.s. And to be honest, I've never heard from a dark-skinned person that they felt actually oppressed by words like blacklist. > > And here my personal opinion, to be taken with a grain of salt: This whole white- and blacklist discussion is mostly "hey I want to make black people feel more welcome, let me call blacklist bad and condemn everyone not agreeing. Then I have done my good deed" - without having any actual impact on the well-being of dark-skinned people. - That's what it feels like for me, but I'm open to being corrected by those who are actually dark-skinned and impacted by it, in which case I'll immediately retract my last sentence. > > Hi Bob, > > Nobody is talking about oppression when it comes to certain "technical" terms. Please look my post from earlier and look at the tweets I link: https://externals.io/message/110515#110574 <https://externals.io/message/110515#110574> > > I can recommend everyone to expand their bubble, as a lot of replies in here show that the bubbles are homogeneous. > > Regards, > Lynn
Hey, yes, you are making quite the same point than I did. Maybe I misused the word _oppression_ here. But in any case, I fully agree with you. Bob

Björn Larsson

6 years ago
Den 2020-06-16 kl. 14:14, skrev Michał Brzuchalski:
> Hi Internals, > > I'd like to start a discussion period for my RFC which proposes to change > the use of "blacklist" in Opcache configuration with better > self-descriptive terminology. > > The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist > > Discussions should remain on the list. > Any emails sent directly are likely to be replied to on the list. > > Cheers, > Michał Marcin Brzuchalski
Hi, Some comments: - I miss from this RFC how it affects documentation if any and with that   how it affects translation of the documentation. So even if it's a small   effort to change a few lines in the INI file, it might be bigger doing it in   the documentation and also come up with good translations to other   languages. - I assume that there is a limited amount of people working with INI files,   primarily sysadmins and to some degree developers and they are not   doing it everyday. So is it fair to assume that it's a limited amount of   people working with INI files and they are not doing it every day? - In a hosting environment where this INI file lives it's fair to assume that   multiple versions of PHP are hosted, e.g. today it can be both 5.6 and 7.x.   So for the sysadmin there will be different names for same functionality   in the INI file when 8.0 comes out. - As a side note, the default version shipped with the recent CentOS 7.8   version, it's PHP 5.4. I also think it's a bit premature to jump on this wagon for several reasons. r//Björn L

Arvids Godjuks

6 years ago
Hello everyone, I would like everyone to slow down a bit and give a think about this: English is not the primary language for the vast majority of people. are a thing and a lot of people, actually, work with PHP that either does not know English at all or, know the basics and rarely have the English skills to a level that allows them to easily understand subtleties of things. What you need to consider, that some alternatives that are being talked about, may not have a translation. Like at all. Here's a case and point for the Russian language - there is no alternative, as far as I can tell, for a "blacklist" that has the meaning blacklist or exclude list can be translated. The only Russian phrase that I know of (and I tried searching for alternatives) is a literal translation of the phrase "black list". Anything I could think of just didn't fit - there is just no other word that describes an "exclude list" - it translates literally to "black list" anyway. Same goes for the Latvian language - the only word we have for it is a literal translation and nothing else. And I suspect, it might be the case for many other languages too for a simple reason - the term came from English first and got adopted one way or the other into the language because there was no counterpart for it in it. On the other hand, Russian has a great translation for the "master/slave" combo - ведущий/ведомый that has 0 association with anything slavery related. But the literal translation to English is "master/slave", and it does not translate correctly to "Primary/Secondary" or other alternatives I've seen around, because it looses all meaning that Russian words describe for the technical implications of how things work in mechanics, engines and so on. it's also actually used in aviation too between Commander and Second Officer. Closest I can translate it is "Leading / One who is led by the leading". Just my 0.02$ as food for thought, because PHP is not a regional project. This is a global project and it's userbase overall, probably, is not primarily English speakers. A lot of us just revolve around in English speaking tech bubble, because it is the international language and it is easiest for everyone who is involved in OSS projects and international companies. But I'm not, personally, an English speaker - English is my 3rd language. I also live in Russian tech space and it is pretty common to have developers who do not know English to a level of speaking and/or reading and relly on documentation translations and those established industry-standard terms that they know and/or use google translate. P.S. I just run "exclude list" through google translate into Russian and Latvian - let's just say that translations were confusing at best because I can't judge how bad they would be for a person who does not know English well or at all. Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius