Package maintainers working group #19
Conversation
thibaudcolas
changed the title
|
|
||
| ## How to join | ||
|
|
||
| To join, members must express an interest in the #packages channel of the [Django Discord server](https://discord.gg/xcRH6mN4fa), or reach out to a current group member. |
There was a problem hiding this comment.
I think a decision should be made if the Discord or the Forum is the "official" place to announce such things. I'm on Discord and sort-of like it, but I think the Forum might be a better place for this, because it's easier to refer back to eventual discussion happening later. It could also give some guidance to interested people since they can see other people's introduction posts.
There was a problem hiding this comment.
Do you mean a decision as far as all working groups ever, or this group specifically? I’d prefer to use a forum as well for the reasons you stated. But didn’t find an appropriate category and was hesitant to have to resolve that (while on Discord, there’s a clear related channel).
Could you recommend a way to do this well on the forum? As in a category or perhaps how you’d see this kind of post working
There was a problem hiding this comment.
My comment was not about htis working group specifically. I'm just not a big fan of chat-based communication when you should be able to refer to it later. It's really good for chatting, spamming, community building etc. but maybe the working groups would benefit from a more formal space.
I know the discussions about the forum and how official it is, and I unfortunately don't really have a recommendation.
There was a problem hiding this comment.
Expressing interest to join isn't necessarily a thing that is worth archival. Joining on the other hand is probably something of note.
| - Facilitating participation in mentoring programs such as [Google Summer of Code](https://summerofcode.withgoogle.com/) or [Djangonaut Space](https://djangonaut.space/). | ||
| - Providing support for tasks requiring very specific expertise, like funding avenues or vulnerability reports handling. | ||
|
|
||
| #### Review the package ecosystem |
There was a problem hiding this comment.
That's certainly an interesting section. Establishing metrics is hard, and even harder once people start to game them. Maybe something to consider (or not).
There was a problem hiding this comment.
It’s a personal interest of mine but if you think it can be a distraction I’m happy to take this out? From my perspective it’s good to aspire to make decisions based on data, but it’s not a must.
Here is an example for ref, a review of Wagtail packages’ compatibility with different Wagtail versions.
There was a problem hiding this comment.
I worry a bit that this could be seen as a way to give some of the "obvious" Django packages even more visibility. This has more to do with the fact that the packages I'm using most of the time are a bit more niche than they maybe should be so I'm a bit wary. Just as an example, counting releases or contributors doesn't necessarily say a lot when different packages are in the same space but do not have the same design goals (e.g. django CMS vs. django-content-editor)
I think there's a lot of value in curating packages and making lists. https://djangopackages.org/ exists already, and I'm sure that the packaging WG could contribute in some way to the same space. I wouldn't want you to remove this, but I do have a few concerns. Maybe joining the group would be a good way to help steer the boat... :-)
There was a problem hiding this comment.
I think choice of metrics would be important to avoid the feedback loop of popularity. I don't normally care about how many people are using a package as much as I do about the flow of PRs/commits/merges as a straw main for whether a package is maintained and the frequency of releases to understand how frequently I should expect to have to set aside time to do upgrades.
There was a problem hiding this comment.
Thank you for the feedback @matthiask! All makes sense to me. I’ll keep it all open as other people start reviewing and want to share thoughts too, and if there’s no further discussions apply the necessary changes in a few days.
Re Django Commons – yes, I’d really hope the work of this WG would help support Django Commons. Both in the early stages and long-term.
|
|
||
| ## How to join | ||
|
|
||
| To join, members must express an interest in the #packages channel of the [Django Discord server](https://discord.gg/xcRH6mN4fa), or reach out to a current group member. |
There was a problem hiding this comment.
Do you mean a decision as far as all working groups ever, or this group specifically? I’d prefer to use a forum as well for the reasons you stated. But didn’t find an appropriate category and was hesitant to have to resolve that (while on Discord, there’s a clear related channel).
Could you recommend a way to do this well on the forum? As in a category or perhaps how you’d see this kind of post working
| - Facilitating participation in mentoring programs such as [Google Summer of Code](https://summerofcode.withgoogle.com/) or [Djangonaut Space](https://djangonaut.space/). | ||
| - Providing support for tasks requiring very specific expertise, like funding avenues or vulnerability reports handling. | ||
|
|
||
| #### Review the package ecosystem |
There was a problem hiding this comment.
It’s a personal interest of mine but if you think it can be a distraction I’m happy to take this out? From my perspective it’s good to aspire to make decisions based on data, but it’s not a must.
Here is an example for ref, a review of Wagtail packages’ compatibility with different Wagtail versions.
|
I think there could be a lot of value in developing best practices in managing orgs and ci. I've been a package maintainer in a number of ecosystems over the years and the platforms are constantly changing. Lessons are constantly being learned. One I've recently ran into on GH actions and a large org I participate in is limits on parallel jobs at an organization level creating back pressure in the build queue that sometimes leads to waiting for hours or days for a job to run. I'm sure the org maintainers could reach out to GH to get those limits increased. Ultimately though that is at VI providers discretion or comes with the payment of $. I think there is a lot to explore to find a good balance between central control and scale of an organization and OSS platform offering limits and building guidelines around that based on what works with input from a large group of packagers would be nice. |
Co-authored-by: Matthias Kestenholz <[email protected]>
|
I'll try to have more detailed feedback at some point, but one initial suggestion jumps out: I would love for this group's charter to explicitly include making recommendations to the DSF Board about how it might spend money/time/resources supporting the package ecosystem. For me, one of the best outcomes would be a tangible list of projects the DSF could embark on or support that could help improve the ecosystem. |
There was a problem hiding this comment.
Looks like a good proposal to me! I'm coming to this less familiar with Django package maintainers' needs specifically but can share some thoughts based on my work with volunteer maintainers of open source projects more generally and the support they often need.
|
|
||
| ### Membership terms | ||
|
|
||
| Members join the group for a 6-month term. At the end of this term, they need to opt into staying involved to keep being a member of the group. |
There was a problem hiding this comment.
I suggest that membership terms be fixed (perhaps 18 months) but renewable. In other words, a member signs up for an 18-month term, and toward the end of that term, is asked whether they'd like to renew or leave. This provides a built-in reminder that it's okay to leave if the responsibilities are proving onerous.
I suggest an 18 month duration because that seems long enough for a person to get a strong sense of what the group's like, but short enough to help take care of overloaded maintainers.
| The group could also work on more ambitious projects to advance the state of the art in Django package maintenance. For example: | ||
|
|
||
| - A standard to call for contributors, maintainers, or request funding via pip or a manage.py check | ||
| - Distributed code review for Django packages (see for example [crev](https://github.com/crev-dev/crev/)) |
There was a problem hiding this comment.
And participation in convenings such as PackagingCon, Upstream, etc.
|
|
||
| ### Group activities | ||
|
|
||
| As an illustration of the group’s remit, here are possible activities members could take part in. |
There was a problem hiding this comment.
Maintainers often benefit from trainings and workshops in skills and topics such as setting and enforcing deprecation policies, doing UX research, writing roadmaps, researching and applying for grants, and so on. Holding such workshops could be one of this WG's activities, if appropriate budget is available or if volunteer facilitators step up to lead them. (I'm biased here in that my consultancy does provide these kinds of workshops.)
| - Sharing calls for new package maintainers | ||
| - Coordinating trusted volunteer open source “roadies” familiar with package ownership transfers. | ||
| - Facilitating participation in mentoring programs such as [Google Summer of Code](https://summerofcode.withgoogle.com/) or [Djangonaut Space](https://djangonaut.space/). | ||
| - Providing support for tasks requiring very specific expertise, like funding avenues or vulnerability reports handling. |
There was a problem hiding this comment.
Some further ideas for what the "Facilitate community-driven maintenance" activity could include:
- A shared blocklist, or at least a warning flag. Every maintainer seems to have to learn for themselves about particular users who consistently file annoying, useless bugs and do not otherwise productively contribute. Could there be a shared blocklist to help with this?
- Boilerplate policies. Beyond licenses and codes of conduct, maintainers could use a shared set of customizable policies on deprecation, security reporting, release announcement, vendoring, user support, contributing guidelines, testing, architectural change, and data privacy. The WG could also share new issue templates, and replies to reuse for common misunderstandings (like "you'll need to rebase" or "we're not able to prioritize this right now but a patch or a donation could change that").
- Shared user experience research efforts. Pool funds and invest in UX research for a suite of tools that people often use together, and learn surprising and helpful things that help all package maintainers improve their projects' UX. (Example: what pip did.)
(I further discuss these ideas in this blog post.)
There was a problem hiding this comment.
I'm not a big fan of blocklists or warning flags for contributors. Maintaining and growing community is one of the biggest challenges for open source communities in my experience. New participants might be learning or may genuinely be a troll, but even in those cases they are engaging. Rather than block them I'd lean toward a policy of educating and including them. I'd rather get a bug report than not, even if it's not a real bug it may be a UX design issue. Even if the reporter is upset and it's coming through in their tone, I'd rather get the bug report than not. I can choose to ignore people's tone and frustration. Although I do agree there need to be rules in regard to abusive language and personal attacks... but those should be listed up front and moderation steps clearly outlined and applied consistently.
| Group members can liaise with organizations dedicated to sharing maintenance efforts, such as [Jazzband](https://jazzband.co/), [Wagtail Nest](https://github.com/wagtail-nest), or [Django Commons](https://github.com/django-commons). Or work directly with packages in need of new maintainers to find new candidates. This can involve: | ||
|
|
||
| - Sharing calls for new package maintainers | ||
| - Coordinating trusted volunteer open source “roadies” familiar with package ownership transfers. |
There was a problem hiding this comment.
In case it's helpful, I wrote a bit recently about some ways to check for trustworthiness in volunteer candidates for maintainership. A WG could do more than an individual maintainer could in more thoroughly checking candidates, and that could make an individual maintainer feel more okay about letting a vetted volunteer co-maintain their package.
|
I didn't know this was a thing until @tim-schilling just told me about it. Since I'm a Django Packages maintainer, I would like to be along for the ride, even if it's more from a position of learning so we can adjust how we score/rank packages. |
Now ready for public feedback. And we need more group members for this viable, including a Chair and Co-Chair :) If anyone’s interested please review and comment here!
For anyone reviewing this, here are relevant discussion threads this proposal is based on:
Additionally this is based on my experience of community-driven package maintenance with @wagtail and @wagtail-nest, plans to create a Wagtail packaging team, and discussions about Django Commons with @tim-schilling. Thank you Tim for the early feedback!