Just a slight addition about "archaic email" and related comments:
Email and its capability for being used in conjunction with OpenPGP
ensures two major institutions in kernel development and elsewhere:
"Trusting the developers, not infrastructure" [1], and, assume "any part
of the infrastructure can be compromised at any time" [1]. This avoids
single points of failure, and complements the chain of trust.
I am not sure if Discourse is capable to be used in conjunction with
OpenPGP if it reformats contents or if it removes attachments (maybe
someone knows?). This leads to the possibility that discourse introduces
a single point of failure (or, single point of vulnerability), which
breaks the above institutions.
Having said that, as far as I follow our devel mailing list, I think the
argument above is of minor relevance, because I think this mailing list
is not used to forward code or to do reviews. Signatures seem to be not
omnipresent at the moment anyway.
However, I just wanted to remind that the issue is a little more complex
than just assuming "email is old and has to be replaced by modern":
there is another consideration, too. And we have to be aware that if
discourse does not support OpenPGP signatures practically, we loose the
possibility to ensure "security of integrity" in the mailing list in
cases WHEN it is necessary - IF there are such cases (which I cannot
determine).
Just some thoughts :)
[1]
https://www.kernel.org/doc/html/latest/process/maintainer-pgp-guide.html
Chris
On 4/21/23 11:42, Aleksandra Fedorova wrote:
> On 4/21/23 02:57, Solomon Peachy via devel wrote:
>> On Thu, Apr 20, 2023 at 07:21:54PM -0400, Simo Sorce wrote:
>>> Hi Matthew, you say: "We're missing people", and I think,
"who?".
>>> And who are you going to miss if you move to discourse?
>>
>> Again and again I have seen this "we're missing people" sentiment
be
>> used to justify scrapping "old" workflows, and *not once* has it ever
>> resulted in "more people" coming out of the woodwork that would have
>> happily contributed in the past, but were turned off/away by the need to
>> use archaic email.
>
> Funny, how from where I am sitting I can not really remember any time
> we managed to scrape the old workflow at least once. So I wouldn't be
> able to measure the effectiveness of such an imaginary thing. I can
> only see how we are unable to do changes and therefore we are always
> adding things on top of old ones, which of course doesn't make
> anything easier neither for those who want to change, nor for those
> who don't.
>
> That's a slight exaggeration of course, but so is your statement.
> People come to Fedora via many ways. But I doubt any of it starts with
> e-mail nowadays. And the fact that you don't see newcomers _here_
> actually proves the point, isn't it?
>
>> (FFS, If we're going to follow this to its logical conclusion, we should
>> just scrap all of this email/discourse/whatever and just move
>> everything to github, or even facebook, as that's clearly where the
>> most numbers of people are. "but no, our custom tooling makes things
>> better for us" is the inevitable pushback, which arguably applies just
>> as much to email-based flows!)
>>
>>> The mailing list make messages land in my client, on which I am very
>>> efficient, therefore I can check all messages once a day, and respond
>>> if I find a worthy topic.
>>
>> ...and the very nature of Discourse or various other Forums pretty much
>> make this sort of workflow impossible; that is to say you're all but
>> forced to manually poll every site you care about in a way that all but
>> makes automation impossible.
>
> Discourse
>
> 1) sends email in a multipart format which has html and plain
> text(kind of markdown);
> 2) adds headers which allow you to filter the messages by topic or
> category on the client-side;
> 2) allows you to configure notifications for mentions per category or
> per tag;
> 3) allows to configure custom searches on the server side, and will
> notifies you for it.
>
> Here is the example of the mail headers:
> ----------------------------------------
>
> Message-ID: <discourse/post/215862(a)discussion.fedoraproject.org>
> In-Reply-To: <discourse/post/215857(a)discussion.fedoraproject.org>
> References: <discourse/post/215855(a)discussion.fedoraproject.org>
> <discourse/post/215856(a)discussion.fedoraproject.org>
> <discourse/post/215857(a)discussion.fedoraproject.org>
> List-Unsubscribe: <...>
> X-Discourse-Post-Id: 215862
> X-Discourse-Topic-Id: 81258
> X-Discourse-Category: Team Workflows/Fedora Magazine
> X-Auto-Response-Suppress: All
> Auto-Submitted: auto-generated
> Precedence: list
> List-ID: Fedora Discussion | Team Workflows Fedora Magazine
> <fedora-magazine.team-workflows.discussion.fedoraproject.org>
> List-Archive:
>
https://discussion.fedoraproject.org/t/article-proposal-using-btrfs-to-up...
> Feedback-ID: fedoraproject:user_posted:discoursemail
>
> ----------------------------------------
>
> It is not perfect, and it requires some effort. But I don't see why it
> is impossible.
>
>> In other words, it's locally optimal for any given site, but is utterly
>> incapable of scaling if you care about more than a small handful of
>> sites.
>>
>> Calling myself semi-active here would be quite generous, but I can
>> uneqvocibly state that if I have to manually poll a discourse site or
>> whatever, that will be the end of my participating in anything Fedora,
>> except to report bugs via abrt (assuming I don't have to keep logging in
>> for new API keys) I suspect I'm far from the only one in that respect.
>
> Let's not get into a "who would you miss more" competition and work on
> a solution which actually helps us to bridge the gap and allows us to
> compromise between different use cases.
>
>>> Unless this discourse has some great mail bridge (it doesn't) or maybe
>>> an rss feed (I do not use those at work, but I guess I could ?) So
>>> that I can skim messages on my terms, I think I (and those like me)
>>> will be the next "missing people".
>>
>> RSS doesn't scale for higher volumes unless you're literally polling
>> every few minutes or the feed includes a large number of entries.
>>
>>> Btw I could make exactly the same quote about any forum that Major made
>>> for Mailing lists, messy discussions are messy and a forum does not
>>> make them easier to follow by any means (perhaps except for those that
>>> chose inferior email readers).
>>
>> Yeah.
>>
>>> Your own post communicates to me (whether you intended it or not) that
>>> in the end the thread that will be generated by this post won't matter,
>>> because this is just a courtesy post and you already think that the
>>> opinion of the "minority of self selected mailing list lovers and
>>> dinosaurs" does not matter much.
>>
>> Unfortunately, I have to agree with this perception. Perhaps it's
>> because I've seen so many other formerly e-mail based communities
>> bifrucate [1] chasing after "engagagement" that never occurs, or even
>> RH/Fedora's near-perfect abysmal record of framing core infrastructure
>> changes like this as a "discussion" when the decision has already been
>> made and will happen no matter what the masses have to say about it.
>>
>> At the end of the day, distro development, like most other
>> infrastructure, isn't sexy or glamorous, and the humongous effort that
>> goes into it is rarely rewarded with anything other than abuse. "Who
>> cares about distros? I just use Docker containers!"
>
> In all seriousness, I would advise you to hang out at the current
>
discussion.fedoraproject.org and feel the vibe a bit.
>
> Distributions _are_ cool and sexy. And people have ideas and interest
> in them. Some of them are totally wrong and misplaced, some may be
> very old, and some are better. But that's how it should be.
>
> It seems you feel like you are cornered, but it is you who put
> yourself in the corner by ignoring the part of the community, which
> actually can and wants to support you.
>
>> [1] Splitting into the "core" developers (ie those paid/compensated
for
>> participating) and an endless summer of newbs seeking help/support;
>> the middle gets completely hollowed out.
>>
>> - Solomon
>