Is contributing to clojurescript is intentionally made hard ?

1442 views
Skip to first unread message

Irakli Gozalishvili

unread,
Jan 18, 2013, 4:01:52 PM1/18/13
to clo...@googlegroups.com
I have being trying to engage community and to contribute to clojurescript for a while already,
but so far it's being mostly frustrating and difficult. I hope to start discussion here and maybe
get some constructive outcome.

## Rationale

I'm primarily interested in clojurescript and not at all in clojure, because of specific reasons (that
I'll skip since their irrelevant for this discussion) dependency on JVM is a problem. Removing
that's dependency is also my primary motivation to contribute. 

## Problems

- I do understand that most of the clojurescript audience is probably also interested in clojure,
  but please don't enforce that. Have a separate mailing list so that people interested in
  clojurescript and not clojure could follow relevant discussions without manually filtering out
  threads.

- What is the point of being on github if you don't accept pull requests and require I do understand
  that there maybe specific reasons why jira flow was chosen, but seriously that's another ball
  thrown at potential contributor to joggle. Not to mention that there are several options how
  jira and github could be integrated.

- My latest attempt was to configure travis.ci for integration tests
  https://github.com/clojure/clojurescript/pull/21
  
   Integration tests are great specially because they run on every pull request and post details back
   into pull requests. This also means that lot of local test run time can be saved. Not to mention that
   for clojurescript tests you need JVM, v8, spidermonkey and more

If these things are intentionally made hard to stop new people with more clojurescipt interests then please
make it more clear, cause otherwise it just a motivation killer. 

Thanks
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

Phil Hagelberg

unread,
Jan 18, 2013, 4:24:35 PM1/18/13
to clo...@googlegroups.com

Irakli Gozalishvili writes:

> - I do understand that most of the clojurescript audience is probably
> also interested in clojure, but please don't enforce that. Have a
> separate mailing list so that people interested in clojurescript and
> not clojure could follow relevant discussions without manually
> filtering out threads.

I don't know whether or not contributions are intentionally made hard,
but I would also appreciate separate mailing lists and IRC channels for
Clojure and ClojureScript.

-Phil

Jay Fields

unread,
Jan 18, 2013, 4:26:41 PM1/18/13
to clo...@googlegroups.com
I'm not sure I've ever sent an email where the entire content should
be "+1", but this is the one where it felt most compelling.

Please split the list.

Sent from my iPhone
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

Andy Fingerhut

unread,
Jan 18, 2013, 4:33:20 PM1/18/13
to clo...@googlegroups.com
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. You aren't likely to change his preference on this issue. That choice wasn't made in order to make it harder on contributors.

Instructions on creating patches for Clojure are under the heading "Developing and submitting patches to Clojure and Clojure Contrib" on this web page:

http://dev.clojure.org/display/design/JIRA+workflow

I suspect they are quite similar for ClojureScript, but I haven't submitted a ClojureScript patch before to know for sure.

Andy

Frank Siebenlist

unread,
Jan 18, 2013, 5:34:39 PM1/18/13
to clo...@googlegroups.com, Frank Siebenlist
One process that could be made a little easier is the contribution of code documentation and suggested improvements of doc-strings.

New or improved doc-strings do not change any functionality, impact any tests, require peer review…

If we could simply suggest new doc-strings for example in the JIRA-issue, have enough eyeballs stare at it, improvements, amendments…,
then after sign-off, a committer could simply copy&paste this approved enhancement in the official code.

Low-impact and it could make it easier to get community involvement and contributions for clojure & clojurescript's documentation, which arguably could use a little patch here and there.

Having to go thru the whole official patch process to suggest an improved docstring is a bit much… and god forbid that you have to thru that multiple time before all the , and . are approved.

-FrankS.

Sean Corfield

unread,
Jan 18, 2013, 6:52:42 PM1/18/13
to clo...@googlegroups.com
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...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

Hugo Duncan

unread,
Jan 18, 2013, 7:11:14 PM1/18/13
to clo...@googlegroups.com
Sean Corfield <seanco...@gmail.com> writes:

> 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.

I wonder if the availability of http://www.clahub.com/ changes anything...

Hugo

Sean Corfield

unread,
Jan 18, 2013, 7:18:47 PM1/18/13
to clo...@googlegroups.com
That will depend on whether it traces the origin of each line in the
patch - just relying on the pull request originator is not sufficient
(unfortunately).
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



Irakli Gozalishvili

unread,
Jan 18, 2013, 8:13:53 PM1/18/13
to clo...@googlegroups.com
At mozilla we also require signing CA but do accept pull requests and there are whole team of legal people that
makes sure things like that don't raise any legal concerns. After all it's just .patch to the pull request url gives you
an actual change patch so if reviewing patches is desired it's easy to build a tool that attaches it to JIRA. We in fact
do that for bugzilla. The good news is that such tools are already written for JIRA so it's just matter of enabling it!


Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

Irakli Gozalishvili

unread,
Jan 18, 2013, 8:16:13 PM1/18/13
to clo...@googlegroups.com
One could also copy attach patch with lines that belong to someone else. How is that different ?
Pull requests are just a tool for working with patches nothing else


Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

Sean Corfield

unread,
Jan 18, 2013, 9:03:28 PM1/18/13
to clo...@googlegroups.com
Because by submitting a JIRA patch explicitly, you are taking the
legal responsibility for the contents of the patch as being a change
that you are authorized to submit under the CA...

I'm not sure that you can even attach a patch to a Clojure ticket in
JIRA without being given permission to modify tickets (which means you
have a CA on file)?

As you say, at Mozilla, you have a whole team of legal people making
sure things are safe and acceptable. Clojure/core does not have that
luxury.

Brandon Bloom

unread,
Jan 19, 2013, 1:03:56 PM1/19/13
to clo...@googlegroups.com
For what it's worth, I've submitted 20+ patches to ClojureScript and one or two to Clojure proper. I still find the process to be extremely unpleasant. I consistently avoid interacting with JIRA until the last possible minute: That software is actively user-hostile. Without naming names, I've spoken with a half dozen other active contributors who feel the same way. If I wasn't between jobs at the time, I'd never have made it over the hump towards being a contributor.

Irakli Gozalishvili

unread,
Jan 19, 2013, 1:29:07 PM1/19/13
to clo...@googlegroups.com
On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote:
Because by submitting a JIRA patch explicitly, you are taking the
legal responsibility for the contents of the patch as being a change
that you are authorized to submit under the CA...

You can in fact do similar with contributing guidelines that are displayed once pull requests  is created:
And just reject pulls from people who did not signed CA
 
I'm not sure that you can even attach a patch to a Clojure ticket in
JIRA without being given permission to modify tickets (which means you
have a CA on file)?

Yes I did signed CA and it's always possible to not merge pull requests from people who have not signed CA yet.
 

As you say, at Mozilla, you have a whole team of legal people making
sure things are safe and acceptable. Clojure/core does not have that
luxury.
Maybe I was not clear here but legal people do not go through each pull request only signers
do merges people sending pull requests. I also have contributed to several other projects that
required signing CA before taking any of my pull requests, so I really don't see why it's a problem
for clojure.

Irakli Gozalishvili

unread,
Jan 19, 2013, 1:40:07 PM1/19/13
to clo...@googlegroups.com
As a matter of fact I have abandoned clojurescript once before and just wrote my own implementation of JVM free clojurescript
subset:


But kanaka's clojurescript in clojurescript https://github.com/kanaka/clojurescript/ got me  excited and I'm trying to get involved
again. Luckily he's being awesome to work with & has no problems accepting pull requests. But if the process of contributing
is more work than I can keep up with I'll have to turn away again :(

I also don't quite see the point of being on github if use of it's features is unacceptable.


Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

Irakli Gozalishvili

unread,
Jan 19, 2013, 1:48:42 PM1/19/13
to clo...@googlegroups.com
BTW also as hugo pointed out  with http://www.clahub.com/ one could just reject pull requests if any of the commit included
is from author who have not signed CLA yet. So looks like CLA problem can be also easily solved.


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote:

Andy Fingerhut

unread,
Jan 19, 2013, 2:47:56 PM1/19/13
to clo...@googlegroups.com

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

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

Andy Fingerhut

unread,
Jan 19, 2013, 2:56:28 PM1/19/13
to clo...@googlegroups.com
Irakli:

I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets.

Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process.

What about comments that are later added to the pull request?  Are they auto-added as comments to the JIRA ticket?

Are comments added to the JIRA ticket auto-added as comments to the pull request?

If the JIRA ticket is closed, does that automatically close the github pull request?

If the answer to all of the above is "yes, already works that way", then I'd be willing to spend a little more time looking into it.  Do you have links to any info on the tools that enable such behavior?

Thanks,
Andy

Michael Klishin

unread,
Jan 19, 2013, 3:01:53 PM1/19/13
to clo...@googlegroups.com
Irakli Gozalishvili:


If these things are intentionally made hard to stop new people with more clojurescipt interests then please
make it more clear, cause otherwise it just a motivation killer. 


Irakli,

Over the years, many people have tried raising the question of why contributing to Clojure (and ClojureScript, and anything Clojure/core touches)
involves so many obstacles and bureaucracy. Just search the archives.

Unfortunately, the answer many folks come up with is: Clojure/core don't see it as a major problem.
So, my advice to you: forget about it. Contributing to Clojure[Script] projects
that do not involve Clojure CA and the existing process is much more productive.

MK 

Alexey Petrushin

unread,
Jan 19, 2013, 3:02:22 PM1/19/13
to clo...@googlegroups.com
+1

Aaron Cohen

unread,
Jan 19, 2013, 5:38:23 PM1/19/13
to clo...@googlegroups.com
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.



Aaron Cohen

unread,
Jan 19, 2013, 5:44:56 PM1/19/13
to clo...@googlegroups.com
Also, another blog post dealing with the open source code contribution issue: http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/

Brandon Bloom

unread,
Jan 19, 2013, 5:57:21 PM1/19/13
to clo...@googlegroups.com
> contributions to clojure are definitely less easy to make than to projects
> that willy-nilly accept any pull request.

False dichotomy. Accepting pull requests does not mean you need to be willy-nilly about it.

You know how people carefully optimize their signup forms and checkout flows? They do this because there's a (very large) category of people who simply give up when things aren't immediately obvious. Granted, this category is much smaller among the class of folks skilled enough to create a desirable Clojure patch. However, the fact that this topic keeps coming up suggests that maybe that group is large enough to pay attention too.

As the Clojure implementations evolve, fewer and fewer people will discover issues large enough to justify diving into the code base to fix them. Most people just work around the issues. If somebody takes the initiative to properly fix an issue, we shouldn't add yet another hurdle discouraging them from contributing.

Brandon Bloom

unread,
Jan 19, 2013, 6:08:41 PM1/19/13
to clo...@googlegroups.com
Aaron, please forgive my failure at formalities: Allow me to add that I agree with the rest of your post.

The Linux kernel and Guava guys are absolutely right about patches defaulting to the rejected state. I'm a big believer in the "minus 100 points" philosophy.

It's just that I just really hate JIRA.

Softaddicts

unread,
Jan 19, 2013, 7:17:52 PM1/19/13
to clo...@googlegroups.com
Yep, tools to maintain tickets suck, Jira, Mantis,...

However, having Clojure code in production 24/7 and ClojureScript code
reaching production status in a month or so, I feel reassured that a maintenance process
is in place and that patch screening is tight.

We have enough doing the same thing here with our own code, I wonder how we would
fare if the layers we are building upon were not tightly managed as possible given
the limited resources. Building pyramids on sand is not my cup of tea.

Nobody yet has invented a maintenance process relying on thin air.
Wether you accept or not pull requests is like focusing on the tree and not seeing
the forest.

There's a documented maintenance/enhancement process, it may look rigid
but unless someone makes a formal proposal for a full maintenance workflow
with human costs and benefits, I would rather stick with this one.

Luc P.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

Irakli Gozalishvili

unread,
Jan 20, 2013, 12:05:27 AM1/20/13
to clo...@googlegroups.com
I think Brandon, in fact I discovered bunch of clojurescript bugs while working on my wisp project but since submitting and fixing them felt like too much work I just ignored them. Unfortunately I keep looking into my fixes now to back port them to cljs_in_cljs. 

I also absolutely agree if issues keeps coming up that certainly means there is a problem worth looking into


Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

--

Irakli Gozalishvili

unread,
Jan 20, 2013, 12:11:40 AM1/20/13
to clo...@googlegroups.com
As of comments related to projects that also make contributions hard that's their choice, and I really hope clojure community will do better than that. I also know that sometimes rewriting patch is a lot less work than making someones contribution acceptable, my day job involves all of that, but still we help people trying to contribute regardless sometimes that means they send in copies of files :) Never the less we work with them so people are still encouraged to contribute, over the time level of these contributions also grows. Turning them away is just strange to me. And yes at mozilla we do code that is production and used by billions of people over the world and being helpful to contributors never had being harmful in doing that.


Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

--

Irakli Gozalishvili

unread,
Jan 20, 2013, 12:17:14 AM1/20/13
to clo...@googlegroups.com
On Saturday, 2013-01-19 at 11:56 , Andy Fingerhut wrote:
Irakli:

I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets.

Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process.

What about comments that are later added to the pull request?  Are they auto-added as comments to the JIRA ticket?

Are comments added to the JIRA ticket auto-added as comments to the pull request?

If the JIRA ticket is closed, does that automatically close the github pull request?

If the answer to all of the above is "yes, already works that way", then I'd be willing to spend a little more time looking into it.  Do you have links to any info on the tools that enable such behavior?

I'm afraid I don't have answers to those questions it's just someone have pointed out this link

in the pull request I created when it was closed down. Bugzilla integration does all of these, but syncing comments. Maybe support for JIRA is better or worth, I have no way of trying that out as I don't have access to JIRA.
 

Thanks,
Andy

On Jan 18, 2013, at 5:13 PM, Irakli Gozalishvili wrote:

At mozilla we also require signing CA but do accept pull requests and there are whole team of legal people that
makes sure things like that don't raise any legal concerns. After all it's just .patch to the pull request url gives you
an actual change patch so if reviewing patches is desired it's easy to build a tool that attaches it to JIRA. We in fact
do that for bugzilla. The good news is that such tools are already written for JIRA so it's just matter of enabling it!

--

Irakli Gozalishvili

unread,
Jan 20, 2013, 12:31:58 AM1/20/13
to clo...@googlegroups.com
Than Sean for pointing to that thread that's helpful although that got me wondering if Rich is only one
doing the reviews ? If that's not the case maybe there at least on maintainer that is willing to bridge the
gap here ?

I really hope someone will step up to bridge the gap, maybe setup a fork and then forward contributions as a
patches to JIRA so people who love patches will look at them instead.

Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

David Nolen

unread,
Jan 20, 2013, 1:00:22 AM1/20/13
to clojure
I have nothing to add to this thread beyond pointing out that ClojureScript has had _51_ contributors in the short year and a half of its existence: http://github.com/clojure/clojurescript/graphs/contributors.

Via JIRA.

David

Irakli Gozalishvili

unread,
Jan 20, 2013, 1:31:50 AM1/20/13
to clo...@googlegroups.com, David Nolen
I would be curious to also see number of lost contributors.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

--

Irakli Gozalishvili

unread,
Jan 20, 2013, 1:36:11 AM1/20/13
to clo...@googlegroups.com
Anyway it's seems to me that message in this thread is pretty clear:

"We're just doing fine without people like you"

It's a shame, but whatever I'll just shut up and let you guys roll as you pleased

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

Dave Sann

unread,
Jan 20, 2013, 2:35:24 AM1/20/13
to clo...@googlegroups.com
It is great that questions are being asked about how things do, might or should work - but tone of the original question and the ensuing discussion, in my view, unfortunate.

Brandon Bloom

unread,
Jan 20, 2013, 5:58:32 AM1/20/13