Naomi Ceder

A surreal nightmare - Chelsea Manning's README.txt

Here are my thoughts on Chelsea Manning's memoir README.txt

Reading Chelsea Manning's README.txt was an odd experience for me. On the one hand, there were lots of things that made me feel connected to her and interested in her story. The most obvious was that we are both trans women, and we began our transitions at roughly the same time. And of course, her struggles for trans care were widely publicized, so I was aware of them, and to a certain extent my transition was also fairly public, if within a much smaller social network and the Python community. We had grown up in very conservative parts of the country - in her case, Oklahoma (at least in part) and in mine, Nebraska. In addition, her use of technology and the internet was similar to mine in the 90's and 2000's.

With that said, there were some real differences. For one thing I'm more than 30 years older, so I had served a self-imposed term of decades of suppressing my gender identity, waiting until circumstances made it safer and easier to transition. Chelsea's childhood was abusive in many ways, while I would not claim that of mine. And in spite of some temptation, I had resisted and avoided entering the military.

In spite of the points of connection, I was not immediately grabbed by her story. She starts with the striking scene of her desperately trying to upload all of the files via a shaky network connection in suburban mall land, during a snowstorm no less, with less than 24 hours before she has to get on a plane back to Iraq. But the telling of it is a bit pedestrian, and it takes a while for the story to emerge. Dramatic as it might be, the how and the why of the uploading of information about the war is not the story. Rather it's what happened after she was caught that I found more compelling.

The story of how she came to have that information and how she uploaded it is all too simple, and the why is not so well articulated, emerging as it does from a tough childhood and rootless adolescence that ended in the army almost out of desperation.

But once she is discovered and taken into custody things get much more gripping. The style is still matter of fact, flat, and mostly emotionless, as if it could only be told by keeping it safely at arm's length. It's a story that is almost Kafka-esque in its absurd cruelty. Earlier, when describing basic training, Chelsea acknowledges that its function is to break people, tear down part of who they are in order to reconstruct them as different people. It's interesting to me that of all the veterans I've known, the only other person who described military training that way was another trans woman, who washed out of ROTC because she wouldn't endure that.

Chelsea on the other hand gives a sense that the process of breaking and rebuilding that happens basic training was not all bad for her. So it's interesting that once in the clutches of the US government she is the target of a similar process, except there is no goal of rebuilding a new personality this time. This time the only goal is to destroy her totally. The unemotional descriptions of the inhuman torture they put her through leaves no doubt that the primary concern of her jailers and the government was pure revenge, nothing more.

That she survived her initial captivity and what was a bizarre show trial (bizarre in that many parts of it were blacked out in the name of "security") and her early captivity is amazing. The treatment she received from her own government, our government, as a citizen on US soil, under an administration that was supposedly humane and progressive, should be a curative for any idealism in regards to the justice of our ways.

If there is anything positive in the story it would be that once she given even the slightest breathing space, she was able to find people to help her as she found ways to deal with the government and even gain concessions from it, both in terms of dealing with prison and in forcing the grudging accommodation of her gender transition.

In the end her eventual movement to Leavenworth to serve her 35 year sentence (which seems almost like summer camp in comparison to what went before) and even the eventual commutation of her sentence and her release all seem not so much the restoration of justice as a calculated attempt to evade the judgment of history.

Chelsea emerges as someone of intelligence, of stunning courage, but not unscathed. After a difficult youth and her nightmarish captivity, she is not broken, but the scars (and even the still open wounds) are extensive, and one wonders if Chelsea Manning will ever be at peace in this world. And to be honest, one wonders if her ordeal was worth it.

PyCon Bolivia 2022 Keynote

Esta charla se presentó como keynote de PyCon Bolivia 2022, 2022-11-09

El texto y las diapositivas de esta charla están aquí.

Um tempo de presentes

Esta palestra se apresentou em PyCon Latam 2022, 2022-08-27

Olá, sou Naomi. Estou muito feliz de falar com vocês hoje e é uma honra dar esta palestra tanto em espanhol e como em português, falando para (quase) toda a América Latina.

Antes de começar, quero compartilhar meu projeto atual. Me aposentei há dois meses e agora tenho tempo para apoiar as comunidades Python. Quero oferecer meus 20 anos de experiência como presente para qualquer comunidade Python ao redor do mundo que queira. Se você quiser conselhos sobre como construir e gerenciar comunidades, melhores práticas, códigos de conduta, inclusão, seja o que for, eu seria feliz de oferecer meus conselhos e ajudá-lo a pensar sobre essas coisas. Para obter mais informações, visite namiceder.tech/community ou entre em contato comigo em info@naomiceder.tech.

Chamei essa palestra de "Um tempo de presentes", inspirada por uma pequena joia de memórias de viagem de Patrick Leigh Fermor, que no início da década de 1930, após ser expulso de seu último ano da public school britânica por não ser sério o suficiente, decidiu caminhar da Holanda até o Reno, através da Europa, descendo o Danúbio e finalmente chegando a Istambul. Demorou mais de um ano, e o foco do livro não são tanto os lugares e pontos turísticos que ele visitou, nem os eventos históricos que se desenrolam ao seu redor (ele atravessou a Alemanha e a Áustria quando os nazistas estavam chegando ao poder, mas ele mal percebeu isso). Em vez disso, Fermor está interessado nas pessoas que conheceu ao longo do caminho - barqueiros e motoristas de caminhão, fazendeiros e lojistas, até mesmo um aristocrata ocasional, que lhe presenteavam com comida, abrigo e companhia, o ajudando a sustentar-se ao longo do caminho.

Para mim, e talvez para muitos de vocês, meu tempo nesta comunidade foi meu tempo de presentes, presentes que me sustentaram de muitas maneiras em minha jornada nos últimos 20 anos para vários continentes, em dois gêneros, através de diferentes estágios da minha vida. Isso me levou a pensar em como valorizamos e compartilhamos os presentes de nossa comunidade e como as pessoas comparam comunidades de código aberto como a comunidade Python a uma economia de presentes.

Na PyCon US, ouvi alguém dizer: "Em Python, as pessoas sabem como o código aberto funciona". Pode ser. Mas eu me pergunto se esse entendimento é realmente o mesmo para todos. Há muitas maneiras de olhar para as comunidades, e espero que haja opiniões que divergem da minha. Mas acho importante que as comunidades articulem como pensam seus princípios, e quero apresentar uma maneira de pensar sobre nossa comunidade que faça sentido para mim. Talvez pelo menos esta palestra começarei alguma discussão.

Acho (pelo menos espero) que o que vou dizer tenha ressonância com o povo da América Latina, pois muitos de vocês experimentaram culturas de presentes em suas redes familiares e também viram os danos que a exploração de recursos e comunidades por dinheiro pode causar.

Bom. Quero deixar claro que o que vou dizer é puramente minha opinião - deixei o conselho da PSF há 2 anos, então, por favor, não culpe nenhum deles.

Eu diria que, como uma comunidade organizada em torno de uma linguagem e ecossistema de Open Source, temos uma orientação para o dom. Uma definição curta dessa orientação seria que as pessoas contribuem com o que podem quando podem e, por sua vez, contam com recursos e ajuda de outras pessoas da comunidade quando precisam.

Estamos tão acostumados com os valores de uma economia de mercado que é difícil entender como funciona essa doação. Dar presentes não é como escambo - os presentes geralmente não são negociados ao mesmo tempo, nem é o objetivo de dar presentes de valor correspondente, para que todos saiam "iguais".

Em vez disso, uma pessoa contribui com algo e, em algum momento posterior, receberá algo de que precisa de outra pessoa. Ninguém tem o direito de exigir um presente, mas ainda assim, aceita-se que todos contribuam como puderem. Por exemplo, em sociedades de caçadores-coletores, se alguém mata ou encontra alguma comida, eles a compartilham com todo o grupo, sabendo que todos os outros farão o mesmo.

Esse estilo de doação de presentes ou contribuição mútua é o que vemos em nossas comunidades Python - algumas pessoas estão contribuindo com código, outras com documentação, outras ainda trabalham para realizar eventos da comunidade. Todos esses presentes são dados gratuitamente e todos desfrutam dos benefícios. Mais ou menos como uma comuna anarco-sindicalista utópica, ou como o que os animais tinham na Fazenda dos Bichos até os porcos se transformarem em ditadores totalitários, né?

E acho que para muitos de nós que amamos essa comunidade, essa é a narrativa para a qual nos voltamos, principalmente em momentos nostálgicos enevoados, que pelo menos veteranos como eu experimentam em todas as PyCons.

Mas nesses momentos tendemos a esquecer que as coisas nunca são tão perfeitas, tão simples, tão idílicas. À medida que o Python, nossa comunidade, nossos projetos e nossas reuniões crescem, as coisas não ficam tão claras. Na verdade, muitas pessoas estão questionando se esse modelo de Open Source alimentado por presentes ainda é sustentável.

Suponho que parte do problema é que o mundo do código aberto em geral e o Python em particular têm sido relativamente bem-sucedidos. Mesmo que tenhamos crescido em todos os aspectos, o número de usuários e suas demandas cresceram exponencialmente mais rápido. Como esses grupos relativamente pequenos de voluntários podem manter uma comunidade e uma linguagem usada por milhões?

É fácil encontrar exemplos de coisas que dão errado. Um problema é o esgotamento por parte dos voluntários que o fazem funcionar. Muitas vezes vi o que chamo de "estrelas cadentes", pessoas que entram em cena e começam a contribuir para a comunidade, muitas vezes de várias maneiras, mostrando quantidades sobre-humanas de energia e entusiasmo. Parece que apenas alguns meses após seus primeiros eventos, eles estão organizando outros eventos, ministrando cursos, contribuindo com código e muito mais. Esses recém-chegados são tão bem-sucedidos, tão ansiosos para ajudar, que nós, como comunidade, alegremente lhes damos mais e mais coisas para fazer, a ponto de veteranos como eu começarem a se perguntar: "como alguém consegue fazer tudo isso?"

A resposta geralmente é que eles não conseguem, pelo menos não por muito tempo. Nesses casos, começaremos a perceber que eles parecem cansados, que o entusiasmo está diminuindo, mesmo que a carga de trabalho continue aumentando. Alguns deles me chamavam de lado e me perguntavam baixinho como lidar com o estresse, como não deixar a peteca cair... e quando eu digo a eles que a resposta é fazer menos, eles nunca acreditam. Oh, você pode ver que eles adorariam acreditar nisso, mas agora eles não têm tempo. Eles têm um evento para organizar, uma revisão ou postagem de blog para editar, código para escrever, chamadas de planejamento para participar.

E depois de alguns meses, ou no máximo dois anos, talvez, eles desapareçam. Os e-mails não são respondidos, os prazos passam, os pull requests são ignorados, as chamadas são perdidas e assim por diante. As demandas de tudo o que eles estavam fazendo, de graça, como voluntários, combinados com as demandas de trabalho, as necessidades da família, etc, literalmente sugaram toda a energia deles. O tanque está vazio e eles não têm mais para dar, e essa relação entre eles e a comunidade é prejudicada, muitas vezes de forma irreparável.

Também vi pessoas que começaram mais devagar e construíram seu trabalho ao longo dos anos até se tornarem desenvolvedores principais, maintainers ou organizadores de comunidades importantes. Eles fazem o que fazem há muitos anos, geralmente recebendo mais reclamações do que elogios, e sentem que seu trabalho está sendo dado como certo. Em muitos casos, acho que eles investiram demais emocionalmente para ir embora, mas estão cansados e se perguntando quanto tempo mais conseguem aguentar.

Às vezes, esses líderes tinham dado mais do que qualquer outra pessoa, com o resultado de que governam o projeto sozinhos. Eles possuem todas as credenciais, e sempre que algo precisa ser feito, tudo tem que passar por eles. Quando encorajados a dividir a carga, eles tendem a explicar que podem lidar bem com isso e, além disso, dá mais trabalho treinar novas pessoas para fazer o trabalho. Ou talvez eles sintam que não têm o conhecimento ou o tempo para integrar novas pessoas.

Seja qual for a causa, o tempo todo vemos pessoas ansiosas para participar de um projeto de codificação ou esforço comunitário e ajudar, que acabam sendo rejeitadas. Pelo menos uma vez por semana vejo alguém cujas ofertas de ajuda sinceras, até mesmo ansiosas, acabam sendo ignoradas por uma variedade de razões: ou ninguém tem tempo para abordá-los, ou o projeto em que eles estão interessados já tem pessoas suficientes envolvidas, ou eles estão perguntando no lugar errado, ou eles estão tentando entrar em um nível muito avançado, ou uma série de coisas.

Se eles estão tentando fazer algo para o qual ainda não estão prontos, podem ser direcionados para contribuições mais apropriadas. Mas muitas vezes me parece que alguns deles simplesmente caem num limbo. E, nesses casos, cada vez que eles tentam se envolver e de alguma forma são rejeitados, é menos provável que tentem novamente, e acabamos perdendo-os.

O resultado é que nossos projetos e nossas iniciativas comunitárias correm o risco de serem abandonados à medida que as pessoas se esgotam e não são substituídas. Acontece que muitas vezes encontramos projetos de open source abandonados, com questões não respondidas, PR's ignorados e dependencies desatualizadas... ou iniciativas com listas de discussão silenciosas, slacks de cidades fantasmas e assim por diante. Ocasionalmente, alguém pode tentar reviver um, mas geralmente eles são simplesmente deixados para trás.

Alguns até veem isso como a forma como os projetos de código aberto são. Eu estava lendo um artigo sobre a sustentabilidade do código aberto alguns meses atrás e um desenvolvedor/maintainer de vários projetos Javascript caracterizou o código aberto como "um modelo que depende de pessoas dando mais do que podem por muito pouco ou nada em troca, e esperando que haja alguém para assumir o responsabilidade quando a pessoa anterior se esgotar."

Essa descrição de como o código aberto funciona me diz que se somos de fato uma cultura que dá presentes (e acredito que somos), as coisas estão dando errado. Temos pessoas dando mais do que podem sustentar e outras que mal são capazes de sustentar o que dão, mas sentem que não estão recebendo nada em troca. Esse sentimento pode ser piorado ao ver até mesmo empresas da Fortune 100 usando seu trabalho no lugar de sistemas que costumavam custar centenas de milhares de dólares em taxas de licenciamento, sem reconhecimento e certamente sem devolver nem mesmo uma pequena fração do dinheiro que eles estão economizando.

E há outros que sentem que seus presentes estão sendo rejeitados. Este último também é sério - em uma cultura de presentear, recusar o presente de alguém é um insulto, é uma maneira de dizer que você não os quer na comunidade.

Então, claramente, existem desafios que enfrentamos como uma comunidade de código aberto. A questão é o que fazemos sobre isso? O que podemos fazer? Para mim, o primeiro passo é entender o que está acontecendo e quais motivações e valores estão impelindo o comportamento das pessoas.

A maneira como você pensa sobre algo, a narrativa que você conta a si mesmo, tem um impacto em como você lida com isso, e algumas maneiras de pensar sobre um problema podem realmente impedi-lo de corrigi-lo. Sei por experiência própria que, às vezes, mudar, ou pelo menos esclarecer, sua narrativa pode ser um primeiro passo importante para lidar melhor com uma situação.

Então, o que impulsiona comunidades como a nossa? Por que estamos aqui em uma conferência como esta, onde se fala tanto sobre comunidade? Há 20 anos, a interpretação mais popular, popularizada em coisas como a Catedral e o Bazar, era que o código aberto era movido pelo interesse próprio. Autointeresse esclarecido até certo ponto, uma vez que, em termos práticos, era mais provável que você conseguisse o que queria se estivesse agradável, mas ainda assim apenas interesse próprio. As pessoas trabalhavam apenas no que as interessava ou as beneficiava e, além disso, a única outra motivação era o impulso do ego que você poderia obter ao refletir que era você quem resolveria o problema, e todos os interessados no projeto saberiam disso. Na verdade, mesmo que você fizesse algo legal, algo altruísta, sem aquele impulso do ego como retorno, isso era apenas porque você, no fim das contas, estaria fazendo isso somente para obter como recompensa a sensação de "quão nobre" você está sendo. Em outras palavras, era interesse próprio até o fim, não importa o que você fizesse.

Junto com isso estava a crença de que um número suficiente de pessoas genialmente egoístas trabalhando para satisfazer apenas seus interesses particulares e alimentar seus próprios egos se combinariam de alguma forma para produzir o melhor de todos os mundos possíveis para todos. Como você pode notar, essa visão não inclui nenhuma noção de comunidade, serviço ou altruísmo.

Se essa é a visão que você tem de como o mundo do código aberto funciona, então não há problema com nenhum dos exemplos que mencionei acima. Burnout e saída rápidas? Bem, o nível de interesse deles não era mais alto o suficiente para eles continuarem. Ou talvez eles simplesmente não tenham conseguido impulsos de ego suficientes. De qualquer forma, não há problema. Voluntários esgotados? Se eles estão fazendo o que querem, eles vão continuar, e quando as recompensas não forem grandes o suficiente eles vão desistir, é assim que funciona. Projetos ou comunidades abandonadas? Bem, isso é o que acontece quando não há interesse suficiente. Melhor aprender a lidar com isso. E aqueles aspirantes a voluntários, que se sentem rejeitados? Eles não devem querer tanto, ou talvez não sejam inteligentes o suficiente ou agressivos o suficiente para abrir caminho.

Olhando para trás, algumas das coisas escritas 20 anos atrás nesse sentido parecem uma mistura adolescente de Ayn Rand e capitalismo liberal, e parece misericordiosamente ter caído em desuso. Nem estou reivindicando o terreno moral elevado. Antigamente, a maioria de nós realmente não questionava noções como essas, embora na prática nas comunidades em que eu estava, a maioria das pessoas realmente se comportasse de maneira diferente - eles não colocavam o ego e o interesse próprio à frente de tudo.

Suponho que todos nós nos beneficiamos de alguma forma com nossa participação, mas havia pessoas demais fazendo muitas coisas generosas e altruístas para que o interesse próprio fosse a única coisa, ou mesmo a principal, que nos impulsionasse. Mas se você nos perguntasse, era assim que muitos de nós explicaríamos como o código aberto funcionava.

Na minha opinião, essa narrativa de interesse próprio foi prejudicial a todas as comunidades de open source - incentiva a cowboy coding, flame wars e fragmentação e desencoraja a colaboração, a inclusão e a construção da comunidade. É algo que ainda estamos lutando para superar 20 anos depois.

Na verdade, a famosa citação de Brett Canon (que eu quase sempre menciono) "Eu vim pela linguagem, mas fiquei pela comunidade" reflete bastante a maneira com que muitos de nós veteranos mudamos a nossa visão dessa comunidade.

Então, isso me traz de volta à noção de dar presentes como essencial para nossa comunidade. Novamente, se pensarmos em caçadores-coletores, um dos exemplos clássicos de uma cultura de dádiva é: se um caçador mata, ele compartilha a carne com todos. Claro, ele quer comer, então há um elemento de interesse próprio no que ele faz, mas ele também compartilha com a comunidade. Não é especial, é apenas o que você faz.

É verdade que não somos caçadores-coletores, mas eu diria que esse padrão atrai a maioria de nós, a maioria dos humanos, na verdade. Se você observar como as pessoas se comportam em nossa comunidade, não é difícil ver o mesmo ethos em ação. As pessoas que contribuem com código o fazem porque podem e porque isso melhora as coisas para todos. Certamente, às vezes, o código que eles fornecem atende a uma necessidade pessoal, mas muitas vezes não. Da mesma forma, os organizadores de eventos e as pessoas do conselho trabalham muito em algo que não os beneficia pessoalmente.

No entanto, podemos (ou devemos poder) contar com a partilha dos benefícios da comunidade. Pode ser apoio e amizade, ou talvez educação e habilidades, ou contatos e uma rede profissional maior. Eu sei que experimentei tudo isso, desde receber uma oferta para escrever um livro, fazer tantos amigos em diferentes países, o que impulsionou meu aprendizado de idiomas nos últimos anos, até o PyCon 9 anos atrás, quando meu pai morreu cedo no domingo de manhã, e naquela noite várias pessoas fizeram questão de sentar comigo para que eu não tivesse que ficar sozinha.

O interessante para mim sobre culturas que dependem de presentes é que o processo é muito vago e confuso. Não há realmente nenhuma maneira de determinar que compartilhar um cervo é exatamente equivalente a, digamos, 15 peixes, ou 50 maçãs, ou qualquer outra coisa. Da mesma forma, também não há como determinar que 10 patches de código equivalem a uma palestra na conferência ou que equivale a 3 reuniões do conselho, ou o que quer que seja. Não há realmente nenhuma maneira de fazer contas exatas de olho por olho - o que todos podemos contar é que quando alguém é capaz, ele fará uma contribuição que todos podem compartilhar. E, por sua vez, contribuiremos com o que e quando pudermos.

Essa confusão não é um bug, é um feature - não saber o momento nem o valor preciso das contribuições realmente funciona para unir as pessoas, já que ninguém pode dizer com certeza que elas estão exatamente empatadas com qualquer outra pessoa. Em vez disso, há uma percepção de que as fortunas de todos estão emaranhadas, que estamos todos juntos nisso. Em outras palavras, contribuições mútuas, essa doação de presentes, é o que ajuda a unir as pessoas e criar comunidade.

Para mim, articular a doação de presentes como o que impulsiona nossa cultura, o que cria nossa comunidade, me leva a pensar em algumas coisas que acho que podemos fazer melhor: precisamos estar cientes se queremos preservar nossa comunidade Python e se queremos que ela continue a crescer e florescer.

Como indivíduos, acho que se considerarmos que todos ao nosso redor estão contribuindo com o melhor de suas habilidades, dando seus dons à comunidade, nós os trataremos (e a nós mesmos) de maneira diferente do que se acreditarmos que estamos todos por nosso próprio interesse e não devemos nada a ninguém.

Eu diria que entender que todos nós estamos nos beneficiando das contribuições dos outros torna mais fácil apreciar esse trabalho, os presentes que eles estão dando. Espero que isso também nos leve a mostrar esse apreço, algo que tantos voluntários recebem muito pouco. E também deve nos tornar um pouco menos críticos em relação aos outros, pois entendemos que sua contribuição é um dom, dado gratuitamente, não uma obrigação nem uma transação.

Quanto às estrelas cadentes que se esgotam rapidamente, talvez refletir sobre a doação de presentes ajude a lembrá-las de que não há necessidade de nenhum de nós dar mais do que podemos, que o que podemos oferecer a qualquer momento é suficiente e que todos nós também precisaremos receber presentes de outros. E espero que alguns de nós que já estamos aqui por um tempo estejamos mais inclinados a dar às pessoas que estão se comprometendo demais o presente de lembrá-las disso.

A mentalidade de que somos uma comunidade que dá presentes também pode nos ajudar a compartilhar mais a carga, a respeitar os presentes que os outros oferecem e a dar o presente de permitir que outros assumam algumas das tarefas que realizamos.

Como eu disse anteriormente, rejeitar a contribuição de alguém mostra falta de respeito - ao rejeitar seu presente estamos dizendo que não queremos que ele faça parte de nossa comunidade. Tendo isso em mente, precisamos ter certeza de que existem maneiras de pessoas novas e diferentes contribuírem, e precisamos dar o presente de orientar e aconselhar essas pessoas.

Uma parte disso é que também precisamos entregar a liderança generosamente, dar o dom de compartilhar posições de liderança. Este presente beneficia tanto o doador quanto o receptor. Tenho certeza de que uma das razões pelas quais consegui permanecer uma parte ativa e envolvida em nossa comunidade ao longo de 20 anos e 2 gêneros foi que tive uma política deliberada de entregar a liderança de qualquer projeto que ajudei criar para novas pessoas após 3-5 anos. Não é fácil no começo, parece uma perda, mas ajuda novas pessoas a crescer e mantém os veteranos frescos. Eu recomendo muito.

Outro aspecto relacionado ao que faz nossa comunidade funcionar, e onde eu acho que uma grande clareza é vital, é quando se trata de dinheiro. Até agora eu deliberadamente não mencionei a forma dominante como compartilhamos recursos: uma economia de mercado com trocas baseadas em dinheiro.

Falando de dinheiro, com sua tendência a transações exatas, exatamente o oposto da bagunça dos presentes, é que ele funciona contra a conexão e a comunidade. Se você me der algo no valor de US$ 2,52 e eu lhe der US$ 2,52, ambos sabemos que estamos exatamente empatados e a transação está concluída. Não há necessidade de continuar o relacionamento. As transações não constroem a comunidade.

Por essa razão, especialmente como comunidade, precisamos ser muito cuidadosos sobre como lidamos com o dinheiro. Não sou ingênua - neste mundo, praticamente todos precisamos de dinheiro e posso testemunhar que é melhor ter um pouco mais do que menos. Isso vale tanto para nós como indivíduos, quanto para o PSF como organização e em geral. Quando pedimos às pessoas que ajudem nossa comunidade a trabalhar em tempo integral, seja gerenciando nossa comunidade e eventos, ou seja nossa infraestrutura ou nosso processo de codificação, deveríamos pagar essas pessoas de forma justa, até generosa. Também queremos tornar nossas comunidades e eventos mais inclusivos, e muitas pessoas precisarão de ajuda financeira para participar. Da mesma forma, promover comunidades em todo o mundo custa dinheiro e, no futuro próximo, por várias razões, as coisas custarão ainda mais.

Então, claramente, precisamos de recursos financeiros para ajudar a comunidade a continuar a crescer e florescer. Mas eu me preocupo com qualquer ideia de que devamos fazer da troca monetária o motor da maneira como obtemos recursos financeiros ou da maneira como os compartilhamos. O que quero dizer com isso é que, apesar de saber que enfrentaremos e lidaremos com diversos tipos de problemas em torno de arrecadar dinheiro e depois usar esse dinheiro em nome da comunidade, acho que precisamos pensar com muita prudência sobre isso e ser particularmente cautelosos para não nos tornarmos simplesmente "um negócio".

Não tenho nada contra os negócios em si, veja bem. Ganhei a vida trabalhando para empresas e ajudando-as a ter sucesso. Mas eu estaria defendendo a ideia de que nossas comunidades Python, a PSF sendo o exemplo principal, nunca deveriam agir como um negócio. Trabalhei em várias empresas ao longo de 35 anos, e não importa o que os RH ou Marketing quisessem que você acreditasse, ser um funcionário não é como estar em uma comunidade de contribuição compartilhada com seu empregador, tampouco ser um cliente. Se nossos colaboradores se tornarem funcionários e nossos patrocinadores se tornarem clientes, nossa comunidade será diminuída, se não destruída.

Provavelmente estou sendo tendenciosa, mas acho que até agora, o PSF e a comunidade Python lidaram bem com isso. O PSF contratou pessoas para apoiar o desenvolvimento da comunidade e ajudar a capacitar as pessoas a contribuir com mais sucesso em todas as áreas. O dinheiro é gasto apoiando grupos regionais e locais menores e ajudando essas comunidades a crescer e contribuir, e a ajuda financeira para PyCon e outras grandes conferências também ajuda pessoas com menos recursos a fazer contribuições em nível global.

Patrocínios foram desenvolvidos para apoiar o PSF em geral, com poucas restrições corporativas. Acredito que esta seja a estratégia certa - ao interagirmos com o mundo dos negócios, não devemos tentar nos tornar um negócio, mas sim convidar essas empresas a se juntarem ao nosso mundo de contribuição gratuita. Isso significa vender a essas organizações benefícios difíceis de quantificar, muitas vezes intangíveis - uma venda difícil, mas não impossível, e vale a pena o esforço.

Estes são apenas os primeiros dias, no entanto. À medida que o capitalismo em estágio avançado se torna mais selvagem, à medida que a importância do Python e o poder da big tech continuam a crescer, a tensão entre uma economia de mercado e uma comunidade centrada na contribuição aumentará. Em outras palavras, acho inevitável que haja mais pressão sobre nós para abandonar nossa cultura de presentes e contribuições gratuitas em favor de transações monetárias. Podem ser empresas tentando comprar o controle sobre a linguagem e/ou comunidade, pode ser a pressão para tratar os colaboradores e voluntários mais como funcionários, ou pode ser outra coisa, mas nos próximos anos haverá ofertas para vender nossa comunidade para uma proposta tentadora ou outra.

Se e quando isso acontecer, caberá a nós decidir se ainda queremos ser uma comunidade de presentes e contribuições gratuitas. Eu certamente sei minha resposta.

Muito obrigada pela atenção e muitos abraços a todos em nossas comunidades.

The time has come...

As we head into the PSF election cycle, I'd like to let everyone know that I will not be running for re-election to the PSF Board of Directors and consequently from mid June I will no longer be serving as chair of the PSF.

Announcements like this always strike me as awkward, since they make two rather unlikely assumptions: that people will even notice, and that they will care if they do. But in the interests of transparency I'm going to go ahead as if both were true and share my reasons for this decision.

FIrst of all, I truly do believe that limited terms are good for the sustainability of an organization like ours. If someone is in a key role for too long, their inevitable departure and replacement can be unnecessarily disruptive and difficult, even with the best intentions. Of course "too long" can be hard to define, but I think it's safer to err on the side of leaving sooner rather than later. I also think it will be good for the PSF to practice handing off board leadership.

My other reason is that it's just time to move on. After five years on the board and 3 as chair, it seems like it's time to step out of that role and find something different to do, some other way to work for the Python community.

This isn't a dramatic change - I will be available to the next board as an advisor, and of course I will remain a passionate supporter of the PSF and Python communities around the world. So no, you're not getting rid of me that easily. :-D

I do hope that the PSF will continue to work on electing a diverse board, in all of the endless possible dimensions. For one target, I would love to see more representation on the board from Latin America, southern Europe, Africa, and Asia, as well as LGBTQ folks, racial and religious diversity, neurodiversity, and the rest.

If you're one of those people would help make the board more diverse but you're thinking, "yes, but there's no way that someone like me could be elected," well... I was thinking exactly the same thing when I ran for the board 5 years ago. There are no guarantees, but I believe it's worth a try, both for what you might bring and for the experience you will gain. So if that's you, get in touch - I'd be happy to talk about the board and what it involves, and offer any support I can.

It's been a privilege to work with so many amazing people on the board - we may not always have agreed on every point, but you would be hard pressed to find a group of people more dedicated to the success of the PSF and the Python community.

I'm also honored to have worked with the PSF staff as it's grown. They are truly amazing - smart, hardworking, and dedicated. I've seen their work up close, and believe me when I say that we're lucky to have them and they deserve all of the support we can give them.

As we move forward into the changes that the current crisis will bring, I have no doubt that the PSF and its board and staff will be more than up to the challenges ahead.

My time as chair of the PSF has been a lot of things for me - sometimes a challenge, often a learning experience, always an honor and a wonderful opportunity to get to know so many Python communities and their members. But above all it has been a rare and ridiculously improbable gift, something to be treasured, but also to be held lightly, and then passed on.

So long, and thanks for all the fish...

Notes on Teaching Python – Mental Models

I admit it – I’m just an old, cranky teacher. As much I love seeing so many people all around me teaching Python, as much as I love the notion of spreading the joy of Python to various masses, there are things… things that give me pause. No, worse than pause, they give me a serious case of teacher twitch.

I start feeling the overwhelming urge to offer constructive criticism and helpful advice where none is wanted. I usually fight these urges, not wanting to be shunned by everyone as “that woman” (or something worse).

However, I also don’t want to end up in the corner muttering something like “get offa my lawn”. So I’m going to rant gently about some of these twinge inducers here.

What are we teaching, really?

I think one issue arises from a failure to ask ourselves what we really are trying to teach when we are teaching “Python”. It seems like a silly question, or a redundant one, but humor me. What are we trying to teach? Syntax? Best practices? Problem solving? TDD? OOP? What is Pythonic? Coding? Critical thinking? Computer science concepts? All of the above?

I’m pretty sure I’ve heard all of those answers at one point or another, and even given some of them. Yet I’m equally sure that something vital is missing when we talk about what we need to teach when teaching Python. And this something really holds everything else together.

The importance of a mental models

The missing “somethings” I’m thinking of (since in fact there are many of them) are mental models. We may not know every detail of how a thing works, but if we have an accurate mental model how it works, we can form some reasonable expectations about how it might work in different situations.

If I have a sound mental model of how AC current works and see that the lamp has a frayed cord, I can pretty confidently unplug it and deal with the problem. On the other hand, if I have an inaccurate mental model of how AC current works, I might either run from the room expecting the lamp to explode, or reach down and grab the bare wire. Neither is a desirable result, but yes, I’ve actually known people who fall into both categories.

The same is true in Python and coding. If we have an accurate way of thinking about a feature of the language, we stand a much better chance of getting code that works as desired. If we have faulty mental models, then the coding equivalent of electrocution or irrational avoidance awaits.

Take “variables,” please

For example what about “variables”? Yes, I agree that the term “variable” is questionable in Python. Yes, I prefer either “name” or “label”. However, it seems pretty much everyone calls them variables at some time or another, which may well be part of the problem. Several times now I’ve seen newcomers to coding being taught that about “variables” in Python. And many of those times I’ve seen the explanation that a variable is a “container that holds a value.” Or, as I used to say when I taught C, they’re told that a variable is like a bucket.

For C this makes some sense. And while no one should argue too much with the notion that the contents of a variable must go somewhere, in fact thinking of Python variables as containers is an inaccurate model – names in Python are more like post-its than buckets. But what makes the notion of variables as buckets even more insidious is that it seems to work well enough at first that people get used to thinking this way, and then pass it along.

Consider the following mindless code:

    a = 1
    b = a
    c = b
    print(a, b, c)

So far, so mindless. If you ask people what you get, they will not have a problem saying 1 1 1.

But suppose you then add the line

   b = 2

and ask about print(a, b, c)?

The followers of the bucket camp will usually (and correctly) say that the result is 1 2 1. In fact, there may be some confusion about what the “contents” of c are, but if you are thinking buckets, the answer makes sense.

But what about a mutable object? Suppose we have this:

    a = [1, 2, 3]
    b = a
    c = b
    b[1] = 5
    print(a, b, c)

Here the members of the bucket brigade are often stumped. In my experience I have been stunned at how many beginning (even intermediate) Python coders are surprised by the actual output of [1, 5, 3] [1, 5, 3] [1, 5, 3]. If variables are containers, how on earth can changing the contents of one change the others?

But if instead they are names that point to objects, the right answer makes sense. Once they have a better mental model of how names work in Python, such surprises (and the attendant bugs) become much rarer.

Let me be clear, this example isn’t the only case of poor mental models in teaching Python. I’ve picked on this example because it’s so fundamental and, in my experience at least, so common.

The question is not if our students will create mental models or not – we all form mental models as we learn. It’s our job as teachers to be thoughtful and help our students form useful and accurate ones.