Maintainer-contributor meet & greets

[tim-schilling]

What do folks think of regular (maybe quarterly) maintainer meet & greets where any established project has 1-2 minutes to explain the project, explain what they are wanting to do and what kind of help they would want. Ideally the audience would be people who are interested in contributing to a project with the hopes of becoming a maintainer.

I think humanizing who a prospective contributor would be working with may make it more compelling to stick with the work. Open source feels a bit daunting at first when it's all new and it's a bunch of strangers.

There is still the hurdle with finding those prospective folks and getting them to show up. On the other hand, we could potentially cut these videos up and hand them off to the maintainers to link to within their contributing docs? I'm not 100% sure, this is a jumping off point.

[ryancheley]

@tim-schilling this sounds like a good idea. Do you think there would be an opportunity to coordinate this with the Djangonaut.spaceprogram at all? If we were able to, I’m not sure if it would make more sense to have this meet and greet at the start or the end of the program. I’m kind of leaning towards the end of the program, but I could see it being beneficial on either side.

[tim-schilling]

I think it's possible. I'd suggest doing it a few weeks to a month after the program ends. There's always a lull that follows it because it's pretty high energy.

[nanorepublica]

I wonder if this could work in an async context? ie a maintainer records a loom video (or similar tech - clarityflow might be an interesting option here but $$), then this get's hosted in a central repo or just on the project itself as an issue?

[tim-schilling]

I think this could be an interesting addition to a suggested practices.

Ido think there's some value in having folks in the same place synchronously because of the connection it creates. It also forces a time limit on the videos too which may be useful to maintainers as a limiter to effort, making it more approachable.

[nanorepublica]

Yes, this would definitely be an addition, getting pre-recorded videos could help the synchronous conversation in terms of keeping to time?

Having the asynchronous would allow for maintainers from disparate timezones when meeting at the time might be impossible.

A side note, I had a similar idea for having a repository of videos that create the human connection between different OSS people.

[bckohan]

Great idea, would participate!

[tim-schilling]

I think the other concern is making sure that a repository is ready to accept new contributors. I would view this as similar to preparing your library for sprints at a DjangoCon. The 2022 DjangoCon US site has a really good post on this topic: https://2022.djangocon.us/news/dev-sprint-leaders/

Maybe we can create a checklist from that as prep work for a maintainer before allowing them to sign up for new contributors?

[ryancheley]

@nanorepublica I really like this idea!

2. Then from this comes a larger idea that we create levels/badges for a repo (think bronze/silver/gold). Going up a level means achieving a defined goal (eg Silver could be ready to accept new contributors).

the hardest past, as always, is being able to determine how to achieve a specific goal. Also, we’d probably need to think about how / if a package slides backward (i.e. they no longer meet the criteria for Silver) and how to handle that. I don’t think it would happen, but it’s better to know how we’re going to deal with it in case it does.

[bckohan]

@nanorepublica @ryancheley

I've been thinking about this too! Seems to me you'd want the criteria to be something you could verify in an automated way. Otherwise I can see the maintenance of it becoming too much of a burden, adding/removing criteria being too difficult and things getting stale. Criteria can be easy things to determine in an automated fashion like "supports all currently supported Django versions" or harder things like "tests against all currently supported Django versions" or even harder things that involve CI security linting or temporal things like "historical record of timely support for new Django versions". You could define levels with absolute thresholds or do a relativistic rating (i.e. Gold == top 5% of all packages, etc). If the goal was to shoot for a certain set of qualities you'd want to do thresholds, but what I like about a relativistic rating scheme is there'd be less bickering about what exactly the criteria should be. Easier to change with the times because adding/removing criteria would have less of an impact. You could measure everything you could possibly think to measure and then have the community vote and determine criteria weights from that.

Seems to me you'd want to run something like this off of djangopackages ultimately, but commons seems like a great place to pilot it.

I do think standards encouragement through badging is the probably the best way to maximize ecosystem quality. Mostly carrot, very little stick. This is also a good way to give devs something more tangible than popularity signals like stars to go off of, especially when comparing alternatives. Its hard for new work to compete with established work, even when its better.

[nanorepublica]

For completion I wrote about this yesterday: https://softwarecrafts.uk/100-words/day-246

[tim-schilling]

@nanorepublica would you like to create a PR to add that link to the django commons content area: https://github.com/django-commons/membership/blob/main/README.md

[nanorepublica]

Done! #137