Pull requests are not conversations
Saturday, 05 February 11
I don't remember anything that changed my work flow in a so big way as git did in the latest two years.
I will not argue too much about that, as you probably experimented the effects yourself if you are reading this blog post, or perhaps you are among the guys I should say thanks for the fact I started using git.
But if git is cool, Github makes it cooler for sure. Github is like a market for git, where code gets exchanged, shared, publicly hacked. In short I love git and github. Still I think that github pull requests are posing a problem in the open source development world, and this post is all about this.
It was possible to start the discussion providing also a patch, but not required. When I say also I mean, along with all the rationale for adding the features, what the problems and complexities are, what the gains, and so forth.
Like a painting uses colors but is not, after all, about colors, so a software project uses code, but is after all, about design. Code can be used to prove your point, to show a way to obtain the effect you are seeking, but the most important point is the design of a new feature. The ability to resist to the temptation of adding things that are not useful but just appear to be useful, because perhaps there is a defect in some other part of the design, or because there is a not so obvious but simple way to get the same effect. And where to discuss this kind of things if not in the project mailing list?
As github is a market for code, the project mailing list is a market for the project design (more and more together with Twitter, in my experience).
So that is how contributions used to work, and how most of the Linux kernel itself was built. But I've the feeling that github pull requests are bringing a new way of thinking to the table, that is preventing a lot of interesting discussions from happening, and at the same time is wasting a lot of coding resources.
In this conversation pull requests are the stage when a developer asks another one: "Hey, let's merge that". In github pull requests this happens in a very private way. This should be the very, very final stage of a contribution, but guess what, now most of the time is the first stage of a contribution, that directly starts with a pull request, about a feature not publicly discussed, possibly not needed, or that is actually related to something else that is already a work in progress, and so forth. In the end this means that most of pull requests are not going to get merged. At least this is what happens with Redis.
Pull requests used in this way are removing value from a conversation, that should otherwise be very different and public. Like:
Please if you have comments use hacker news instead of the blog comments.
But if git is cool, Github makes it cooler for sure. Github is like a market for git, where code gets exchanged, shared, publicly hacked. In short I love git and github. Still I think that github pull requests are posing a problem in the open source development world, and this post is all about this.
How it used to work
Before git and pull requests the obvious way to contribute to a large enough open source project was to write a message in the mailing list of the project, asking about what the feelings are about adding a given feature.It was possible to start the discussion providing also a patch, but not required. When I say also I mean, along with all the rationale for adding the features, what the problems and complexities are, what the gains, and so forth.
Like a painting uses colors but is not, after all, about colors, so a software project uses code, but is after all, about design. Code can be used to prove your point, to show a way to obtain the effect you are seeking, but the most important point is the design of a new feature. The ability to resist to the temptation of adding things that are not useful but just appear to be useful, because perhaps there is a defect in some other part of the design, or because there is a not so obvious but simple way to get the same effect. And where to discuss this kind of things if not in the project mailing list?
As github is a market for code, the project mailing list is a market for the project design (more and more together with Twitter, in my experience).
So that is how contributions used to work, and how most of the Linux kernel itself was built. But I've the feeling that github pull requests are bringing a new way of thinking to the table, that is preventing a lot of interesting discussions from happening, and at the same time is wasting a lot of coding resources.
Pull requests
My point so far has been that contributing to code should be a conversation about design, with some code in order to support that conversation or to finally implement what seems a good design in a tangible form.In this conversation pull requests are the stage when a developer asks another one: "Hey, let's merge that". In github pull requests this happens in a very private way. This should be the very, very final stage of a contribution, but guess what, now most of the time is the first stage of a contribution, that directly starts with a pull request, about a feature not publicly discussed, possibly not needed, or that is actually related to something else that is already a work in progress, and so forth. In the end this means that most of pull requests are not going to get merged. At least this is what happens with Redis.
Pull requests used in this way are removing value from a conversation, that should otherwise be very different and public. Like:
- To mailing list: Hey guys, I've this idea what do you think?
- (Optionally) I've implemented a proof of concept, it's not finished but I think it shows my point: this is my topic branch.
- Bla bla bla, arguing about usefulness, alternatives, what can be improved and so forth.
- Finally, if the feature is accepted: code code code.
- And a new message arrives in the mailing list: ok, that's my code, let's merge if it seems sane enough.
Please if you have comments use hacker news instead of the blog comments.
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Comments
05 Feb 11, 12:53:16
Would it be better if you could specify a Mailing List address where pull requests should be sent?
05 Feb 11, 15:22:10
Dude ... WTF. Honestly, get help.
Also, take a look at organizational learning theory, communities of practice and legitimate peripheral participation. This has been shown to also apply to OSS communities. People sending pull requests out of the blue as in the above post are still in the periphery of the community. Reading discussions and, at some point, taking part in them, are important steps in learning a community's conventions and rituals.
Also, take a look at organizational learning theory, communities of practice and legitimate peripheral participation. This has been shown to also apply to OSS communities. People sending pull requests out of the blue as in the above post are still in the periphery of the community. Reading discussions and, at some point, taking part in them, are important steps in learning a community's conventions and rituals.
05 Feb 11, 21:26:57
> "eading discussions and, at some point, taking part in them, are important steps in learning a community's conventions and rituals."
Not to mention, extremely educational. Good design is hard to learn. Many coders never really get there. But if you want to learn, one of the best ways is to listen to people discuss real examples and their trade offs.
Not to mention, extremely educational. Good design is hard to learn. Many coders never really get there. But if you want to learn, one of the best ways is to listen to people discuss real examples and their trade offs.
05 Feb 11, 23:34:39
@1: Maybe you've been banned from HN because you sound like a crank, and tend to post long, tenuously related diatribes on the discussion threads of articles of narrow technical interest?
Here it is:
******************
Not sure if I am "permitted" by the unseen "moderators" -- based on recent experience -- to post on this forum, but I'll take the chance and write my message anyway because I do have something to contribute ...
Github is a transitional model, providing a bridge between the old way and what is to come:
Software is a 'high' cultural artifact that soon will be an indispensable component of maintaining civilization. It is subject to industrial demand in the marketplace and to date can generally be categorized as a product of an arts and crafts.
Historically, the typical reaction of the societal hyper-organism to such conditions has been guild formation. To illuminate this, consider that the guilds of priests, magicians, and soothsayers are present, to this day, in every society that relies, to some critical extent, upon irrational views to conduct basic societal activities. A more infamous guild is that of the 'Masons', the guild of designers and craftsmen who knew how to construct the machinery of State Warfare, an 'indispensable' component of the civilizational order of their day. Being apparently quite a clever bunch -- they were the hackers of the middle ages -- they also extended their services to provide capital and operational support for the said military activities.
Naturally, they became a force to be reckoned with and the inevitable conflict between the new upstart guild and the established guilds of 'priests' and 'statesmen' came to head or rather quite a few beheadings and other sordid measures meted out by the establishment to persuade upstart guilds to reconsider.
The software guild, should it ever happen, is direct threat to the established 'financial', 'news', 'communication', and 'security' interests, up to the international level. [I refer the critical HN reader to consider the recent IPSec and openBSD allegations.]
The great bubble of 90's was, in my opinion, a direct intervention of the 'finance' guild, namely through the directing agency of Goldman Sachs and other actors at the Treasury and Federal Reserve, to get a (controlling) handle on the development of the nascent guild's formation. This was deemed important in order to control the development of the new ("disruptive") technology. Certainly, if they had not done that they would have been negligent of their interests. Easy money was on tap, flowing furiously until the order to shut it down came from unseen quarters.
Tellingly, critical pieces of infrastructure, e-money and e-identity and e-comm, all remain firmly in control of the established interests who had only mastered the analog and physical realizations of these components. It is truly a disgrace to the hacker community that our children will be wearing VeriSigns on their person. Consider that.
Parallel with these efforts of infiltration, the establishment has predictably resorted to vilifying the 'hacker' that either refuses to join the offered seats, or remains unmoved by the lure of the purks and the '15 minutes' provided by the supporting guilds of 'news' and 'entertainment'.
http://www.tgdaily.com/sites/default/files/stock/a...
*This effort continues to date*, with the recent offer of 150,000.00 dollars to the 'crafty' would be guild members and potential 'knights' cum Financial Establishment 'servants'. A word of advice to the young upstart: Esau sold his birthright to Jacob for porridge. A bad decision.
Back to git and github.
These 'out of band' contributions are attempts to participate in the project by would be apprentice to generous master contributing 'works' to a 'project'. The project manager on the receiving end -- in this case the well known master 'antirez' -- has no doubt has his hands and head full of matters requiring his personal attention.
Who is this person *intruding* with a 'pull request'?
A reputation market is, to an extent, already in place in github. The deluded butterfly's portfolio is full of forked gravitas with little activity. The masters' boast of an impressive array of original contributions with established following. The great gray middle is not so clear, as is the unknown worker who gets a github account just so s/he could send you that pull request. All this is due to the lack of an explicit 'guild cultural mindset' in the minds of machine-based knowledge workers who lack an established organization order and well debugged paths of traversing the guild hierarchy to provide input at the appropriate level of (organizational) interface.
Clearly the problem is at both ends of this process.
Unknown or quiet actors on the send side is one issue. Either each project must establish their own methodology of assessing the individual's skill set and product offering -- a time consuming task, per OP's well considered critical review. The alternative is to establish the necessary services that can undertake this evaluation for the OSS community.
But antirez, and not just him, also have structural issues to deal with on their end. Looking at the previous guilds of 'high art' and 'mason', people like him may come to see the wisdom of 'the atelier system' -- the historic *working solution* to this problem -- that allowed the 'master' to delegate effectively to a team structure that was well understood and internalized by all the participating actors in *the works*.