Michael, I would also love it if bugs got fixed in master more quickly. I've done some things to try to make that happen, but for all I know I've only exacerbated the issue. I'm still searching for ways to improve that.
One thing I know at the base of all such suggestions is: I am not going to expect others to change what they do in order to satisfy what I want, unless we've got a mutually agreed upon contract in place that says so. Acting otherwise is akin to storming the North Pole and demanding that Santa give an accounting of what he's done for me lately. (I am not saying you have acted like this -- it is an illustration of what I have to remind myself not to do.) Here is one suggestion that might help. Remove the "doc improvements" part that you mention from the patch submission process completely. Today you can fire up a Leiningen REPL, type (cdoc map), and get examples from the ClojureDocs.org web site. None of those examples went through JIRA, and anyone in the world can update them in 5 minutes. I'm not saying we should all rest on the laurels of the cdoc macro. If one wanted *slightly* more editorial control of what appeared in those doc strings, they could publish a not-very-large file of "new improved doc strings" and make a macro like doc and cdoc that shows them. Or one could even redefine doc in your own REPL to show the new doc strings instead of the ones built into Clojure. Publishing such a file on github would work, and the person publishing that file of new improved doc strings could take pull requests, or whatever they chose that works for them, to update them. It would take someone with the energy you have shown in reviewing and accepting upates to clojure-doc.org. I do not mean by that statement that I expect you to do such a thing -- only to describe the kind of time and thought required. Anyone could do it. Andy On Jan 21, 2013, at 10:46 AM, Michael Klishin wrote: > > 2013/1/20 Aaron Cohen <aa...@assonance.org> > Maybe not, but Clojure has managed to collect quite a few contributions over > its life, so all I know is that we at least are not at a complete minima. > > Whatever the goal of the current process is, it is not stated clearly to the > community. > Instead of guessing what the current process is focused on, lets focus on one > important thing it fails at. It fails at making > bug fixes reach master quickly. 3 to 10 months is not a time frame to be > proud of for a relatively small, fairly young project. > > What does this suggest? To me it suggests that maybe Clojure/core simply does > not have enough bandwidth to go through this N step > process. The community growing at double digits every year also is not > helping. If so, having more people involved will help. > The current process certainly does not make it easy to get involved, even if > your goal is to work on boring > things existing maintainers may have little interest in (bug fixing, doc > improvements, etc). > > Whatever benefits come from a tiny group of people having very tight grip > over even the most minor changes to the language, contrib libraries and docs, > rapid bug fixing is not one of them. > -- > MK -- 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
