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.
Yeah, I'd be interested in metrics mostly as a way to avoid the popularity feedback loop. Without naming names I can think of a few packages I use that have <20 stars but that are better designed, keep up with Django updates better, and have better/more extensive tests than alternatives that have >1000 stars. Stars and other popularity metrics are mostly used as a proxy for the actual metrics people care about and in some cases are increasing the technical debt of the ecosystem.
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 the CI 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.
There was a problem hiding this comment.
I agree with the principles and the method here, but I also agree that 6-month term is a bit short. I'd recommend 12, a full calendar year.
| 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.
There was a problem hiding this comment.
+1 for not having a blacklist. I think that's a bit too harsh of a political action, and creates fear around the community instead the good feelings we all want to share.
| 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. |
|
|
||
| ## Eligibility | ||
|
|
||
| Membership is open to all Individual Members of the Django Software Foundation. |
There was a problem hiding this comment.
About this membership requirement,
The only other WG I could find with an individual membership requirement is Social Media WG. For that case, I think it makes sense because of the particular working topic, but I don't think it should be a requirement here.
DSF Individual Memberships page says
Individual Members are appointed by the DSF in recognition of their contribution to the DSF's mission of advancing and promoting Django, protecting the framework's long-term viability, and advancing the state of the art in web development.
Contribution to the DSF's mission takes many forms. Here are some non-exhaustive examples of the categories of work that might qualify:
- ...
- Serving on a DSF Working Group.
If serving on a WG is a soft requirement for a membership, having that condition reversed sounds counterintuitive.
The more inclusive requirement would be, at least one of:
- Having open source contribution/maintenance experience
- Having team lead/management experience
- Having enough professional experience
There was a problem hiding this comment.
I feel open source maintainership experience is very important to contribute productively to a discussion about package maintainer best practices. There are things you will experience as a maintainer and release manager that you will never experience as solely a contributor. Maybe that should be a requirement for chair/co-chair?
There was a problem hiding this comment.
It depends. Does the Chair/co-chair have some extra ability associated with the role? Or are they the people managing the logistics of the group? If it's the latter, I think the requirement is anyone who wants to do the job. If it's the former, I'm on the fence. Well as long as the group has people in it with that experience 😁
There was a problem hiding this comment.
@tim-schilling I see your point. I was assuming the chair/co-chairs would have some sort of responsibility to resolve tie votes on recommendations or something of the sort that would require technical expertise. So maybe it makes sense to clarify the role and responsibilities of the chairs?
|
|
||
| ### 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 agree with the principles and the method here, but I also agree that 6-month term is a bit short. I'd recommend 12, a full calendar year.
|
|
||
| ### 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.
What about sprints?
Basically, a Django sprint is an excuse for people to focus their undivided attention, for a set time frame, on improving Django. It's a focused, scheduled effort to test, fix bugs, add new features and improve documentation.
https://code.djangoproject.com/wiki/Sprints
If you read "on improving Django" as "on improving Django and its ecosystem of tools/packages", I think it matches the WG's goal perfectly.
|
|
||
| - Creating a shared calendar with Django release dates and deadlines. | ||
| - Creating communication channels for package maintainers to coordinate compatibility changes for a specific release. | ||
| - Recommending appropriate automation, such as [django-upgrade](https://github.com/adamchainz/django-upgrade) or how to set up Django pre-releases in Continuous Integration. |
There was a problem hiding this comment.
What about deprecations? I see lots of packages trying to maintain for EOL - insecure versions of Django, saying that not everyone always update (I think they should but it's a topic for another discussion 😄 ) A central "authority" that informs and warns maintainers about not using old versions of Django could be beneficial.
| - 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.
+1 for not having a blacklist. I think that's a bit too harsh of a political action, and creates fear around the community instead the good feelings we all want to share.
| The group can organize periodic reviews of the package ecosystem to assess its health, for other efforts to make more informed decisions. | ||
|
|
||
| - Statistics on compatible Django / Python versions, or use of type annotations | ||
| - Package health and popularity metrics |
There was a problem hiding this comment.
+1 for package health, -1 for popularity metrics. Having PyPI download counts could be a neutral middle way of saying "people use this" (which still doesn't directly correlate to value), but anything else like Github stars or contributor numbers would harm the packages that doesn't need to increse those numbers to be beneficial.
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!