Debian discusses Discourse
Debian discusses Discourse
Posted Apr 17, 2020 20:26 UTC (Fri) by pizza (subscriber, #46)In reply to: Debian discusses Discourse by judas_iscariote
Parent article: Debian discusses Discourse
Email is my universal inbox. I don't have to remember to check a dozen (or more) distinct web pages or whatever to make sure there's nothing else that needs my attention. That _vastly_ improves my overall productivity, and I'm sure I'm not alone in that regard.
Posted Apr 17, 2020 22:04 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
I miss loads of stuff because I can't tell what I have and haven't read.
(even here :-)
Cheers,
Posted Apr 18, 2020 20:37 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
As a subscriber, you can have the posts rendered with different colors based on whether you've fetched them before when logged in.
Posted Apr 19, 2020 12:15 UTC (Sun)
by excors (subscriber, #95769)
[Link] (1 responses)
Posted Apr 19, 2020 12:23 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 19, 2020 3:28 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (26 responses)
That's _exactly_ what is wrong with mailing-lists, (sincere!) thanks. Information and people don't decide when they need my attention; I go and find specific information / discussion / code review when I need it and only _if_ I need it. Often not.
"Universal inbox" = merging into a single firehose various signals that were separate in the first place... and then have every user independently configure and run bespoke filters, local search engines and other scripts to reverse entropy. We've been in the information overload age for a few decades now; I trust your made-to-measure solution to that problem is crazy efficient and admirable, but is it really so hard to understand that most people can't bother and find "ready-to-wear" much cheaper and good enough? "I just want to talk to people!"
Now don't get me wrong: "ready-to-wear" is NOT good enough yet. I'm afraid it'll never be as long as the geniuses that could make it so keep wast... spending their time in their respective garage fine-tuning their email scripts. See my other post above.
Can't resist quoting https://lwn.net/Articles/817795/:
From the same person:
I wish I had that much perspective on both the old and new ways when I was your age. Thanks for articulating and sharing it that well.
> As Steve McIntyre put it:
I guess very many, that ship has sailed.
Not counting myself as "great", the only reason I recently contributed some patches to debian and actually went through the review process is because https://salsa.debian.org/ exists. I would have just uploaded a throw-away branch somewhere otherwise, most likely on github.
Posted Apr 19, 2020 13:50 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
"not good enough yet" is a gross understatement, because the problem is fundamentally asymmetrical. *everyone* who wants to "communicate" [1] with you considers their stuff the most-est important-est EVAR and something that NEEDS to be read IMMEDIATELY. And at any given point, only one of them can be right...
> "Universal inbox" = merging into a single firehose various signals that were separate in the first place... and then have every user independently configure and run bespoke filters, local search engines and other scripts to reverse entropy.
...and only the final recipient can assign relative priorities between those various communications, and in order to do that, they have to have everything aggregated into a single place. (Because at the end, it all goes into the same pair of eyeballs, no?)
And thank you very much, I want that place to be something _I_ control, not a service that requires constant genuflection to the Monks of Google, tithing to the prosperty gospel hucksters of Microsoft, or allowing Facebook to track my every bowel movements.
> but is it really so hard to understand that most people can't bother and find "ready-to-wear" much cheaper and good enough? "I just want to talk to people!"
If all you want to do is "just talk to people" then that approach is fine. But we are not discussing "just talking to people" here, we are talking about how to effectively collaborate with dozens, of not hundreds, of people. And then repeating that several times over. And every app, web site, and organization out there that thinks nothing of sending you multiple "here's what you should be paying attention to, and, oh, buy our stuff" messages a day.
Being able to more effectively (and efficiency is part of effectiveness) communicate is a strategic asset in today's knowledge-based economy. Why would one not choose to cultivate that?
So.. yes, "ready-to-wear" is genuinely not good enough for them; their approach to "information overload" is to leave thousands upon of unread messages in an inbox, effectively covering their ears and going LALALAICANTHEARYOU -- how does one know if one of those new messages is actually something important? The short answer -- they can't, because they _choose_ to let the noise drown out the signal. This is the same principle behind "zero compiler warnings" -- if you're used to seeing hundreds (or thousands) of superfluous warnings, you're going to miss the handful that you genuinely need.
To be blunt again, this is analagous to the gap between an amateur and a master craftsman, only here the amateur is trying to tell the craftsman to scrap their entire ashop and switch to a walmart-grade 3D printer. Or a "Nailed It!" participant telling a pâtissier that all they actually need is an ez-bake oven.
If one wants to get better at something, it takes sustained effort and discipline, and the willingness to accept that one will have to change one's ways, likely multiple times.
> That's _exactly_ what is wrong with mailing-lists, (sincere!) thanks. Information and people don't decide when they need my attention; I go and find specific information / discussion / code review when I need it and only _if_ I need it. Often not.
How is this a "mailing-lists" problem, and not a problem with literally every method of communication ever? If anything, mailing lists make this simpler, because I can then use my standard MUA to rapidly filter/discard stuff I don't care about. -- Of the mailing lists I'm on, I probably delete 95% of what comes in without reading it, and respond on average to a fraction of a percent. But that approach is far, far more efficient than hitting a web site multiple times a day. Now multiply that by several hundred other sites for every other thing I attempt to stay on top of. That approach simply doesn't scale.
[1] I especially include notifications here.
Posted Apr 19, 2020 16:37 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
- I can subscribe to get only the first message in any thread. Since they "automute" after this, filtering out things uninteresting to me is *far* easier as I don't keep getting updates to things I already deemed unimportant. Nevermind getting hooked into a thread after I've deleted the start of the thread I previously deemed useless.
Most of my gripes have been mentioned elsewhere in the discussion and are largely the same. One other thing I dislike is that there's no "I've already gone through this" escape hatch for the "welcome to Discourse" bot upon signing up.
I think if you're in a dev-heavy environment (e.g., patch slinging, intricate threading becomes a thng), lists can work, but if you have users who just want to ask a question or two and then leave, a list is a very poor tool (imagine having to watch or subscribe to a repo before being able to file an issue). Once we had the user lists migrated, the dev lists weren't that much more to move over as well, but our traffic is probably more heavily weighted to user discussion than dev. Other projects with different balances may rather keep the dev list. But end-user interactions are *far* better on Discourse IME.
Posted Apr 19, 2020 17:21 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
I agree that end-user interactions are usually far better served by a forum of some sort than an email list, especially when combined with an actively-curated knowledge base (eg wiki or a stack overflow sort of approach)
My experience with "serious" development, on the other hand, seems to indicate that the optimal approach involves use of a good code/patch-review tool (eg gerrit) tied to a CI system, combined with some sort of group chat (eg irc) for immediate things, and a mailing list for long-form discussions.
Posted Apr 19, 2020 17:42 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
We've been looking at some way to use Discourse for this. I've also been pushing to get the wiki information adapted into in-repo docs where appropriate so they end up in the Doxygen and have a hope of being updated when situations change (the wiki got locked down registration years ago due to spam and has languished accordingly).
> My experience with "serious" development, on the other hand, seems to indicate that the optimal approach involves use of a good code/patch-review tool (eg gerrit) tied to a CI system, combined with some sort of group chat (eg irc) for immediate things, and a mailing list for long-form discussions.
I largely agree (though I disagree about Gerrit in particular, but that's out-of-scope here ;) ). However, in our case, the dev list doesn't get that much traffic, so it was easier to just stuff it onto Discourse as well. Roughly:
- design discussions -> Discourse
is the categorization we use. Since that then involves only two systems (Discourse and the code host) rather than 4, it's a lot easier to deal with (we do have chat, but that is company-wide rather than community-wide).
Posted Apr 19, 2020 17:00 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (2 responses)
I don't doubt that people who have invested time and effort in fine-tuning email are the most efficient at processing large amounts of information. Unfortunately, that investment makes a number of them too emotional to see past temporary and irrelevant UI implementation issues and consider alternative ways to _structure the data_.
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#...
> their approach to "information overload" is to leave thousands upon of unread messages in an inbox, effectively covering their ears and going LALALAICANTHEARYOU
We're all human with limited bandwidth in the end.
Posted Apr 19, 2020 17:39 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
I think you inadvertently hit the nail on the head here, and basically summed up the point I was trying to make:
One can't [re]structure data one doesn't control.
And at the moment, email provides the only way to extract and aggregate that data so that one can actually take control, and begin to think about restructuring it in a way that makes it more manageable.
All of these other systems require handing control of your data to third parties -- even if you assume the best of intentions on their part, the structures they impose will their reflect their interests/needs, not yours.
Posted Apr 19, 2020 18:51 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
gitlab, discourse, mattermost and likely many others can run "on [the project's] premises".
> the structures they impose will their reflect their interests/needs, not yours.
I have no doubt Debian (and Fedora) will fork gitlab the second gitlab.com "imposes" data structures they can't tolerate.
Again I am _not_ saying gitlab is perfect or even more productive than an email workflow with decades of investment. I'm merely answering your point about "control" and (LCD) structures.
Posted Apr 20, 2020 8:46 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (18 responses)
I think your issue is just a poorly configured email client. On kmail you can just create rules per mailing list and move the various mailing lists in various directories.
Posted Apr 20, 2020 16:16 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (16 responses)
I'm not going to repeat all the issues already mentioned in this long thread and in many other places, I understand not everyone has the time to read all the comments (sense a theme here? :-)
So just this: imagine you want to submit yet another once-off, "drive-by" fix for an issue in yet another tool you hope you'll never have to contribute to again (cause you just want to use it). Of course the first thing you do is look at the past code reviews for the code you're modifying. Manually subscribing to a mailing list and configuring a filter helps you with absolutely none of that. It just takes some time and adds noise. Modern tools achieves that in a few clicks and/or keystrokes.
There's a somewhat of an analogy between "One mailing list per (sub)project" and "One version control per file". They're both incredibly static.
Posted Apr 20, 2020 19:45 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
I guess any replies would be ccd to you so it is ok to email it externally.
Posted Apr 20, 2020 20:42 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
Most mailing lists now restrict posting to subscribers. Some auto-moderate stuff from unrecognized addresses, but the legit stuff tends to get completely lost under the deluge of spam. So yes, subscription is usually necessary if you want your messages to get through.
Posted Apr 20, 2020 21:41 UTC (Mon)
by madscientist (subscriber, #16861)
[Link]
Yes, lists are moderated so that non-subscribers have to wait to be approved. But even moderated lists do spam pre-filtering so moderators will generally find your message quickly and easily approve it and messages certainly do not get lost in a deluge.
As long as you don't mind some (typically pretty short) delay before your message is seen there's no need to subscribe.
Some lists support whitelisting: when a moderator approves your first message they will add you to a whitelist so you won't have to wait for subsequent messages.
Posted Apr 20, 2020 20:36 UTC (Mon)
by pizza (subscriber, #46)
[Link] (11 responses)
This initial-contribution speedbump is not avoided by simply avoiding email -- There is nearly always some sort of signup/joining for whatever tooling/channels a given project uses, and the would-be contributor will still need to jump through whatever hoops they've imposed.
For example, forums still require you to sign up (providing an email address or phone number). Once joined, you still probably won't have posting rights out of the gate, because spammers and bots have ruined a lot more than email and email lists.
Even if you limit yourself to github by assuming everyone and everything that matters is hosted there, I can speak from experience in saying that a random unsolicited pull request will rarely get accepted as-is, and more often than not gets dropped because the initiator of that PR (or issue/ticket) can't be bothered to respond.
Posted Apr 20, 2020 22:07 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
https://lwn.net/Articles/797613/ "Change-Id"
Every code review solution that has solved this [database] problem also got a email notification system much more flexible than a mass mailing list.
Who still reads LKML?
Posted Apr 21, 2020 7:30 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (9 responses)
In many cases I can login using my Google account.
Posted Apr 21, 2020 15:13 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Yes, OAuth/OpenID/etc. and password managers have largely solved the spam versus account proliferation issue. There may be be better ways in theory but in practice they are IMHO "good enough" for now.
I think these problems and their solutions are mostly orthogonal to the main topic = basically off-topic.
Posted Apr 22, 2020 13:21 UTC (Wed)
by gray_-_wolf (subscriber, #131074)
[Link] (7 responses)
Yeah, which is awesome way to lose access if Google ever decides it does not
Posted Apr 25, 2020 1:47 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (6 responses)
This true of every account consolidation solution, any better concept?
If this comment was specifically about Google, any better OAuth / password manager recommendation? With FIDO 2FA please!
Posted Apr 25, 2020 4:19 UTC (Sat)
by pizza (subscriber, #46)
[Link] (5 responses)
Sure, run your own single-user OpenID provider on a cheap $5/mo VPS host.
Then your identity is truly *yours*, and can't be taken away from you.
(Yes, I realize this takes a little bit of money, and a little bit of work. So only folks that truly care will bother)
Posted Apr 25, 2020 11:35 UTC (Sat)
by rschroev (subscriber, #4164)
[Link] (4 responses)
In any case I'm not entirely sure but I don't have the impression there are many sites that support you using your own OpenID.
Posted Apr 25, 2020 13:19 UTC (Sat)
by pizza (subscriber, #46)
[Link]
Unfortunately, you are correct. Big sites are more than happy to act as an OpenID identity provider; after all it gives them more opportunities to collect data on you and increases lock-in with their services, but very few accept anyone else acting as a provider.
Welcome to the future, I guess.
Posted Apr 26, 2020 7:22 UTC (Sun)
by jezuch (subscriber, #52988)
[Link] (2 responses)
It sucks.
Posted May 4, 2020 17:54 UTC (Mon)
by wookey (guest, #5501)
[Link] (1 responses)
I'm not telling either of those entities which sites I visit so have never used the 'log in with unpleasant entity' button. But the alternative is trusting each and every site (there must be hundreds by now) to take good care of my credentials. They do of course lose them on a regular basis. Quite why I'm not allowed to manage my own identity, I don't know.
Posted May 6, 2020 6:10 UTC (Wed)
by jezuch (subscriber, #52988)
[Link]
To clarify, I mean the kind of managers who say that we don't have time for writing tests and refactoring. Which I think is most managers?
Posted Apr 21, 2020 16:10 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Another real-world example one step above the one patch, drive-by contribution.
For my previous project I needed project X on githab, made a number of small contributions to it and discussed in a few issues. I don't need X anymore yet I keep receiving notifications if anything still happens on these patches and issues. I don't receive anything about newer stuff I don't care about. All this with absolutely zero manual subscription or filter configuration. If one of the issues is too active and doesn't interest me any more I can unsubscribe from just that one in a couple clicks/keystrokes. If there's a new patch or issue following up something I did then anyone can Cc: me on just that one. Etc.
Subscribing to a mailing-list is like committing to a relationship. Sometimes you want or need to but plenty other times you want a looser connection; like in the "real world". If you read again the comments posted here with that perspective you will sense this "Are you with us or not?" mailing list vibe.
Posted Apr 20, 2020 18:53 UTC (Mon)
by Deleted user 129183 (guest, #129183)
[Link]
I’d say rather “poorly designed”. Old Opera M2 sorted the incoming mailing list messages into per-list directories *automatically*. It was a feature that from the usability perspective is completely obvious, yet I haven’t seen any other e-mail client doing the same.
Debian discusses Discourse
Wol
Debian discusses Discourse
> (even here :-)
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
> I've got several thousand unread emails in my inbox at any given time, and I'm not too concerned about reading most of them, because I already read all of the messages that I actually need to care about. The rest, I just let float by into the ether, occasionally plucking one from the stream of detritus if the subject line looks interesting
> As one of the twenty-somethings who seem to always get blamed for not liking email sufficiently, I thought I'd chime in on this.
> Hell, there's a strong confirmation bias here too - how many potentially great future developers have we lost at a very early stage because our email-centric workflow didn't appeal to them initially?
Debian discusses Discourse
Debian discusses Discourse
- I'm not juggling Nx the number of lists versus projects (usually -announce, -devel, and -users). Instead of yet another private list or (worse) direct private emails (where information goes to die a lonely death), we can just use a restricted section of Discourse.
- Cross-referencing between those "lists" if a cinch. (As is moving threads if someone starts off in the wrong place.)
- Replies which are "solutions" to the original problem are marked as such. This makes figuring out if a thread is "done" or not is also very easy.
- Top-posting is essentially gone (not-quoting is still a thing, but that's not new).
- I don't get multi-meg images dumped into my email. Then quoted and duplicated for the rest of the thread.
- Engagement is way up. Mostly on the user side where other users seem much more ready to reply to questions with answers before I have to spend time on it. I can just look at the "solution" reply, maybe add a clarification, and then I can ignore the rest instead of the thread without spending time reading it all. Development discussions seem to be about level.
- Jumping in on an existing thread is much easier. I hate having to craft headers to hook my reply into a thread that started before I subscribed. This allows new users to answer old questions too (something I've ~never seen elsewhere except forum software and hard-core nntp users).
- I don't have to tell others to CC me on a thread where I have list delivery turned off.
- 2FA support. And no more "here's your password in plain text" emails every month.
Debian discusses Discourse
Debian discusses Discourse
- design discussion conclusions -> issue
- implementation details -> MR (but go back to an issue/discourse if problems are found)
Debian discusses Discourse
> [...]
> Of the mailing lists I'm on, I probably delete 95% of what comes in without reading it,
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
> The problem Anderson describes is real enough; your editor, who spends a lot of time digging up old versions of patch postings to work out how a patch has evolved over time, can attest to that.
For example, forums still require you to sign up (providing an email address or phone number).
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
like you.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse