search

w3c / mailing-list-archives

Modernizing W3C's mailing list archives
https://w3c.github.io/mailing-list-archives/samples/
19 stars 12 forks source link

should we continue to use hypermail? #8

Open gosko opened 8 years ago

gosko commented 8 years ago

W3C has been using hypermail to generate its mailing list archives for the past 20 years or so. It generally works well but has a few drawbacks:

However, there doesn't seem to be much in the way of software we could use to replace hypermail. Hyperkitty is the only option I have seen that looks viable, but switching archive systems would be fairly disruptive to our user community, and hyperkitty likely has its own set of drawbacks that we don't know about.

So I think we should plan to continue using hypermail for the forseeable future, and try to improve some of its thread navigation features using external code.

But I wanted to open this as an issue in case others want to propose we switch to something else, and to have a place to discuss possible alternatives.

marcoscaceres commented 8 years ago

We could fork hypermail and at least hack a bit on the HTML output? It's not as if anyone is maintaining it, and maybe the HTML output parts are easy to change. Worth a look.

gosko commented 8 years ago

We could fork hypermail and at least hack a bit on the HTML output? It's not as if anyone is maintaining it, and maybe the HTML output parts are easy to change. Worth a look.

@marcoscaceres W3C has been the main contributor for the past decade or so (thanks primarily to Jose Kahan), and we have managed to avoid forking it so far. We can certainly reconsider that and do a fork if the changes we want would be too disruptive to the main hypermail project.

marcoscaceres commented 8 years ago

It would be great if the modifications made their way back upstream.

tripu commented 8 years ago

I was just looking around Hypermail. As a newbie in that project, I submitted one PR and a few suggestions in the form of issues to try to improve its forkability a bit.

gosko commented 8 years ago

This discussion about gmane has some interesting comments about some of its most beloved features. (and one person who really hates hyperkitty)

In particular, a number of people commented how useful it is to be able to create a link to a message based on its msgid, pointing to a threaded view with the specific message highlighted.

marcoscaceres commented 8 years ago

Mozilla moved our mailing lists to Google's list-thing. They are really good - particularly for searching, replying, etc. Why don't we just do that?

gosko commented 8 years ago

@marcoscaceres a few reasons come to mind: privacy, persistence, decentralization.

Also I expect it would be frustrating not to have any control over how things work, and Google doesn't respond to user feedback.

marcoscaceres commented 8 years ago

@marcoscaceres a few reasons come to mind: privacy, persistence, decentralization.

Not much different to what we have today. Persistence and decentralization can still be handled by keeping a copy of the list archive (assuming that is possible somehow).

Also I expect it would be frustrating not to have any control over how things work, and Google doesn't respond to user feedback.

Ok, but compare that to the 20+ year old software we are using today.

gosko commented 8 years ago

Not much different to what we have today.

!? The privacy situation couldn't be any more different, between us hosting it vs. Google.

By persistence I didn't mean losing access to the data, but breaking all the links. I would say one of the best features of our archives (maybe the single best feature) is having the ability to link to something and trust that the link will continue to work 5, 10, or 20 years from now.

Re: decentralization, putting more and more of our data in the hands of a small handful of companies is actively harmful to the health of the Web.

Ok, but compare that to the 20+ year old software we are using today.

Hence this project :)

And it hasn't been unmaintained all that time, we have made a number of improvements. It just needs a bit of an update...

fantasai commented 6 years ago

Totally agree with @gosko's last comment. We use links to individual messages in the email archives a lot, and being able to go back and make sense of historical discussions is important. This won't be possible except with a system we host ourselves--and if we switch systems, we're still going to need those old links to work.

fantasai commented 6 years ago

I'd say, if we were going to continue to use email for issue-tracking, switching to a different system would be worth it if it let us get features that made that more workable. But since we're all switching to GitHub for that, just making hypermail a little bit more usable by addressing the threading issue and adding a handful of minor usability fixes is enough for me.

Fwiw, I'm opposed to switching to some JS-based system, I like the last-century perf characteristics of the current system. :p

tripu commented 6 years ago

@fantasai: I agree about not relying on JS. All usability changes proposed so far are “progressive enhancements” (controversial term, I know), on top of pages that are functional also without JS (try disabling JS on better headers, gravatars, formatting, etc). If by mistake we did something that breaks when there's no JS, we'll change that!

gosko commented 4 years ago

I just discovered another archive system, used by the apache software foundation: Pony Mail. I am not a fan of the styling but some of the features may be interesting.

We still have no plans to move beyond hypermail or invest much time in this project in the near future; just mentioning this here since I'm using this issue to track possible alternatives and look for ideas worth stealing.

ericprud commented 4 years ago

+1 to keeping an eye out for other archive systems.

re Pony Mail, I like their reply rationale but it doesn't appear to have a tree-threaded UI. While Google has concluded otherwise, I strongly believe that tree-threading is essential. For day-to-day issues, it's possible got get by with linear theading (like this issue), but a navigable tree is essential for e.g. making sure that public comments are fully addressed. (Github and its users invent lots of conventions for splitting off issues to get around this but in my adamant opinion, they're crappy approximations of a tree forced, by tooling limitations.)