Re: [Evolution] Announcement: this mailing list will be retired by the end of Oct 2022

[Ángel <angel 16bits net>]

On 2022-10-26 at 12:00 +0100, Pete Biggs wrote:
> That's interesting. It looks like Gnome are using an old version of
> Discourse then.
>
> The comments about categories and topics is interesting. I asked if
> it were possible to create sub-categories in the Applications
> category and the answer was a complete and resounding NO.

I think you refer to 
https://discourse.gnome.org/t/sub-categories/11733/6

When looking at discourse I also considered the interface should have a
section per application and for properly filing the support requests.
Then, actually looking at the workflow it understand it makes sense.
It's a bit weird, sure, but when creating a new post, it does ask you
the tag (i.e. the application), and you can search for only some
application tags.

It's not what I expected, it can probably be made available with a
"better" interface, but their use of tags makes sense. Specially since
there's such large number of GNOME applications that would have to be
listed.


> It seems to me that they think users/we/contributors should be
> interested in the whole of the Gnome ecosystem not just one bit of
> it.  This is a Gnome Discourse issue, not a Discourse issue.

I think it will lead to more exposure of the different silos. So that
someone mostly interested in the Music player will now be more likely
to help an evolution or gedit user. But, at the same time, this also
means more exposure to the other apps for those not interested a tiny
bit in the other parts of GNOME.


> Plain text emails going into the system should be just that. I send
> them as plain text not as markdown. If I wanted to give them some
> form of extra formatting I would use HTML. Can't text just be
> interpreted as text.

Plain text emails often use _some_ symbols for *emphasis*.
While there is no clear standard for that, interpreting them as
markdown isn't that an odd choice.

Hyperkitty can do something similar (which is configurable):

https://docs.mailman3.org/projects/hyperkitty/en/latest/rendering.html


> Or it should at least be a bit more intelligent about it - if
> there are markdown elements, interpret it as markdown, otherwise it's
> plain text.


That would be sensible. Although markdown should be mostly backwards
compatible when feed with plaintext.


Regards