Implement Jazzband guidelines for django-newsletter

[jazzband-bot]

This issue tracks the implementation of the Jazzband guidelines for the project django-newsletter

It was initiated by @dokterbob who was automatically assigned in addition to the Jazzband roadies.

See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

Feel free to ping a Jazzband roadie if you have any question.

TODOs

• Fix all links in the docs (and README file etc) from old to new repo
• Add the Jazzband badge to the README file
• Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
• Check if continuous testing works (e.g. Travis CI, CircleCI, AppVeyor, etc)
• Check if test coverage services work (e.g. Coveralls, Codecov, etc)
• Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/django-newsletter/collaboration/)
• Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-newsletter/users/)
• Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-newsletter/integrations/)
• Fix project URL in GitHub project description
• Review project if other services are used and port them to Jazzband
• Decide who is project lead for the project (if at all)
• Set up CI for Jazzband project releases if needed and open ticket if yes

Project details

Description	An email newsletter application for the Django web application framework, including an extended admin interface, web (un)subscription, dynamic e-mail templates, an archive and HTML email support.
Homepage
Stargazers	540
Open issues	33
Forks	158
Default branch	master
Is a fork	False
Has Wiki	False
Has Pages	False

[dokterbob]

@jezdez Long time no seen! Thanks for setting up this Jazzband thing - it’s a great way to keep projects and the community alive!

As I’ve not been very active in the Django community for a long while, I’ve decided to transfer my baby, ‘django-newsletter’ to the Jazzband. Must admit, it’s an excellent idea to make the maintenance less dependent on one person! There’s pull requests I haven’t tended to in months..

That having been said, I am realising that giving full write access to the ~ 800 members of this band to my repo has the risk of dissolving the responsibilty so much that it might actually reduce participation. I’ve noticed there’s already separate teams for pip-tools and Grumpy - would you be okay creating a separate team for django-newsletter as well?

I am very much willing to give access to any members of the Jazzband that ask for it, there are several contributors that have already facilitated the maintenance of the package, but I feel that if 800 people share this load, none of them might feel a final sense of responsibility. However, in the case of permanent of temporary unavailability of the current maintainers, other members of the jazzband, or even the band as a whole might take over so the project would not be abandoned.

[jezdez]

Hey @dokterbob! Thanks for reaching out to me, I appreciate your words regarding Jazzband. It's my hope that by lowering the barriers to maintenance it basically becomes less of a burden for those that started projects and allow more people to contribute.

For that reason Jazzband uses an unusual practice in the age of "social coding", allowing everyone to participate who is willing since it's my experience that there are more people willing, than not. While it's understandable that GitHub itself can't be "open by default", Jazzband has a much narrower scope for Python projects. Those projects share best practices that are much easier to partially or fully automate. E.g. the way we've come to set up continuous integration with the Jazzband package index allows us to reduce the risk of accidental or malicious releases to PyPI without prior review by "project leads". Similarly we've standardized loosely on other aspects like documentation and code quality testing. All with the single goal to reduce the friction we've all seen when either maintaining an own or contributing to a 3rd party project.

Jazzband is indeed growing and has reached a size that I did not expect to happen when I started it 5 years ago. So your concern about a potential lack of responsibility is certainly there and I've been monitoring for it for a while. I can anecdotally say though that while some members may leave the organization again (e.g. in total ~1100 people joined in the past, ~800 remain), and while there are many inactive members, the risk of loss of contributors is a bigger threat to long-term maintainability than an open-door policy. In fact I've seen many people start to contribute in earnest for the first time because of having the same permission level as everyone else. It is also encouraging to new contributors and reduces stress for original authors. In other words, it's okay to not maintain something alone.

So I strongly believe it's essential to keep the "door open" for new people who finding interest, time and energy to contribute to one or more projects. We have all different reasons why we're doing this of course, but the end result is the same.

As such I'm afraid that reducing the number of people that would have access to django-newsletter would be contrary to a very central idea of Jazzband and I must decline your wish for now. That said, creating a GitHub team to simplify coordination and communication is certainly fine, in fact it's been a long term feature request to add teams for each project automatically so people may "join" them via the website or GitHub and get a bit more updates (or other optional features) and ease communication via GitHub's discussion system. Alas I haven't finalized the feature (some progress e.g. jazzband/website#489).

I would like to encourage you to try out the open model, but I would fully understand if you were to decide to transfer the repo back. Please let me know either way. Thank you!

[claudep]

FWIW, I'm with jezdez here. Having maintainers who care is important, but I don't think that's related to the number of people having access to the repo.

[dokterbob]

Thanks for the feedback @jezdez and @claudep. I am not too worried for malicious behaviour so having many people with access is good.

However, I would really appreciate if you could manually create us a group to facilitate the communication, basically to know who's currently actively involved, to be able to reach out to them and, perhaps, also to facilitate updates. I guess the main thing is, whom of these 800 people might I contact if I have questions - rather than it just being myself as being project lead.

This is how we've been functioning in the past, doing @-mentions for active contributors to see if they have an opinion about things. If we can @-mention the team, it might facilitate things.

What do you think?

[frennkie]

I opened PRs for the first three ToDos. For the other ToDos account acccess (Github, RTD, PyPI) is needed.

[dokterbob]

Thanks @frennkie ! I'll see if I can tend to the other issues as soon as I can (next rainy day, probably, later this week :p)

[dokterbob]

Ref: #353

I'm rather saddened to see that, somehow, my rights to change settings in the repo have been revoked and would very much appreciate having them back. I don't feel all admin rights reside with a single person resolve the issues that the jazzband was created to solve. Hope this was unintended. @jezdez

[dokterbob]

In addition, I would propose a co-leadership of the project between myself and @frennkie.

[jezdez]

@dokterbob Sadly the GitHub permission system doesn't provide a way to select only certain permissions, and there are only basically write and maintain permission levels: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

I know that "maintain" seems sensible for project leads in most of the cases, but sadly having the ability to act on security or conduct issues means that I can't give you access to the settings back. I hope you understand that it's a legitimate concern in an open GitHub organization such as this and forgive the extra steps to open tickets for settings updates. Obviously if you disagree (which I would totally understand) I'm happy to transfer the repo back to you until we can find a better way of dealing with this. Ideas are welcome to handle it better btw!

Your feedback regarding the bus factor of the roadies is spot-on, it's being tracked in jazzband/help#196.

[bittner]

@dokterbob Having permissions revoked on editing Settings is something you get used to. I co-maintain django-analytical and it felt weird not be allowed to inspect, let alone change settings related to things you care about.

But, yeah, now it's all about reviewing PRs and engage in & triage issues. At least, I can create feature branches directly on the repository (on any Jazzband repository, I guess), so I don't need to fork into my personal namespace. But I can get the changes merged only if I manage to have at least one Jazzband member review and accept the PR.

It's actually a good system. Having a lot of automation in place and a uniform approach to managing similar projects. It's nice. 🧸