Debian discusses Discourse
Debian's discussion began on April 10, when Neil McGovern announced the existence of a Discourse instance at discourse.debian.net. He asked for feedback on whether the project was interested in Discourse, and said that he thought it might make sense to move some mailing lists over:
One invariant over the Debian project's long history is that, if one asks for feedback, one will get it. Indeed, the "asking" part is generally unnecessary. Feedback is exactly what McGovern got.
Moves to systems like Discourse often raise concerns about usability, and that was certainly the case here. Developers who do not want to have to fire up a web browser to communicate with other members of a project are not in short supply anywhere. It has often been pointed out that Discourse offers email integration, and just as often that this integration falls rather short of how fully email-based communication works. Discourse cannot be used offline, doesn't work with terminal-based workflows, and requires a JavaScript-enabled browser that may be too resource-intensive for the PDP-11-based development system that somebody is surely still using. There was little new in that part of the debate.
Moderation, trust levels, and gamification
One of the features that Discourse proponents tend to like is the support for distributed moderation of discussions. A discussion on a Debian list seems sure to turn out developers who are opposed to moderation in any form, and indeed one such duly put in an appearance. Overall, though, opposition to moderation was not a strong theme in the discussion; Russ Allbery pointed out that the mailing list on which the discussion was being held is moderated, and said that this is a good thing:
Given the recent history of attacks on the Debian project, arguments against moderation of the communication channels seem less likely than usual to find wide support.
That said, the way in which Discourse handles moderation did raise a few eyebrows. Rather than having specific people designated as moderators, Discourse spreads that task among the "trusted" members of the community. There are, by default, five trust levels; new users start at level 0 and work their way up from there. At level 3, users can flag posts and cause them to be hidden.
Movement through the trust levels is managed automatically by the system (with the exception of the highest level, which requires manual promotion). Moving up requires that the user spend a specific amount of time on the site, read a certain number of articles, hand out and receive "likes", and more. To implement this mechanism, Discourse tracks the amount of time spent reading each article. Reaching level 3 requires visiting the site 50 out of the last 100 days, replying to at least ten different topics, viewing at least 25% of new topics, and more. Users can be demoted back to level 2 if they fail to maintain that level of performance.
This aspect of Discourse repels a number of Debian developers for a couple of reasons. Debian folks are naturally resistant to the idea of a communication system that is monitoring their activity, tracking the time spent on each topic, and making decisions based on that data. Many of them use free software precisely to get away from that kind of thing. They also dislike the whole "gamification" aspect of this system — a feeling that is only made stronger by the extensive system of "badges" handed out by the system to encourage various types of activity. As Ansgar Burchardt described it:
Current project leader Sam Hartman agreed that
this mechanism "does not seem to meet Debian's needs very well for
trust
". McGovern said
that this mechanism can be reconfigured or turned off entirely if the
project desires, but he also emphasized that it does help to make the
moderation system work well.
Archival and new developers
Another area of concern is archival. Email is easily archived by anybody with the storage space to accumulate a mailbox full of messages; Discourse conversations, instead, live within the instance's database. This seems more like a problem that needs to be worked out than a serious blocking issue, though. Charles Plessy pointed out that email archives are often messy and do not make finding required information easy; he suggested that a system like Discourse might work better for the task of getting useful information out of the archive. There is also, McGovern pointed out, a mechanism to automatically summarize the discussion on a topic (seemingly by picking out the most "liked" posts) that make it easier to figure out what the state of a discussion is.
The tone of the discussion overall struck many as hostile toward the idea of using Discourse. That may at least partly be the result of a fear that the project's mailing lists will be turned off and use of Discourse will be mandatory. But there were still positive comments about aspects of the system. For example, Allbery said multiple times that he is fully comfortable with an email-based workflow, but still sees things to like in Discourse. These include splitting threads that have wandered off topic, pinning messages with important information where all will see them, the quick ability to indicate agreement with a "+1" click, and more.
And, underneath the whole discussion, is an awareness that, while current developers may be comfortable with email, the newer developers they might like to attract often are not. As Steve McIntyre put it:
Moving to a more "contemporary" system might help to keep some of those developers around, but there is the opposite problem noted by Raphael Hertzog: web forums can also drive developers away. Finding a solution that appeals to everybody is not a straightforward task.
McGovern, meanwhile, has expressed
some frustration with the topic and suggested that he might give up on
the whole thing. That would be understandable, but might also be
unfortunate; Debian might not, in the end, prove as hostile to the idea as
it seems now. With some work, it may be possible to move a Discourse
instance in the direction that current Debian developers will accept while
appealing to new developers; Marco Möller posted
some ideas that could be a good starting point.
But this is Debian, so the process of reaching consensus on a change like
this is never going to be smooth.
Posted Apr 17, 2020 17:01 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (76 responses)
Posted Apr 17, 2020 17:12 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (75 responses)
Posted Apr 17, 2020 18:17 UTC (Fri)
by josh (subscriber, #17465)
[Link] (74 responses)
Posted Apr 17, 2020 18:34 UTC (Fri)
by pizza (subscriber, #46)
[Link] (72 responses)
There are things you can't do via email that you can do via the discourse UI -- and that is pretty much the entire point of using discourse; to gain those additional capabilities. This means email users are by definition second-class, and that's even before one considers the importance that discourse places on rewarding "user engagement".
It leads to an entirely different user interactivity paradigm, and therefore culture, than traditional email. I make no value judgement if that's _better_ or _worse_, just that it is inherently different.
(That said, I do find it sadly hilarious that we keep reinventing the wheel to compensate for ever-crappier mainstream email clients. Small wonder nobody wants to use email any more..)
Posted Apr 17, 2020 20:57 UTC (Fri)
by josh (subscriber, #17465)
[Link] (39 responses)
Email is a lowest-common-denominator. Should it be a limiting factor preventing the use of other communication mechanisms, just because those mechanisms can't be translated to email?
Posted Apr 17, 2020 21:28 UTC (Fri)
by pizza (subscriber, #46)
[Link] (26 responses)
I don't know if I'd call email a LCD; there are a ton of things I can do via email that those other communication mechanisms can only dream of, because I'm not limited to whatever features those other tools have deigned that I shall have access to. Including aggregating every account on everything, highly expressive filtering, multiple personalities, full indexing and searching, and the ability to fairly easily tie into other tools. Oh, and total control over my own data.
(Of course when "email" just means "gmail/o365 web/app" then many of those would-be benefits go right out the window..)
Meanwhile, back to Discourse -- like other tools designed around "user engagement", it is set up to reward frequent, shallow uses, and penalizes those who use it more infrequently but with longer/more considered responses -- because more page hits mean more opportunities for data gathering and advertising impressions. Due to those metrics, folks participating via email (or indeed, even the main UI but not logged in) are _penalized_ versus those that remain logged in.
That is what is meant by email users being relegated to second-class citizens -- and yes, while a self-hosted Discourse instance allows one to turn off many/most of those "engagement"-oriented features, you're left with what basically amounts to a crappy forum with a crappier mailing list bolted onto the side.
Again, I'm not saying that a discourse forum is necessarily _worse_ than a mailing list, but the choice of tools influences the culture that develops (and vice versa), and Debian-as-an-organization has some very strong views on the sort of culture they wish their organization to embody, culture that seems to be incompatible with what Discourse fosters due to its fundamental design. Will that desired culture detrimental to Debian in the long run? Time will tell, but either way it's their sandbox.
Posted Apr 18, 2020 0:06 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (18 responses)
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.
For me, "email" does mean "Gmail." I know perfectly well that I could set up a local MUA and configure it fancily, but frankly, setting up adequate (but not great) Gmail filters is already an order of magnitude more effort than I actually wanted to spend in the first place. I just want to talk to people! I don't really care whether it's over Gmail, Discourse, or some other thing, so long as I can access it from x-www-browser (because I already spend a lot of time on the web for other purposes anyway, and human context switching is far more expensive than computer context switching). In practice, Gmail serves that purpose acceptably. However, if I'm limited to plain text emails (I've never encountered a mailing list that encourages the use of HTML), then the actual feature set available to me is rather circumscribed in comparison to other technologies. So that's why I do regard email as a LCD. That doesn't mean I don't use it - my family is actually rather frustrated that I refuse to use Facebook etc. But it does mean that I consider it a legacy technology, which primarily serves as a backup option for people who are not otherwise able to communicate.
> Meanwhile, back to Discourse -- like other tools designed around "user engagement", it is set up to reward frequent, shallow uses, and penalizes those who use it more infrequently but with longer/more considered responses -- because more page hits mean more opportunities for data gathering and advertising impressions. Due to those metrics, folks participating via email (or indeed, even the main UI but not logged in) are _penalized_ versus those that remain logged in.
I agree that engagement metrics are Not Great, especially for a project such as Debian. They might make sense for a community where forum posts are the primary or only means of participation, but that obviously does not describe any open source or free software community. There are quite a lot of forum-only internet communities not related to software development, who are probably the intended target of these features.
> That is what is meant by email users being relegated to second-class citizens -- and yes, while a self-hosted Discourse instance allows one to turn off many/most of those "engagement"-oriented features, you're left with what basically amounts to a crappy forum with a crappier mailing list bolted onto the side.
I'm not sure you're giving forums, in general, enough credit here. A forum has a far lower barrier to entry than a mailing list, for several reasons (note: in this context, "entry" = "mostly lurking with limited posting"):
- Most mailing list web interfaces (e.g. Mailman/Pipermail) force you to read one email per page-load, while most forum software allows you to read many messages per page-load. Even if this was the only benefit, it would be enormous all by itself.
Posted Apr 18, 2020 0:46 UTC (Sat)
by pizza (subscriber, #46)
[Link] (4 responses)
I'm glad you have something that is "good enough" for your purposes, but without a decent MUA and a workflow I've refined over many, many years, I'd have been long overwhelmed by the sheer volume of communication traffic I need to stay on top of and meaningfully respond to, much of it highly technical in nature.
Yes, there was a learning curve for this stuff, and maintaining it takes some time and effort, but in return, I gain efficiencies that pay for themselves many, many times over in the form of (much!) higher personal productivity.
>> That is what is meant by email users being relegated to second-class citizens -- and yes, while a self-hosted Discourse instance allows one to turn off many/most of those "engagement"-oriented features, you're left with what basically amounts to a crappy forum with a crappier mailing list bolted onto the side.
> I'm not sure you're giving forums, in general, enough credit here. A forum has a far lower barrier to entry than a mailing list, for several reasons (note: in this context, "entry" = "mostly lurking with limited posting"):
It was not my intent to call all forums crappy, just that Discourse with those "engagement" features turned off amounts to little more than a relatively crappy example of a forum, with an even crappier implementation of a mailing list tacked onto it. In other words, turn those features off, and there are better forums, and much better mailing lists.
Posted Apr 18, 2020 6:54 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
I receive a large volume of email as well. I found that prioritizing emails with my own address in the To: and CC: lines, and one or two carefully chosen lists, was sufficient, and nearly all of my other filters are just quality-of-life "skip the inbox" filters. 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. I'm sure this sounds horrifying and uncivilized to some readers, but I read all the email I need to read, and I don't read the rest. Isn't that what a filtering strategy is meant to accomplish?
> Yes, there was a learning curve for this stuff, and maintaining it takes some time and effort, but in return, I gain efficiencies that pay for themselves many, many times over in the form of (much!) higher personal productivity.
I'm well aware of this general concept; I have a highly tricked out zshrc and a moderately tricked out vimrc. I just don't see much point in extending that effort to email when the only benefit is making the number next to my inbox folder smaller (as opposed to, say, allowing me to execute commands or edit text with fewer keystrokes, which directly increases my productivity).
> It was not my intent to call all forums crappy, just that Discourse with those "engagement" features turned off amounts to little more than a relatively crappy example of a forum, with an even crappier implementation of a mailing list tacked onto it. In other words, turn those features off, and there are better forums, and much better mailing lists.
That's certainly fair, and I'm not sufficiently experienced with forum software to comment here. My concern, however, is that nobody is discussing any forum-like alternatives as far as I can see from limited skimming of the Debian discussion (as I mentioned above, there's a laundry list of reasons why these discussions are hard to read as a non-participant, so I may have missed something). And it's likely that many of the same arguments you and others are making against Discourse would translate to most other forum software packages as well (none of them are going to support POP3 or SMTP, for example, so you won't be hooking your MUA up to the forum).
As a result, I fear the "older" open source and free software communities may reject forums altogether, and wall themselves off into an aging and disfavored protocol. SMTP already requires numerous weird extensions to the RFC just to make it slightly harder to send spam, and its encryption story has never made much sense in comparison to HTTPS. Meanwhile, web-based technologies get more powerful and modern every year. Meanwhile, the "younger" open source (mostly) communities will embrace GitHub et al. and refuse to even have mailing lists, which creates a worst-of-both-worlds scenario wherein Debian developers (and anyone else in the "distro" space) have to constantly context-switch between their MUAs and their browsers to interact with each other and upstreams respectively. There's also a serious risk of email ceasing to effectively federate, as more and more anti-spam measures are piled on top of a system that was never designed for a global, trustless internet. I don't think this is happening any time soon, but nobody appears to be planning for it at all.
There are problems with web-based tech, too. Federation is usually poor to nonexistent (unless you count dumb hyperlinking), many sites are bloated beyond all reason, the web is increasingly a Chrome/Chromium monoculture, and it's not clear that anyone actually cares about any of these problems enough to do something about them. However, if all of the people who most strongly object to those issues simply avoid using the web entirely, then the web will continue to develop without their input, and things will get worse.
Posted Apr 18, 2020 13:01 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
It's worth noting that what makes this hard is that you were a _non-participant_, not because it took place via email versus Discourse or some other forum. How do you ensure you don't miss something important, without reading the whole thing? (Important to _you_, not what others involved might think is important. Because, especially when discussing technical things, the details matter)
> And it's likely that many of the same arguments you and others are making against Discourse would translate to most other forum software packages as well (none of them are going to support POP3 or SMTP, for example, so you won't be hooking your MUA up to the forum).
This is one of the points I tried to make earlier. I've participated in forums where the admins went through great lengths to make email users have a first-class experience in the discussions. Technically, it worked great, but for any given message, you could *always* tell who wrote it via email and who wrote it via the web site -- not just from superficial details like quoting style or the typical length of the response, but the depth of what was said as well -- the difference between the cultures was quite stark. It quickly became clear that folks who did most of the actual development work overwhelmingly preferred email, and the mass of non-[code-]contributing users overwhemingly preferred the forum.
Of course, looking just at the traffic/usage metrics the latter vastly outnumbered the former, leading naive outsiders to question why so much effort went into supporting those old fogeys who just didn't want to embrace modern things..
I've seen this pattern repeat itself many, many times over the years.
(Oh, and you don't need to make your forum directly speak POP3; that's what the recipients' email servers are for, and these days webapps that do any sort of email notifications nearly always directly speak SMTP)
> However, if all of the people who most strongly object to those issues simply avoid using the web entirely, then the web will continue to develop without their input, and things will get worse.
Until, of course, those developing those "modern" web thingeys with ever-more-"modern" tooling realize they still need an actual operating system running on actual hardware, at which point their heads explode when they encounter that _very_ different mentality and culture.
Systems administration used to be the ultimate example of "box of tools, make it do what you want" and a necessary rite of passage (or minimum threshold of competence to enter) but now, like so much else, it's just another platform API to interact with, handed down from up high on immutable [1] slabs of javascript.
[1] Immutable for the end user; the service provider can and will change it whenever they feel like it.
Posted Apr 18, 2020 16:04 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
I already rattled off a huge list of reasons why I disagree with this assertion. I will not repeat myself.
> How do you ensure you don't miss something important, without reading the whole thing?
Is this a trick question? I would read the whole thing. But that's a lot easier when it's in a forum than when it's in an email thread, as I explained.
> Until, of course, those developing those "modern" web thingeys with ever-more-"modern" tooling realize they still need an actual operating system running on actual hardware, at which point their heads explode when they encounter that _very_ different mentality and culture.
Pffft, they don't need to care about that. Just look at Chrome OS. Sure, someone has to develop Zircon etc., but the average web developer does not care.
> Systems administration used to be the ultimate example of "box of tools, make it do what you want" and a necessary rite of passage (or minimum threshold of competence to enter) but now, like so much else, it's just another platform API to interact with, handed down from up high on immutable [1] slabs of javascript.
This is a Good Thing, it means more people can contribute with less effort. Sure, they may be using a methodology, language, and layer of abstraction that is foreign to your experience, but they're still, y'know, developing software.
Posted Apr 18, 2020 16:29 UTC (Sat)
by pizza (subscriber, #46)
[Link]
Our experiences obviously differ, but the best interface I've personally used for staying on top of a large number of mailing lists is a nntp reader pointed at the gmane nntp gateway.
> Pffft, they don't need to care about that. Just look at Chrome OS. Sure, someone has to develop Zircon etc., but the average web developer does not care.
...Nor should they have to care.
However, it behoves those webdevs to be aware that they aren't the only fish in the pond, and their ability to generally not care is due to a great deal of effort on the part of many other folks who (usually) have pretty good reasons for doing things their own way.
> This is a Good Thing, it means more people can contribute with less effort. Sure, they may be using a methodology, language, and layer of abstraction that is foreign to your experience, but they're still, y'know, developing software.
"developing software" basically consists of bolting abstraction layers on top of abstraction layers, which is great until one of those buried middle layers inevitably leaks all over your shoes.
Posted Apr 18, 2020 9:16 UTC (Sat)
by nilsmeyer (guest, #122604)
[Link] (7 responses)
I don't see how this is a good thing. You can block / ignore people on mailing lists without having to resort to a moderator or other authority figure. This allows you to make your own decisions on who you want to interact with instead of making a decision for the whole community.
Posted Apr 18, 2020 11:30 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (4 responses)
Posted Apr 18, 2020 12:44 UTC (Sat)
by nilsmeyer (guest, #122604)
[Link] (3 responses)
Posted Apr 18, 2020 18:11 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
> I still think it's far more efficient and less stressful than to try and get individuals removed.
I have never "tried to get individuals removed." I have, on plenty of occasions, pressed the equivalent of the "report" button and thereafter ignored the person. It's not my problem, it's the moderators' problem. This is another cultural difference between forums and mailing lists: Forums have a much greater tolerance for the moderators doing their jobs. Even in the thread linked in this very story, you can see a moderator and a member of the community arguing back and forth about the former's authority to politely ask a third user to stop making references to Hitler. On a typical forum, such an argument would be quite ridiculous.
Posted Apr 18, 2020 19:02 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
How is this phenomenon unique to email or mailing lists?
> I have, on plenty of occasions, pressed the equivalent of the "report" button and thereafter ignored the person. It's not my problem, it's the moderators' problem.
Yeah, "make it someone else's problem" is great for an individual until you're on the receiving end of someone deliberately reporting your posts because they don't like what you have to say, and that "someone else" is a three strikes algorithm that perma-bans you before you have a chance to object.
(Or if you're the one having to administer or moderate the forum/mailing list/whatever, and the professional troll you just blocked turns their sights to you and your family instead. Welcome to the jungle.)
Posted Apr 22, 2020 1:21 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Because:
- In a forum, a deleted message is gone. In a mailing list, a message deleted from the server has already been delivered to everyone's inbox, and normally cannot be recalled.
> Yeah, "make it someone else's problem" is great for an individual until you're on the receiving end of someone deliberately reporting your posts because they don't like what you have to say, and that "someone else" is a three strikes algorithm that perma-bans you before you have a chance to object.
I've never heard of a forum designed that way. Can you provide a specific, real-world example?
> (Or if you're the one having to administer or moderate the forum/mailing list/whatever, and the professional troll you just blocked turns their sights to you and your family instead. Welcome to the jungle.)
Moderators are not new users, so I would characterize this as out of scope. Moderation will always be difficult. But as explained above, a forum does provide the moderator with more powerful tools and a greater shield of pseudonymity, if it comes to that.
Posted Apr 19, 2020 15:31 UTC (Sun)
by spwhitton (subscriber, #71678)
[Link]
Posted Apr 23, 2020 9:27 UTC (Thu)
by neilm (guest, #28422)
[Link]
Just for the record, Discourse allows individual users to mute others (so you never get a notification about a post) or even ignore other users (suppress all posts and notifications from these users.). This doesn't require moderator intervention.
Posted Apr 18, 2020 15:18 UTC (Sat)
by nilsmeyer (guest, #122604)
[Link]
I think Markdown is a good compromise here since it's still readable as plain-text without a renderer and it could also be rendered on a console. HTML adds far too much bloat for my taste and most clients don't support it well.
Posted Apr 18, 2020 16:05 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Apr 18, 2020 16:58 UTC (Sat)
by mfuzzey (subscriber, #57966)
[Link] (2 responses)
I don't think serious software development can be done on a smartphone (unless you hook up enough external gear that it essentially stops being a smartphone and is just a CPU module).
A smartphone is really a content consumption and basic communication device and is not really suited to content creation.
So, if you're using a desktop / laptop to actually do the development work (writing code, documentation or whatever) you're better off using the same technology to communicate with others on the project
Posted Apr 18, 2020 19:43 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
That means they are uncomfortable with email processing, so mailing lists overwhelm them.
> I don't think serious software development can be done on a smartphone (unless you hook up enough external gear that it essentially stops being a smartphone and is just a CPU module).
I do not disagree, but it is not the point.
> A smartphone is really a content consumption and basic communication device and is not really suited to content creation.
This is not their experience at all. In fact most of what they created digitally since they were eleven was done on their smartphone.
> So, if you're using a desktop / laptop to actually do the development work (writing code, documentation or whatever) you're better off using the same technology to communicate with others on the project
Sure, but for them that would mean setting a dedicated email address for FLOSS interaction and learning how to use a MUA, while they can accept a pull-request on github with their smartphone.
Posted Apr 23, 2020 15:07 UTC (Thu)
by mrshiny (guest, #4266)
[Link]
Sure, I'm not coding from my phone, but a significant portion of development work is not coding, and having the flexibility to do it from a mobile device is very valuable. YMMV but it's 2020, people are using phones for work.
Posted Apr 18, 2020 6:45 UTC (Sat)
by josh (subscriber, #17465)
[Link]
Posted Apr 19, 2020 18:01 UTC (Sun)
by tesarik (subscriber, #52705)
[Link] (5 responses)
This part got somewhat little attention. Email was designed as a decentralized service, just like most of the early-days Internet services. Anyone can run a MTA, let people know about it somehow (MX record in DNS these days) and that's about it. Sure, mailing lists have a central point, but as soon as you fork off a private off-list thread, you're on your own. Also, moving a mailing list to another provider is relatively easy, and there are usually many copies of the complete mailing list archive, should anything wrong happen to the main site.
OTOH if everything is stored in a single database, this database (and its operator) constitute a single point of failure. Even worse, if someone tampers with the database (some government agencies come to mind for some reason), will anyone even have enough evidence to prove it?
Just saying…
Posted Apr 21, 2020 9:54 UTC (Tue)
by pkern (subscriber, #32883)
[Link] (4 responses)
Anonymity is also much harder to achieve with email than it is with web fora. And it turns out anonymous posting to mailing lists is frowned upon, which is kinda ironic given how people say they are in control of their data. (Really? Tried to delete a post on someone else's machine?) Yes, if you are tech savvy and run your own MTA you might be able to be more in control. Otherwise you likely are not.
Posted Apr 23, 2020 5:11 UTC (Thu)
by bferrell (subscriber, #624)
[Link]
For these very reasons, I run my own MTA. I've done so for a long time.
Is it easy? Maybe if I were setting it up from scratch today it would be more tedious now than it was when setting up an MTA was new. And I've had to bolt things on over the years to keep it up to date.
So it's hard. So what. As others here have mentioned, it gives me full control of my mail.
Know what else is hard? Writing code and thinking logically.
It makes my ears bleed and my brains leak sometimes. When I do it, it's a choice I make and I really don't think it's anyone else's responsibility to make it easier for me to execute on that decision. That decision is MY interior landscape.
In my opinion (humble or not), it's rude and obnoxious to try to hold others responsible or accountable in any way for my landscape/my decisions. That opinion is based on years of trying to do exactly that and finding out just how poorly THAT works.
'nuff said.
Posted Apr 23, 2020 5:38 UTC (Thu)
by tesarik (subscriber, #52705)
[Link] (2 responses)
On the other hand, if you (hypothetically) move everything to Discourse, and Civilized Discourse Construction Kit, Inc. is bought e.g. by Baidu, Inc. next year, what can you do?
Regarding anonymity, I believe that topic is completely separate. FWIW many FOSS communities have never aimed at anonymity of individual contributors. Quite the opposite! They give credit where credit's due and often keep a very long list of all people who have helped. For example, I sent a small patch set to the Wine project many years ago, and my name was added to the AUTHORS file automatically. I did not even expect it to happen, but I was flattered. My name is still there; I have no intention to ask for deletion. Why should I?
Posted Apr 23, 2020 5:44 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 23, 2020 19:50 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
End-to-end encryption would mean zero instances of the message in plaintext from the time it leaves the sender's mail client to the time it arrives at the final recipient's mail client. SSL transport for e-mail is not end-to-end. It only encrypts individual links. Every server in the path can see the plaintext, including (at a minimum) your SMTP relay, the mailing list host, and the recipient's MTA.
Posted Apr 18, 2020 1:35 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link] (11 responses)
Why is this a bad thing?
Email, precisely because of the lack of whizzbangs and knick-knacks mentioned in the article, allows the user to decide for themselves what features they want to build over it. It is like a Unix program that can be composed with other tools, while Discord is more like a macOS Application that implements exactly what the developers want, and serves the developers' (rather than the user's) needs.
For any of the features that the community as a whole want---what could be simpler than defining an X-header and implementing it in a few Free email clients of choice? Clients like mutt, riseup, and so on are generally quite receptive to this sort of thing. Would you rather beg Discord to implement a feature that matters to your community and nobody else?
By using email, I have the freedom to barely use it at all. I don't like the idea of my mail service getting a request from wherever in the world my laptop is every minute, so I use IMAP just to download my email once to a personal server, whence it gets committed to git-annex, and replicated to all my machines over git over SSH over WireGuard. No need for the data to remain permanently on the hosting server or to travel all over the world over TLS.
I can run python scripts over the Maildir to organize everything the way I like. I can choose a mail provider outside the surveillance catastrophe that is the United States, or host it myself. I can view threads, while the commenters on here that hate threading for some reason can just use a client that shows a straight list of emails. I could belabour the point, but I'd rather not, because I realise that not everybody shares my values. Using Discord forces everybody to have the same values and make the same compromises, while I can still talk to somebody using GMail even if I would never subject myself to such a crippled interface.
Can I do any of these things with Discord? Of course not. Should email have been implemented with any of these features from the beginning? Of course not, because then I wouldn't have the chance to decide which of them are important enough to implement myself.
Posted Apr 18, 2020 1:54 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
Posted Apr 18, 2020 2:26 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link] (4 responses)
I possibly wasn't clear enough above: literally none of my email manipulation happens server-side. I download my email once, trash it on the email provider, then work with it on my own machines. As far as my email provider knows, every single email that gets sent to me gets deleted without being read very soon after it reaches my machine.
The larger point is that Discord's API is Discord's API. If there's something I need from it that it doesn't provide, there isn't anything I can do about that. Using a protocol like email, that gives you nothing, leaves you free to build anything.
Posted Apr 18, 2020 7:10 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link] (3 responses)
What the server does with it, isn't under your control. You can't verify whether said deletions are in fact actual deletions or mere archivals.
Posted Apr 18, 2020 12:29 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link] (2 responses)
Posted Apr 23, 2020 16:50 UTC (Thu)
by mrshiny (guest, #4266)
[Link] (1 responses)
Posted Apr 23, 2020 20:27 UTC (Thu)
by karkhaz (subscriber, #99844)
[Link]
Posted Apr 18, 2020 19:27 UTC (Sat)
by riking (guest, #95706)
[Link] (3 responses)
Posted Apr 18, 2020 19:28 UTC (Sat)
by riking (guest, #95706)
[Link] (1 responses)
Posted Apr 18, 2020 19:31 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 18, 2020 19:30 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 20, 2020 18:17 UTC (Mon)
by hkario (subscriber, #94864)
[Link]
no, thank you
Posted Apr 18, 2020 17:04 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (31 responses)
> There are things you can't do via email that you can do via the discourse UI -- and that is pretty much the entire point of using discourse; to gain those additional capabilities
The entire issue is summarized above. Discourse and all other web interfaces offer advanced features (auto cross links, filtering, searching,...) not because they have a web interface but because the discussions are in a _database_.
The code review / discussion solution of the future is a some sort of hopefully open-source and distributed database, there's no escaping that. However this future tool just doesn't have a good command line interface yet that advanced users can script to death like they already do for email. Think pwclient done right and from scratch. Email will be of course be one of the interfaces.
Every time some email fanboy starts with: "but look at all I can do with my crazy email scripting" they give a laundry list of features built-in in most databases.
Fixing this will be compared to creating git.
Posted Apr 18, 2020 17:07 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
Posted Apr 19, 2020 15:37 UTC (Sun)
by spwhitton (subscriber, #71678)
[Link] (3 responses)
Posted Apr 19, 2020 16:29 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (2 responses)
As I wrote earlier, every advanced "email scripter" is independently re-inventing/mimicking database features on top of mbox files. As of August 2019, none of that was "distributed". Proof: messages didn't even have a universal unique key yet:
Posted Apr 20, 2020 23:53 UTC (Mon)
by spwhitton (subscriber, #71678)
[Link] (1 responses)
Posted Apr 21, 2020 0:26 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Maybe it is, and maybe it is closer to a proper code review database than Usenet.
It's also 40 years later.
Posted Apr 18, 2020 17:18 UTC (Sat)
by pizza (subscriber, #46)
[Link]
I'm cautiously optimistic that the folks that brought us Linux and git will cause lightning to strike a third time.
(And yes, I share your view of gmane.org; that was an immeasurably useful service..)
Posted Apr 20, 2020 11:17 UTC (Mon)
by dunlapg (guest, #57764)
[Link] (24 responses)
That's part of why I was initially really excited last year when I read about Fossil: distributed VCS with integrated wiki, issue tracker, &c, all built on top of a SQL database.
Unfortunately the author doesn't understand review-based workflows; as such, AFAICT it will currently only work for SQLite's very "cathedral"-style development model. But I think it could serve as inspiration to someone. It would be really nice if bitkeeper : git :: fossil : $THE_NEXT_BIG_THING.
Posted Apr 20, 2020 14:07 UTC (Mon)
by pizza (subscriber, #46)
[Link] (9 responses)
It's more like "deliberately doesn't understand." ...What a disappointment.
(Even on stuff where I'm the only developer, I make _very_ heavy use of rebasing. It's one of git's killer features..)
Posted Apr 20, 2020 21:33 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (8 responses)
But the answer is not that rebase is a terrible concept! The answer is that your definition of "publish" is wrong.
In systems I've worked with we use branch namespaces to segment "public" and "private". Developers are allowed to rebase their private branches all they want, including after the private branch is pushed to a server, and still run all tests on them.
Only once a commit is pushed to a public branch is it "published" and rebase is no longer allowed. We have Git hooks on the server to ensure this but those hooks apply only to public branches.
If you're trying to track someone else's private branches that's fine, but you may have to do extra work if they rebase it and that's just the way it goes.
Posted Apr 20, 2020 21:53 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
"Volatile" and "immutable" are better names. There are private branches with immutable SHA1s and public branches with volatile SHA1s (linux-next).
There are also many different circles of privacy whereas you either make the promise that a SHA1 will not change or you don't, no grey area somewhere in the middle.
https://public-inbox.org/git/70ccb8fc-30f2-5b23-a832-9e47...
Posted Apr 21, 2020 13:11 UTC (Tue)
by gracinet (guest, #89400)
[Link] (6 responses)
The phases concept has been introduced in Mercurial precisely to formalize these kind of use cases: "draft" changesets (commits) can be amended or rebased, whereas "public" changesets are strongly immutable.
This is better in my opinion (at least it's trying to be) than exchanging patches that aren't officially in the DVCS yet or relying on conventions, such as GitHub PR sources from forks being volatile.
Disclaimer: I do work on Mercurial.
Posted Apr 21, 2020 15:51 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Apr 21, 2020 16:49 UTC (Tue)
by gracinet (guest, #89400)
[Link]
Indeed that's exactly the kind of use cases it's meant to support.
> Is there a way to turn a draft into "public" without modifying the draft itself?
Yes, that's the crux of it. The phase information is not part of the changeset itself. When you push to a server (or any remote), it might publish it or not, according to its configured rules.
On top of that, there's a whole system for non destructive history editing (https://pypi.org/project/hg-evolve/)
Posted Apr 21, 2020 16:54 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (1 responses)
Yes, you can change phase only on a changeset in Mercurial. One way to set things up is that only core automation can make commits public; doing so means that you push draft commits around (with metadata that tells you about amends, rebases etc) and then eventually end up with the automation creating a public commit that is flagged as the "successor" of your draft commits.
Changeset Evolution provides a lot of the metadata stuff you might want when implementing this sort of workflow, and Octobus are doing a lot of work to drive this forward.
Posted Apr 21, 2020 18:01 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 21, 2020 16:18 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (1 responses)
We find that using branch naming conventions is simple, clear, and pretty much foolproof. We have a (very small) set of branch name prefixes which represent "managed" branches and we have hooks for those branches which are very strict about what can be pushed there.
Then any other branch name which does not use one of these prefixes is open to whatever you want to do with it.
The act of pushing changes to a "managed" branch is what causes it to become public/immutable.
I know obviously MMV throughout different projects but this works for us and we don't really feel the need for more "built-in" support.
Posted Apr 21, 2020 20:33 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
A GitHub PR "draft" (if that was the question) is only blocking merges and not connected to force pushes. You could use it as a "volatile SHA1" flag if you want to but that would be merely by convention and I think projects prefer to force push always til the end of the review or never.
> works for us and we don't really feel the need for more "built-in" support.
Fine as long as you don't really care about giving or receiving "drive-by" contributions to/from people with different conventions - same spirit as mailing lists: https://lwn.net/Articles/818238/
Posted Apr 20, 2020 15:59 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (6 responses)
Wow, so the guy designed and implemented a version control system but he never corrects commits locally just for himself. I'm pinching myself. I taught myself git the first time only to use git-svn and get that "Super Save and Undo" ability. I still use it every minute of every day. For instance I often revert, test and drop the revert to make sure a new test works.
https://www.fossil-scm.org/xfer/doc/trunk/www/rebaseharm.md
Yeah I totally want my stupid initial ideas and typos to be archived forever on the Internet. Oh my...
Posted Apr 20, 2020 18:21 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
This post sums things up really well I think: https://jeremykun.com/2020/01/14/the-communicative-value-...
Posted Apr 20, 2020 19:53 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
You've been reading my mind :-)
Nice https://jeremykun.com/2020/01/14/the-communicative-value-..., thanks!
Relatively subjective discussions about code review aside, I just realized Fossil can say good bye to "git bisect":
> "what happened to be in my tree at time X"
Another casualty of this strong Fossil opinion and mistake: it forces you to collapse the history and the "history of the history" onto the same axis (https://blog.linuxplumbersconf.org/2016/ocw/proposals/384...)
Of course git doesn't take a stance and let's you do that too, in fact Github tries to push you into that exact same Fossil direction [*]. Git is the C++ of version control: it lets you do absolutely anything including of course shooting yourself in the foot.
The Code Review Tool of the Future will treat the history of the history/of the code review as a first class citizen and subsume git pile, git series, etc. Due to its severe data[base] shortcomings, email is especially bad there.
[*] https://github.com/isaacs/github/issues/959#issuecomment-...
Posted May 21, 2020 12:45 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted May 21, 2020 13:33 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Does it save commit history or is it a series of snapshots all sharing the same parent? Even better would be to reconstruct the history like Vim's (and probably Emacs') history tree too. If it's just a temporal snapshot history, a history viewer where you could collapse the nodes down by a time span would be nice.
Posted May 21, 2020 13:45 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
This is one of the things I like about Mercurial's Changeset Evolution feature - I can have a messy pile of commits while I'm working, and then have a clean pile for review that I've fixed up, but that maintains the links to my messy pile so that I can see how I got there.
Posted Jun 2, 2020 13:10 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Every time you commit, the corresponding wip branches are restarted: the old ones are still accessible until the reflog expires (this is clunky, but I can't really see a way around it). You end up with wip branch history like this:
193b21c09b (refs/wip/index/refs/heads/oracle/ctf-next) autosave ld/lexsup.c after stage
(where bfeee83394 is the last commit on the real branch.)
or this, for a working tree:
436a729994 (refs/wip/wtree/refs/heads/oracle/ctf-next) autosave ld/ldlex.h before stage
Manual: https://magit.vc/manual/magit/Wip-Modes.html
Posted Apr 20, 2020 16:04 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
BTW github is not much better, it's preferred model is "fixup and optional squash": https://github.com/isaacs/github/issues/959#issuecomment-...
Posted Apr 30, 2020 18:30 UTC (Thu)
by seneca6 (guest, #63916)
[Link] (5 responses)
This sentence, and also the responses, seem needlessly aggressive. I don't use Fossil but I have great respect for its author.
Isn't Free Software supposed to be allowed to scratch the author's itch instead of solving all of the world's problems? Especially a niche system, which Fossil certainly is compared to Git, Mercurial, or maybe even SVN.
Posted Apr 30, 2020 19:12 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (3 responses)
> Isn't Free Software supposed to be allowed to scratch the author's itch instead of solving all of the world's problems? Especially a niche system, which Fossil certainly is compared to Git, Mercurial, or maybe even SVN.
Fossil's rebaseharm.md stance is absolutely not about a "niche" or just the "author's itch". Did you read it? Focusing on git as the main example, it claims that rewriting version control history is universally bad in any version control system, even rewriting one's own private history! What next, removal of the "undo" feature in editors?
> This sentence, and also the responses, seem needlessly aggressive.
Considering millions of git users do and enjoy rewriting history on a daily basis (especially during code reviews but not just), I find rebaseharm.md's claim pretty... "aggressive" and the responses here fairly civilized compared to the boldness of that claim.
Posted May 1, 2020 8:26 UTC (Fri)
by seneca6 (guest, #63916)
[Link] (2 responses)
> What next, removal of the "undo" feature in editors?
Given that the author once said in a podcast that he created an editor just for his own habits, it's possible :-) He also said that the editor would be rather useless for anyone else. Writing niche software is visibly nothing the author is afraid of. Our community used to encourage that. We're free to use it if we like, and not to use it if we don't like it, and still wish them well. Many others already are vocal enough and will never understand why one would want to use Replicant instead of Android, Linux instead of Mac OS, or emacs instead of VS Code. It's funny that this author of niche software happens to have written the most used database in the world.
> Considering millions of git users do and enjoy rewriting history on a daily basis (especially during code reviews but not just)
Well, if someone goes to the extent of creating a new version system, I very much hope it won't be just a clone of git's functionality with a different implementation. That would be just a waste of time.
We don't know when that article was originally written. But Fossil started in 2006, two years before GitHub! Rebase was very controversial back then. And I'd argue that only the GitHub/GitLab style of development made rebase so popular. By now, most Git users have adopted it and have learnt, sometimes with pain, where to use it and where not to use it. If others have kept their non-rebase workflow and are happy with it, why not.
Posted May 1, 2020 8:33 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Github absolutely not:
Gitlab barely:
Posted May 4, 2020 11:30 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
SQLite (written by the same person) started out as niche software and is now the most popular SQL implementation on the planet by a few orders of magnitude. A similar argument may be made for the Linux kernel.
Posted Apr 30, 2020 22:46 UTC (Thu)
by rschroev (subscriber, #4164)
[Link]
But the article uses a very different tone. It categorically states that nobody should use rebasing, ever. The title alone is a hint to that; in the conclusion the author makes it abundantly clear: "Rebasing is an anti-pattern. It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits."
I think dunlapg's reaction to that is a bit excessive, but I can understand where he comes from. When so many people successfully use rebasing workflows, is it smart of Hipp to think he knows better than all of them and reject their workflow? He's undoubtedly an intelligent man, but so are many of the people who do use rebase.
Posted Apr 23, 2020 11:11 UTC (Thu)
by hartmans (subscriber, #135969)
[Link]
Posted Apr 17, 2020 19:21 UTC (Fri)
by judas_iscariote (guest, #47386)
[Link] (32 responses)
Developers who are ageing and resistant to change are not in short supply do you mean? Yeah, I am one of those older toads I honestly recognise I am set in my ways. I also recognise mailing lists are arcane nerdy things built on top of terrible mail protocols and that no sane person in 2020 should start using to get into a developer community.
Posted Apr 17, 2020 20:26 UTC (Fri)
by pizza (subscriber, #46)
[Link] (31 responses)
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.
Posted Apr 18, 2020 2:35 UTC (Sat)
by berndp (guest, #52035)
[Link] (33 responses)
Debian (or whoever) looses "great developers" because of the "email requirement"?
All that blurb about "loosing ... $SUPER_GOOD_PEOPLE" without proof is just handwaving BTW.
Sorry to the "I grew up with a mobile and twitter/fb/<and other crap tools> and only my grandma uses email" generation but please grow really up and don't primarily discuss the tools (that you actually know today - there are more out there ...) but think about "what makes good and constructive communication to solve problems and what avoids and/or discourages trolling, handwaving, etc.?".
Posted Apr 18, 2020 2:43 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
> All that blurb about "loosing ... $SUPER_GOOD_PEOPLE" without proof is just handwaving BTW.
Posted Apr 18, 2020 23:58 UTC (Sat)
by lkundrak (subscriber, #43452)
[Link] (15 responses)
:(
Posted Apr 19, 2020 3:39 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
But seriously, on my $DAYJOB I'm responsible for infrastructure and I strive to make it as easy to use as possible. So that actual flesh-and-bones developers can comfortably work and contribute to the company. I have never seen that forcing all newcomers to go through a hazing ritual would result in anything good.
Posted Apr 19, 2020 13:57 UTC (Sun)
by pizza (subscriber, #46)
[Link] (13 responses)
What you are calling "hazing rituals" others refer to as "training" or "basic education"
> Given that I was a cofounder in two successful software startups?
I'd be willing to bet that you, in your managerial/cofounder role at said startups, required quite a lot of "hazing" to be present on prospective employees' resumes.
Posted Apr 19, 2020 16:02 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> I'd be willing to bet that you, in your managerial/cofounder role at said startups, required quite a lot of "hazing" to be present on prospective employees' resumes.
Posted Apr 19, 2020 17:09 UTC (Sun)
by pizza (subscriber, #46)
[Link] (11 responses)
You're absolutely right, a tool "not used anywhere but in a few projects" isn't something one would expect a random person/developer/whatever to be proficient in.
Unless, of course, you're looking to participate (and become productive) in one of those niches with domain-specific tooling. That isn't "hazing"; it's demonstrating basic competency in the field of question.
> No, we don't require anything like "built my own computer from sticks and stones"
In my experience, the folks who grew up tinkering with their computers/cars/whatevers are far more likely to become awesome developers than the ones who only chose it because some top-ten list said it was what employers were looking for at the time.
Posted Apr 19, 2020 17:17 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
I know companies that use a PR-based model with a Git forge for kernel development and only package the results as email patches at the very last step.
> In my experience, the folks who grew up tinkering with their computers/cars/whatevers are far more likely to become awesome developers than the ones who only chose it because some top-ten list said it was what employers were looking for at the time.
Posted Apr 20, 2020 7:42 UTC (Mon)
by juliank (guest, #45896)
[Link] (2 responses)
Posted Apr 20, 2020 8:04 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
To give you an example, my electric stove has a clock that is showing incorrect time (for about 3 years now). Mostly because I can't find myself caring enough to get the manual and find how to change it.
Posted Apr 20, 2020 15:50 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 21, 2020 10:59 UTC (Tue)
by tao (subscriber, #17563)
[Link] (6 responses)
You can certainly suggest that a particular tool might not be the optimal one, and the approach used in Debian surround Discourse (set up an example server) is the right way to do so. Not to say that the current model is wrong. Build momentum.
As for e-mail vs other forums for discussions and code reviews, etc., I think it actually *does* come down to your e-mail client. I would never ever consider doing serious code reviews in gmail, thunderbird, or *shudder* outlook; sure, sometimes I briefly glance over code and point out obvious flaws, but for any larger amount of code I want access to a proper text client with a proper editor.
Posted Apr 21, 2020 16:38 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
> As for e-mail vs other forums for discussions and code reviews, etc., I think it actually *does* come down to your e-mail client. I would never ever consider doing serious code reviews in gmail, thunderbird, or *shudder* outlook; sure, sometimes I briefly glance over code and point out obvious flaws, but for any larger amount of code I want access to a proper text client with a proper editor.
Posted Apr 21, 2020 22:41 UTC (Tue)
by Jandar (subscriber, #85683)
[Link]
Why? I prefer e-mail over any other communication method for non-volatile content like a chat and havn't use neither gmail, thunderbird, nor **violent shudder** outlook and mutt has attracted my attention for the last years my attention but I haven't used it once for now.
Why is mutt the only alternative to embarrassing popular email clients? There is a innumerable multitude of email clients serving every linking but web fora serve mostly only one or a few styles.
E-mail has many shortcomings but most (or all?) can be worked around, but web fora have also shortcomings but there the workarounds are not so plentiful.
For short or clear-cut discussions a forum is nice but for widely ramified discussion e-mail is way better.
The last and most important aspect is the ingrained muscle memory. I can operator my e-mail client with motions of my finger that are cultivated since before the web arouse. This is way faster than any web forum allows me to work.
The last paragraph can be dismissed as "grey-beard dosen't want to learn" (my beard is partly grey :-) but I've seen many fads come and go, a few communication channels come and go and some web services come and go. In the company I work for a quarter of a century I see the debris left behind by the alleged progressive people who propagate "this is the way of the future" and leave after a few years to bequeath some (toxic) legacy to the steady and essential work force. This has shown to me the questionability of the argument "this it is how it is done nowadays". Adapting to the fad of the year (or according to age the fad of the decade) throws away your fine tuned operation to throw it away the next time the next year and so on. Envision a master of his/her craft to turn his/her working on the head because some journeyman/woman has another idea. This doesn't dismiss the notion of a master learning from a journeyman/woman but not only because one of them is younger and therefore at the tip of the advancement. Where I am on the scale of proficiency I can't say for myself, but newer means mostly unseasoned and only rarely better. I have trained a few co-workers over the years and seen many trained by other, those who want to change basic procedures (and are allowed to do so, we are willing to try new things) are the ones that leave after a short time, those that accept the environment and try to learn the given tools are in for the long run and are productive for many years.
Any change you make to the workflow of the main current set of contributing people has to make a substantial improvement for almost all of them. A change to the the detriment of some of them is more pivotal than an improvement to several. Even a slight negative experience overshadows a larger positive one.
Posted Apr 22, 2020 11:05 UTC (Wed)
by tao (subscriber, #17563)
[Link] (3 responses)
I admit, I haven't used Discourse. I've used various other collaboration tools though; Gerrit, Gitlab, Github, Teams, Sourceforge (back when people actually used that), and Slack.
I really like Slack (but it's non-free), Teams is similar (also non-free), Gerrit is OK as long as nothing is rebased--at which points it turns into a nightmare, Gitlab & Github are OK:ish, Sourceforge was crap back when I used it.
The system I've liked the most though is simply Debian's combination of mailing lists and the BTS. It's certainly not ideal in every aspect, but it's really, really easy to customise to your liking.
The big issue these days with e-mail based interaction is simply that most ISPs actively work against you--they want you to use GMail or their own inferior copy there-of; they don't want you to download your e-mail and read it locally, and they definitely don't want you to send e-mail from your local machine using anything else than a web browser.
Posted Apr 22, 2020 14:06 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
These two you can. Far better than a mailing list too. For instance, I get only the first message of a thread for most of the areas of our Discourse instances. Some I watch all traffic. Still others I basically ignore and I get no notifications. My split is unlikely to match other folks' preferences. I have no idea how to do that sanely for a mailing list without having a list per Discourse section which sounds like an absolute nightmare. Or everyone reverse engineers headers and hopes they can write rules to filter on them (gmail has no support for header-based filtering outside the 3 or 4 fields they index).
Posted Apr 22, 2020 16:29 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
So you have described two problems:
1) the admins of the various discourse boards configured them to not include the name of the boards in the notification emails. (It defaults to being included, btw)
2) Gmail sucks. (and water is wet)
Posted Apr 22, 2020 16:43 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 18, 2020 4:08 UTC (Sat)
by pizza (subscriber, #46)
[Link] (15 responses)
For the F/OSS projects I'm active on these days, the barrier of entry is steep indeed; not because we eschew "modern" pull-request github contributors, not because we rely on "archaic" mailing lists for correspondence, but because in order for someone to meaningfully contribute, they have to have some pretty niche skills -- reverse-engineering hardware and writing low-level device drivers or other bare-metal code.
To be blunt, someone that doesn't have the patience to semi-effectively operate an email client isn't going to be willing to invest the dozens of hours needed to wrap their heads around the problem spaces we operate in. It's a very steep learning curve (I'm not sure if I'll ever be done climbing it myself!) and our "making it easier for folks to contribute" efforts are better spent on tasks like the endless need for [improved] documentation.
> Sorry to the "I grew up with a mobile and twitter/fb/<and other crap tools> and only my grandma uses email" generation but please grow really up and don't primarily discuss the tools (that you actually know today - there are more out there ...) but think about "what makes good and constructive communication to solve problems and what avoids and/or discourages trolling, handwaving, etc.?".
I feel that this is not a "generational" gap so much as one of attitude -- It's not really about "email" or "forums" or whatever. Instead, are you the sort of person to accept the tools you're handed, and what the tool supplier says you are allowed to do with them, even when it doesn't really work that well for you, or do you roll up your sleeves, take things apart, and build/adapt better tools? (I might add that the latter is what brought us the Internet, Linux, and git, among the most wildly successful engineering efforts of all time..)
After all, the entire raison d'etre of Free Software is to empower the end-user [1], and Debian holds that principle very dear indeed. Sure, most folks probably don't care how the Debian sausage is made, but when you're the ones making that sausage, it's an entirely different conversation.
[1] As opposed to "Open Source", which is about empowering the _developer_, who may or may not chose to empower their end-users as well.
Posted Apr 19, 2020 3:31 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (8 responses)
OK, so there is a rite of passage element, thanks for the honesty. Except not because a rite of passage is a test you pass only _once_ to prove your worth. It can't be the main and (by your own admission) more complicated main communication channel with the rest of the world that you have to keep using every day.
Posted Apr 19, 2020 11:20 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (7 responses)
Posted Apr 19, 2020 16:32 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Apr 21, 2020 11:08 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (5 responses)
Posted Apr 21, 2020 13:17 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Okay, that one's a bit of a stretch, but here's one that isn't: Employers that require a college degree. Or a master's degree for more senior positions. They don't actually care about any specific coursework you took, as it will simultaneously be irrelevant, outdated, or insufficient.
What they do care about, and what the degree demonstrates, is that you were able to demonstrate effective time management and deliver results on a deadline. It shows you can juggle multiple projects simultaneously, with the project management (ie professors) considering their project to be the most important. It shows you can interact within a team, with incomplete and inconsistent requirements and the help of certian colleagues that, if you're being honest in your peer reviews, aren't worth the air they're breathing. It shows you can generally function on your own, both in the professional "work independently" sense, but also in the personal (hygiene/laundry, nutrition) sense.
In short: it shows you can endure (and perhaps even thrive) in spite of heaping piles of conflicting BS being dumped on you.
None of those "soft skills" are an explicit part of the coursework, but they are such that if you don't learn them reasonably well, you won't make it through university. And if you can't hack it well enough to get through university, you're probably not going to get far in a workplace that requires those skills, and more.
This is even more true for advanced degrees; rarely is your exact thesis or dissertation of interest to prospective employers; what matters is that you independently developed an idea/project from start to finish, running the approval/review/bureaucracy/BS gauntlet. Again, a valuable and necessary skill for higher-level positions.
(Yes, there are exceptions to this, but most folks don't have three-deviations-beyond-the-mean levels of raw talent...)
Posted Apr 21, 2020 14:23 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
Posted Apr 22, 2020 5:29 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (2 responses)
Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...
Posted Apr 22, 2020 13:08 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
Eh, even back in my undergrad days where we had to fend off dinosaurs on the way to class, it was commonly "joked" that our degrees would be in general crisis management with a minor in our erstwhile field.
In all seriousness, freshly graduated folks are fairly useless when it comes to specific technical skills. I don't say that pejoratively; what I expect instead is a decent understanding of the theory that underpins those technical specifics.
I want to see how they _think_, because it's completely unrealistic to expect fresh-outs to be immediately productive with the unique combination of miscellany that makes up our codebase (and technical debt). They're going to be learning on the job for the rest of their career.
(I should point out that I'm making a distinction between a university/college and a trade school)
> Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...
"be allowed to contribute"? Not at all. But they're not going to be terribly useful starting out, either. It takes time to grok a new codebase, even if you are already very familiar with the problem domain and tooling used.
(And these days, the typical software dev hasn't ever left the confines of client- or server-side javascript. It's quite a steep learning curve from that to reverse-engineering compiled binaries so you can figure out why your bare-metal realtime system is occasionally corrupting the data being read off the SD card...)
Posted Apr 22, 2020 18:56 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
There is always plenty of "quality of life" fixes in every project that experienced developers are too busy and too precious to do: small bug fixes, documentation gaps, small validation gaps, basic optimizations and simplifications, etc. These are a great way to ramp-up and learn about a project while being immediately productive and useful.
Tools like githab try hard to lower the barrier to submit these - and doing them lowers the barrier even more for the next project noobs[*]. "Are you with us or not?" mailing-lists and email code reviews keep (by your own admission) that barrier not crazy high but significantly higher. The difference is really that simple.
[*] a "project noob" can be very experienced with other environment and tools and may bring fresh perspectives.
Posted Apr 21, 2020 11:12 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (5 responses)
Why? Someone may have infinite supply of patience for problems they are interested in but zero for configuring stupid email client just the way the reviewer likes it on pain of rejecting your contributions. I know I do. And I'm definitely not one of the snapchatting youngsters!
Posted Apr 21, 2020 12:42 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
There's a pretty substantial gap between "configuring [the] stupid email client just the way the reviewer likes it" and "semi-effectively operating an email client"
The objection folks seem to have is that email is used _at all_, because *waah, it's too much effort*. Meanwhile they will hand out their email address or phone number to every app or website they encounter, and click on the link that comes back to "confirm their account". Congratulations, that's the total effort required to subscribe to a mailing list, and unlike the "messages from our selected partners" the apps or websites send in buckets, the mailing list will have clear subject lines -- and far more often than not, be considerably less voliminous.
But sure, let's scrap email for github-style PRs. And guess what? All three of the F/OSS projects I actively work on have github and/or gitlab mirrors. One has seen a total of 4 PRs opened, and 3 of those ended up abandoned because the submitter didn't respond. The fourth was eventually resubmitted via the "proper" channels, but still didn't make it in because the submitter didn't follow through with requested changes. Meanwhile, the other two projects have yet to see a single PR opened. Indeed, one project (for which I am the sole developer) has yet to see anyone click on the "fork" button, and, over the course of _eight years_, has received only one patch of any substance and maybe three or four trivial few-liners.
The overwhelming reason project X doesn't get drive-by contributions is that there isn't anyone (beyond the 1-4 people already involved) that gives enough of a f*ck to even look at the code, much less make changes to it. If local changes do get made, IME the biggest impediment to contributing upstream are actually corporate policies and processes that default to "don't share anything, ever."
As evidenced by the steady trickle of folks contacting me over email with questions, highly-technically-challennged support requests, or the rare "offering to test", "semi-effectively operating an email client" is a pretty low barrier indeed, I find it pretty hilarious that clueless end-users can manage this just fine but this mythical pool of hyper-talented developers that would be all over my code can't.
Indeed, it seems that the best way to generate contributions is to make your software crappier, because folks simply don't notice or care about the stuff that JustWorks(tm).
Posted Apr 21, 2020 15:49 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Plus, for any project that only gets a handful of external contributions over a long stretch, why would I want to set up a mailing list for it? The hosting service is largely irrelevant there (maybe CI solutions differentiate, but CI for such things is also usually the empty set), but if it's at least on *some* forge, those drive-bys are much more possible.
And any contribution mechanism will have abandoned patches. I don't know that one can derive rationale behind them without doing actual studies, especially with such a low N. As a contributor, I was definitely put off for a while when I had sent a patchset and it got, seemingly, completely ignored. Next time I go to rebase it (when I got a chance). Hey, it's been merged (with some minor fixups). A notice to the list would have been nice (not only for me, but else wanting those patches). Forges at least let me know when that happened.
And I'm not saying forges are always better. Lists work…ok for the kernel (as an occasional contributor), but feedback and better status tracking would definitely be appreciated.
Posted Apr 21, 2020 17:21 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Those young whippersnappers...
Posted Apr 21, 2020 17:27 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 22, 2020 5:45 UTC (Wed)
by jezuch (subscriber, #52988)
[Link]
Autism works in mysterious ways...
Anyway, I was responding to the argument that since the project's subject matter is complex then it's fine if the submission process is also complex - and especially to ascribing an ideology to that. It's way simpler to be honest and just call it a hazing ritual :) It's fine to have reasons you work this way (it's better to try to improve that) but ideologies are bad.
Posted Apr 18, 2020 11:49 UTC (Sat)
by qyliss (subscriber, #131684)
[Link] (3 responses)
I’d like to offer some counter-evidence.
I’m 21, and for my first several years of free software involvement, I don’t think I ever had reason to stray away from GitHub. But as my interests and efforts have shifted, I’ve come to appreciate the power and importance of email. Several of my peers have been coming to similar realisations after starting to interact with email-based projects. (I think it’s fair to say that many of the projects still using mailing lists are projects people are likely to come to a bit later on than many GitHub projects, for reasons other than the use of mailing lists!)
The tooling for filtering, archiving, and searching email is unparalleled. Managing a high volume of GitHub or Discourse notifications on the web is basically impossible — and it makes sense! How can we expect every platform to reimplement good notification handling? Even if they do, every platform has a separate system to learn and set up, and that’s going to pull people toward using fewer platforms. Good news for platform companies, bad news for users. Whereas with email, every new mailing list program or whatever people want to use fits perfectly into an existing ecosystem of powerful software.
Proper threading is hugely important for following long, detailed discussions. As soon as things are starting to veer off-topic, you can just skip the resulting subthread. You can follow multiple areas of conversation, etc. Following a long GitHub issue thread is basically impossible due to the lack of threading, as is following a Discourse discussion on the web. Discourse _does_ send threaded notification emails, which is nice. And their web UI even manages to get people to reply to the right messages, even if the web UI doesn’t show any concept of threading, which is very impressive.
Being able to reply to people off-list is important to keep discussions focused and on-topic. Somebody can ask me a question about details of how I did a particular thing or what tool I’m using or whatever, and we can have a conversation about it without cluttering the main conversation. Alternatively, we can change the Subject and continue posting on-list, allowing other people to see where the conversation started from, and choose whether to read it, or skip back to the main thread.
The ease with which we can have redundant, decentralised archives with email means that we can be confident that the historical record is preserved, and when we want to find out why something works the way it does 20 years after it was introduced, we’ll be able to find the original discussions. We can see this playing out already — usenet conversations for the 90s are still easy to locate, but try finding a particular thread from a mid 00s web forum! Despite sending emails, GitHub and Discourse notifications sadly do not fit into this properly — they do things like having special tokens in the email that mean if I send a copy of the email to somebody else or publish it in an archive, somebody else can now take actions on my behalf. This means that we can’t easily have resilient, decentralised, mirrored archives like we do for email.
While all of these platforms do claim to interoperate with email, they do it poorly, and miss out on many of the advantages. There’s the token issue as previously stated. GitHub’s email notifications don’t support threading, even when (e.g. on PR reviews) the web interface does to some extent — replying to an inline PR review notification will post a new top-level comment, meaning you have to be very careful to know which notification emails you can safely reply to. The plain text parts of discourse emails are just their own raw hideous Markdown/bbcode mashup. The really sad thing is that this _could_ all be done properly. There’s no fundamental reason there couldn’t be a perfectly pleasant GitHub or Discourse email experience. But people seem to be largely accepting their claims of proper email integration at face value, and so they have no incentive to make them actually work properly.
All of this means that when I was setting up the infrastructure recently for a new free software project that I really hope will take off (has funding, etc), the choice was obvious. However, I also set up Hyperkitty, which seems to me to be a far more promising way to allow those who prefer web software to interact with those of us who prefer email than Discourse. It’s a web based discussion platform backed by a mailing list, and it’s part of GNU Mailman 3. I strongly encourage anybody interested in this area to check it out. It’s not nearly as polished as Discourse at the moment, which is not at all surprising given the disparity in presumed developer attention, but it’s heading in a very promising direction. Fedora’s Hyperkitty instance is a bit outdated, but still I think a good example: https://lists.fedoraproject.org/archives/
This doesn’t have to be a fight, and there’s no reason we can’t have a solution that satisfies both groups, except that neither side appears to want to accept the legitimate needs of the other and work together on solutions that work for all of us.
Posted Apr 18, 2020 23:04 UTC (Sat)
by mtaht (subscriber, #11087)
[Link] (1 responses)
I miss gmane, also.
Posted Apr 19, 2020 0:19 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Posted Apr 19, 2020 12:30 UTC (Sun)
by erwaelde (subscriber, #34976)
[Link]
Several years back I (old bloke) decided, the only thing I could do to improve knowledge about tools is to actually teach those tools to the so called youngsters. So on several occasions I gave 2-hour introductions to emacs. I have no idea, whether I created "following", but at least I showed to others, why I love this tool. Response from the audience was alway very encouraging. Feel free to share/update/translate/reuse the flyer I made for the occasion https://gitlab.com/erwaelde/public_files/-/tree/master/de (german text thus far).
Cheers,
Posted Apr 19, 2020 10:21 UTC (Sun)
by comex (subscriber, #71521)
[Link] (2 responses)
- I configure them to forward all posts to my email (I use Gmail).
- I use email as my only browsing/notification interface (i.e. to find threads with posts I haven't read). Much more convenient than visiting the sites, since I can see messages from (multiple) Discourse forums, GitHub projects, and other sources, all in one place.
- However, I send replies by clicking the "view on web" link and writing the reply in the web interface. I also sometimes switch to the web interface when reading long threads.
It's an okay user experience, but there are some annoying limitations:
1. Discourse's email notifications tend to lag behind the posts, at least on the Rust forums, which use Discourse's hosted service rather than self-hosting. GitHub notifications always arrive promptly in my experience.
2. Editing. Both services allow users to edit their posts, but neither notifies email subscribers when this happens, so I completely miss out on edits when I'm reading from my inbox.
Some edits are minor, but other times people add large amounts of text to their posts after the fact. I can't blame them; in fact I sometimes do the same myself. If you write a post and then think of something new, you can always write a second post in a row, but that can come off as annoying (even on mailing lists where editing isn't an option!); editing your first post is less intrusive and is a nice option to have. I wish we could just have editing for emails. In theory, this could be as simple as header that marks an email as a revised version of an earlier one: email clients would show only the latest version by default, with an option to show the full history. But it would be no easy task to come up with a standard and convince Gmail, Discourse, and GitHub all to adopt it.
2.5. Reactions (Discourse 'likes', GitHub emoji reactions) are also invisible. Not a big deal, since they don't form an essential part of the conversation, but personally I like them. I suppose that under that hypothetical standard for editing emails, the services could have a reaction count at the bottom of their emails, and 'edit' the email as the count changes.
3. I'd prefer to reply via email too; the reason I don't is that it's hard to predict how messages will come out after passing through Discourse or GitHub's email parser. One issue is that they both try to strip out quotes in at least some cases. Another is that I can't reach the raw Markdown to properly edit my replies, though that one is at least partly my fault. Both services' emails actually already include a text/plain MIME part containing the Markdown, alongside the HTML version, but AFAIK there's no way to get Gmail to show it by default. I could fix that by switching email clients (which I probably should), or by forwarding the emails through some custom apparatus. But the services could also work around the issue by providing a preference to send plaintext only, and AFAICT neither does.
Even with all that, as I said, it's an okay user experience. And I understand why people are moving away from mailing lists. In large part it's because mailing lists are worse than they could be. There's no reason that mailing list software can't provide a web UI that (a) is as well-designed and nice to use as Discourse and (b) supports sending messages from the web rather than just reading. But as far as I can tell, such software doesn't exist. The closest I've found to a good mailing list web interface is HyperKitty, but that feels more like an amateur imitation of modern web design than the real thing.
Posted Apr 20, 2020 7:44 UTC (Mon)
by juliank (guest, #45896)
[Link] (1 responses)
You'll also need a sender signature on the old and revised messages to make sure nobody else was revising the message. And now you're down the rabbit hole.
Posted Apr 20, 2020 11:03 UTC (Mon)
by comex (subscriber, #71521)
[Link]
Posted Apr 20, 2020 0:37 UTC (Mon)
by flewellyn (subscriber, #5047)
[Link] (3 responses)
But there are deficiencies to the current email standards that could be fixed if we replaced it with a new protocol altogether. Of course, then we risk running into the XKCD 927 problem: https://xkcd.com/927/
Regardless, I can understand why email's pain points would drive some people to move to a system like Discourse. I can also understand why email's advantages would drive other people to be wary of such a move.
A worthy discussion, but at the moment I remain hopeful that the Debian community will discuss it productively. We don't want a Panic! at the Discourse.
Posted Apr 20, 2020 4:12 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
927 makes a (funny) joke about yet another 15th protocol. Applied to email that leaves room for 14 new protocols/data structure before we reach the xkcd point.
OK, maybe 13.5 if you count NNTP.
Posted Apr 20, 2020 21:08 UTC (Mon)
by smoogen (subscriber, #97)
[Link] (1 responses)
Each one of those would probably be a different protocol (as the Usenet people will tell you it still exists, PHPNuke people seem to show up and say 'you can always use us', the various people wanting you to move to XMPP etc keep going. ) Each of those solutions have adherents and each gets regularly replaced with some new version which is supposedly easier to use. And each solves a different way of communicating which needs a different toolset.
The problem is that we want just one tool to do all these things. It is like we all looked over the house design, saw that it was way too complex with all these pipes, and we could just use one system. Then we wonder why the sewage, hot and cold water system doesn't work as well as we envisioned and no one is happy.
Posted Apr 20, 2020 21:24 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Right, so let's do one that does just code reviews really well. It would be like a... hub for git or something.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
- Mailing list threads are nested, and can turn into a horrendously complicated tree of responses. Reading the whole thread involves a pre-order tree traversal, and with poor quoting it may be difficult to remember the context in which each reply was made. Most forums are flat and do not nest replies, which makes it harder for long off-topic tangents to be sustained, and makes it less complicated to read the entire topic in one pass. This also makes it more socially acceptable for moderators to split an off-topic set of comments into a new thread (at which point they are entirely removed from the original thread and no longer visually clutter it).
- If you join a mailing list, then everything gets sent to you and you're expected to post-filter. If you post to a forum thread, you (may, depending on software capabilities) automatically receive replies from that thread only.
- Mailing lists trivially allow for off-list communication, which cannot be easily moderated. Forums usually have private messaging, but it's still on-service and subject to moderation if abused. More generally, moderators on a forum have a much richer set of tools available to them than moderators on a mailing list (which does require appropriate discretion from said moderators, of course).
- Forums can have stickied and locked threads, for metadata such as rules and announcements (which are both highly relevant to lurkers since they usually have excellent signal-to-noise ratio). Mailing list threads can be locked, but this is usually only done in extremis. Announcements are normally implemented as "just a regular thread, except on the foo-announce@ list." If you don't subscribe to that list, then it's simply assumed that you're not a "real" member of the community.
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
Debian discusses Discourse
Debian discusses Discourse
- Mailing lists usually lack a one-click report button or link. They *might* have an abuse address, but typing out a message justifying yourself creates a lot more friction than just hitting a button.
- Off-list communication is completely impossible to effectively moderate. Forums need not expose a user's email address, typically require registration, and if necessary can implement IP blocking etc., so that their private messages are a lot harder to abuse.
- Mailing list users, in my experience, tend to be a lot more suspicious of content moderation than forum users, which makes it harder for list moderators to use the limited tools they have.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Email is more useful when the email archive is available as files on the development box.
Debian discusses Discourse
Debian discusses Discourse
Imagine your phone beeping each time you receive an email from LKML !
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
1. Fork the Discourse (it's OpenSource).
2. Switch to another forum software, leaving the old forum as a read-only archive.
3. Switch to another forum software, importing the data from Discourse.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
You actually can, through its API.
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
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
https://lwn.net/Articles/797613/ "Change IDs for kernel patches"
Hard to believe from the community who created git.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Fixing this will be compared to creating git.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
> In systems I've worked with we use branch namespaces to segment "public" and "private". Developers are allowed to rebase their private branches all they want, including after the private branch is pushed to a server,
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
> These changes are accomplished not by removing or modifying existing repository entries, but rather by adding new supplemental records. The original incorrect or unclear inputs are preserved and are readily accessible. The original history is preserved.
Debian discusses Discourse
Debian discusses Discourse
> " Programs must be written for people to read, and only incidentally for machines to execute.” The same view guides my philosophy for working with revisions, that code changes must be written for people to read [and review] and incidentally to change codebases.
Debian discusses Discourse
The obvious extension is that every in-editor edit should end up as a new commit.
You think it's a joke, but this is what git-wip does, triggering a commit in a not-normally-visible ref on every save via editor hooks. Its only problem (other than an unavoidable complete lack of useful commit log, so you more or less have to do a log -p restricted by date to find stuff you want to recover) is that it's so transparent that I usually forget that it even exists, so I don't use its careful records of every save I did as often as I could.
It's part of magit but also a separate project and I think there is a vi-hooking variant around too.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
9848c17b26 autosave ld/lexsup.c after stage
23ccc37ffb autosave ld/ldlex.h after stage
9ece7ac0f3 autosave ld/ldlang.c after stage
4652ac99a8 autosave ld/ldlang.c after stage
c9a78b787f autosave ld/ld.texi after stage
2e0966c4e8 autosave ld/ld.h after stage
bfd20b8df2 start autosaving index
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default
fbcdd02300 libctf: add ctf_link_set_variable_filter
...
662a4b4ee5 autosave ld/ldlang.c before stage
1c3b615c7d autosave ld/ld.texi before stage
1dccab233e autosave ld/ld.h before stage
5958b6cd68 autosave ld/lexsup.c after save
22bfa4bcfb autosave ld/lexsup.c after save
c744e6c41f autosave ld/lexsup.c after save
76c6a6e074 autosave ld/lexsup.c after save
caf21622cb autosave ld/lexsup.c after save
f7d813e9f5 autosave ld/lexsup.c after save
a486e6417e start autosaving worktree
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
https://github.com/zephyrproject-rtos/zephyr/pull/14444#i...
https://github.com/isaacs/github/issues/959#issuecomment-...
https://gitlab.com/gitlab-org/gitlab/issues/20339
Debian discusses Discourse
Writing niche software is visibly nothing the author is afraid of. Our community used to encourage that.
Debian discusses Discourse
I want to make it clear that I'm interested in trying out Discourse, and that there are discussions we had last year that I would rather have had on Discourse.
But the idea that if you turned off Discourse's web interface, it would be a reasonably comperable mailing list is simply not up to snuff. Among other things, you cannot:
Discourse Email Integrataion Short of Mailing List
These are not criticisms of Discourse: there are good reasons it works that way.
But Discourse would make a really crappy mailing list. Its email integration is adequate that a dedicated email user can participate in a forum offline.
Debian discusses Discourse
The world changes and technology moves on, we shall deal with it 8-)
Debian discusses Discourse
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
Debian discusses Discourse
And the total archivability is a feature to motivate folks to actually *think* about the stuff they write - with all positive and/or negative consequences.
*Why* do these supposedly "great developers" actually don't (want to) use email?
- "never used it before"/"don't know ...": Sry, developers should use the good tools and not just the one they know from the last job/project/...
- "one can read my 10 years old emails": So what? Just don't write anything without thinking about it (and then twitter, fb and similar so-called social media would be useful) - problem solved.
Yes, we all - at least me - made enough public fuck-ups - it may be embarrasing but that's it, nobody is perfect.
- "it's easier to write sth in some forum": Sry, but there is - TTBOMK - no forum software with threading like the next good MUA. Twitter never had it AFAIK, Fb had something in that direction but they castrated it to just one level - totally unusable for a useful and/or good discussion. With this change, Fb actually degenerated in the direction of twitter ...
Debian discusses Discourse
Mostly because email workflows are idiosyncratic and require tools that are far off the norm nowadays.
I contributed a couple of patches to Linux. I did it at my $DAYJOB, with my employer paying me for it. There's no way I would have set up all of the mail-related nonsense without it.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
No. The use of niche email clients (like mutt) and email to send patches is not basic training, as it's not used anywhere but in a few projects. It's educational, but just in the same way as fixing plumbing in your house.
No, we don't require anything like "built my own computer from sticks and stones". We also hire quite a few interns so I'm actually used to working with people out of basic training.
Debian discusses Discourse
Debian discusses Discourse
This would be true if the email workflow was somehow important for the core kernel functionality. But it's not, it's merely a tool used to contribute to the mainline.
This is true, but it's not a _requirement_. I know good developers who struggled to reinstall Windows or Linux on their laptops, simply because they have never had to do that.
Debian discusses Discourse
I'm having trouble believing that. Surely, learning something new, and adapting to it quickly, is one of the key requirements for being good.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
At _some_ point you'll have to draw a line. These days pretty much everybody uses git, so it's not really possible to be a good developer without knowing at least its basics.
Which basically comes down to "you must use mutt". Which IS a niche software.
Debian discusses Discourse
> Which basically comes down to "you must use mutt". Which IS a niche software.
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
If you cannot deal with a bunch of email files, I am not going to let you deal with files on my computer.
(because fundamentally that is what free software is about).
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
Debian discusses Discourse
Debian discusses Discourse
It's actually quite funny. If you host your code on Github under an Open Source license then you can get free CI from Travis or Github Actions.
Debian discusses Discourse
Debian discusses Discourse
The importance of email, from a member of “the newer generation”
google doesn't index mailing lists very well
google doesn't index mailing lists very well
The importance of email, from a member of “the newer generation”
thanks for sharing this!
Erich
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse
Debian discusses Discourse