Debian discusses Discourse

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.

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.

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

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.

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?

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.

"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...

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.

You've been reading my mind :-)

Nice https://jeremykun.com/2020/01/14/the-communicative-value-..., thanks!
> " 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.

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-...

> 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.