[omdv]

Like many others I too admire Drew's work. But one thing I appreciate the most is the visual style and usability of Sourcehut. I don't know what it is exactly (am not a UX or visual designer myself, although work with them a lot), but to me it is one of the most aesthetically appealing sites I visit.

[fluffything]

I used some of their work, so I'm forever indebted to them.

However, I don't like how they treat users, potential contributors, etc.

Like, I started using sway full time, posted a question, started looking at the source code to fix it myself, and then just ended up fixing it for my fork and never pushing it upstream because the main thing I learned through my questions was that my free time is to valuable to deal with them.

Maybe 30 years ago the badge of being able to contribute to open source even though the maintainers are "super tough" meant something. But it's 2020: I want to do things in my free time that make me happy, I want to learn something while contributing to open source, and ideally learn from those who know more than me. So I'd rather just continue contributing to Rust, where everybody is super nice, those who know more teach and mentor those who know less, and in general the community is super open and reflective (e.g. the attitude is not "how come you didn't know this" but rather "which mistake did _we_ make that led you here without learning this along the way").

To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence.

This attitude is super harmful. Drew is just one person, and they can only do so much, and that does reflect on Sway, which is why I ended up switching back to i3.

[gustavo-fring]

Someone on this thread called Drew "militant", which isn't as negative as it sounds but accurate.

I will say, having observed his interactions in a few places, he rubs me the wrong way sometimes, even though it seems his heart is in the right place. I get it, totally guilty of it myself with strongly held views.

Don't mean this as a criticism but rather as a friendly suggestion if Drew is reading, but there are a lot of situations where backing down or just a softer approach is in order, especially now that he's running a business. There are a lot of us that are interested in what he's doing, but hesitant about using his services because it isn't obvious when the it is my way or the highway approach is going to come out.

[beagle3]

My observation is that most of the people who get projects done, in the sense that they can manage a project with many contributors over a long period of time with successful outcomes, are considered somewhere between militant and obnoxious by others. The project leaders who are all-around considered nice, like GvR and (so far) Andrew Kelly (not an exhaustive list!) are the exception, not the rule.

I do want to point that millitant/obnoxious/ahole is a very subjective judgement. Personally, I've read many of (what's considered) Linus' worst responses, and I did not find them a problem - he is not gentle, and he occasionally uses expletives, but he is factual, and drives the point through in places gentler people waste ten times as much effort, by themselves (and everyone else) to get the same result - and the result IS good.

I, for one, much prefer to be told "this is sh*t, you need to redo this" (assuming, of course, that's a good summary) than going around and around in endless deliberations about specific details.

[deng]

> To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence.

I was with you for a while, but this goes way too far. You had a bad experience with Drew on Sway, and because Drew is responsible for Sourcehut you project this on any project using Sourcehut as its platform?

[fluffything]

> You had a bad experience with Drew on Sway, and because Drew is responsible for Sourcehut you project this on any project using Sourcehut as its platform?

I've interacted with ~15 projects on Sourcehut, and all of them are by the same team of people maintaining Sway.

I'm not projecting to all sourcehut projects, just recollecting the experience of all sourcehut projects I've ever interacted with.

[enriquto]

> However, I don't like how they treat users, potential contributors, etc.

What are you talking about? The mailing lists are super friendly.

[fluffything]

I only interacted with them on Github issues in the sway repo.

The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]".

Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange.

At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind....

Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.

[ddevault]

I'm sorry you had a bad experience with Sway. If you can be more specific, with links to issues, it would be helpful for me to learn to deal with those cases better.

It's worth keeping in mind that maintainers see a lot more issues than you do. It's likely that I've heard and declined your feature a dozen times already, or that it's part of a broader class of problems which has been heard a hundred times. Sometimes, it tests my patience. And sometimes we do just have to say "no" - not every feature or change is desirable, and if we said "yes" to everything, then sway would quickly become a Cronenbergian mess.

[fluffything]

Being more specific would give away my identity, but this is one issue I ran into while moving from i3 to sway:

https://github.com/swaywm/sway/issues/1005#issuecomment-3315...

where the comment that closes the issue just says "we'll never implement this, issue closed".

I sympathize with you in that, if you had little time and other things to attend to, then just closing an issue is an instant reward of having something less to do.

But I think it would have been better to, first, don't do anything about that issue if you didn't had the time to do it properly (even if you were the one that filled the issue!), which would have been to write down the rationale why you think that feature is not worth its tradeoffs, and also, to have let other users speak up their mind, and see what others think, before making a decision.

For me, that difference in "project culture" is the difference between an open source project that's worth contributing to, and one that is not.

I've grown a couple of very large open source projects, and some of them I look at once a year, and they keep growing with dozens of PRs per week or day! The main reason I am able to just move on to other things is because I've grown and mentor the new maintainers and leaders of these projects , and I know they both carefully listen to the projects users, and are able to grow new contributors, just like I did.

[ddevault]

This was 3 years ago. I usually treat these issues a bit better these days.

However... I disagree with your suggestions about how to go about this better. You're still coming from a place where all paths lead to the implementation and inclusion of the feature. We will say "no" sometimes, and there's no amount of discussion which is going to change that. We're volunteers with a limited amount of time, why should we lead everyone on by entertaining a fruitless discussion in on a feature for which we have no interest in supporting?

There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed. At some point I just don't want to discuss it any more. I could redirect you to /dev/null and let you say your fill, but I don't think that's fair to you, either. You can't always get what you want, and if I don't always give you what you want, that doesn't make me a bad maintainer IMO.

[tsukurimashou]

you cannot be that emotionally involved, what you take as aggressive is simply someone not giving you enough attention.

and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.

[Dayshine]

The problem of course is that if you have

- an open source project which you advertise as collaborative open source

- a personal vision for what you want in your project

- and hence, a secret list of requests you will turn down

Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.

If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.

I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.

[pushedx]

One thing that I’ve learned from the Kubernetes community is to have a list of “Non-Goals” right next to every list of “Goals” in documentation, and of course to have a list of “Goals” at all.

[fluffything]

> and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.

So if someone sends you a contribution that isn't good enough, you reject them with a "no", and that's it?

Sure, you can do that. A different project might expend some time teaching that contributor and being nice to them, until their PR can be merged. And then the contributor submits another one that's better, and then another one, and then before you realize it you have another full time maintainer that you can trust.

So when you say that if a contribution isn't good enough you reject it I say "Thank you", because that person will move on to a different open source project, which might be one of mine, and I'll be getting another contributor instead.

You might not think that the work required to attract a new full-time contributor is worth it. To me it is.

[girzel]

I feel the same way, and as someone who has struggled to make his open source projects look like anything other than roaring garbage, I am perplexed, and jealous, and guess somehow a little hopeful?

I can totally imagine making something like Sir Hat (sorry) a part-time project and, in an alternate universe where I am a better coder and more dedicated than I actually am, producing something super solid after a few years. I cannot, however, imagine any universe in which I would produce something that looked as good as this.

I recommended it to the Emacs developers (who are considering moving to some sort of forge-alike site) in part because it seems to fit the FSF's principles, but more because the aesthetics are what Emacs should aspire to: plain text that looks good.

[kick]

What exactly do you think is so revolutionary about its design? I love it, personally, but I love it because it's not revolutionary. It takes some basic design principles and sticks to them militantly, which is sort of how Drew seems to handle everything. It's a successful approach.

Some tips:

If you're going for a flat look (which you should), don't go the Google direction.

* Make it actually flat; no shadows. Shadows are your enemy. Only use shadows if absolutely necessary, and even then think twice.

* Use solid lines to separate buttons and other colorful objects from the page. This is more accessible than shadows, and looks pretty instead of Google's weird 2014 pseudoskeuomorphism.

Use accessible colors!

* You have no excuse for using a color scheme that isn't accessible; accessible color schemes generally work better for people who aren't design-inclined, anyway.

* There are a bunch of sites you can use to check whether a color scheme is accessible, and there are also a bunch that have a bunch of accessible color schemes already laid out for you.

* Do not believe yourself when trying to justify an inclusion of a pretty color that makes the site less accessible. I know the color is pretty. There are a lot of colors that won't make the site harder to view, though!

Don't break from your design. Ever.

* Nobody likes using an application that has seven different styles of interaction and looks like it's from three different eras depending on the page you're on.

[girzel]

What you've described is exactly what I like about it! Just nice visible text, interactive elements are very evident, your eye goes in the right direction, and there's "nothing special" about it.

The tips you've provided are how not to screw up an excellent design. Not how to get an excellent design to begin with.

[brigandish]

Thanks for the tips.

I wasn't aware of what an accessible colour scheme is, a bit of searching and clicking led me to the Web Content Accessibility Guidelines guidelines [1]. Now I know to search for something like "WCAG colour scheme" there seem to be many more resources that are a bit less dry.

[1] https://www.w3.org/TR/WCAG20/

[indymike]

There's some really good advice right here:

Take some basic design principles and stick to them

[Polylactic_acid]

I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a list of branches and I had to click through every tab until I landed on "refs" that had it. What does refs mean? I assume its some internal git terminology but why not just call the tab branches. I then went to find out where I could submit a PR/MR and I couldn't find any such feature. I also couldn't find a list of bugs or how to open one.

I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.

[ddevault]

The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology.

SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way:

https://man.sr.ht/

There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started:

https://git-send-email.io

If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.

[thayne]

> There are no pull requests or merge requests. We use email, which is how Git was designed to be used.

I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has:

- Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky.

- Ability to search by tags/labels

- Automatic linking between related issues and pull requests (with backreferences)

- The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

- Highlighting changes in the diff (source hut actually does this)

I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.

[emersion]

Many of these features can be implemented in lists.sr.ht.

lists.sr.ht already has support for threads and diff highlighting. Example thread: https://lists.sr.ht/~emersion/public-inbox/patches/7077

[ddevault]

Quick drive-by response:

>Ability to subscribe to individual pull requests

>Automatic linking between related issues and pull requests (with backreferences)

Both are planned

>The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

Not planned, but you can pretty trivially do this yourself. Just git checkout -b test-branch before applying the commits locally.

>Ability to search by tags/labels

Already there, kind of. You can search by the patch prefix, which is generally used to indicate the subproject. This is also supported outright on tickets, for which it's arguably a lot more useful.

[thayne]

> Just git checkout -b test-branch before applying the commits locally.

I guess that works, but it is a few more steps than clicking on a link. And if you are actively working on the project, it means you have to either switch branches or make a new workspace.

[fluffything]

TBH it sounds to me that you just need a better email client ?

Like... that's the program that handles everything that you mentioned.

[oefrha]

The best solution to email filtering is not receiving irrelevant emails in the first place. It’s always funny seeing people bending over backwards to justify terrible inconveniences they’re merely used to.

Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?

[emersion]

aerc [1] supports arbitrary content filters (programs invoked when showing a message body). These are used for quote and diff highlighting. It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

[1]: https://aerc-mail.org/

[pcr910303]

Well, an email client isn't a tool just for developing - it's a generic tool that has a lot of use cases. I don't think one should sacrifice features to get diff highlights or filtering PRs, nor should a generic email client try to implement out-of-the-box SourceHut filtering functionality.

Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.

[ignaloidas]

Nothing is stopping you from using more than one email client.

[thayne]

Sure. What is that better email client? I don't mean to imply there isn't one, I'm genuinely curious what you email client you think has these features.

[goranmoomin]

> We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools.

I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.

> There are no pull requests or merge requests.

If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?

[ddevault]

>I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.

In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. I don't believe that users are not capable of learning new things. In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around.

>If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?

Yeah, this is still true, and somewhat implemented now. The large blue button on the repo summary page can clone the repo to your account, and then be used to interactively prepare a patchset to send to the mailing list. I'm not sure how Polylactic_acid missed it, actually, unless they don't have an account. The UI only works for account holders, though the big button is replaced with instructions on how to contribute by email if you're logged out.

There's a video of the process here:

https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...

[pcr910303]

> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance.

> I don't believe that users are not capable of learning new things.

Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches.

If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.

[ddevault]

But your suggestion relies on them knowing what "branches" are - an equally tenuous proposition for a new programmer, I think. Recall that at one point, you didn't know how to use GitHub, either. Pull requests? Cloning? What do these words mean, out of context? New users on GitHub struggle a lot, too, something I know from firsthand experience dealing with new programmers on my GitHub projects all the time.

I would prefer to solve these problems by fostering a culture of mentorship, and being responsive to questions. This is what I do on GitHub, too.

[jckzlg]

> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

I agree deeply with the ethos this statement represents. It's hard for me to formulate at the moment what I think this "ethos" is exactly, but I think it's really important. I'll try to explain by example. I think we should favor manpages over Stack Overflow, documentation over Google, composable CLI tools over monolithic IDEs, etc. I think that every engineer on a team should have read the most popular O'Reilly book (or some equivalent) for each of the tools the team works with. Of course, these "rules" are not commandments and we should always strive to be prudent.

Sometimes I'm accused of being cranky for these sorts of opinions, and I guess I might be, but I also see so much time and money wasted because nobody in an organization understands basic tools like SSH or how to use systemd.

The other day there was a developer tool on the front page of hacker news that lets you "run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse.

Edit: s/UPPERCASE/italics/

[TeMPOraL]

I generally agree with you. Especially strongly on the point about books.

It is my observation that, just as much as Stack Overflow and various on-line cheatsheets are replacing man pages (which is unfortunate), man pages are replacing info pages. By that I mean they aren't thorough enough. My eyes opened to that point when I started browsing M-x info in my Emacs, and run across documentation of non-Emacs things. Info pages tend to be more like a book than a short manual. And it's great, since if you're going to be using a tool semi-regularly, going through a book explaining it is a boost in learning time and scope.

And as a more general point: I miss the times when software shipped with book-sized manuals.

> run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse

I guess it depends on where you compose. The above goes against Unix philosophy, but not necessarily against Emacs philosophy. I.e. I consider Emacs as a 2D interface to composable applications (vs. 1D interface a command line is). So a bit of Elisp that implements a cloud API provides a piece that can be composed with just about every other piece of Elisp in Emacs, yielding a solution that's both composable and convenient :).

[thayne]

> I think we should favor manpages over Stack Overflow, documentation over Google

these are not really comparable things. I definitely don't think that Stack Overflow should replace man pages, but I still find Stack Overflow valuable. It's value is in finding how someone else solved a problem similar to the one you had, or where you go to ask other developers for help when the your attempt at finding the needed information in the documentation has failed.

[rswail]

The issue is that when we hire skilled craftsmen or engineers, we expect them to be familiar with and capable of using the tools of their craft.

You wouldn't hire a carpenter who didn't know how to use a hammer, why do we expect so called "software engineers" to be handheld through using a basic tool like git, which is entirely based on simple structures like a DAG, immutable hashes and pointers?

[Aeolun]

> In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around.

To be fair, when I tried sourcehut the first time around, I did go ‘wtf’ when I saw branches being called refs.

I didn’t end up using it though, so I’m probably not the target market.

I do like the reasoning behind the hub released now though, so maybe I’ll try again.

[vnorilo]

I use hg by choice and git when needed. The git interface feels confusing to me, but after learning the data model (enough to construct commits with the github data api) it suddenly seems a lot simpler, which I feel is a good reason to grok what "ref" actually means.

[oefrha]

> We use email, which is how Git was designed to be used.

> If you insist on everything having the same workflow, then what utility is there in different tools?

I'll admit many if not most git users have only ever tasted the GitHub workflow, but there are also many who have experienced the old school email workflow and the GitHub workflow and legitimately prefer the latter. Two major considerations:

1. A lot of value-add around pull requests, both in terms of organization/filtering and lifecycle features (inline comments/reviews, CI/CD integration, policy enforcement, merging from web interface, etc.). I planned to go into details here and actually wrote quite a few bullet points before realizing I can't do this topic justice without spending a lot of time to produce a huge wall of text, so please excuse me for the lack of details. (Note: not saying CI/CD integration is impossible with the email workflow, but it doesn't seem possible on sr.ht at the moment without manually pushing someone else's patch to a branch of yours -- correct me, and other implementations I have seen are nowhere as streamlined as those provided by GitHub and clones.)

2. Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete (e.g. In-Reply-To is not covered). Even the incomplete coverage highlights the complexity. Now what about the git-am side of the equation? How do I fish out a patch from my email client, any email client? How do I figure out which commit to apply the patch on top? Then there's the branching and git-am dance. Maybe it could be streamlined if you use some sort of hacker's mail client with ninja plugins, but you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly. The PR workflow, on the other hand, stays within the boundaries of push/fetch/pull/checkout, the basic operations required for working with any git remote and core competency of any git client (if you choose to use one); no ninja mail client required. hub(1) makes it even easier.

I don't think "how Git was designed to be used" is a strong defense, Linus isn't almighty and what he originally designed could be improved.

I can understand not being a GitHub clone, but when flexibility is a stated goal (I'm sort of reading between the lines, correct me if I'm wrong) maybe it doesn't hurt to support multiple workflows (a lot of work of course). Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table, which is in itself okay depending on your goal.

[ddevault]

>inline comments/reviews

>CI/CD integration

>merging from web interface

All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete.

>Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete

I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it.

>you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly

My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

>Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table

Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.

[oefrha]

Good to hear all the planned features in this reply and https://news.ycombinator.com/item?id=23041522. One small clarification: re: inline comments/reviews, what I had in mind was all reviews aggregated on a single page, not scattered and obsoleted by each patch version, which means comments are basically lost if not immediately addressed.

Anyway, it seems to me that once you have all these planned features, the workflow would inch towards the Phabricator workflow, and to a lesser extent the GitHub workflow. The only major differentiator would be that you use emails to send in patches instead of using a branch. The actual code review activity would center around the web interface instead of the mailing list. That would mean (if my interpretations are correct) we disagree to a much smaller extent than I thought, but that would also mean your workflow is actually pretty different from “how git was designed to be used”, which I interpret as the mailing list-centric workflow of lkml (as I understand it; I’m not involved) and other old school projects I have participated in.

Re mail clients:

> (1) you can use multiple email clients for different reasons, you don't need to give up your current one;

It’s possible, but not pleasant. Each client needs to be configured so that mail intended for the other doesn’t clutter it up (not only inbox, but also search, archive, etc.). Usually people already use two or more mail clients to begin with (pc, mobile), so, more configurations.

> (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...

[ddevault]

>Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...

_I_ like using emails. But the point of tools like that are so that people who don't like using emails can use other tools instead, and seamlessly collaborate with people who prefer to use emails.

[haolez]

Out of curiosity: what do you think of the attempts to create something better than emails for communication? Maybe easier to host without getting harassed by big corps anti-spam systems. Maybe with cryptography being easier and less error prone to use.

What do you think of something like Matrix?

[thayne]

What I found confusing is that after finding the source code page for a project, I couldn't figure out where to go navigate to the related bug tracker, mailing list, wiki, etc. It looks like the project hub now has project pages that help with that, but the individual pages don't seem to have backlinks to the project that contains them (or at least if they do, I can't find them). But it's still a work in progress, so hopefully that will come in due time.

[lhorie]

I find the text a bit hard to read (and it seems at least one other commenter mentioned the compressed line-height).

What I do notice is that the site loads very fast (sub-1s w/ cache disabled via devtools to simulate first visit, and sub-50ms otherwise). That alone deserves big props.

[ddevault]

I am very proud of our performance :)

https://forgeperf.org/

[mappu]

I think Codeberg.org is not doing the (normally very fast) Gitea any favors here, because it's hosted on Hetzner in Germany. Lighthouse may only throttle the connection further.

Where are the tests being run from?

Is there any way to control for network latency (maybe subtract the ICMP rtt from the tests?)

You might consider comparing it to other Gitea instances like https://try.gitea.io/ (Digital Ocean / USA), https://mirror.git.trinitydesktop.org/ (Czech Republic) or https://gitea.com/ (China), but I guess Codeberg is probably the most representative instance for public use.

[ddevault]

This has been brought up many times, but latency and bandwidth is controlled for with Lighthouse. The same tests have also been run from Germany without appreciably different results. It's also easy to run the test suite yourself if you have an hour of compute time to spare:

https://git.sr.ht/~sircmpwn/forgeperf

The goal here isn't to compare forge software (that would require a completely different approach to level the playing field), but to compare hosted options. The test suite is easily extended with other hosts or pages, and a few people have tested against their own Gitea instance - usually it ranks somewhere just above the middle of the pack.

[kick]

Line-height on Sourcehut itself is reasonable. It's just on the blog that it's off.

[Scarbutt]

some heavy caching is happening somewhere.

[ddevault]

No caching (except for the CSS file, which your browser is probably caching), just simple pages and lightweight backends.

https://forgeperf.org

All of our pages are done in 2 requests, or 1 with a warm cache.

[Hello71]

I was going to ask how you speed up pygments so much, but apparently the answer is "actually, some stuff is cached".

[ddevault]

Ah, yes, some stuff is cached :) but it doesn't do much, we kind of cache it on principle. An example that makes more of a difference is the git SSH pipeline.