Is contributing to clojurescript is intentionally made hard ?

[Irakli Gozalishvili]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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:

https://github.com/blog/1184-contributing-guidelines

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]

As a matter of fact I have abandoned clojurescript once before and just wrote my own implementation of JVM free clojurescript

subset:

https://github.com/Gozala/wisp

http://jeditoolkit.com/wisp/

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]

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]

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]

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]

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]

+1

[Aaron Cohen]

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]

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]

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

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]

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]

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]

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]

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

https://confluence.atlassian.com/display/JIRASTUDIO/Linking+GitHub+Activities+to+JIRA+Issues

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]

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]

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]

I would be curious to also see number of lost contributors.

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

--

[Irakli Gozalishvili]

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]

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]

There are 176 forks on GitHub. Even assuming that all 51 contributors have a public fork (most probably do), that's 125 potential contributors unaccounted for. Only 29% of those forks account for an accepted contribution. What portion of the remainder might have been contributors?

I was curious if 29% was "good" in comparison to other projects on GitHub. I also have never written a Ring/Compojure app, so I took 2ish hours and threw a little toy together and seeded it with some "interesting" repositories from GitHub's "explore" feature.

Code: https://github.com/brandonbloom/cvf

Running: http://boiling-inlet-6842.herokuapp.com/

Feel free to add some repositories to it, but please try not to break it. It's not exactly robust :-)

In short, 29% seems pretty reasonable for the number of forks ClojureScript has. Obviously that percentage goes down as the number of forks goes up, so some normalization would need to occur.

Of note, technomancy/leiningen scores 49% for 331 forks. That's pretty *awesome*. Good job guys!

[Marek Šrank]

On Saturday, January 19, 2013 8:56:28 PM UTC+1, 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?

Thanks,

Andy

There's another, easier possibility - When the pull request is created, create also the JIRA issue with the patch added, then add a github comment pointing to the JIRA issue and close the pull request. This is not perfect, but IMO better than the current state...

Another, even easier would be just to autopost a github comment, stating that pull requests aren't accepted and pointing to the Clojure contributing page...

Marek

[Michael Klishin]

2013/1/20 Aaron Cohen <aa...@assonance.org>

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.

…as well as tens of millions that do, and it works wondefully for them.

 

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.

Who says any pull request should be accepted? It is pretty widely accepted that contributing to Clojure and anything Clojure/core

touches is needlessly hard. That's what this thread is about, not "accepting any pull request".
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin