Suggested to a source forge that gets flack for being inaccessible/elitist that they simply use the plain text part in a multi-part email instead of rejecting it on their discussion list as some folks are limited in their ability to send text-only email.
Response: we consider that a bug in your email service provider.
Context: there’s a tool I use and want to contribute to but I can’t without jumping through arbitrary hoops. I’m emailing with the author directly now because it’s easier.
*smh*
I’m emailing with the author directly now because it’s easier
To be fair, being able / encouraged to do that is a good thing imo. Directly emailing the author is good for the Git network (regardless of the format of the email), and its something that popular forges often make very difficult to do.
@robby I disagree. When a conversation is had in the open and there’s a record others benefit from it also.
@robby (And anyone can place their email address on their profile on ~ any service. As far as I’m concerned, that’s a last-try contingency. When all else fails.)
I think encouraging the use of email from the start is a good thing, because it makes contacting the authors a non-issue. Contacting the author *publicly* is a different problem, and it's about as much of an issue on GitHub as <unnamed forge> (our way or the highway + git commit messages).
@robby Oddly, I’ve never had a problem opening an issue on GitHub/GitLab/Gitea, etc. In fact, it’s never something I’ve had to think about.
I don't have a GitLab account, and my GitHub account is essentially dead, and I'd rather not use it. I have no pressure to create an account on <unnamed forge> because I can interact with it entirely over email (I'm lucky enough that my email setup handles plain text fine).
To be clear, I think your idea for simply keeping the plain text part is an interesting one. I'm thinking there is more of a reason to their decision against it than they shared, and I'm curious why. Modifying emails to format them for a mailing list does seem like it could cause trouble.
And that's only after you have registered on their platform of choice to begin with.
As a security researcher I sometimes spend way too much time to track down a safe contact for a vendor so that I can submit information about vulnerabilities in their software to them in a responsible way.
@robby I’m talking about emails sent to a project’s discussion list. Not patches :)
@aral until ~25 years ago i used a popular text-based e-mail client and agreed with the "down with html email" "wrap your lines at 79 characters" "don't top-post" crowd. because someone might be using an old system or software that can't do html?
but then i realized how ridiculous it is to spend a lifetime whining at everyone for not adjusting their behavior to suit my software
if free software is as great as we say, we should be able to adjust its behavior to suit people instead of vice-versa
@aral (email embedded in proprietary microsoft word documents is a different story but nobody attempts to do that anymore)
Others at least try to render the html part as something readable in the plain text part, but with varying success. More often than not the result is difficult to decipher in any meaningful way, or even completely unreadable. (I've got emails where the plain text part had all the correct letters, but no whitespace, for example.)
Neither of this is anything you would want to clutter up your discussion list.
Tbh, I think the only way to do it is to pass the html part along so that the client can decide which part to render and how.
@aral yeah, I ran into that recently while trying to submit an issue on a sourcehut project
it's borderline impossible to send a plain text email from gmail on a mobile device
you have to go in the browser, enable desktop mode and manually put in a URL to be put on the full desktop frontend, which is the only one that allows setting an email as plain text
(even an email without formatting is otherwise considered HTML)
but also, maybe sourcehut should just strip the formatting from HTML mails, instead of completely rejecting them and dumping the problem on the user.
In theory you could use any client that supports sending plaintext but this is one I know of that has this switch
@aral What is "a source forge?" I've never heard of that as a generic term. Is it a generic term for a SVN repository or something?
@mdhughes @aral I never much liked Sourceforge, but I could never quite put a finger on why. I remember the rumors (apparently w. receipts) about malware in binaries. Long before that, I recall noting the forced wait for downloads and thinking "that's a pretty brazen monetization tactic, even for the commercial web."
@mdhughes @aral I'm very sold on the self-hosting philosophy, in my case probably a little more PESOS than POSSE, although I'm trying to migrate to the latter. Big downside to that is much of the very best content in the history of online has been lost to the sands of time due simply to someone not being able to pay their hosting or domain name bill. So Internet Archive is near the top of my to-do list of donations.
@mdhughes @aral "Trust no-one" is something I've also learned the hard way, and yes, I also don't trust the non-commercial sector to remain non-commercial (Mozilla being a whopper of an example there), but I've also concluded that, for now, donor-funded activities are the only viable alternative to monetization, which is to say, predatory behavior.
There’s a fine line between having principles and being arrogant/elitist/inaccessible. I believe folks in the #foss world aren’t always aware of where that line is and that hurts the whole movement.
When I’m feeling a bit better (hopefully later this week, still taking it easy as I recover from COVID), I’m going to put up the recording we did with @gabek (hope you’re feeling better too, btw… also COVID) where we go into this in the context of small web.
#foss #design #usability #accessibility