DjangoCon US 2024 Maintainership Open Space

[tim-schilling]

Below are the notes I took from the open space on package maintainership during DjangoCon US 2024.

---

Wagtail is struggling with the same issue where the community doesn't always update the packages

Docs need a how-to for bumping the latest version

How do we get new people started?

• Need clear tasks started
• Maintainers recognizing they need help
  • Open source governance
    • Thinking about the project beyond bugs
    • Docs
    • How you resolve conflict
    • Can we provide a manual?
    • Consider a transition plan
  • Contributor bot to give others recognition
• How do we transitioning ownership to others
  • When a new PR creates grief, you need some governance

Who can we look to?

• David Lord - collection of disorganized maintainers tasks
• Jazzband

How do you incentivize potential maintainers?

• Build a community, let them know they aren't alone
• Communicate the benefits that can accrue towards you
  • When would you have the opportunity to work on something of that size, complexity and engineering decisions

Have there been any success stories?

• Django crispy forms Carlton -> David

Security concerns:

• It's very unlikely, you should trust others
• Review the code though

How do you communicate with strangers?

• How much energy do you put into it?
• Providing regular communication with people, set expectations
• It's helpful to have more than one maintainer, someone can communicate

How do you manage multiple notifications and focusing on things

• Github has an ability to filter notifications
• Could potentially create email rules to highlight issues

Open PRs and the project has been abandoned

• Is there any community consensus to merge PRs or make changes?
  • Knowing Git is a special, difficult skill
  • How do we balance people needing to spend so much mental energy on projects?
  • How can we help eliminate logistical concerns from new contributors and maintainers?
    • Explicitly tell people these things need to happen so a release can happen

I don't maintain a package

• It's burdensome and seems overwhelming
• There are a lot of expectations on maintainers when creating a package
• I need help from other people and someone to ask help for

What characteristics would be most helpful to maintainers for a group that seeks to exist in that helpful layer

• People are going to be different and need different things
• Ask people if they need help and redirect them to people you know who can help
• How to best operate as a maintainer
  • Attributing contributors

[carltongibson]

Thanks for writing this up @tim-schilling!

One thought that's kept coming back to me from the discussion is that we need to normalise saying I don't know.
That may not sound like much but, particularly for the prospective maintainers who are looking for answers, often the existing maintainers don't really know all the answers, they're just bust doing their thing. Communicating that can take the pressure off of everybody, I think, maybe.

[tim-schilling]

As long as its a suggestion and not a requirement, I'd be good with that. I think ultimately a maintainer is allowed to do what they want with a project. They are spending their time on it and will better understand those cost benefit ratios.

[nanorepublica]

Ah yes, completely! The time it might become a requirement is dependent on the conditions for a package to be migrated to django-commons, current we ask for tests and docs. This could be a way for the scaffolding around those to be bootstrapped more easily. Or if in future CI was a requirement, then having that run the same way would be advantageous.

But generally these will always be about advancement (carrot) and not forcing them on others (stick)

[bckohan]

I'm ambivalent about levying requirements on structure and toolchains. On the one hand I see a great benefit to being able to skip from commons project to commons project and know where all the light switches are, but on the other, I know some of those decisions will be different than the ones I would make and I'd be salty about it 🤣 and it may be a major impediment to bringing older established projects in.

I think its a worthwhile exercise to think about the specific maintenance tasks you'd hope would be made easier by being part of a group effort like this. For me, I think it'd be neat if each time a new version of Python or Django RC was released all django-commons owned projects were automatically tested against it and if the CI passed releases were automatically published to pypi. I think the commitment to github could facilitate automation like this. You could also do cool things like automatically open issues for projects that fail or that have unhandled deprecation warnings surface in their tests.

You also don't have to levy specific toolchain requirements on projects to get the light-switches-are-all-in-the-same-place effect. For instance, you could have a standard Justfile interface for building docs, publishing, installing, testing etc that projects would be required to wrap their tool chains with. That wouldn't be heavy lift and could also be a good task for new contributors to chew on. It'd also make possible cool batch maintenance things like above.

I just feel like there's a lot of maintenance drudgery that I've been wanting to automate but it hasn't really balanced out in the cost benefit analysis if its just for me.

[tim-schilling]

I know some of those decisions will be different than the ones I would make and I'd be salty about it

Agreed.

For me, I think it'd be neat if each time a new version of Python or Django RC was released all django-commons owned projects were automatically tested against it and if the CI passed releases were automatically published to pypi

That's a neat idea. It'd have to be a script that actually manipulated a project's release.yml which we'd probably end up needing to consolidate on naming, etc.

I just feel like there's a lot of maintenance drudgery that I've been wanting to automate but it hasn't really balanced out in the cost benefit analysis if its just for me.

This is a great perspective. There's certainly a benefit to defining scripts that expect a package to be structured in some particular way (filestructure or a justfile). I know Adam Johnson has a few scripts that updates the dozens of packages he maintains. We could roughly do the same. Just slower 😁

[carltongibson]

The "many repos" type approaches are good — there are several options now -- but a lot of effort to set up.

One good carrot would be to have an opt-in pipeline configured. "Do THIS to your repo, and get automatic PRs for new version testing and so on" 🥕