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 |
|---|---|
| domain | |
| packages | |
| case studies | |
| prompts |
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 software engineering 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. Fundamentally, I see software engineering as a complex social activity that unfolds over time. In my book, to be a software engineer means to seek responsibility, build relationships and adopt attitudes of curiosity, empathy and servant leadership.
For although code is a technical artifact inside a computer, it is also an attempt to model and achieve something 'out there'. An 'out there' that goes on and changes regardless of what the code says; that changes as people's understandings and discoveries of what matters to them 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.
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.