The section on Pull Requests was by far the least convincing part of this.
But low-trust is the opposite of what I believe most smaller teams want; even teams in big organizations. In those environments you want to encourage autonomy which requires high-trust.
What does this even mean? Trust in what? For what? To what ends? The author mentions an alternative to code review is basically massively wasting resources by having many people work on the same thing at the same computer at the same time. This still doesn’t solve the problem that code reviews are meant for. Another “alternative” is if you could “open up your teammates code as easily as opening a new file in your editor to leave comments”…so, basically all of those IDE integrations for… PR’s?
This is the fourth or fifth article I’m seeing, in a very short time span, which insists that PRs are an evil gatekeeping tool and I just don’t know what to make of it. Is this a real cultural trend? Is it marketing hype, and we’re going to see a big announcement about some Google/Apple/whoever else is at odds with Microsoft-sponsored hosting platform with a PR-less workflow in about six months? Is this a ploy to get everyone back into offices again?
I mean… leaving aside the matter of valid use cases for prudency, even in the presence of boundless trust (“a culture of trust” is the goat right up until someone breaks it and starts the first commit war) it’s genuinely baffling to me that something we’ve literally done forever with every bit of trust is suddenly gatekeeping.
I swear to God I’ve reviewed diffs, and submitted diffs for review, in good faith and with every bit of implied trust, for as long as I can remember, as far back as CVS and ClearCase being the thing of the day rather than the version control systems of Nag Hammadi. Pull requests are just the latest format for that.
We’ve always done it in addition to informal reviews (does nobody talk code at the watercooler/coffee machine anymore!?), never for gatekeeping, and I never felt kept at the gate, either [1]. It was just the final review stage, the one you get at when you feel your design and implementation are “final” enough that it’s worth a thorough review. We did it asynchronously, first over email, then over whatever review interface (Github/Gitla PRs nowadays) because “a thorough review” is a significant time investment for everyone else, so doing it asynchronously meant they could do it whenever they wanted.
I mean, the lead dev at my first “big” gig was an early riser and I was working part-time and putting myself through school – our schedules overlapped for two hours on a good day; of course we did patch reviews, the alternative was to lock her every Wednesday afternoon and Friday morning, and I was by no means the only doe-eyed h4x0r kid with delusions of programming grandeur she had to turn into a competent programmer.
Yes, like every system, it isn’t always done in good faith – some people just like to nitpick and show they’re the best and you suck. Public reviews, like PRs, are absolutely amazing for that, because they’re public, and you can call them on it, and the folks in charge can’t weasel out of it. If you think nasty punks are nasty there, wait until you see how they do “reviews” in person, in informal settings, where they can bully and threaten anyone, without anyone else or in the presence of a carefully-picked, narcissist-cheering audience, safe in the knowledge that there’s no record of that and any attempt to call them on it will inevitably degenerate into a he-said-she-said ordeal ordeal.
Have I been living in a bubble? Am I starting to lose it!?
(Edit:) [1] to clarify: I never felt “kept at the gate” because of the process itself. I’ve certainly had to deal with bad reviewers, of every kind – up to the point where, while I haven’t quit because of how code reviews went, it was a big reason why I quit at one point. But IMHO that has absolutely nothing to do with the pull request process itself. Douchebaginess is in no way confined to a pull request setting, and in my experience it tends to get worse in private.
I definitely think that a good part of this is in the domain of the old language game. Trust, as an interpersonal affect, is something entirely different from the belief of whether or not a change is correct. In the former sense, I trust myself and have thankfully trusted about every single person I’ve ever worked with. However, in the latter sense I’ve learned to distrust any new diff, especially my own!
I want my peers to check what I’m doing, because they might catch something I missed that will simply make my life better down the line.
I really don’t personally care how any one organization actually does code review but it seems pretty obvious it’s an essential part of reliably producing good software as a group of people. Attacking PR’s on the basis that code review itself is bad seems pretty backwards to me without evidence to show otherwise.
I find this “trend” rather strange - PRs are about quality; trust is a almost completely unrelated issue. I trust everyone in my team to work hard and do their level best, but even the best people I’ve worked with aren’t infallible.
I don’t seen “pairing” as a solution at all. Part of the value in code review is to get the perspective of someone who hasn’t been part of the development. When you’re close to the code it can be far too easy to miss things.
They are also about communication. People need to know about changes so that properly structure their work. If something fundamental changes then people need to understand it.
You are not losing it. I have come across a spectrum of different levels of review quality, as well as a spectrum of different expectations around reviews. Not to mention a variety of team size and complexity of code. Because the variety of experience is so varied, I expect some consider them as unnecessary friction based on limited experiences where they have not been valuable to the author.
I would stake the opinion that PRs as a default make the most sense for most professional situations (other than pairing). They are friction. It is true. They are also opportunities for advice, learning, insights, sharing knowledge, sharing responsibility , and rarely: catching big issues.
I do not accept the perspective that it boils down entirely to trust. Or even that blind trust is desirable.
Right, I mean, don’t get me wrong, I’ve had my share of terrible review experiences, and it’s not something you can keep in check through process alone. I’ve been in projects where reviews from some particular people on the team were literally causing more harm than good (nitpicked so much, and so arrogantly, that other people spent hours “fixing” completely irrelevant things like names of counter variables, and nobody ever got to see glaring performance bugs or outright buffer overflows). But those aren’t things you can fix by changing the particulars of the review and merging procedure, if someone’s an asshole in a PR, they’re going to be assholes in person and in informal settings, too.
You’re not starting to lose it. Because reasons, there’re increasing numbers of people pushing for what I’ll refer to as–for lack of a better term–software collectivization. In order to achieve this, power structures must be toppled and removed, and in order to accomplish that the removal of “gatekeeping” in the form of PRs and code reviews and contributor hierarchies must be done.
Because reasons, there’re increasing numbers of people pushing for what I’ll refer to as–for lack of a better term–software collectivization. In order to achieve this, power structures must be toppled and removed
Gendered power dynamics, ego-driven behavior, and the style of community-building that’s centered around a single charismatic individual who leads in a top-down fashion are not left or right, they can exist anywhere in politics, even in political niches that have spilled tankers of ink writing about why they’re bad.
Stallman has been openly and loudly a socialist, though he perpetuates misogyny and other bigotries which many leftists condemn. His many writings make this extremely clear.
It’s a different flavor, sure. My leftist friends talk a lot about this sort of thing and how to carry those core ideals forward without encouraging Stallman-esque behavior.
I guess I could see what this looks like on a theoretical level, but how would removing PRs and code reviews work on a practical level? If you have a project where the original creator has a certain vision and isn’t going to support a feature because it would add significant maintenance work, is that considered gatekeeping? Would denying a feature because it’s not implemented very well be considered gatekeeping?
I think the original author is lamenting PRs being used in domains where they are not adding value.
I worked on a large software project (thousands of developers) with no code reviews. It worked because the project is decomposed into components, and each component is worked on by a handful of people. Those people are highly motivated to ensure the code is robust, efficient, readable, maintainable, debuggable, etc. They have domain knowledge to do this well, and anyone who can’t will be moved along fairly quickly.
PRs are needed in open source for casual contributors. If somebody isn’t going to hang around to carry the project forward, that change needs some kind of evaluation from the people who are going to carry the project forward.
But somehow as an industry we’re drifting to a model where PRs are ubiquitous. The author says this is the “opposite of what I believe most smaller teams want; even teams in big organizations”, which suggests it’s not referring to open source.
Personally I think the big loss in this change is moving from a model where contributors set direction (in proportion to contribution!) to a model where managers or old-timers set direction. Instead of encouraging developers to think about design patterns that would be helpful, we end up with institutional dogma dictating patterns to apply. I really hope the next generation of developers can still learn the breadth of options and creative thinking when operating in these cultures.
However, it’s also not clear to me that Github made this happen. Github fully supports allowing many contributors to commit and push without PRs.
One tangential issue I’ve noticed with projects that take patches versus pull requests is who is responsible for revisions. When a maintainer gets a patch, it’s not uncommon to make small corrections—especially to things like formatting/variable names—and just merge in the patch because the essence of the patch was perfectly fine, it just needed some adjustments. In the pull request model, you might get someone to say “this needs to be named like [insert convention]”; the tests were passing but now we have to re-waste the contributor and the maintainers time going through a re-review process—and there are times where I’ve force-pushed on those fixes, poked the maintainer, & months went by before a merge. At any time, you can add .patch to the pull request URL and cURL the patch, and while the ability is appreciated, it’s more like a hidden feature and doing anything outside of the Microsoft GitHub UI breaks the one and only workflow that forge is designed to work with.
I am definitely not in the right bubble for that :-D. I think most of the patches I’ve submitted (regardless of format – diffs over email, Github PRs, whatever) are actually patches that I ended up merging myself. As in we all had commit rights on the main branch, this was just the most convenient review format. I think I ended up in some of the world’s worst power structures.
Of course there are exceptions. I’m the maintainer of a small Linux driver (“maintainer” as in I fire it up on a RPi every couple of weeks to make sure it works, it’s a trivial driver for a very simple ADC) and that obviously went through reviews. Thank God. The perspective of running an operating system developed by a team where everyone who’s as good a programmer as I am has commit rights on the main branch and everything gets reviewed as it’s being written, mostly in person, fills me with dread.
I actually like pair programming (and pair debugging! that’s super efficient) but if I had to review everything in person, on a continuous basis, and keep a schedule, I’d go insane in three weeks, tops.
This is the fourth or fifth article I’m seeing, in a very short time span, which insists that PRs are an evil gatekeeping tool and I just don’t know what to make of it. Is this a real cultural trend?
Not sure about trend, but toxic reviewers do definitely exist, and I’m guessing the author had a fair share of those. I’ve experienced both ends of the spectrum at different work places.
I’ve dealt with my share of toxic reviewers, too, I certainly don’t want to discount the author’s experience in that regard. But that is not inherent to pull requests in any way, just like toxic project managers aren’t inherent to project scheduling and task assignment, or hell, just like toxic programmers aren’t inherent to programming.
Besides, if toxic reviewers are a concern, IMHO moving the formal reviews from a public, written medium to a private, informal setting with no public and permanent record is about the worst thing you can do. In my experience, these people are worse in private, not better, and as long as they make sure not to be nasty in the presence of anyone who’ll talk to the wrong person in management, they can have a field day with interns and junior every day.
Sure, but no one says you can’t do both. You can always teach in private, no matter how you do the review. And public reviews are not devoid of teaching opportunities, either – I learned a lot by reading other people’s reviews of other people’s code.
So can you confidently tell me that the organization you work at right now can accomplish the same goals with the same budget if every single ticket was “mobbed”? I don’t want to give the impression I don’t think pair programming has its place, but I am here responding to the idea of replacing code review with such a thing.
So can you confidently tell me that the organization you work at right now can accomplish the same goals with the same budget if every single ticket was “mobbed”?
Oh, in that case definitely, since we’re such a small team most things are already anyway, heh.
I agree you don’t have to pair on 100% of all work that gets done necessarily, but not doing so shouldn’t be because one thinks it’s a better use of resources to avoid it. Pairing always pays off when the team knows how to do it (or at least someone in the pair does…)
I’ve always find it a strange choice as well, but since natively English speaking folks coined it like that, I guess it’s just us non-native English speakers that for some reason have a stronger association with negative meanings like “lynch mob”?
I believe it’s part of a thing that happens in management periodically, which can be distilled as ‘we have a problem with our culture that is made obvious by process X, we should therefore replace process X’.
There are problems with gatekeeping, leaving unhelpful or demotivating comments, and so on in a lot of projects. There are benefits from mentoring and leaving constructive comments that let people work at their own pace in a lot of projects. Both of these happen with the PR process, the difference is the team culture.
Fixing culture is hard though and selling people a new process is much simpler. I recently realised why I was so confused by the notion of a standup and why people thought it was useful after talking to a manager who started running them. They were happy that now they had horizontal communication within their team daily. My attitude had always been ‘why would you want to wait a whole day for horizontal communications and why would you make it synchronous?’. If your team culture is that horizontal communication doesn’t happy, you can either fix it (hard, requires actual management) or you can apply a patch from the Agile methodology that works around it. Expect to see a new range of buzzwords processes that try to work around poor team culture soon.
An important place to start is getting Microsoft GitHub out of classrooms and “influencers” for the next generation. There are a lot of courses and programs that require students to sign up for a Microsoft account to get their education and as a result, they’ll probably create a new project where their projects are.
Another important place to start is to police and push back against the genericized-trademark-ification of Microsoft GitHub preferring “Git forge” or “code forge”. This includes places like your job application form & the settings page of Lobsters which only allow two proprietary services to be linked with your Lobsters account.
Related is giving special treatment shorthands where $maintainer/$repo implies Microsoft GitHub—commonly plaguing Vim plugin managers. This makes users feel as if their choice to be elsewhere is lesser as their choice isn’t first-class supported. The worst thing a community do is standardize Microsoft GitHub as the only option for uploading community packages, as seen in Elm, or authentication being limited purely to Microsoft GitHub OAuth, as seen with Unison Share.
Also, for shorthands, there are still good ways to do shorthands without making GitHub special! Nix flake references have various types which can be used in the shorthand references:
Agreed. I like that there are shorthands but none is prioritized over the others & the documentation also point to using plain Git to support anyone anywhere. More specifically is that there is nouser/project that assumes one place over the other.
I’ve been using sourcehut lately but am warily eyeing the email-based pull request workflow. I like that engaging with it provides a lower-stakes playground for learning the workflow to prep users for possibly eventually contributing to larger projects like Linux, but it is a big obstacle for if you want contributing to be accessible. A lot more people have learned how to do github style PRs by comparison.
The main inability to escape is because so many projects use Github, so how do you contribute without supporting?
The only real way forward I can see is if one creates burner accounts that are deleted once the PR is merged. That or attempt to influence the project to a different platform. OR fork the project with something like Fossil and manage your own copy of it. You don’t have to give your bug fixes and code over to an OSS project, it’s just “nice”.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
The less a developer has the fight and fiddle with infrastructure the better. Developer tooling should just work and get out of the way of the real task, which is building a product useful for others.
Yeah, as someone who’s worked on these sorts of systems (my first full time job was at Bitbucket), I definitely have the knowledge but not the time for self-hosting… and feature wise GitHub is still miles ahead of the rest, plus there’s still the whole network effect.
I want to focus on building things that are useful to people - Emacs themes, SSH libraries, emulator frontends, whatever I find interesting. I don’t want to spend any more time or energy figuring out where to host them than I need to.
Calling this an “awful mindset” seems like a very short-sighted way of thinking.
feature wise GitHub is still miles ahead of the rest
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
Github’s page load times are atrocious compared to Sourcehut or Gitea. They claim you can reply to comment notifications over email, but that stopped working a couple years ago. Their CI doesn’t even have the ability to SSH into a failing build to debug, so its popularity while missing such a critical feature is rather baffling to me. Sure they have a large number of features, but once you look a little closer, each one on its own doesn’t hold up very well compared to the competition. (Unless you’re comparing with Gitlab in which case it becomes damning with faint praise.)
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
We may have to agree to disagree on this one - admittedly, it has been a while since I tried to use Gitea or something similar as a public instance (though I do have a private instance for some of my homelab infrastructure), but last time I did, GitHub’s more popular features were way more polished - pull requests/reviews, CI, issues/project management. I know Gitea recently added CI which is mostly compatible with GH Actions, so I’ll definitely try that out at some point, I just doubt it will fully replace GitHub for me.
plus there’s still the whole network effect.
It’s this. This is the whole thing.
It’s a bit more than this though, or at least a bit more nuanced. There’s also the monetary cost to hosting a service and how easy it is for people to contribute (which usually involves them setting up yet another account).
Part of my goal as an open source maintainer is making it easy for everyone to contribute, and right now the easiest place to do that is GitHub. I could see that changing in the future if there was a solid, easy-to-use federated system, but I personally can’t imagine that being easier to use, and it definitely wouldn’t be cheaper to run. Maybe it would still be worth it for me if it was close, but it seems like it’s a ways off still.
This isn’t to say moving to another platform doesn’t make sense for other people, but it also doesn’t line up well with my personal goals as an open source developer. I’ll be watching to see how things develop and migrate when it makes sense for me.
Contributing to anything on GitHub is supporting Microsoft materially speaking. It doesn’t matter if you used a normal account, burner account, or submitted the change via email. You are the product.
I use GH only to submit issues and lately started sponsoring a software on one of my favorite software programs. Hope I am not much of a product due to this reduced engagement with GH as a platform.
If a GitHub project receives a lot of patches via email that reduces GitHub’s hold on the maintainers, which would hurt Microsoft. Of course it’s possible that not receiving those patches at all could induce them to leave GitHub sooner, but no reason to think that’s usually the case.
An incredible number of things happen in the open source world because somebody was annoying enough about it but also nothing happens unless a maintainer somewhere is willing to go along with it. It probably depends on the project, what resources they have invested in the platform, and most importantly the political stance of the maintainers. If they see no problem with Microsoft and Github’s dominance, they’re unlikely to care much about changing regardless of what you do.
You can usually find an IRC channel or email address to send a patch to, even if the project doesn’t officially support any workflow other than GitHub.
I accept patches this way, but it’s very rare to find a maintainer who is receptive to this unless it’s someone from the olden days of sourceforge or savannah.
If the workflow is the issue and people want to advocate for this, maybe developers could normalize responding via email and/or listing a few alternative methods of contributing in the README? All my public projects are on GitHub, and every once in a while people reach out via IRC, but it’s not a very common occurrence… and that’s for the projects which list IRC as a place to get support.
It depends on how you do it - generally it involves someone submitting a patch via email, you having a back-and-forth similar to a review, and then you merging a re-submitted patch manually. It’s not very smooth, but it just needs an email client which supports attachments. Some platforms like SourceHut advocate the use of git-send-email, but that’s very quirky to set up properly.
Maybe I’m too far gone but I honestly don’t mind it.
I was able to get set up after reading git-send-email.io. To review and apply patches, I started with Thunderbird using the Colored Diffs addon, but more recently have taken to using aerc.
I can’t speak to different email clients, since I only use one client myself (mu4e in Emacs). But for me it works great; much smoother than the code review flow in github.
That said, for my primary projects I have left a read-only mirror in github since I know a lot of people haven’t got a good email setup. We still get contributions sent to that but they tend to be more minor; most of the contributors who have been around a while and tried it prefer email.
This is a strange argument. No matter where you host your code there is counterparty risk. That’s why the industry converged on distributed version control. If you want to reduce your counterparty risk to almost 0, then use multiple mirrors, don’t use any proprietary features on these mirrors, and if you have a private repo, encrypt it. Problem solved.
This article reminds me of when people say you should host your own IMAP server because Google is evil or whatever.
I’ll give you that. Self hosting an IMAP server definitely sounds like a better use of my time than spending hundreds, perhaps thousands, of cumulative hours throughout my life writing comments in obscure internet forums, arguing with random people I’ve never met in upvote-ordered comment trees.
Couldn’t agree more. When GitHub was bought by Microsoft, I migrated all my personal repos to GitLab, and since then I’ve never really had any reason to switch back. Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome. I do have a small self-hosted Gogs server; the only reason I chose Gogs over GitLab is just how resource-hungry GitLab can be for small collaborative groups. It scales well, I’m sure, but if you’ve just got 4 or 5 users it makes sense to use a lightweight server. Hell, for a few years I even just ran a git “server” with no front-end at all. Just pushing directly to repositories. If I wanted to create a new one I’d ssh in and make a –bare repo, and then push to it.
Addressing what others have said: I don’t get the Pull Requests thing either. It seems like a great way to manage contributions to public, open-source projects. Especially if you get many small contributions from a large number of people, with a small core group of developers, the amount of time it saves everyone really does add up. But, if you don’t want to support GitHub but want to contribute to projects on there, emailing git-formatted patches is a thing. I mean, that’s how the Linux team still does it, right? I don’t have much experience using git this way, but I have done some work manually emailing diff/patch stuff and if git integrates well, it’s probably not too painful.
I think trying to convince projects to move to a different platform is a great idea in principle, but when a stranger walks in and immediately starts complaining about the hosting service, the devs usually have bigger fish to fry. I think it’s better to encourage new projects to use alternative platforms. A huge number of people seem to have only heard of GitHub and maybe GitLab; but as I mentioned, there are Gogs and Gitea for self-hosting, SourceHut, LaunchPad, and BitBucket; plus there are lots of free tools like Gerrit that help manage git and code tracking.
Curious to know what platforms people use by default, especially when it comes to personal vs. professional projects.
Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome.
Weellllllll … partially. Part of it is open source and free to self-host. Whereas Sourcehut (where I migrated to from GitLab, after having left GitHub) is fully open source.
Is there a transcript or text version? I don’t really ‘do’ video content, but given the title, I suspect it’s not really addressing the point. Pairing isn’t a code review strategy, it’s something else entirely, it’s “code with 2 authors doesn’t require review” which is totally viable in an company, but less so in OSS.
Git has supported “federation” from its inception. Activity-pub’ing some git frontend webshit isn’t going to work any better than adding activitypub to anything else has.
Put issues and documentation into the source-code repository. Check in all relevant files. (GitHub makes this difficult; Issues are designed to be hard to move to another service.)
One way to do this, given tooling support, may be an explicit folder for ‘broken tests’; then issue reports can take the form of “pull request/patch for a broken test.”
I’m a little nervous about federation as a strategy here, for the same reason that I don’t think the fediverse should be the end-goal of social media: federation leads to feudalism
I think there might need to be some creative thinking on what to do instead. taking a corporate platform and trying to mirror the identical features as if they make sense when decentralized is a bit silly. the thing where you submit changes by forking the repo was never really for the benefit of the community, it was to give github a network effect.
people submitted patches through mailing lists for decades before github came along. it worked fine. people made local copies of repos to work in, not every contributor needed to have a published repo. I do understand why, in a world where email is for old people, that model probably needs to be rethought, but I offer it as an existence proof that there are meaningfully different strategies that work.
(I note that the author of this article would probably still be upset about the central approver on a mailing list thing as “gatekeeping”, but I think it’s worth discussing regardless)
Can you elaborate on that? AFAIK actual feudalism only persisted because people weren’t free to switch patrons / lords / what-have-you.
Relatedly: this is why I worry when political power is centralised in Federal Government rather than remaining with the States (here in Australia). Granted there are efficiency arguments, but one of the major attractions of a federation is the freedom to switch states if one goes off the rails.
I’d love to elaborate on that, and since I do kind of have a habit of saying it a lot I need to flesh out the metaphor a bit more. the following thoughts are in the nature of a first draft, not well-thought-out, so please take them for what they’re worth.
I see two negative aspects of federated social networks which I consider to be feudalism. the first is the power dynamic that instance operators have with respect to their members. the second, and the one that really suggests “feudalism” as a word to me, is that instances wind up in conflict with each other, staking out territory and attacking each others’ reputations and generally trying to create impermeable boundaries between parts of the fediverse, where you can’t see your friends if you’re on the wrong side of the instance-block wall.
I agree in principle that ease of switching would give members more power, if you could actually switch without consequences, but there are consequences, both technical (you lose all your post history) and social (you lose access to some subset of your former mutuals, and you can’t easily guess who, unless you somehow have the entire map of the political terrain in your head).
the other thing to keep in mind about switching is that in many cases, it doesn’t actually solve the problem. if your instance has been widely defederated due to political dynamics such as coordinated efforts to characterize marginalized groups you belong to as inherently abusive or whatever, that’s going to happen on any instance you and your friends choose to move to. switching is high-cost and at best a short-term solution to that sort of thing. so the incentive is generally to pick a place and stay there.
The discussion about PRs leaves out pre-checkin CI runs. That is incredibly useful to have. Catch the problem before it gets commited and avoid the “works on my machine” problem. Sure there are problems with CIs too, but for the most part they are very useful.
hmm, now that I’ve finally found time to read this, I think I like the author’s motivations and goals more than I like their thoughts on what to do about it. I appreciated people’s speculation here that this could be corporate propaganda but it doesn’t feel that way to me, although there’s ideology at play (as the author openly states).
I would have mentioned stuff like the “everyone pulls” model as worth doing more of, in this context. I think that’s indeed a more liberatory model than pull requests, although the short-term difference is not that big a deal.
it’s worth noticing that git, the underlying technology, was written for the exact ideological reasons this author appeals to. I don’t think we should move away from git, especially not to options which are more corporate in nature. I do think we should look at less corporate ways to use it, and what it would take to shift the culture that way.
I don’t agree with most points in that article (and the articles it references), but I think this paragraph sums up my overall feeling about the subject:
If GitHub continues to evolve in directions I’m not comfortable with, I have alternatives for some critical tools. I also still use GitHub, but I only choose it when it has something to offer, not because it’s convenient.
Reminder that https://pagure.io/pagure exists and is a GPL source control platform. No hosts running this as a service so far as I know, but nothing stops anyone reading this from being that host.
Or what if a tool could helps teams design software before code is written?
…
I do not know what these tools are or what they look like, …
To me this is where frameworks come into play. Adopting a framework is akin agreeing that problems like those that fit the framework should be implemented using the patterns and tools provided by the framework. We have a lot of tools for linting code at a textual level but I would like to see frameworks begin to ship linter-esque tools that would help focus review. i.e. this one file looks least like what we would expect for this framework so focus review on it.
I want to underscore this because I think it’s important: git and GitHub’s symbiosis are holding us back as an industry.
Quoted for truth. GitHub’s work model is one thing, but having so much critical infrastructure dependent on a for-profit company is another thing. I know a lot of folks view Microsoft more positively than we did in the 90s, but I’m fearing a resurgence of “embrace/extend/extinguish” – so far it’s thin at best, but when I see things like GitHub providing their own gh CLI tooling that they promote alongside/over the git client (which yes, I know they work diligently on), I can’t help but be reminded of the bad old days.
The section on Pull Requests was by far the least convincing part of this.
What does this even mean? Trust in what? For what? To what ends? The author mentions an alternative to code review is basically massively wasting resources by having many people work on the same thing at the same computer at the same time. This still doesn’t solve the problem that code reviews are meant for. Another “alternative” is if you could “open up your teammates code as easily as opening a new file in your editor to leave comments”…so, basically all of those IDE integrations for… PR’s?
This is the fourth or fifth article I’m seeing, in a very short time span, which insists that PRs are an evil gatekeeping tool and I just don’t know what to make of it. Is this a real cultural trend? Is it marketing hype, and we’re going to see a big announcement about some Google/Apple/whoever else is at odds with Microsoft-sponsored hosting platform with a PR-less workflow in about six months? Is this a ploy to get everyone back into offices again?
I mean… leaving aside the matter of valid use cases for prudency, even in the presence of boundless trust (“a culture of trust” is the goat right up until someone breaks it and starts the first commit war) it’s genuinely baffling to me that something we’ve literally done forever with every bit of trust is suddenly gatekeeping.
I swear to God I’ve reviewed diffs, and submitted diffs for review, in good faith and with every bit of implied trust, for as long as I can remember, as far back as CVS and ClearCase being the thing of the day rather than the version control systems of Nag Hammadi. Pull requests are just the latest format for that.
We’ve always done it in addition to informal reviews (does nobody talk code at the watercooler/coffee machine anymore!?), never for gatekeeping, and I never felt kept at the gate, either [1]. It was just the final review stage, the one you get at when you feel your design and implementation are “final” enough that it’s worth a thorough review. We did it asynchronously, first over email, then over whatever review interface (Github/Gitla PRs nowadays) because “a thorough review” is a significant time investment for everyone else, so doing it asynchronously meant they could do it whenever they wanted.
I mean, the lead dev at my first “big” gig was an early riser and I was working part-time and putting myself through school – our schedules overlapped for two hours on a good day; of course we did patch reviews, the alternative was to lock her every Wednesday afternoon and Friday morning, and I was by no means the only doe-eyed h4x0r kid with delusions of programming grandeur she had to turn into a competent programmer.
Yes, like every system, it isn’t always done in good faith – some people just like to nitpick and show they’re the best and you suck. Public reviews, like PRs, are absolutely amazing for that, because they’re public, and you can call them on it, and the folks in charge can’t weasel out of it. If you think nasty punks are nasty there, wait until you see how they do “reviews” in person, in informal settings, where they can bully and threaten anyone, without anyone else or in the presence of a carefully-picked, narcissist-cheering audience, safe in the knowledge that there’s no record of that and any attempt to call them on it will inevitably degenerate into a he-said-she-said ordeal ordeal.
Have I been living in a bubble? Am I starting to lose it!?
(Edit:) [1] to clarify: I never felt “kept at the gate” because of the process itself. I’ve certainly had to deal with bad reviewers, of every kind – up to the point where, while I haven’t quit because of how code reviews went, it was a big reason why I quit at one point. But IMHO that has absolutely nothing to do with the pull request process itself. Douchebaginess is in no way confined to a pull request setting, and in my experience it tends to get worse in private.
I definitely think that a good part of this is in the domain of the old language game. Trust, as an interpersonal affect, is something entirely different from the belief of whether or not a change is correct. In the former sense, I trust myself and have thankfully trusted about every single person I’ve ever worked with. However, in the latter sense I’ve learned to distrust any new diff, especially my own!
I want my peers to check what I’m doing, because they might catch something I missed that will simply make my life better down the line.
I really don’t personally care how any one organization actually does code review but it seems pretty obvious it’s an essential part of reliably producing good software as a group of people. Attacking PR’s on the basis that code review itself is bad seems pretty backwards to me without evidence to show otherwise.
I find this “trend” rather strange - PRs are about quality; trust is a almost completely unrelated issue. I trust everyone in my team to work hard and do their level best, but even the best people I’ve worked with aren’t infallible.
I don’t seen “pairing” as a solution at all. Part of the value in code review is to get the perspective of someone who hasn’t been part of the development. When you’re close to the code it can be far too easy to miss things.
They are also about communication. People need to know about changes so that properly structure their work. If something fundamental changes then people need to understand it.
You are not losing it. I have come across a spectrum of different levels of review quality, as well as a spectrum of different expectations around reviews. Not to mention a variety of team size and complexity of code. Because the variety of experience is so varied, I expect some consider them as unnecessary friction based on limited experiences where they have not been valuable to the author.
I would stake the opinion that PRs as a default make the most sense for most professional situations (other than pairing). They are friction. It is true. They are also opportunities for advice, learning, insights, sharing knowledge, sharing responsibility , and rarely: catching big issues.
I do not accept the perspective that it boils down entirely to trust. Or even that blind trust is desirable.
Right, I mean, don’t get me wrong, I’ve had my share of terrible review experiences, and it’s not something you can keep in check through process alone. I’ve been in projects where reviews from some particular people on the team were literally causing more harm than good (nitpicked so much, and so arrogantly, that other people spent hours “fixing” completely irrelevant things like names of counter variables, and nobody ever got to see glaring performance bugs or outright buffer overflows). But those aren’t things you can fix by changing the particulars of the review and merging procedure, if someone’s an asshole in a PR, they’re going to be assholes in person and in informal settings, too.
You’re not starting to lose it. Because reasons, there’re increasing numbers of people pushing for what I’ll refer to as–for lack of a better term–software collectivization. In order to achieve this, power structures must be toppled and removed, and in order to accomplish that the removal of “gatekeeping” in the form of PRs and code reviews and contributor hierarchies must be done.
You mean people like Richard Stallman?
Ha, I suppose so! I think that it’s a somewhat different flavor there.
You seem to be implying that it is somehow bad/wrong/sinister for people to want to do what Richard Stallman has been advocating for decades.
So if his crusade is not what you meant, could you perhaps provide a concrete example of what you did mean?
Gendered power dynamics, ego-driven behavior, and the style of community-building that’s centered around a single charismatic individual who leads in a top-down fashion are not left or right, they can exist anywhere in politics, even in political niches that have spilled tankers of ink writing about why they’re bad.
Stallman has been openly and loudly a socialist, though he perpetuates misogyny and other bigotries which many leftists condemn. His many writings make this extremely clear.
It’s a different flavor, sure. My leftist friends talk a lot about this sort of thing and how to carry those core ideals forward without encouraging Stallman-esque behavior.
I guess I could see what this looks like on a theoretical level, but how would removing PRs and code reviews work on a practical level? If you have a project where the original creator has a certain vision and isn’t going to support a feature because it would add significant maintenance work, is that considered gatekeeping? Would denying a feature because it’s not implemented very well be considered gatekeeping?
I think the original author is lamenting PRs being used in domains where they are not adding value.
I worked on a large software project (thousands of developers) with no code reviews. It worked because the project is decomposed into components, and each component is worked on by a handful of people. Those people are highly motivated to ensure the code is robust, efficient, readable, maintainable, debuggable, etc. They have domain knowledge to do this well, and anyone who can’t will be moved along fairly quickly.
PRs are needed in open source for casual contributors. If somebody isn’t going to hang around to carry the project forward, that change needs some kind of evaluation from the people who are going to carry the project forward.
But somehow as an industry we’re drifting to a model where PRs are ubiquitous. The author says this is the “opposite of what I believe most smaller teams want; even teams in big organizations”, which suggests it’s not referring to open source.
Personally I think the big loss in this change is moving from a model where contributors set direction (in proportion to contribution!) to a model where managers or old-timers set direction. Instead of encouraging developers to think about design patterns that would be helpful, we end up with institutional dogma dictating patterns to apply. I really hope the next generation of developers can still learn the breadth of options and creative thinking when operating in these cultures.
However, it’s also not clear to me that Github made this happen. Github fully supports allowing many contributors to commit and push without PRs.
One tangential issue I’ve noticed with projects that take patches versus pull requests is who is responsible for revisions. When a maintainer gets a patch, it’s not uncommon to make small corrections—especially to things like formatting/variable names—and just merge in the patch because the essence of the patch was perfectly fine, it just needed some adjustments. In the pull request model, you might get someone to say “this needs to be named like [insert convention]”; the tests were passing but now we have to re-waste the contributor and the maintainers time going through a re-review process—and there are times where I’ve force-pushed on those fixes, poked the maintainer, & months went by before a merge. At any time, you can add
.patchto the pull request URL and cURL the patch, and while the ability is appreciated, it’s more like a hidden feature and doing anything outside of the Microsoft GitHub UI breaks the one and only workflow that forge is designed to work with.I am definitely not in the right bubble for that :-D. I think most of the patches I’ve submitted (regardless of format –
diffs over email, Github PRs, whatever) are actually patches that I ended up merging myself. As in we all had commit rights on the main branch, this was just the most convenient review format. I think I ended up in some of the world’s worst power structures.Of course there are exceptions. I’m the maintainer of a small Linux driver (“maintainer” as in I fire it up on a RPi every couple of weeks to make sure it works, it’s a trivial driver for a very simple ADC) and that obviously went through reviews. Thank God. The perspective of running an operating system developed by a team where everyone who’s as good a programmer as I am has commit rights on the main branch and everything gets reviewed as it’s being written, mostly in person, fills me with dread.
I actually like pair programming (and pair debugging! that’s super efficient) but if I had to review everything in person, on a continuous basis, and keep a schedule, I’d go insane in three weeks, tops.
Not sure about trend, but toxic reviewers do definitely exist, and I’m guessing the author had a fair share of those. I’ve experienced both ends of the spectrum at different work places.
I’ve dealt with my share of toxic reviewers, too, I certainly don’t want to discount the author’s experience in that regard. But that is not inherent to pull requests in any way, just like toxic project managers aren’t inherent to project scheduling and task assignment, or hell, just like toxic programmers aren’t inherent to programming.
Besides, if toxic reviewers are a concern, IMHO moving the formal reviews from a public, written medium to a private, informal setting with no public and permanent record is about the worst thing you can do. In my experience, these people are worse in private, not better, and as long as they make sure not to be nasty in the presence of anyone who’ll talk to the wrong person in management, they can have a field day with interns and junior every day.
The challenge there is that (IME) a private discussion is the best place for a caring mentor to teach.
Sure, but no one says you can’t do both. You can always teach in private, no matter how you do the review. And public reviews are not devoid of teaching opportunities, either – I learned a lot by reading other people’s reviews of other people’s code.
They are not a replacement for code review per se, but pairing and mobbing are hardly “wasting resources”.
So can you confidently tell me that the organization you work at right now can accomplish the same goals with the same budget if every single ticket was “mobbed”? I don’t want to give the impression I don’t think pair programming has its place, but I am here responding to the idea of replacing code review with such a thing.
Oh, in that case definitely, since we’re such a small team most things are already anyway, heh.
I agree you don’t have to pair on 100% of all work that gets done necessarily, but not doing so shouldn’t be because one thinks it’s a better use of resources to avoid it. Pairing always pays off when the team knows how to do it (or at least someone in the pair does…)
What does this mean, in this context? Because it has a specific meaning in Swedish: bullying.
It means pair programming by more than 2 people.
Thanks. Needs a rebrand, a “mob” is generally considered pejorative.
I’ve always find it a strange choice as well, but since natively English speaking folks coined it like that, I guess it’s just us non-native English speakers that for some reason have a stronger association with negative meanings like “lynch mob”?
OK, it’s done a weird circuitous route from English via German to Swedish:
https://en.wikipedia.org/wiki/Mobbing#Development_of_the_concept
Edit I think the people who coined the term “mob programming” simply didn’t know about the negative connotations.
I believe it’s part of a thing that happens in management periodically, which can be distilled as ‘we have a problem with our culture that is made obvious by process X, we should therefore replace process X’.
There are problems with gatekeeping, leaving unhelpful or demotivating comments, and so on in a lot of projects. There are benefits from mentoring and leaving constructive comments that let people work at their own pace in a lot of projects. Both of these happen with the PR process, the difference is the team culture.
Fixing culture is hard though and selling people a new process is much simpler. I recently realised why I was so confused by the notion of a standup and why people thought it was useful after talking to a manager who started running them. They were happy that now they had horizontal communication within their team daily. My attitude had always been ‘why would you want to wait a whole day for horizontal communications and why would you make it synchronous?’. If your team culture is that horizontal communication doesn’t happy, you can either fix it (hard, requires actual management) or you can apply a patch from the Agile methodology that works around it. Expect to see a new range of buzzwords processes that try to work around poor team culture soon.
An important place to start is getting Microsoft GitHub out of classrooms and “influencers” for the next generation. There are a lot of courses and programs that require students to sign up for a Microsoft account to get their education and as a result, they’ll probably create a new project where their projects are.
Another important place to start is to police and push back against the genericized-trademark-ification of Microsoft GitHub preferring “Git forge” or “code forge”. This includes places like your job application form & the settings page of Lobsters which only allow two proprietary services to be linked with your Lobsters account.
Related is giving special treatment shorthands where
$maintainer/$repoimplies Microsoft GitHub—commonly plaguing Vim plugin managers. This makes users feel as if their choice to be elsewhere is lesser as their choice isn’t first-class supported. The worst thing a community do is standardize Microsoft GitHub as the only option for uploading community packages, as seen in Elm, or authentication being limited purely to Microsoft GitHub OAuth, as seen with Unison Share.Also, for shorthands, there are still good ways to do shorthands without making GitHub special! Nix flake references have various types which can be used in the shorthand references:
I think more projects should pick up similar shorthand formats - they have support for some large forges built-in, but not just one large forge.
Agreed. I like that there are shorthands but none is prioritized over the others & the documentation also point to using plain Git to support anyone anywhere. More specifically is that there is no
user/projectthat assumes one place over the other.yes, absolutely agreed
I’ve been using sourcehut lately but am warily eyeing the email-based pull request workflow. I like that engaging with it provides a lower-stakes playground for learning the workflow to prep users for possibly eventually contributing to larger projects like Linux, but it is a big obstacle for if you want contributing to be accessible. A lot more people have learned how to do github style PRs by comparison.
Pijul rocks.
The main inability to escape is because so many projects use Github, so how do you contribute without supporting?
The only real way forward I can see is if one creates burner accounts that are deleted once the PR is merged. That or attempt to influence the project to a different platform. OR fork the project with something like Fossil and manage your own copy of it. You don’t have to give your bug fixes and code over to an OSS project, it’s just “nice”.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
The less a developer has the fight and fiddle with infrastructure the better. Developer tooling should just work and get out of the way of the real task, which is building a product useful for others.
Yeah, as someone who’s worked on these sorts of systems (my first full time job was at Bitbucket), I definitely have the knowledge but not the time for self-hosting… and feature wise GitHub is still miles ahead of the rest, plus there’s still the whole network effect.
I want to focus on building things that are useful to people - Emacs themes, SSH libraries, emulator frontends, whatever I find interesting. I don’t want to spend any more time or energy figuring out where to host them than I need to.
Calling this an “awful mindset” seems like a very short-sighted way of thinking.
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
Github’s page load times are atrocious compared to Sourcehut or Gitea. They claim you can reply to comment notifications over email, but that stopped working a couple years ago. Their CI doesn’t even have the ability to SSH into a failing build to debug, so its popularity while missing such a critical feature is rather baffling to me. Sure they have a large number of features, but once you look a little closer, each one on its own doesn’t hold up very well compared to the competition. (Unless you’re comparing with Gitlab in which case it becomes damning with faint praise.)
It’s this. This is the whole thing.
We may have to agree to disagree on this one - admittedly, it has been a while since I tried to use Gitea or something similar as a public instance (though I do have a private instance for some of my homelab infrastructure), but last time I did, GitHub’s more popular features were way more polished - pull requests/reviews, CI, issues/project management. I know Gitea recently added CI which is mostly compatible with GH Actions, so I’ll definitely try that out at some point, I just doubt it will fully replace GitHub for me.
It’s a bit more than this though, or at least a bit more nuanced. There’s also the monetary cost to hosting a service and how easy it is for people to contribute (which usually involves them setting up yet another account).
Part of my goal as an open source maintainer is making it easy for everyone to contribute, and right now the easiest place to do that is GitHub. I could see that changing in the future if there was a solid, easy-to-use federated system, but I personally can’t imagine that being easier to use, and it definitely wouldn’t be cheaper to run. Maybe it would still be worth it for me if it was close, but it seems like it’s a ways off still.
This isn’t to say moving to another platform doesn’t make sense for other people, but it also doesn’t line up well with my personal goals as an open source developer. I’ll be watching to see how things develop and migrate when it makes sense for me.
Contributing to anything on GitHub is supporting Microsoft materially speaking. It doesn’t matter if you used a normal account, burner account, or submitted the change via email. You are the product.
I use GH only to submit issues and lately started sponsoring a software on one of my favorite software programs. Hope I am not much of a product due to this reduced engagement with GH as a platform.
If a GitHub project receives a lot of patches via email that reduces GitHub’s hold on the maintainers, which would hurt Microsoft. Of course it’s possible that not receiving those patches at all could induce them to leave GitHub sooner, but no reason to think that’s usually the case.
An incredible number of things happen in the open source world because somebody was annoying enough about it but also nothing happens unless a maintainer somewhere is willing to go along with it. It probably depends on the project, what resources they have invested in the platform, and most importantly the political stance of the maintainers. If they see no problem with Microsoft and Github’s dominance, they’re unlikely to care much about changing regardless of what you do.
You can usually find an IRC channel or email address to send a patch to, even if the project doesn’t officially support any workflow other than GitHub.
I accept patches this way, but it’s very rare to find a maintainer who is receptive to this unless it’s someone from the olden days of sourceforge or savannah.
If the workflow is the issue and people want to advocate for this, maybe developers could normalize responding via email and/or listing a few alternative methods of contributing in the README? All my public projects are on GitHub, and every once in a while people reach out via IRC, but it’s not a very common occurrence… and that’s for the projects which list IRC as a place to get support.
Curious, how smooth/easy is the git->email->git workflow? Does it integrate well with different email clients?
It depends on how you do it - generally it involves someone submitting a patch via email, you having a back-and-forth similar to a review, and then you merging a re-submitted patch manually. It’s not very smooth, but it just needs an email client which supports attachments. Some platforms like SourceHut advocate the use of git-send-email, but that’s very quirky to set up properly.
Maybe I’m too far gone but I honestly don’t mind it.
I was able to get set up after reading git-send-email.io. To review and apply patches, I started with Thunderbird using the Colored Diffs addon, but more recently have taken to using aerc.
I can’t speak to different email clients, since I only use one client myself (mu4e in Emacs). But for me it works great; much smoother than the code review flow in github.
That said, for my primary projects I have left a read-only mirror in github since I know a lot of people haven’t got a good email setup. We still get contributions sent to that but they tend to be more minor; most of the contributors who have been around a while and tried it prefer email.
they are not receptive in the sense that they will ignore your patch?
Usually either ignore altogether or redirect you to the pull request flow, yeah.
I guess it’s more common than I thought, but I maintain that projects like that are a joke.
If I had the luxury of being able to not use projects run by people who made bad decisions I would be a much happier person than I am today.
at least you can withhold your patches
This is a strange argument. No matter where you host your code there is counterparty risk. That’s why the industry converged on distributed version control. If you want to reduce your counterparty risk to almost 0, then use multiple mirrors, don’t use any proprietary features on these mirrors, and if you have a private repo, encrypt it. Problem solved.
This article reminds me of when people say you should host your own IMAP server because Google is evil or whatever.
To be fair, running your own IMAP server is fun! It definitely doesn’t prematurely age you.
I’ll give you that. Self hosting an IMAP server definitely sounds like a better use of my time than spending hundreds, perhaps thousands, of cumulative hours throughout my life writing comments in obscure internet forums, arguing with random people I’ve never met in upvote-ordered comment trees.
please imagine me making a skeptical thinking face here :D
I mean… I sincerely believe the thing you said. I’m not sure anyone else does :D
Couldn’t agree more. When GitHub was bought by Microsoft, I migrated all my personal repos to GitLab, and since then I’ve never really had any reason to switch back. Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome. I do have a small self-hosted Gogs server; the only reason I chose Gogs over GitLab is just how resource-hungry GitLab can be for small collaborative groups. It scales well, I’m sure, but if you’ve just got 4 or 5 users it makes sense to use a lightweight server. Hell, for a few years I even just ran a git “server” with no front-end at all. Just pushing directly to repositories. If I wanted to create a new one I’d ssh in and make a –bare repo, and then push to it.
Addressing what others have said: I don’t get the Pull Requests thing either. It seems like a great way to manage contributions to public, open-source projects. Especially if you get many small contributions from a large number of people, with a small core group of developers, the amount of time it saves everyone really does add up. But, if you don’t want to support GitHub but want to contribute to projects on there, emailing git-formatted patches is a thing. I mean, that’s how the Linux team still does it, right? I don’t have much experience using git this way, but I have done some work manually emailing diff/patch stuff and if git integrates well, it’s probably not too painful.
I think trying to convince projects to move to a different platform is a great idea in principle, but when a stranger walks in and immediately starts complaining about the hosting service, the devs usually have bigger fish to fry. I think it’s better to encourage new projects to use alternative platforms. A huge number of people seem to have only heard of GitHub and maybe GitLab; but as I mentioned, there are Gogs and Gitea for self-hosting, SourceHut, LaunchPad, and BitBucket; plus there are lots of free tools like Gerrit that help manage git and code tracking.
Curious to know what platforms people use by default, especially when it comes to personal vs. professional projects.
Weellllllll … partially. Part of it is open source and free to self-host. Whereas Sourcehut (where I migrated to from GitLab, after having left GitHub) is fully open source.
I don’t get the PR hate going around these days. How is it different than any other code review process?
Here’s the “super biased” opinion on PRs by Tuple’s CEO, Ben Orenstein:
https://web.archive.org/web/20211030160932/https://zipmessage.com/ben_orenstein/pairing-vs-code-review-prs
Is there a transcript or text version? I don’t really ‘do’ video content, but given the title, I suspect it’s not really addressing the point. Pairing isn’t a code review strategy, it’s something else entirely, it’s “code with 2 authors doesn’t require review” which is totally viable in an company, but less so in OSS.
I hope progress is being made on federation for gitea (and others).
Git has supported “federation” from its inception. Activity-pub’ing some git frontend webshit isn’t going to work any better than adding activitypub to anything else has.
The federation isn’t simply the source code repo, but stuff like issue trackers, documentation etc.
Put issues and documentation into the source-code repository. Check in all relevant files. (GitHub makes this difficult; Issues are designed to be hard to move to another service.)
One way to do this, given tooling support, may be an explicit folder for ‘broken tests’; then issue reports can take the form of “pull request/patch for a broken test.”
I don’t think gitea will focus on federation but a fork (forgejo) will.https://github.com/go-gitea/gitea/issues/18240
Thanks for the correction
I’m a little nervous about federation as a strategy here, for the same reason that I don’t think the fediverse should be the end-goal of social media: federation leads to feudalism
I think there might need to be some creative thinking on what to do instead. taking a corporate platform and trying to mirror the identical features as if they make sense when decentralized is a bit silly. the thing where you submit changes by forking the repo was never really for the benefit of the community, it was to give github a network effect.
people submitted patches through mailing lists for decades before github came along. it worked fine. people made local copies of repos to work in, not every contributor needed to have a published repo. I do understand why, in a world where email is for old people, that model probably needs to be rethought, but I offer it as an existence proof that there are meaningfully different strategies that work.
(I note that the author of this article would probably still be upset about the central approver on a mailing list thing as “gatekeeping”, but I think it’s worth discussing regardless)
Can you elaborate on that? AFAIK actual feudalism only persisted because people weren’t free to switch patrons / lords / what-have-you.
Relatedly: this is why I worry when political power is centralised in Federal Government rather than remaining with the States (here in Australia). Granted there are efficiency arguments, but one of the major attractions of a federation is the freedom to switch states if one goes off the rails.
I’d love to elaborate on that, and since I do kind of have a habit of saying it a lot I need to flesh out the metaphor a bit more. the following thoughts are in the nature of a first draft, not well-thought-out, so please take them for what they’re worth.
I see two negative aspects of federated social networks which I consider to be feudalism. the first is the power dynamic that instance operators have with respect to their members. the second, and the one that really suggests “feudalism” as a word to me, is that instances wind up in conflict with each other, staking out territory and attacking each others’ reputations and generally trying to create impermeable boundaries between parts of the fediverse, where you can’t see your friends if you’re on the wrong side of the instance-block wall.
I agree in principle that ease of switching would give members more power, if you could actually switch without consequences, but there are consequences, both technical (you lose all your post history) and social (you lose access to some subset of your former mutuals, and you can’t easily guess who, unless you somehow have the entire map of the political terrain in your head).
the other thing to keep in mind about switching is that in many cases, it doesn’t actually solve the problem. if your instance has been widely defederated due to political dynamics such as coordinated efforts to characterize marginalized groups you belong to as inherently abusive or whatever, that’s going to happen on any instance you and your friends choose to move to. switching is high-cost and at best a short-term solution to that sort of thing. so the incentive is generally to pick a place and stay there.
The discussion about PRs leaves out pre-checkin CI runs. That is incredibly useful to have. Catch the problem before it gets commited and avoid the “works on my machine” problem. Sure there are problems with CIs too, but for the most part they are very useful.
hmm, now that I’ve finally found time to read this, I think I like the author’s motivations and goals more than I like their thoughts on what to do about it. I appreciated people’s speculation here that this could be corporate propaganda but it doesn’t feel that way to me, although there’s ideology at play (as the author openly states).
I would have mentioned stuff like the “everyone pulls” model as worth doing more of, in this context. I think that’s indeed a more liberatory model than pull requests, although the short-term difference is not that big a deal.
it’s worth noticing that git, the underlying technology, was written for the exact ideological reasons this author appeals to. I don’t think we should move away from git, especially not to options which are more corporate in nature. I do think we should look at less corporate ways to use it, and what it would take to shift the culture that way.
I don’t agree with most points in that article (and the articles it references), but I think this paragraph sums up my overall feeling about the subject:
I hope
himalayafrom @soywod can add to that list of email clients to help with the patch workflows!Reminder that https://pagure.io/pagure exists and is a GPL source control platform. No hosts running this as a service so far as I know, but nothing stops anyone reading this from being that host.
To me this is where frameworks come into play. Adopting a framework is akin agreeing that problems like those that fit the framework should be implemented using the patterns and tools provided by the framework. We have a lot of tools for linting code at a textual level but I would like to see frameworks begin to ship linter-esque tools that would help focus review. i.e. this one file looks least like what we would expect for this framework so focus review on it.
An important message well conveyed.
Quoted for truth. GitHub’s work model is one thing, but having so much critical infrastructure dependent on a for-profit company is another thing. I know a lot of folks view Microsoft more positively than we did in the 90s, but I’m fearing a resurgence of “embrace/extend/extinguish” – so far it’s thin at best, but when I see things like GitHub providing their own
ghCLI tooling that they promote alongside/over thegitclient (which yes, I know they work diligently on), I can’t help but be reminded of the bad old days.