feature request. change the 'list my other subscriptions' to also report if the other subscriptions are enabled or disabled
| Affects | Status | Importance | Assigned to | Milestone | ||
|---|---|---|---|---|---|---|
| GNU Mailman | Status tracked in 3.0 | |||||
| 2.1 |
Fix Released
|
Undecided
|
Unassigned | |||
| 3.0 |
Triaged
|
Low
|
Mark Sapiro | |||
Bug Description
I have a large number of subscriptions to mailing lists on python.org. Delivery is disabled on most of them. This is exactly how I want it -- I don't want to keep up with the day to day matters of the list, but I do want to be able to re-anable delivery and discuss things there should the need arise without having to create a new account.
However, when I go on vacation, what I want to do is also disable a few high volume lists that I normally want
to read every day. Thus what I would really like to see is which lists are currently enabled, so I can decide
which one(s) if any I want to disable for the vacation. I don't want to disable the low-volume ones. Given
that I am going to have to re-enable the lists I want to read when I get back one by one, I want the number of lists that get temporarily disabled to be as small as possible. And I want to be able to email me the short list of what they were so I can remember which ones to turn on again.
Interestingly, the text of the message indicates a usability misunderstanding, and a grammatical error. The text reads:
You can view a list of all the other mailing lists at python.org for which you are a member.
Use this if you want to make the same membership option changes to this other subscriptions.
It should be 'these other subscriptions'.
And the people who want to make the same membership option changes to all the lists they are subscribed to on a site are precisely the users who don't need the feature. They can blindly go off and change things
globally. If the number of lists they are subscribed to on that site is 1 -- i.e. they do not have any other subscriptions -- then saying to do things globally will do no harm.
The reason you might want to look is to check because you might _not_ want to do things globally. And once you are dealing with that case, things you do not want to do globally, then of course you want to see the
current settings that you have. But for my use case, all I care about is changing delivery status. All the
other options I either never change, or want to change globally. I suspect that most people use mailing
lists in this way, where the only thing they need to worry about is changes due to vacation, but I haven't
conducted any polls to test this theory.
This request sent to the tracker because the automated mail I recevied when some moderator refused
to accept my mail to mailman-dev with this feature request, with the message 'why don't you just disable delivery globally and then reset them globally when you return' said that this was the place for feature requests and not the mailing list. Hope this request is clearer and explains why globally disabling is not
what I want to do.
Thank you
| Mark Sapiro (msapiro) wrote | #1 |
| Changed in mailman: | |
| importance: | Undecided → Wishlist |
| tags: | added: mailman3 |
| Mark Sapiro (msapiro) wrote | #2 |
| Mark Sapiro (msapiro) wrote | #3 |
| Changed in mailman: | |
| assignee: | nobody → Mark Sapiro (msapiro) |
| milestone: | none → 2.1.15 |
| status: | New → Fix Committed |
| Changed in mailman: | |
| status: | Fix Committed → Fix Released |
| status: | Fix Released → Fix Committed |
| no longer affects: | mailman/2.2 |
| Abhilash Raj (raj-abhilash1) wrote | #4 |
Thank you for the request and the detailed explanation of the requirement. It would be fairly simple to implement this in Mailman 2.1, but I hesitate to do so because it opens a can of worms which is not so easy to deal with. If this were implemented, I see more requests with equal justification for displaying digest mode, and possibly other settings.
I am attaching a patch which will italicize those list names for which delivery is disabled, but as I said, I hesitate to actually implement it. I understand the patch does you no good because you want it on python.org, but even if I released it, there's no telling when it would be installed (python.org is currently two releases behind).
At this point, I suggest you do post something to <email address hidden> or possibly better, <email address hidden> referring to this request and asking if others have interest in this feature. Note that both this lists are 'officially' closed to non-member posts. See the respective listinfo pages. Had you joined mailman-developers before sending your original post, I wouldn't have rejected it, but any reply from me would have been the same.
Also, I completely agree that the text "Use this if you want to make the same membership option changes to this other subscriptions." is misleading and should probably say something like "Use this if you want to make membership option changes to these other subscriptions.", but changing that has serious i18n implications, and I'm not sure it's worth it.
I'm also tagging this report for MM 3.