[ripe-list] The Future of Discussion Lists

Leo & all -

I do share your assessment of the current state of the email union: 
having been a lurker on <mailop at mailop.org> for almost two years now 
definitely cured me from believing that everything is basically still 
fine with some exceptions - it's rather the other way around.

The question however is - and I have put this up already yesterday 
during the session - whether this community of Internet systems 
operating people would just accept this as a matter of fact and so 
effectively carve in.

Or whether there is enough people around in this community to say 
"Enough of your email oddities, GAFA!" (or whatever the acronym of the 
day is for this group of Internet businesses), to put the feet in the 
ground and to get this fixed.

And as a side observation with an explicit eye on yesterday's last 
session on diversity: it seems that we are getting more diversity on the 
social layer of our industry - which is good! - but we are losing 
diversity at an even higher rate on the technical layer.

Beste Grüße

	-C.

On 26.05.2023 09:41, Leo Vegoda wrote:
> Dear RIPE community,
> 
> At yesterday’s community plenary I asked whether mailing lists are
> sustainable as our main communication channel. For those who were not
> able to attend, the slide and a recording are available here:
> 
> - https://ripe86.ripe.net/wp-content/uploads/presentations/12-Mailing-Lists-RIPE-86.pdf
> - https://ripe86.ripe.net/archives/video/1115
> 
> I am obviously concerned that discussion lists might not serve us with
> fidelity in the future. If that is the case, I want us to manage any
> change we need to make. We should not be bounced into rapid change.
> 
> There was more discussion than I expected. I’m sending this message to
> ask the questions:
> 
> - Am I wrong? Are e-mail discussion lists a sustainable communication
> channel for the foreseeable future?
> - Are e-mail discussion lists an acceptable technology to people
> joining the industry?
> 
> The text below is similar to something I shared with the WG Chairs
> several months ago.
> 
> Kind regards,.
> 
> Leo
> 
> ripe-781 describes four fundamental principles supporting our policy
> development process. The first two principles are openness and
> transparency.
> 
> Changes in the treatment of e-mail by large industry players presents
> a challenge to these two principles.
> 
> In 1992, when ripe-001 was published, anyone could run e-mail services
> on any Internet infrastructure they could use. It is now far more
> difficult to run e-mail services. Technology developments, like DMARC,
> have made discussion mailing lists less effective.
> 
> Validation failures increase the probability of messages being treated
> as junk. Subscribers to RIPE's discussion lists will miss messages
> when their e-mail services provider treats them as junk.
> 
> When a legitimate message to a RIPE discussion list is treated as junk
> the sender's voice has been moderated by a third-party mail provider.
> RIPE's transparency is diminished when its discussion lists are
> subjected to gatekeeping by third-party mail providers.
> 
> In 1992, e-mail was an improvement to postal services and telephony
> protocols. In 2023, we have a wide choice of communication protocols
> and platforms.
> 
> I believe that new protocols and platforms are preferred over e-mail
> by potential participants in RIPE at the start of their careers. We
> want these people to take part in RIPE. They are the future of
> coordination for the operators of IP networks in Europe and the rest
> of the world.
> 
> We must offer all current and potential participants in RIPE an
> effective set of tools. Any tools we use must support the principles
> of openness and transparency.
> 
> An ideal set of tools might have features like this:
> 
> 1. An open protocol available for implementation by anyone.
> 2. Free(ly available) software implementations for popular operating
> systems (Android, iOS, Linux, macOS, and Windows).
> 3. Allows a user to choose to have activity pushed to them. They must
> not be forced to maintain a login to be informed of activity they are
> interested in.
> 4. A public archive that cannot be retrospectively edited (barring
> exceptional situations).
> 
> While the technology choices need to support the principles of
> openness and transparency, they do not need to do all the work.
> Announcements, blog posts, and other kinds of communications can be
> built into our processes.
> 
> The combination of technology and process can make the whole more effective.