Package maintainers working group #19
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,126 @@ | ||
| # Package Maintainers Working Group | ||
|
|
||
| ## Scope of responsibilities | ||
|
|
||
| This group supports package maintainers in the Django ecosystem. | ||
| Packages are an important part of the experience of using Django, and their maintainers can benefit from different forms of support than Django contributors and users. | ||
|
|
||
| The goals of the group are: | ||
|
|
||
| - To facilitate discussions and share knowledge about common issues or tasks in package maintenance. | ||
| - To coordinate efforts to improve the health and quality of packages in the Django ecosystem. | ||
| - To advocate for the needs of package maintainers in the Django community. | ||
|
|
||
| This is a broad definition of the group’s remit. | ||
| Current members select specific activities to undertake based on their interests and availability. | ||
| See [Group activities](#group-activities) for examples of what the group may choose to do. | ||
|
|
||
| ### Delegated responsibilities | ||
|
|
||
| With regards to Django Software Foundation responsibilities and resources, the group operates with: | ||
|
|
||
| - No special powers delegated by the board to the group. | ||
| - No specific "Django Software Foundation" actions the group can take directly. | ||
|
|
||
| Any request for funding or resources are made via existing processes outside of this group. | ||
| This can be revised in the future as and when the group identifies specific recurring needs. | ||
|
|
||
| ## Membership | ||
|
|
||
| - Chair: You? | ||
| - Co-Chair: You? | ||
| - Board Liaison (must be an active Board member; may be the same as Chair/Co-Chair): Thibaud Colas | ||
| - Other members: | ||
| - You? | ||
|
|
||
| ## Eligibility | ||
|
|
||
| Membership is open to all Individual Members of the Django Software Foundation. | ||
|
|
||
| ## 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. |
||
|
|
||
| Candidates will be invited to an upcoming Working Group meeting to discuss their interest and potential contributions, after which they will be voted in by current group members (50%+1). | ||
|
|
||
| Members will be selected for the group based on their interest in the group’s goals and ability to contribute to them. | ||
|
|
||
| ### 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. |
||
|
|
||
| If any member wishes to leave the group before the end of their term, they can do so without a vote. | ||
|
|
||
| Members can propose a vote on removing a member from the working group. This needs 50%+1 agreement. | ||
|
|
||
| ## Budget | ||
|
|
||
| No allocated budget, the group makes ad-hoc requests for funding or resources as needed. | ||
|
|
||
| ## Group communications | ||
|
|
||
| The group communicates asynchronously via: | ||
|
|
||
| - The public `#packages` channel on the Django Discord server. | ||
| - Appropriate public sections of the [Django Forum](https://forum.djangoproject.com/). | ||
| - GitHub issues and pull requests in a new `django/package-maintainers-wg` repository. | ||
| - Collaborative documents set up in the Django Software Foundation’s Google Workspace. | ||
| - A new private #package-maintainers-wg` channel on the Django Discord server for internal discussions. | ||
|
|
||
| The group will also offer office hours for package maintainers every month via a video call. | ||
|
|
||
| ## Reporting | ||
|
|
||
| The group will share highlights from current activities on a monthly basis via a forum post. | ||
|
|
||
| ## Appendix | ||
|
|
||
| ### 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. What about sprints?
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. |
||
|
|
||
| #### Support Django version compatibility efforts | ||
|
|
||
| As Django regularly releases new versions, it’s an ongoing effort to ensure packages are compatible with new releases. | ||
|
|
||
| Group members can support maintainers in this effort by: | ||
|
|
||
| - 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. |
||
| - Proposing additions to the Django release notes with recommendations on how to handle deprecations. | ||
|
|
||
thibaudcolas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| #### Share packaging best practices | ||
|
|
||
| The group can work on create, maintain, or curate best practices for Django package maintainers. For example, the official [Advanced tutorial: How to write reusable apps](https://docs.djangoproject.com/en/5.0/intro/reusable-apps/), or packaging-focused sections on third-party resources like [awesome-django](https://github.com/wsvincent/awesome-django). | ||
|
|
||
| Those best practices can cover aspects like: | ||
|
|
||
| - Documentation approaches and tools | ||
| - Use of the `django_` prefix for app names (see [Change reusable apps naming recommendation](https://forum.djangoproject.com/t/change-reusable-apps-naming-recommendation/25233)). | ||
| - Recommended Python, Django, browser, operating system support policies to align with those of Django itself. | ||
| - Tooling, for example how to set up Continuous Integration for Django packages. | ||
|
|
||
| #### Facilitate community-driven maintenance | ||
|
|
||
| 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. |
||
| - 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:
(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. |
||
|
|
||
| #### 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. |
||
|
|
||
| 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. |
||
| - [Django Developers Survey](https://lp.jetbrains.com/django-developer-survey-2023/) ([2022](https://lp.jetbrains.com/django-developer-survey-2022/)) questions relevant to package maintenance | ||
|
|
||
| ### Advance the state of the art | ||
|
|
||
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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?