pycon-mentored-sprints / organisational

🗂 All things related to the organisation of the sprints
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Enhanced mentor support #43

Open trallard opened 4 years ago

trallard commented 4 years ago

Over at our last event, we realised that there were some nuances and particular challenges faced due to the online nature.

I would like to explore how we can better support mentoring teams. Some common issues folks run into sprints and on virtual sprints are:

@Zac-HD creates a meta issue for sprints: https://github.com/HypothesisWorks/hypothesis/issues/2510 so maybe requesting this would make the onboarding easier This could be pinned or set as the Discord project's description

GitHub Codespaces is not yet available for the wider public but when this is it might be worth exploring this and encourage projects to use this to help with the local environment issues

Please add ideas and suggestions here

trallard commented 4 years ago

@pycon-mentored-sprints/organisers

Zac-HD commented 4 years ago

More of a general reflection than a suggestion: making a project accessible for new contributors is a hard UX problem.

For someone who isn't comfortable with git or Python dev tools, every single step is going to be slow and probably stressful... the best I've done is a cross-platform tox setup. Designing your build system to be used by absolute beginners with unknown environments is a nontrivial investment in preparation, but does help a lot.

Finding suitable issues is way worse; to be tractable they have to be small/easy/low-context and those get fixed very quickly. I usually end up with a document of 'issue ideas' starting a few months before, and write them up on GitHub the week of the sprint. This is a lot more work than just fixing them, obviously, since I'm 'growing low-hanging fruit' on mature projects or starting new projects to suit.

There's no substitute for contributor-focussed docs, ample comments, etc.; but I've found it useful to carve out small chunks of work that don't require contributors to know about the rest of the project - on the level of "fill out this function, the signature and docstring are in the issue". At least for me, mentored sprints are much more about the skills of contributing code to open source projects, not about the skills of programming.

So, some checklist questions for maintainer-mentors: