Package maintainers working group #19
Conversation
thibaudcolas
changed the title
active/package-maintainers.md
Outdated
|
|
||
| ## 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.
There was a problem hiding this comment.
Coming back to this – see #28 for consistency across different teams. Personally in the current system I like the idea that different groups can do what works for them, though it would help if the setups were at least consistently documented.
For now for this proposal – I’ve updated to suggest setting up an application form, so the process is less stressful and more predictable for everyone involved.
active/package-maintainers.md
Outdated
| - 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.
I’ve removed this section as I don’t think it’s a crucial part of the proposal. If some working group members wanted to work on metrics that seems fine to me, if none were interested, also fine.
I don’t really see how measuring popularity is a bad thing personally. Those metrics can be misused but that’s the same as any other metric really, you need to understand the limitations and biases of what you’re relying on.
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.
active/package-maintainers.md
Outdated
|
|
||
| ## 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
active/package-maintainers.md
Outdated
| - 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.
active/package-maintainers.md
Outdated
|
|
||
| ### 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.
There was a problem hiding this comment.
I think a 6 to 12 month term should be okay.
There was a problem hiding this comment.
Thank you! I’ve updated to 12 months for now, based on this feedback. 18 months sounds fine too.
active/package-maintainers.md
Outdated
| 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.
There was a problem hiding this comment.
Nice, I’ve added this as-is, makes a lot of sense to me. I also wondered about adding a mention of PEP 772 – Packaging governance process but felt like it was too early.
active/package-maintainers.md
Outdated
|
|
||
| ### 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.)
There was a problem hiding this comment.
Yes please! I added this as-is.
active/package-maintainers.md
Outdated
| - 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.
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.)
Can you explain what you meant by useless bugs? I agree with your point on the UX research efforts I think it really would help the maintainers and users in the long term.
There was a problem hiding this comment.
Thanks - "annoying, useless bugs" (perhaps I should have said "bug reports, patches, and queries") are things like requesting support for Python 2.x environments when maintainers have clearly documented that their minimum Python versions are 3.x, or asking for help with unrelated software problems. Beyond that we might also consider issues that criticize the maintainer or project for a stance they do not even hold, or ill-formed pull requests generated by LLMs.
I am not suggesting that a single annoyed maintainer ought to be able to block someone, after a single mildly unpleasant interaction, and keep them from being able to open an issue with any of the other maintainers in the working group. But when a single user persistently asks many different project maintainers for help or features outside reasonable scopes, I would appreciate a shared warning that pops up, much akin to the "hey, this is this user's first issue ever" or "first interaction with your repository" heads-up message that GitHub currently offers.
There was a problem hiding this comment.
All of this makes sense to me but I chose to leave out those ideas from the proposal. Ultimately once the group is up and running they could decide to take on some of those ideas, or the ones added as examples in the charter, or different things altogether.
Re managing difficulties with contributors, I’ve found it pretty helpful to maintain shared canned / stock responses.
active/package-maintainers.md
Outdated
| 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. |
active/package-maintainers.md
Outdated
|
|
||
| ## 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?
There was a problem hiding this comment.
I’ve left the proposal as-is for now. As the group is defined currently I think membership can be pretty open. I wouldn’t be concerned about this kind of group being too big.
active/package-maintainers.md
Outdated
|
|
||
| ### 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.
active/package-maintainers.md
Outdated
|
|
||
| ### 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.
active/package-maintainers.md
Outdated
|
|
||
| - 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.
There was a problem hiding this comment.
I’ve not seen this as a problem, as it’s pretty simple for packages to follow Django’s deprecation policy. But if it’s a problem, definitely the right thing for this working group’s members to explore.
active/package-maintainers.md
Outdated
| - 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.
active/package-maintainers.md
Outdated
| 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.
There was a problem hiding this comment.
I’ve removed this section as it seems to be a distraction from more important aspects of the proposal. This is just provided as an example of what group members could do, I think there are better places to discuss the relevance of specific metrics.
|
This forum post was opened today and would be relevant to this WG if this PR is resolved and voted on in a timely manner: https://forum.djangoproject.com/t/be-aware-python-packaging-governance-discussion/38756 |
|
Hey all, what is left needed to proceed with this PR? Also, I'd like to express my interest for being a member and I have some time that I already reserved for open source projects - I can try to help if any leg work is required. |
|
I am also interested. Is all we need to move forward a chair? I can't in good conscience commit to that by myself at the moment, but if there was someone willing to split the burden as a co-chair it becomes much more plausible for me. |
|
From my experience of getting #23 merged, the lack of chair/co-chair definitely an issue and requires someone to step up. As well as getting a few other members. Second to this would be to take ownership of this PR and decide what to do with with the comments made and get the document in a state ready that the board could discuss it one meeting, then vote on it the next (assuming no issues) |
|
Do we have a clear understanding of the chair/co-chair's responsibilities? I saw a similar question asked here but we don't have an answer yet. My current understanding of responsibilities is based on the group's mission and other WGs' past actions. I know that numerous volunteer contributors in the community have a much deeper and broader understanding of package maintenance. Still, having the time and energy is vital, and I'm currently willing to allocate them. I can also help as co-chair if there is anyone else who is better suited for the chair position. |
|
It seems like the biggest challenge to work groups functioning is the availability and time of people to do the logistical work. Yes, a they should understand how to create a python package and the various steps of maintaining it, but they don't need to be the experts on it. In regards to technical good practices and this working group defining them... A person should be able to rely on the community for support. If you craft well scoped questions about package maintenance, it should be possible to get the community to align on what are good practices. From there, it becomes evaluating a few different approaches, documenting what the decision factors were. I suspect most experienced engineers would be capable of that. Also, it serves as a good reason to set up calls with various people who maintain lots of packages or have done an excellent job of maintaining packages. I'm sure they'd be willing to meet with another community member for the community's sake. @ulgens and @bckohan, I think it's fair to assume that this WG is up for grabs. If you two are interested in collaborating to lead on it, I'd suggest setting up some time for both of you to discuss your intentions, availability and next steps. If you find you're in alignment, it sounds like we may have our co-chairs 😁 |
|
We discussed this during our weekly DSF office hours, and we might need a few champions (volunteer chair, co-chair, etc) to take this to the finish line. I think @thibaudcolas mentioned he had a lot on his plate and didn't want to be a blocker. Is it possible to close this PR or commit it in a draft folder/state so others can pick it up and continue the work? I'm not sure if that's a better solution since there are limits to how many people can work off of a branch/private fork. |
|
Yes! It’s very much up for grabs! Discussing this with @jefftriplett, we’re going to try merging the proposal to a new @ulgens @bckohan if you want to take this on please go ahead with making a new PR! Feel free to either make it as updates to the newly-merged doc in I’ve done one quick update with everyone’s feedback to date, will make sure to reply to comments to explain the changes. |
|
I’ve replied to all the comments, and will leave this there now :) Please reach out on Slack / Discord / Django forum / email if you have any questions, I’m still very much interested in packaging and actively work in this space, just don’t have capacity for more working groups.
This is for the group’s charter to define! For now I’ve added the following:
|
Edit: this proposal is merged as a draft. There is no approved working group currently. See latest updates.
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!