-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello,
As far as I understand there is no centralized tool allowing users to manage their mailing list subscriptions. Each ML has to be individually micro-managed.
Also MLs seem to assume that only messages from subscribed users are allowed through (even though there is a nice message that informs you if you are not yet subscribed that the message you just sent is "pending approval", in my recent experience none of the messages I sent this way actually went though).
So the business logic here entails that sending message to several MLs pushes you under the following bus:
Either
your messages will land on the "waiting for approval" purgatory and probably won't ever go through
Or
you have to manually subscribe to every single ML you want to write to keep track of all of them (to avoid sending a message to the one ML you forgot you weren't subscribed to); and you have to add filters to your email client (as opposed to a centralized web manager) to avoid drowning in a tsunami of emails; and you have to be empirical about this, making sure your filters don't get false positives or negatives.
Not a cool dilemma. I mean ML clearly have their purpose but if I didn't miss anything obvious, this does not help with making the ML for attractive to people born after 1995.
Am I missing the obvious?
Also what's the margin for feasible improvements? How strong do we need to push to shake up status quo?
Best,
Adrien
On 19/10/2020 15.15, Adrien Glauser wrote:
Hello,
As far as I understand there is no centralized tool allowing users to manage their mailing list subscriptions. Each ML has to be individually micro-managed.
The mail lists are being migrated from mlmmj to mailman, and also the mail server. So things will change, but it is a slow process donee be some volunteers (the heroes team).
Also MLs seem to assume that only messages from subscribed users are allowed through (even though there is a nice message that informs you if you are not yet subscribed that the message you just sent is "pending approval", in my recent experience none of the messages I sent this way actually went though).
Correct.
So the business logic here entails that sending message to several MLs pushes you under the following bus:
Either
your messages will land on the "waiting for approval" purgatory and probably won't ever go through
Correct.
Or
you have to manually subscribe to every single ML you want to write to keep track of all of them (to avoid sending a message to the one ML you forgot you weren't subscribed to);
Most people only subscribe to those lists they really want. If you post to one and it bounces, consider subscribing and resending, or renouncing.
and you have to add filters to your email client (as opposed to a centralized web manager) to avoid drowning in a tsunami of emails; and you have to be empirical about this, making sure your filters don't get false positives or negatives.
Machine filtering is easy.
For this mail list, for example, filter on this header:
X-Mailinglist: opensuse-project
Every list has a similar header.
Mail lists are an "ancient" system, but they are efficient.
On Mon, Oct 19, 2020 at 9:16 AM Adrien Glauser adrien.glauser@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello,
As far as I understand there is no centralized tool allowing users to manage their mailing list subscriptions. Each ML has to be individually micro-managed.
Also MLs seem to assume that only messages from subscribed users are allowed through (even though there is a nice message that informs you if you are not yet subscribed that the message you just sent is "pending approval", in my recent experience none of the messages I sent this way actually went though).
So the business logic here entails that sending message to several MLs pushes you under the following bus:
Either
your messages will land on the "waiting for approval" purgatory and probably won't ever go through
Or
you have to manually subscribe to every single ML you want to write to keep track of all of them (to avoid sending a message to the one ML you forgot you weren't subscribed to); and you have to add filters to your email client (as opposed to a centralized web manager) to avoid drowning in a tsunami of emails; and you have to be empirical about this, making sure your filters don't get false positives or negatives.
Not a cool dilemma. I mean ML clearly have their purpose but if I didn't miss anything obvious, this does not help with making the ML for attractive to people born after 1995.
Am I missing the obvious?
Also what's the margin for feasible improvements? How strong do we need to push to shake up status quo?
The transition to Mailman 3 will give people a web-based centralized mechanism to manage mailing list subscriptions. There will be some other changes as well in terms of how emails are sent and received, and how header-based filtering will need to be done for clients, and those will be communicated relatively soon as the migration date is pinned down.
-- 真実はいつも一つ！/ Always, there's only one truth!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hey Neil & Per, thanks for your replies.
Neil,
The transition to Mailman 3 will give people a web-based centralized mechanism to manage mailing list subscriptions. There will be some other changes as well in terms of how emails are sent and received, and how header-based filtering will need to be done for clients, and those will be communicated relatively soon as the migration date is pinned down.
Wow that sounds awesome! Does it mean that any user with valid openSUSE credentials (I have in mind the type of credials used by OBS and accessible from the idp-portal) will be able to post to any of these mailman 3 MLs without the hassle described in my previous email?
Best,
Adrien
On 19/10/2020 20.25, Adrien Glauser wrote:
Hey Neil & Per, thanks for your replies.
Neil,
The transition to Mailman 3 will give people a web-based centralized mechanism to manage mailing list subscriptions. There will be some other changes as well in terms of how emails are sent and received, and how header-based filtering will need to be done for clients, and those will be communicated relatively soon as the migration date is pinned down.
Wow that sounds awesome! Does it mean that any user with valid openSUSE credentials (I have in mind the type of credials used by OBS and accessible from the idp-portal) will be able to post to any of these mailman 3 MLs without the hassle described in my previous email?
AFAIK no.
What it means, I understand, is that you can go to a single web page and click to subscribe to several lists in one page.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hey Carlos,
Wow that sounds awesome! Does it mean that any user with valid openSUSE credentials (I have in mind the type of credials used by OBS and accessible from the idp-portal) will be able to post to any of these mailman 3 MLs without the hassle described in my previous email?
AFAIK no.
What it means, I understand, is that you can go to a single web page and click to subscribe to several lists in one page.
That's unfortunate. Ideally one would check for a sender's credentials ahead of their actual messages to openSUSE MLs. This way the sender: - - wouldn't get their message stuck in the purgatory, provided their address was associated with the right credentials; - - would only get the replies that use their address, so that they don't have to worry about filtering (typically me when I spam many MLs but don't want to receive all messages that are not direct replies).
Basically MLs as pure sets of receiving addresses, as opposed to now as control structures doing much more than just broadcasting emails.
Too late too complicated to look into this workflow? Or perhaps I am the only one in town to prefer this model to the actual / foreseeable one...
Best,
Adrien
Adrien Glauser wrote:
Hey Carlos,
Wow that sounds awesome! Does it mean that any user with valid openSUSE credentials (I have in mind the type of credials used by OBS and accessible from the idp-portal) will be able to post to any of these mailman 3 MLs without the hassle described in my previous email?
AFAIK no.
What it means, I understand, is that you can go to a single web page and click to subscribe to several lists in one page.
That's unfortunate. Ideally one would check for a sender's credentials ahead of their actual messages to openSUSE MLs.
Today, a subscriber's "credentials" are established when he subscribes, automatically. That is how mailing lists have worked for two-three decades, I'm not sure if there is much room nor need for improvement.
This way the sender:
- wouldn't get their message stuck in the purgatory, provided their
address was associated with the right credentials;
- would only get the replies that use their address, so that they
don't have to worry about filtering (typically me when I spam many MLs but don't want to receive all messages that are not direct replies).
When you subscribe to the nomail version of a list,
a) your postings don't get stuck b) you only get replies that are sent directly to your address.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Per,
Today, a subscriber's "credentials" are established when he subscribes, automatically. That is how mailing lists have worked for two-three decades, I'm not sure if there is much room nor need for improvement.
if you support the migration (which is more like a migration + overhaul of the whole user experience than just a change of storage), you *very clearly know* where the room for improvement over the user experience offered by two-three decades mailing system is. ;)
I am enthusiast about the migration. Let's see how it goes!
Cheers,
Adrien
This way the sender:
- wouldn't get their message stuck in the purgatory, provided
their address was associated with the right credentials;
- would only get the replies that use their address, so that they
don't have to worry about filtering (typically me when I spam many MLs but don't want to receive all messages that are not direct replies).
When you subscribe to the nomail version of a list,
a) your postings don't get stuck b) you only get replies that are sent directly to your address.
-- Per Jessen, Zürich (7.0°C) Member, openSUSE Heroes
Adrien Glauser wrote:
Per,
Today, a subscriber's "credentials" are established when he subscribes, automatically. That is how mailing lists have worked for two-three decades, I'm not sure if there is much room nor need for improvement.
if you support the migration (which is more like a migration + overhaul of the whole user experience than just a change of storage),
I not only support it, I initiated it - the main reason being lack of functionality and incomplete features in our current mailing list manager.
Am Mo, 19. Okt, 2020 um 8:55 P. M. schrieb Carlos E. R. robin.listas@telefonica.net:
On 19/10/2020 20.25, Adrien Glauser wrote:
Wow that sounds awesome! Does it mean that any user with valid openSUSE credentials (I have in mind the type of credials used by OBS and accessible from the idp-portal) will be able to post to any of these mailman 3 MLs without the hassle described in my previous email?
AFAIK no.
What it means, I understand, is that you can go to a single web page and click to subscribe to several lists in one page.
Hyperkitty actually allows to create new threads and post replies to existing threads. Postorius allows for managing multiple email addresses with one account though, so what you said is still true.
LCP [Stasiek] https://lcp.world
Adrien Glauser wrote:
As far as I understand there is no centralized tool allowing users to manage their mailing list subscriptions. Each ML has to be individually micro-managed.
Actually, I do the list management, whereas users merely have the options of subscribing and unsubscribing. :-)
Also MLs seem to assume that only messages from subscribed users are allowed through
Yes, most of our lists only accept postings from subscribed users, that is our default. It is a per-list setting - I think some lists are open to non-subscribers.
(even though there is a nice message that informs you if you are not yet subscribed that the message you just sent is "pending approval", in my recent experience none of the messages I sent this way actually went though).
It depends on the list and its owners/moderators - but yes, it is also possible they were simply overlooked. Some go to ml-admin (which is me amongst others) and I have been busy with other stuff. Basically, when you get the nice message, the easiest solution is to subscribe and resend.
Hey,
On 19.10.20 15:15, Adrien Glauser wrote:
So the business logic here entails that sending message to several MLs pushes you under the following bus:
And of course for reasons. Reasons that were sound in 1995 and that still are sound today :-)
1. Sending mails to multiple mailing lists (cross-posting is the term that is used for this) is frowned upon. Most lists have wildly different topics. If you want to make an announcement to everybody and/or an unspecifc group of openSUSE people, use the announcement list.
2. sending mails to a mailing list you are not subscribed to is frowned upon as obviously can't be bothered with replies on the list, most people also don't want to hear what you have to say.
There are more sound rules, you can find them on our netiquette
https://en.opensuse.org/openSUSE:Mailing_list_netiquette
Henne
On Wed, Oct 21, 2020 at 04:35:36PM +0200, Henne Vogelsang wrote:
Hey,
On 19.10.20 15:15, Adrien Glauser wrote:
So the business logic here entails that sending message to several MLs pushes you under the following bus:
And of course for reasons. Reasons that were sound in 1995 and that still are sound today :-)
- Sending mails to multiple mailing lists (cross-posting is the term that
is used for this) is frowned upon. Most lists have wildly different topics. If you want to make an announcement to everybody and/or an unspecifc group of openSUSE people, use the announcement list.
- sending mails to a mailing list you are not subscribed to is frowned upon
as obviously can't be bothered with replies on the list, most people also don't want to hear what you have to say.
There are more sound rules, you can find them on our netiquette
Funny enough, both of these recommendations are the exact opposite of the practice (and recommendations) in most developer mailing lists...
Michal Kubecek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Just to be clear because it seems that some people are replying to messages that presuppose a backlog they haven't read.
Issues with current model:
1) Errors messages are not bubbled up appropriatedly. If you send a message not as plain text, you are met with an error message that does not tell you the reason your message didn't go through. => Per already acknowledged this issue and told me it was quite deeply entrenched within the backend. Whether mailman3 will work around this or whether the issue won't occur in the first place, I don't know yet.
2) The "Pending approval" work-flow generates false assumptions. If you send a message while not subscribed, you are met with a message that says that your message is pending approval, building the assumption that your message will probably go though within a reasonable span of time. The assumption is however false, as far I have experienced. => Per also acknowledged that moderation could be delayed, but I don't think mailman3 in itself solves this issue -- it's rather an issue of what moderation settings one favors. From what I gather, nothing is settled yet about how this will be handled by mailman3.
3) The current model makes 0 use of the platform-wide openSUSE user auth + login system. In practice this means that users that want to use MLs have to undergo as many authentication checks as there are MLs to which they want to send to, and to keep track of each of them if they don't want to run into issue (2) above. => It's not a compelling issue, it's more like a missed opportunity to minimize convoluted work-flows and / or cognitive load for the user. As per some of the answers on this ML I gather that the migration to mailman3 won't improve on this.
4) Subscribing to a ML for the sake of sending a few messages is likely to create the need for client-side filtering, as more messages than those in which the sender is interested will be send back to them. => Ok, this is how ML have worked for a number of years, I'll grant you that. But so what?
My humble suggestion to solve all these 4 problems at once, made already but rehearsed here, goes like this: a) authorize by default all and only those email addresses that users have registered against the current openSUSE auth + login system to send to any ML, no matter which b) handle subscriptions to MLs closer to the literal meaning of subscribing: i.e. open a receiver's channel, nothing less and nothing more.
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms. This helps bring the two parts of the community (forums people, other people) a tad bit closer to one another, adding an extra little bit of peace and harmony to the cosmos.
Cheers,
Adrien
Le mercredi 21 octobre 2020 à 18:55 +0200, Michal Kubecek a écrit :
On Wed, Oct 21, 2020 at 04:35:36PM +0200, Henne Vogelsang wrote:
Hey,
On 19.10.20 15:15, Adrien Glauser wrote:
So the business logic here entails that sending message to several MLs pushes you under the following bus:
And of course for reasons. Reasons that were sound in 1995 and that still are sound today :-)
- Sending mails to multiple mailing lists (cross-posting is the
term that is used for this) is frowned upon. Most lists have wildly different topics. If you want to make an announcement to everybody and/or an unspecifc group of openSUSE people, use the announcement list.
- sending mails to a mailing list you are not subscribed to is
frowned upon as obviously can't be bothered with replies on the list, most people also don't want to hear what you have to say.
There are more sound rules, you can find them on our netiquette
Funny enough, both of these recommendations are the exact opposite of the practice (and recommendations) in most developer mailing lists...
Michal Kubecek
Am Do, 22. Okt, 2020 um 10:20 A. M. schrieb Adrien Glauser adrien.glauser@gmail.com:
Just to be clear because it seems that some people are replying to messages that presuppose a backlog they haven't read.
Issues with current model:
- Errors messages are not bubbled up appropriatedly. If you send a
message not as plain text, you are met with an error message that does not tell you the reason your message didn't go through. => Per already acknowledged this issue and told me it was quite deeply entrenched within the backend. Whether mailman3 will work around this or whether the issue won't occur in the first place, I don't know yet.
With mailman, we have a few options: - Accept HTML mail - Reject HTML mail (via MIME filter) - Turn HTML mail into plaintext
and I honestly haven't played around with any of that yet. In the end I think we want to make sure the subscribers get plaintext mail, so turning HTML into plaintext may be the most user friendly of an option.
- The "Pending approval" work-flow generates false assumptions. If
you send a message while not subscribed, you are met with a message that says that your message is pending approval, building the assumption that your message will probably go though within a reasonable span of time. The assumption is however false, as far I have experienced. => Per also acknowledged that moderation could be delayed, but I don't think mailman3 in itself solves this issue -- it's rather an issue of what moderation settings one favors. From what I gather, nothing is settled yet about how this will be handled by mailman3.
Your message will also land in a moderation queue with mailman if you aren't subscribed if the settings remain similar, there really isn't much difference there.
- The current model makes 0 use of the platform-wide openSUSE user
auth + login system. In practice this means that users that want to use MLs have to undergo as many authentication checks as there are MLs to which they want to send to, and to keep track of each of them if they don't want to run into issue (2) above. => It's not a compelling issue, it's more like a missed opportunity to minimize convoluted work-flows and / or cognitive load for the user. As per some of the answers on this ML I gather that the migration to mailman3 won't improve on this.
Eh, you really can't blame anybody, nobody would have wanted to deal with Novell's auth system more than they needed, so for most of the time project was a thing, having auth in some services was done out of necessity and not willingness.
- Subscribing to a ML for the sake of sending a few messages is
likely to create the need for client-side filtering, as more messages than those in which the sender is interested will be send back to them. => Ok, this is how ML have worked for a number of years, I'll grant you that. But so what?
That's why nomail subscription is a thing, being subscribed without getting mails.
My humble suggestion to solve all these 4 problems at once, made already but rehearsed here, goes like this: a) authorize by default all and only those email addresses that users have registered against the current openSUSE auth + login system to send to any ML, no matter which
That's not possible with the current mail system, since we can't poll auth system for that kind of info afaik
b) handle subscriptions to MLs closer to the literal meaning of subscribing: i.e. open a receiver's channel, nothing less and nothing more.
nomail
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms. This helps bring the two parts of the community (forums people, other people) a tad bit closer to one another, adding an extra little bit of peace and harmony to the cosmos.
That's kinda the point of hyperkitty and postorius to begin with
LCP [Stasiek] https://lcp.world
Adrien Glauser wrote:
Issues with current model:
- Errors messages are not bubbled up appropriatedly. If you send a
message not as plain text, you are met with an error message that does not tell you the reason your message didn't go through. => Per already acknowledged this issue and told me it was quite deeply entrenched within the backend.
ACK again :-)
- The "Pending approval" work-flow generates false assumptions. If
you send a message while not subscribed, you are met with a message that says that your message is pending approval, building the assumption that your message will probably go though within a reasonable span of time. The assumption is however false, as far I have experienced. => Per also acknowledged that moderation could be delayed,
ACK again. This is at least partially due to our mailing lists not having enough owners and moderators. Most of our lists have just one owner (ml-admin) and no moderators which pretty much means I become the bottleneck.
but I don't think mailman3 in itself solves this issue -- it's rather an issue of what moderation settings one favors. From what I gather, nothing is settled yet about how this will be handled by mailman3.
Overall, I expect mailman3 to bring technical improvement, but no major changes to list management policy.
- Subscribing to a ML for the sake of sending a few messages is
likely to create the need for client-side filtering, as more messages than those in which the sender is interested will be send back to them. => Ok, this is how ML have worked for a number of years, I'll grant you that. But so what?
True, so what - it could be changed. OTOH, you subscribe not just for "sending a few messages" but also for receiving a few replies to those.
My humble suggestion to solve all these 4 problems at once, made already but rehearsed here, goes like this: a) authorize by default all and only those email addresses that users have registered against the current openSUSE auth + login system to send to any ML, no matter which
This is doable, a nomail subscription for all. Although many will want a regular subscription. (you can't have both on the same list). Synchronization might be a stumbling block. Also, only one email address is registered (afaik), and many people (incl myself) use multiple.
b) handle subscriptions to MLs closer to the literal meaning of subscribing: i.e. open a receiver's channel, nothing less and nothing more.
I'm not sure I really understand what you mean here - the above sounds like what any mailing list manager does already ? i.e. you subscribe to a mailing list and you start receiving traffic.
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms.
Just for the sake of argument - whose comfort zone is more important, the above or those of people who already use mailing lists?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
To the point:
My humble suggestion to solve all these 4 problems at once, made already but rehearsed here, goes like this: a) authorize by default all and only those email addresses that users have registered against the current openSUSE auth + login system to send to any ML, no matter which
This is doable, a nomail subscription for all. Although many will want a regular subscription. (you can't have both on the same list). Synchronization might be a stumbling block. Also, only one email address is registered (afaik), and many people (incl myself) use multiple.
The backend logic I am assuming is: - - for any message submitted to any ML, if the sender has *some* email address associated with their account, let the message through;
where *some email* can be determined in many different ways, for instance: - - in openSUSE user profile (feature: "use this text-field to add as many email addresses as you want our MLs to whitelist for you).
I notice en passant from what you just said that my proposal seems to solve a 5th problem I overlooked in my previous message:
Issue 5) The current system (and mailman3!) enforce subscriptions as 1-1 relations between email addresses and MLs, when in fact there is 0 need for enforcing this if users have sets of addresses whitelisted upstream in the work-flow.
b) handle subscriptions to MLs closer to the literal meaning of subscribing: i.e. open a receiver's channel, nothing less and nothing more.
I'm not sure I really understand what you mean here - the above sounds like what any mailing list manager does already ? i.e. you subscribe to a mailing list and you start receiving traffic.
When you navigate a forum you usually don't need to subscribe to a topic in order to be able to post to it. In that context "subscribing" means "getting notified upon updates to the topic". My suggestion is to move MLs closer to that meaning of "subscribing".
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms.
Just for the sake of argument - whose comfort zone is more important, the above or those of people who already use mailing lists?
Care to explain in what way my proposal makes a negative impact on the comfort zone of ML people? My understanding of its implications was that it didn't change anything for ML people, while lowering the entry- barrier for non-ML people in a reasonable way.
Perhaps all this is a nice on paper but is horribly bad as far as cost- efficiency is concerned, which may well be the case if mailman3 does not easily bend to such fine-tunings. I have no way of knowing that beforehand unless I discuss these things here :)
Cheers,
A
-- Per Jessen, Zürich (15.2°C) Member, openSUSE Heroes
Am Do, 22. Okt, 2020 um 11:52 A. M. schrieb Adrien Glauser adrien.glauser@gmail.com:
b) handle subscriptions to MLs closer to the literal meaning of subscribing: i.e. open a receiver's channel, nothing less and nothing more.
I'm not sure I really understand what you mean here - the above sounds like what any mailing list manager does already ? i.e. you subscribe to a mailing list and you start receiving traffic.
When you navigate a forum you usually don't need to subscribe to a topic in order to be able to post to it. In that context "subscribing" means "getting notified upon updates to the topic". My suggestion is to move MLs closer to that meaning of "subscribing".
Posting a thread/response to a thread using hyperkitty automatically subscribes you as a nomail subscriber to the list, so the forums analogy stays relevant if the user ends up using hyperkitty.
Perhaps all this is a nice on paper but is horribly bad as far as cost- efficiency is concerned, which may well be the case if mailman3 does not easily bend to such fine-tunings. I have no way of knowing that beforehand unless I discuss these things here :)
Well, I would probably recommend suggesting some things upstream as well, we are deploying this as a solution that's a huge improvement for us, but may not be sufficient for the users yet. If you let me know after getting a feature upstream, I would be glad to deploy it to our servers.
LCP [Stasiek] https://lcp.world
On 22/10/2020 11.52, Adrien Glauser wrote:
Care to explain in what way my proposal makes a negative impact on the comfort zone of ML people? My understanding of its implications was that it didn't change anything for ML people, while lowering the entry- barrier for non-ML people in a reasonable way.
For instance, I as user hate when somebody says "do not reply on the list, I'm not subscribed and I will not read it." My instant reaction is to not answer at all, or ignore the request and answer on the mail list.
With the current system you do not need any password to interact with the mail list manager. It is done by sending special emails to the server, which authenticates you based on you sending an email from the subscribed email address.
Mailman, on the other hand, has a web page for controlling the subscription and, in the older versions I have used, gives you an automated password, and possibly a single one for several mail lists. But it sends you a password reminder every month with the password in clear text that can be intercepted. I don't think it can be integrated with the openSUSE account - and then what about the people that are not registered there?
Making it much different from what users of mail lists are used to, would "impact our comfort zone", considering that we subscribe also to other non openSUSE mail lists.
I would like to remind you about the "nomail" option. It is a mode of subscribing to a mail list in which you do not receive list mail. It simply authorizes you to post to the list. Possibly it tries to send you replies to your post, but I'm not sure how it can make sure to send the entire thread to you.
Am Do, 22. Okt, 2020 um 1:27 P. M. schrieb Carlos E. R. robin.listas@telefonica.net:
Mailman, on the other hand, has a web page for controlling the subscription and, in the older versions I have used, gives you an automated password, and possibly a single one for several mail lists. But it sends you a password reminder every month with the password in clear text that can be intercepted. I don't think it can be integrated with the openSUSE account - and then what about the people that are not registered there?
Thankfully that system is gone, and with postorius and hyperkitty it just uses openSUSE account, and a lot of other social media accounts for login.
LCP [Stasiek] https://lcp.world
On Thu, Oct 22, 2020 at 01:27:17PM +0200, Carlos E. R. wrote:
On 22/10/2020 11.52, Adrien Glauser wrote:
Care to explain in what way my proposal makes a negative impact on the comfort zone of ML people? My understanding of its implications was that it didn't change anything for ML people, while lowering the entry- barrier for non-ML people in a reasonable way.
For instance, I as user hate when somebody says "do not reply on the list, I'm not subscribed and I will not read it." My instant reaction is to not answer at all, or ignore the request and answer on the mail list.
The standard is to reply both to author and the list - or, more precisely, to everyone involved so far, i.e what "group reply" or similar does. Replying _only_ into the list makes sense for huge flames, not for technical discussion.
(Yes, I'm aware that the official openSUSE mailing list "netiquette" is, sadly, exactly the opposite of the standard developer mailing list netiquette, I already pointed that out.)
Michal Kubecek
Michal Kubecek wrote:
On Thu, Oct 22, 2020 at 01:27:17PM +0200, Carlos E. R. wrote:
On 22/10/2020 11.52, Adrien Glauser wrote:
Care to explain in what way my proposal makes a negative impact on the comfort zone of ML people? My understanding of its implications was that it didn't change anything for ML people, while lowering the entry- barrier for non-ML people in a reasonable way.
For instance, I as user hate when somebody says "do not reply on the list, I'm not subscribed and I will not read it." My instant reaction is to not answer at all, or ignore the request and answer on the mail list.
The standard
s/The/One/
is to reply both to author and the list
In my experience, the vast majority of our subscribers only reply to the list - I acknowledge that some people practice replying to the author and the list, but I don't. I believe it came about to make use of very busy lists easier for everyone.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2020-10-22 a las 18:42 +0200, Michal Kubecek escribió:
On Thu, Oct 22, 2020 at 01:27:17PM +0200, Carlos E. R. wrote:
On 22/10/2020 11.52, Adrien Glauser wrote:
Care to explain in what way my proposal makes a negative impact on the comfort zone of ML people? My understanding of its implications was that it didn't change anything for ML people, while lowering the entry- barrier for non-ML people in a reasonable way.
For instance, I as user hate when somebody says "do not reply on the list, I'm not subscribed and I will not read it." My instant reaction is to not answer at all, or ignore the request and answer on the mail list.
The standard is to reply both to author and the list - or, more precisely, to everyone involved so far, i.e what "group reply" or similar does. Replying _only_ into the list makes sense for huge flames, not for technical discussion.
I don't see the relationship, sorry.
(Yes, I'm aware that the official openSUSE mailing list "netiquette" is, sadly, exactly the opposite of the standard developer mailing list netiquette, I already pointed that out.)
And being so, not respecting the netiquette does cause flame wars.
- -- Cheers Carlos E. R.
(from openSUSE 15.1 (Legolas))
On Thu, Oct 22, 2020 at 08:10:23PM +0200, Carlos E. R. wrote:
El 2020-10-22 a las 18:42 +0200, Michal Kubecek escribió:
The standard is to reply both to author and the list - or, more precisely, to everyone involved so far, i.e what "group reply" or similar does. Replying _only_ into the list makes sense for huge flames, not for technical discussion.
I don't see the relationship, sorry.
For huge non-technical discussions taking place within one list, there is little harm having whole discussion only within that list (but there is no harm following the standard procedure either). For technical discussions, e.g. issue reports, technical questions or proposed patches, your (and, most unfortunately, official openSUSE) practice of replying only "to the list" has severe drawbacks:
- people not subscribed to the list do not get replies at all - for mails sent into two (or more) lists, part of the discussion is only in one of them, part only in the other; people subscribed only to one of the lists see only a random selection of the discussion; those subscribed to both need to go through the tree twice
And, yes, the official openSUSE "netiquette" of not "cross-posting" is also fundamentally flawed.
For an illustrative example, take recent discussion about kernel upgrade to 5.9 which started with a heads up sent to opensuse-kernel and opensuse-factory. This was the best course of action as the topic belongs to both and there are people subscribed to any of the lists who are not subscribed to the other. If Jiří followed the official recommendation and sent his heads up mail only to one of the lists, people subscribed only to one of them would not receive the heads up warning at all. Do you really believe it would be better? I don't.
And if you look at the discussions in both lists, you can also see an example of why replying "only to _the_ list" is wrong: each of the two lists now contains only a random subset of the discussion. People subscribed only to one of the lists won't see big part of the discussion at all. Is it desirable? I don't think so.
As a contrast, look at kernel developer mailing lists as an example of mailing list culture which actually works. You don't have to subscribe to a specific mailing list for an area you do not work regularly in just to be able to ask a question, report an issue or submit a patch. You just send it (also) there and you don't have to worry about not getting replies because people (with rare exceptions) will use "group reply" properly. And it does not really matter whether I read the discussion in my inbox or any of the list folders because all replies (again, with rare exceptions) will be in all of them.
Michal Kubeček
On 24/10/2020 00.58, Michal Kubecek wrote:
On Thu, Oct 22, 2020 at 08:10:23PM +0200, Carlos E. R. wrote:
El 2020-10-22 a las 18:42 +0200, Michal Kubecek escribió:
The standard is to reply both to author and the list - or, more precisely, to everyone involved so far, i.e what "group reply" or similar does. Replying _only_ into the list makes sense for huge flames, not for technical discussion.
I don't see the relationship, sorry.
For huge non-technical discussions taking place within one list, there is little harm having whole discussion only within that list (but there is no harm following the standard procedure either). For technical discussions, e.g. issue reports, technical questions or proposed patches, your (and, most unfortunately, official openSUSE) practice of replying only "to the list" has severe drawbacks:
- people not subscribed to the list do not get replies at all
- for mails sent into two (or more) lists, part of the discussion is only in one of them, part only in the other; people subscribed only to one of the lists see only a random selection of the discussion; those subscribed to both need to go through the tree twice
And, yes, the official openSUSE "netiquette" of not "cross-posting" is also fundamentally flawed.
For an illustrative example, take recent discussion about kernel upgrade to 5.9 which started with a heads up sent to opensuse-kernel and opensuse-factory. This was the best course of action as the topic belongs to both and there are people subscribed to any of the lists who are not subscribed to the other. If Jiří followed the official recommendation and sent his heads up mail only to one of the lists, people subscribed only to one of them would not receive the heads up warning at all. Do you really believe it would be better? I don't.
And if you look at the discussions in both lists, you can also see an example of why replying "only to _the_ list" is wrong: each of the two lists now contains only a random subset of the discussion. People subscribed only to one of the lists won't see big part of the discussion at all. Is it desirable? I don't think so.
I see your point, thanks. No one explained this to me in many years, so thank you again.
As a contrast, look at kernel developer mailing lists as an example of mailing list culture which actually works. You don't have to subscribe to a specific mailing list for an area you do not work regularly in just to be able to ask a question, report an issue or submit a patch. You just send it (also) there and you don't have to worry about not getting replies because people (with rare exceptions) will use "group reply" properly. And it does not really matter whether I read the discussion in my inbox or any of the list folders because all replies (again, with rare exceptions) will be in all of them.
But people that don't belong to the group, specially those reading the mail archive later, will not see all the answers if some of the answers were direct and not to the list (like those done by non-subscribers on a list that rejects non-subscriber posts).
Michal Kubeček
On Sat, Oct 24, 2020 at 02:06:11AM +0200, Carlos E. R. wrote:
As a contrast, look at kernel developer mailing lists as an example of mailing list culture which actually works. You don't have to subscribe to a specific mailing list for an area you do not work regularly in just to be able to ask a question, report an issue or submit a patch. You just send it (also) there and you don't have to worry about not getting replies because people (with rare exceptions) will use "group reply" properly. And it does not really matter whether I read the discussion in my inbox or any of the list folders because all replies (again, with rare exceptions) will be in all of them.
But people that don't belong to the group, specially those reading the mail archive later, will not see all the answers if some of the answers were direct and not to the list (like those done by non-subscribers on a list that rejects non-subscriber posts).
Yes, this model assumes that people don't have to be subscribed to be allowed to send e-mails to the list.
Michal Kubecek
On 24.10.20 00:58, Michal Kubecek wrote:
As a contrast, look at kernel developer mailing lists as an example of mailing list culture which actually works. You don't have to subscribe to a specific mailing list for an area you do not work regularly in just to be able to ask a question, report an issue or submit a patch. You just send it (also) there and you don't have to worry about not getting replies because people (with rare exceptions) will use "group reply" properly. And it does not really matter whether I read the discussion in my inbox or any of the list folders because all replies (again, with rare exceptions) will be in all of them.
True, but does not work for opensuse lists where you need to subscribe to be able to post to them (it would have worked for me, as I am subscribed to both opensuse-kernel and opensuse-factory :-))
A change in this policy, maybe with the switch to mailman would be possible / desirable(?) but it would need two things: * "if you subscribed to one opensuse list, you can post to all lists" * "use group reply as default"
But then, what about the "oh, a support question got (cross-)posted to factory, where only development questions are allowed!!1!, now all developers will instantly leave factory list" (presumed) problem?
There is no easy solution :-)
Have fun anyway,
seife
Carlos E. R. wrote:
I would like to remind you about the "nomail" option. It is a mode of subscribing to a mail list in which you do not receive list mail. It simply authorizes you to post to the list. Possibly it tries to send you replies to your post, but I'm not sure how it can make sure to send the entire thread to you.
An address subscribed to the nomail version of a list will never receive any mails from the list.
On Thu 22 Oct 2020 07:37:25 PM CDT, Per Jessen wrote:
Carlos E. R. wrote:
I would like to remind you about the "nomail" option. It is a mode of subscribing to a mail list in which you do not receive list mail. It simply authorizes you to post to the list. Possibly it tries to send you replies to your post, but I'm not sure how it can make sure to send the entire thread to you.
An address subscribed to the nomail version of a list will never receive any mails from the list.
Hi Then you use the likes of gmane and nntp (which I do), if a list is missing, ask for it to be added to the gmame service.
Le 22/10/2020 à 11:13, Per Jessen a écrit :
Adrien Glauser wrote:
- Subscribing to a ML for the sake of sending a few messages is
likely to create the need for client-side filtering, as more messages than those in which the sender is interested will be send back to them. => Ok, this is how ML have worked for a number of years, I'll grant you that. But so what?
True, so what - it could be changed. OTOH, you subscribe not just for "sending a few messages" but also for receiving a few replies to those.
and for such, forums are better fitted than mailing lists (IMHO)
jdd
On Thu 2020-10-22, Per Jessen wrote:
- The "Pending approval" work-flow generates false assumptions. If
you send a message while not subscribed, you are met with a message that says that your message is pending approval, building the assumption that your message will probably go though within a reasonable span of time. The assumption is however false
ACK again. This is at least partially due to our mailing lists not having enough owners and moderators. Most of our lists have just one owner (ml-admin) and no moderators which pretty much means I become the bottleneck.
I believe we have a great moderator community on our forums (and maybe other media like Discord)?
How about asking for volunteers for our mailing lists? Maybe some of those moderators are willing to help there, too, or others step up, so this doesn't all rest on your shoulders.
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms.
Just for the sake of argument - whose comfort zone is more important, the above or those of people who already use mailing lists?
Ultimately any community needs an influx of new members not only to grow, but even to remain stable. The question is: is this an either - or?
Or can we be more open, more accomodating (and if so, how) to new participants without alienating existing ones?
Gerald
PS: Moving a bit outside of one's comfort zone may be good. That's one good way to learn and grow. ;-)
Le 22/10/2020 à 13:57, Gerald Pfeifer a écrit :
I believe we have a great moderator community on our forums (and maybe other media like Discord)?
How about asking for volunteers for our mailing lists? Maybe some of those moderators are willing to help there, too, or others step up, so this doesn't all rest on your shoulders.
but is it necessary to moderate? (as long as there is no spam)
may be we can add a bottom line "hit "k" with thunderbird to ignore this discussion" :-))
jdd
Gerald Pfeifer wrote:
On Thu 2020-10-22, Per Jessen wrote:
- The "Pending approval" work-flow generates false assumptions. If
you send a message while not subscribed, you are met with a message that says that your message is pending approval, building the assumption that your message will probably go though within a reasonable span of time. The assumption is however false
ACK again. This is at least partially due to our mailing lists not having enough owners and moderators. Most of our lists have just one owner (ml-admin) and no moderators which pretty much means I become the bottleneck.
I believe we have a great moderator community on our forums (and maybe other media like Discord)?
How about asking for volunteers for our mailing lists? Maybe some of those moderators are willing to help there, too, or others step up, so this doesn't all rest on your shoulders.
Certainly, it is a fixed item on my todo-list. The key thing is assigning an owner though, and then leave it to him/her to sort out the rest. However, the truth is that there is _very_ little to do, which is another reason why requests can take a long time. When I know my mailbox is always empty, I might only check it once a week.
(a) + (b) solve all four issues, don't open loopholes for spams, and bring the ML worflow closer to the workflow of forums and instant messaging apps, making use of the comfort zone of people who already use these platforms.
Just for the sake of argument - whose comfort zone is more important, the above or those of people who already use mailing lists?
Ultimately any community needs an influx of new members not only to grow, but even to remain stable. The question is: is this an either - or?
Or can we be more open, more accomodating (and if so, how) to new participants without alienating existing ones?
I don't think we are doing particular badly right now, but I am probably not the right one to judge that. Still, we have a plethora of communications channels - lists, fora, discord, irc, usenet, reddit, various IM services. They are different and attract different audiences. I don't think making any of them more open or more accomodating will change that.
-
Adrien Glauser -
Carlos E. R. -
Gerald Pfeifer -
Henne Vogelsang -
jdd＠dodin.org -
Malcolm -
Michal Kubecek -
Neal Gompa -
Per Jessen -
Stasiek Michalski -
Stefan Seyfried