Am Do, 22. Okt, 2020 um 10:20 A. M. schrieb Adrien Glauser
<adrien.glauser(a)gmail.com>om>:
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.
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.
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.
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.
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.
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.
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?
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org