The pytest onboarding project
This repository is a step towards contributing 'Case Studies and Documentation' to the pytest framework. It is a work in progress.
In this readme, you can view and learn something about:
| Directory | Description | Motivation |
|---|---|---|
| advice | I write up advice I've received from pytest devs here. | juniors can give back by documenting and scaling advice |
| case studies | I write up issues and pull requests here. | examples and retrospection are teachers |
| domain | I speculate about and suggest domain objects here. | thinking about design increases understanding |
| functions | I summarise and hypothesise about pytest functions here. | knowledge is data organised, memories are senses processed |
| objects | I summarise and hypothesise about pytest objects here. | knowledge is data organised, memories are senses processed |
| packages | I summarise and hypothesise about pytest packages here. | knowledge is data organised, memories are senses processed |
| prompts | I write prompts and prompt pipelines here. | automation frees up higher-level thinking |
| python | I learn about python and ground those lessons in the pytest codebase here. | without meaning, there is despair |
| scripts | I keep scripts that help manage this repo here. | automation frees up higher-level thinking |
As I learn and contribute to the pytest framework, I will use this repository to:
- write up each contribution as a case study
- record any advice I receive
- store notes, diagrams, prompts, experiments and workflows
Over time, I hope to convert elements of this repository into documentation that helps onboard and welcome junior developers to the the pytest framework's community.
The motivation for this project was first mentioned in pytest issue #11351 (I want to encourage beginners to contribute by making refactoring pull requests):
If I can make the pytest codebase more accessible to beginners like me, maybe programmers will find some of the passion and professionalism they will need to make the world safer by being part of the pytest community.
In general, I hope to make it easier for junior developers to 'find intellectual, social and emotional welcome in the pytest community'.
Issue #11351 is primarily a proposal about refactoring. It suggests a refactoring process that new developers like myself might follow to get started contributing to the pytest framework.
It also provides an example of what a contribution following this process would look like.
The refactoring process is
- Do Extract Function/Method
- Type annotate the extracted function
- Write a docstring for the extracted function
- Commit the change
The larger hope behind the refactoring proposal is 'to increase the number of people who have a passion for something I think is very important':
- testing systems and making them safer
- building and maintaining testing tools so that others can make systems safer
If put in service to that goal, I think that 'outreach and documentation of all stripes' could help onboard and inspire junior developers. This repository is the start of my attempt to do that outreach and documentation.
Who. My name is Warren. I'm a career changer. I'm average height, average weight and of average intelligence. I don't know a lot about programming and I find it very challenging. You are in good company if you are feeling overwhelmed. By documenting some of the steps I'm taking, I hope it helps you take some of yours.
Why. In a sense, this repository embodies how I view software engineering, which I view as different to programming. I enjoy programming and work at improving my skills. But what I'm really passionate about is software engineering. Fundamentally, I see software engineering as a complex social activity that unfolds over time. In my mind, to be a software engineer means to seek responsibility, build relationships and adopt attitudes of curiosity, empathy and servant leadership.
For although programs are technical artifacts inside a computer, software is the attempt to model and achieve something 'out there'. An 'out there' that goes on and changes regardless of what the code says. The 'out there' changes as people's understandings and discoveries of what matters to them most in their reality changes. Therefore, a software engineer cannot model or act with purpose about the things that are 'out there' without patience, commitment, empiricism and people-skills. They must step towards people and think about people.
How. If you interact with me, you can expect me to be passionate, fully engaged and kind. You are also very welcome to interact with me! I've chosen software engineering as a career path because it demands and inspires the whole of my personality and skillset.