One thing to note here: In my experience, a lot of the work for making a good and successful sprint happens before the sprint itself, so even if you can't or don't want to come and mentor at this particular sprint, you could still be enormously helpful.

A big problem with sprints is figuring out what to work on and matching programmer skill level to the issues where they can have the highest impact. To that end, I recommend that for any projects that want to participate in the sprint should make extensive use of issue labels or something equivalent. The most important things to label:

1. Good first issue: Things that someone with no knowledge of the project and who has never made a PR before could pick up and finish relatively quickly.
2. Sprint-friendly: Things that someone who has done open source before could reasonably finish in under, say, 8 hours.
3. Blocked issues: sprinters can spend a lot of time digging into an issue only to realize that it's blocked on a PEP or a third party package or a high-level decision. Best to label them in red so that people don't waste their time.

I would also recommend at least some sort of t-shirt sizing for issues, so that people get a sense of how much they are biting off when they pick one of these issues.

Another very useful contribution would be actually raising specific issues. If you've got some simple fixes you were planning to put in, or some minor issue with the documentation that you know about, but you haven't raised an issue, now is the time to start coming up with small, discrete packages of work that can be accomplished in a single sprint, even for trivial things. Look at your test coverage and make issues like, "add tests for function X" and "add documentation to module X". A lot of sprinters will be want to simply pick something from a list and start working on it (and coordinate with others as to who works on what), so turning vague tasks like "improve documentation" and "improve tests" into specific tasks would be an enormous benefit.

One nice thing about this work is that it's still useful after the sprint is done - even the most successful sprint will only make a small dent in the work there is to be done. Having your issues triaged and categorized and easy for new contributors to jump on will be useful not only for future sprints but for the new contributors who, empowered by the sprints, want to do more work on the package and also for people who come across the project not as part of a sprint and want to contribute.

Best,

Paul

Hi all,

As mentioned previously in a distutils-sig thread [0], Bloomberg is
hosting an "open source weekend" development sprint focusing on tools
in the PyPA ecosystem. The events are free and open to the public.

In addition, Bloomberg has offered to arrange travel for up to 6
"mentors" to attend the event and lend expertise, (preferably 3 in
each location, but this is flexible).

If you are interested in being a mentor and DO NOT require travel assistance:

1. Reply to this thread indicating that you'd like to be a mentor
2. RSVP to the respective event below
3. Attend the event!

If you are interested in being a mentor and DO require travel assistance:

1. Reply to this thread indicating that you'd like to be a mentor
2. RSVP to the respective event below
3. Email me with the dates, location, and where you will be traveling from
4. DO NOT book travel or accommodations yourself. Bloomberg is unable
to directly reimburse mentors, and will book travel for you instead.
5. I will follow up with more details

To RSVP and see more details about the event, follow the links below:

NYC:
10/27: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/new-york-city/58377
10/28: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/new-york-city/58382

LON
10/27: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/london/58402
10/28: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/london/58403

Any questions, please respond in this thread!

Thanks!
D.

[0] https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/UKMJ7QRBFASA5EPY54QQWO6JJNYPGISO/
_______________________________________________
PyPA-Committers mailing list -- pypa-committers@python.org
To unsubscribe send an email to pypa-committers-leave@python.org
https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/