RE: Coming soon: A new site for fully free collaboration

[Alexandru-Sergiu Marton]

Hi all,

I want to comment on the "ongoing analysis" that's being done regarding 
the new collaboration platform. For Sourcehut, you listed

> No Web merge request UI. A Web merge request can be done by
> creating a ticket and including the forked git repo url and branch
> name, but this missing feature seems like a key thing we are looking 
> for.

as a bad thing. Let's discuss the "forking" and "merge request" ideas a 
little further.

Following the canonical GitHub model, a fork represents a copy of a 
repository from one user/organization to another user's/organization's 
account. Notice that it is essential that the forker has an account on 
the platform the process is done, otherwise this wouldn't work.

Forcing people to have an account on your code hosting platform for 
basic things like filing a bug report/feature request or sending patches 
doesn't benefit the users at all. It ties all of their actions to a 
specific workflow, basically locking them in. Compare these two 
workflows:

1) I want to fix a stack overflow bug in a Rust project hosted on 
GitHub. The actions I need to take are, in order: log in, fork, clone 
the fork locally, make the changes, commit, push, go back to the web UI, 
figure out how the hell the pull request interface works, send a pull 
request and wait for response.

2) I want to add a package to GNU Guix. I go to their Savannah page to 
find the link I need to clone. No account required. I clone the repo, 
make the changes, commit, `git format-patch` and send an email with the 
patch either in the email body or as an attachement to 
address@hidden and wait for response.

The most distributed and inclusive method is the second. That way, 
anyone who has an email account (and anyone has those, including the 
people that use the first workflow) can send in their contributions. It 
makes the whole process feel more personal also. There isn't a single 
step where you're required to use some overly specific tooling -- you 
write the code however you want, generate the patches however you want 
and send them however you want, as long as it reaches the maintainers.

But what if, in any of those two cases presented above, I would have to 
revise my contribution -- maybe I made a typo or I created a WIP thread 
and I'm now sending more progress.

1) I continue making changes to my fork, and the pull request follows 
whatever branch I set it to look at so it automatically updates with the 
latest commits when I push them. I don't know how one would gracefully 
handle amending the last commit with a PR system though.

2) I continue making changes to my local repository and commit them. 
When done, I send more emails, one per patch, to the already opened 
thread. If I want to revise my first patch, I can easily amend that 
commit in my local repository and send a second, improved version of the 
first patch without thinking about having to use --force.

One of the common so called "counter-arguments" to proposing email-based 
collaboration is "but email is antiquated". Email is indeed something 
that's been around for a long time, yet that doesn't make it bad. It 
encourages sending thoughtful messages, rather than short replies that 
lack important information. Furthermore, most people already have have 
an email address and, if not, it's very easy to obtain one -- from 
whatever provider you want.

We should keep in mind that we shouldn't be adopting the GitHub model 
just because that's what most people are familiar with. We should search 
for the best platform, not the most familiar. I am aware that 
email-based collaboration is alien to a big part of the people working 
in tech, but that doesn't mean it's bad or worse than the alternatives. 
In my opinion, it's the best thing we have yet. Simple, efficient, 
decentralized.

If anyone says that it's hard because they're not used to it, we 
shouldn't drop the idea. Instead, we should create better documentation, 
tutorials and guides to support people coming from the GitHub model or 
people that are totally new to contributing to free software projects.

If anyone reading this is interested in a taste of collaboration by 
email for git-based projects, check out this cool guide for using git 
send-email: https://git-send-email.io/

Note that the fact that I'm pushing for "email-based" collaboration 
makes this look more shallow than it is. If I know a maintainer I can 
drop him patches as letters to his door if I want to. I really need to 
stress out the fact that git patches can be sent exactly however you 
want -- they're just text.

Another reason to like patches is the fact that they can live outside 
the "official" project, too. Look at the suckless software -- st (simple 
terminal) doesn't include the ability to have transparency by default, 
yet they distribute a patch that, when applied, can make it go 
transparent.

I think everyone can agree that a clear git history is important for 
projects of any sizes. Unlike merge/pull requests, applied patches don't 
pollute your git history -- each patch is a commit, as it was in the 
patch-sender's tree, and that's it.

I remember a discussion about pull requests vs patches where someone 
said: "Let git do its job. No need for pull requests." I totally agree.

I'd like to hear your thoughts on this, especially about why "this 
missing feature seems like a key thing we are looking for".

Cheers,
Alexandru-Sergiu Marton