On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote:
>
> I don't think the tweets you link are the 'normal approach'. I would call 
> them pretty unusual in several aspects.  For one, I think that for the vast 
> majority of Clojure tickets created, no on asks and gets Rich's comments on 
> them before they are created.  Second, most end up being committed as the 
> submitter created them, with fewer rounds of review and updates.  Most of 
> them are a lot less work on the part of the contributor than the two 
> examples mentioned.
>
> Note: I am not saying that those two examples didn't happen, or that there 
> are no others like that.  I am saying they are unusual examples, as 
> compared to the great majority of Clojure tickets.  Most tickets that have 
> a change committed for them end up being committed as a patch submitted by 
> a contributor, without being implemented differently.
>
> It is fairly common for there to be months or years of waiting time for a 
> ticket to be considered.  Rich is one person, and like most people, he gets 
> to choose how much time he spends on volunteer projects, and what projects 
> those are.  Alex Miller spends a significant fraction of his time tending 
> to tickets and commenting on and reviewing patches.
>

This point (i.e. lead time) is by far my biggest gripe about the Clojure 
contribution process. It causes a number of problems:
A) Contributors get de-motivated waiting for feedback / communication
B) Patches often become stale. This wastes more time
C) People forget what they were thinking about months or years ago
D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is 
a good example)
E) It creates the perception (even if it is not the reality?) that Clojure 
is unfriendly to contributors

My practical suggestion is simple: Clojure needs more "trusted maintainers" 
who know particular parts of Clojure well and can work more closely with 
contributors to get patches in a good state for Rich to review, and 
potentially even merge the simpler types of changes (bug fixes, 
documentation updates, basic refactoring, indentation etc.). Rich's time 
can then be spent on the high value stuff (reviewing good quality patches 
only when they are ready in the view of the "trusted maintainer", 
considering changes which impact language design etc.).

FWIW It's worth comparing the rate of development on Clojure vs. Linux:

Clojure: https://github.com/clojure/clojure/graphs/commit-activity (<10 
commits per week)
Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 
commits per week)

Obviously Linux is a bigger project, but there is still only one BDFL in 
both cases (and I am sure both BDFLs are very busy!)

So how does Linus do it? The answer is organisation. Linux has many trusted 
subsystem maintainers who do most of the work reviewing and merging 
patches. Linus may have the final say on everything but the Linux community 
has done a lot of thinking and self-organisation to make sure that Linus is 
not usually the bottleneck. 

Also worth noting that Linus does indeed use pull requests (just not GitHub 
ones, see the extended discussion here if interested: 
https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not 
saying Rich has to do so himself, but the "trusted maintainers" would be 
able to do so if it helped with the workflow for work-in-progress patches.

 

>
> As for indentation of Java code, it is called Whitesmiths style: 
> https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style
>
> Clojure was the first project I came across using this indentation style, 
> but Rich isn't the only one to use it.  A few bits of code have crept in 
> over the years using other indentation styles, usually contributed by 
> others.
>
> Andy
>
> On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh <ni...@niwi.nz 
> <javascript:>> wrote:
>
>> Hi!
>>
>> I have some, maybe controversial, questions...
>>
>> A little bit of context: 
>> https://twitter.com/aphyr/status/621806683908542464 
>>
>> Why this is like a normal approach for managing third party contributions 
>> to clojure core? This kind of things the only discourages the 
>> contributions. Maybe I don't have more context about this concrete case, 
>> but seems is not a unique.
>> And in general, I have the perception that the clojure development 
>> process is a little bit opaque... 
>>
>> An other question: Why the great amount of clojure compiler code has no 
>> indentation style and bunch of commented code. 
>>
>> It is indented like a freshman. Sorry, I don't want offend any one, but 
>> eyes hurt when reading the code compiler clojure (obviously I'm speaking 
>> about the look and feel, and no the quality of the code).
>>
>> Some examples:
>>
>> Indentation (or maybe no indentation):
>>
>> https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86
>>
>> Bunch of commented code and also no indentation:
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60
>>
>> If you compare some clojure compiler code with different code snippets 
>> from other languages, the indentation is clearly more cared:
>>
>> Kotlin: 
>> https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44
>> Rust: 
>> https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165
>> Ceylon: 
>> https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233
>>
>> This is a random list of code snippets from different compilers with 
>> indentation that is more human friendly.
>>
>> I don't intend judge any one, but when a I learn Clojure compiler I 
>> expect something different. I expect something more carefully done.
>>
>> No body thinks the same thing that me? 
>>
>> I think that have a sane, more open contribution policy, with clear and 
>> more cared code formatting, is not very complicated thing and is going to 
>> favor the clojure and its community.
>>
>> Andrey
>> -- 
>> Andrey Antukh - Андрей Антух - <ni...@niwi.nz <javascript:>>
>> http://www.niwi.nz
>> https://github.com/niwinz
>>  
>> -- 
>> 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 
>> <javascript:>
>> 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 <javascript:>
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to