Being the maintainer of an open source problem is a hard task. Contributing to a project is not a process that begins and ends with code submissions. In fact, it's often more work for a maintainer to accept a patch or pull request than it is for him or her to write the equivalent code himself.
Clojure is hardly the only project that doesn't accept pull requests. The Linux Kernel and Guava are two that immediately come to mind. For Guava's rationale, you might read the following: https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM Their reasons are not identical to Rich's, but the sentiment is similar. Does this mean you shouldn't even try to contribute? No, of course not. But, contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request. On Sat, Jan 19, 2013 at 3:02 PM, Alexey Petrushin < alexey.petrus...@gmail.com> wrote: > +1 > > > On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote: > >> >> On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: >> >> > On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut >> > <andy.fi...@gmail.com> wrote: >> >> The issue that Clojure, its contrib libraries, and ClojureScript do >> not accept github pull requests has been brought up several times before on >> this email list in the past. Feel free to search the Google group for >> terms like "pull request". Short answer: Rich Hickey prefers a workflow of >> evaluating patches, not pull requests. It is easier for him. >> > >> > My understanding is that with pull requests it becomes much harder to >> > provide accountability for Intellectual Property which is a legal >> > concern, and that's why we have a Contributor's Agreement. The patch >> > process naturally falls out of the legal CA-covered process since each >> > patch is clearly identified as "belonging" to a specific contributor - >> > and submitting a patch comes with the responsibility of vouching for >> > the legal status of that submission. Github's pull request process >> > makes it all too easy to incorporate code that belongs to a Github >> > account holder who is not covered by the legal agreement and places >> > the burden of verification on screeners to verify the IP ownership. >> > >> > But let's not re-hash the issue of the CA. Folks can just read the >> > archives and there's really nothing new to add... >> >> I won't rehash the issue, but will provide direct pointers to a couple of >> posts that led me to believe my statements above. >> >> Here is a link to the whole thread, with many posts on the >> then-just-being-started clojure-doc.org web site (which I'm pleased to >> see has certainly come a long way since early Oct 2012): >> >> https://groups.google.com/**forum/?fromgroups=#!topic/** >> clojure/jWMaop_eVaQ<https://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ> >> >> Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's >> response later the same day. I don't have any inside info about Rich's >> preferences for patches outside of such public messages, but it definitely >> seems to be due to workflow preference issues, not legal issues. >> >> Andy >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
