>>> 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
> 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.
> where *some email* can be determined in many different ways, for
> - - 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:
> 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.
> 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.
>>> (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?
As I said - just for the sake of argument. I only meant to suggest you
ought to be considering both sides.
> 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