22 Oct
2020
22 Oct
'20
12:28 p.m.
Adrien wrote:
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;
Okay, I'm with you sofar.
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".
Aha, I see - I never use any webfora, so I wasn't in the right context.
Well, some of our lists are in fact open for non-subscribers, quite a
few of them. opensuse-factory for instance.
Care to explain in what way my proposal makes a negative impact on the
comfort zone of ML people?
As I said - just for the sake of argument. I only meant to suggest you
ought to be considering both sides.
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. 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 see a bit of over-engineering? I have to log in, to a system I
rarely have any reason to use, navigate unfamiliar territory and add my
email address(es). Subscribing isn't much more difficult?
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.
I don't see any issue, it is how mailing list managers work.
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? 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 :)
Generally speaking, our (openSUSE's) mailing list manager has to be an
appliance, not a bespoke development. If a feature is supported or can
easily be done by normal means, we can do it. If a new feature means
developing custom code, I am personally not in favour - development is
easy, maintenance is the killer.
--
Per Jessen, Zürich (15.2°C)
Member, openSUSE Heroes
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
86
days inactive
86
days old
0 comments
1 participants
participants (1)
-
Per Jessen