But still not anonymous. If you’re doing anything remotely likely to make someone powerful unhappy, I recommend not using a real name, or a real email, at the very least. Tor and remailers are likely your friend.
Do you think a mailing list combined with a web-based archive and retrieval system would be a good way to address this?
Although not related to the title, the article includes a 12 minute video and links for using email with git as opposed to central pull requests. I went through the video and link, but it only showed how to send a patch, not the workflow of what happens when a patch is received. I know this is the workflow git was really designed for, but haven’t used it, and would appreciate seeing the workflow end-to-end.
This is possibly what you’re after: git send-email from the perspective of a maintainer.
My main problem with mailing lists is that sometimes it is hard to follow the discussion as it became multithreaded discussion. SourceHut makes it a little bit easier by providing view for them in the single threaded manner. This is a big help when you need to follow the discussion.
Every popular email client I’ve seen will sort mail into threads. Which one is failing to do that?
I meant when I want to check out archives, not when I joined the discussion earlier.
It is a pity that email mailing lists have no way to “catch-up” and download old messages to your client.
Mailman 3 has exactly this functionality. Check the mailman-user’s mailinglist’s web interface for an example: https://firstname.lastname@example.org/latest – on the left there’s a download button which will give you the mailing list’s archive in MBOX format. It is also possible to download an MBOX file for individual threads.
That’s nice, for technical users. How does the average mobile or webmail user can avail themselves of that feature?
Err, that wasn’t the question which I replied to. However, the average webmail user can perfectly browse the web archive provided by Mailman 3. It even supports both a flat view and a threaded view, so you can choose whatever you like. Each thread page has a “sort by date” link for a non-threaded view. Example: threaded – by date
True, I moved the goalpost. Thank you for the heads up about mailman 3!
So the problem is archives that have no concept of threading? Or archives that implement threading in a confusing way?
Most mailing list archives use unnatural (for me) approach for display of the messages. And as previous discussions are often important for the newcomers, it can sometimes become pain point for new contributors.
Most mailing list archives I’ve seen display messages as a response tree.
Without that, I find it hard to wade into threads, since the information about
who’s responding to what is lost. I’d personally prefer to look at:
+ I think foo
+-- Great idea, but bar
| +-- Yeah, and it can be enhanced with baz
| +-- Not sure on bar.
+ Nope, never
| +-- how about if we tweaked it thusly?
I think foo
Great idea, but bar
How about if we tweaked it thusly?
Yeah, and it can be enhanced with baz
Not sure on bar.
Which forces me to tease out from context who is responding to what, and in what order.
I find github threads, gmail, and other similarly flattened interfaces get very unweildy as soon as there are more than a couple of people in the conversation.
It is ok approach when you have threads similar to the one on Lobste.rs, however on in many archives you see only one message at the time and you need to manually traverse the tree, which is irritating and confusing. Also people often cannot write emails properly and you need to traverse a lot through top-posted replies or bottom-posted replies without any cleanup and it is hard to read.
In case of youtube-dl, it is annoying to lose access to a code repository but no one is crying “oh no all my code is gone forever” of course, but rather (for Github) “oh no all the issues/wikis are gone”. I haven’t checked whether the owner(s) still have access to these, but I guess not (?).
The DMCA notice is specifically complaining about code and a bunch of URLs, so blocking the rest of the project’s “assets” looks like an overreaction. Surely there’s a Github software issue here, but also a lack of will to fight.
I’m glad that srht promises to be less docile but only time will tell.