Re: Evolving the Clojure contribution process and goals
+1 Accepting CAs by mail would be very welcome. The impact of this until now is something quite difficult to measure, since potential contributors maybe never voiced their interest and just quit when they get to know the effort (or cost) required. But it probably makes a difference when a process takes days vs minutes. Something that is certain, is that it wouldn't hurt to allow it by mail, unless there is some reason I can't think of. This maybe won't change the situations for sizable contributions, but I would bet this would translate in an increase in bug fixes/reports. Max On Wednesday, September 19, 2012 5:59:48 PM UTC+2, Michael Klishin wrote: Paul deGrandis: 4.) What are the limitations behind changing the CA process? Can the CA process be made digital (a scan of a signed CA, SSH shared key, OAuth credential confirmation) or potentially reformed to allow more of the community to easily get involved, especially for smaller patches or doc changes? After looking at similar communities (Scala - http://docs.scala-lang.org/sips/sip-submission.html, Python - http://www.python.org/psf/contrib/), it seems like there are potential improvements we could make as the language, ecosystem, and community evolve. It would be great if someone from clojure/core could explain why CAs have to be submitted via snail mail. Oracle, OpenJDK, ASF, Neo Technologies and several other companies accept CAs as PDFs. From my personal experience with neo4j, it takes no more than a day to submit and have your CA confirmed. Sounds like if something is legally acceptable for Oracle, ASF, OpenJDK and significantly smaller yet not exactly young companies, it can work well for Clojure? The current process definitely does not take a day and is problematic for people who live outside of North America and Western Europe. People in Russia, South America, Asia don't necessarily have the luxury of cheap, reliable, fast snail mail delivery to North Carolina. FedEx and friends charge over $200 for a single sheet of paper mailed to Durham, NC from Moscow. $200+ for an opportunity to spend my time contributing to an OSS project in this age of GitHub sounds a little unreasonable. Last time I asked a clojure/core member about this I was told that's too bad. I don't have an opportunity to go to the Conj, don't have access to clojure-dev and consider myself a pretty active contributor to the ecosystem via clojurewerkz.org. I am sure there are many other people like me in the same situation. Please, clojure/core, explain why the CA process has to be so archaic. 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
Re: Evolving the Clojure contribution process and goals
On Wednesday, September 19, 2012 at 6:59 PM, Michael Klishin wrote: Paul deGrandis: 4.) What are the limitations behind changing the CA process? Can the CA process be made digital (a scan of a signed CA, SSH shared key, OAuth credential confirmation) or potentially reformed to allow more of the community to easily get involved, especially for smaller patches or doc changes? After looking at similar communities (Scala - http://docs.scala-lang.org/sips/sip-submission.html, Python - http://www.python.org/psf/contrib/), it seems like there are potential improvements we could make as the language, ecosystem, and community evolve. It would be great if someone from clojure/core could explain why CAs have to be submitted via snail mail. Oracle, OpenJDK, ASF, Neo Technologies and several other companies accept CAs as PDFs. From my personal experience with neo4j, it takes no more than a day to submit and have your CA confirmed. Sounds like if something is legally acceptable for Oracle, ASF, OpenJDK and significantly smaller yet not exactly young companies, it can work well for Clojure? The current process definitely does not take a day and is problematic for people who live outside of North America and Western Europe. People in Russia, South America, Asia don't necessarily have the luxury of cheap, reliable, fast snail mail delivery to North Carolina. FedEx and friends charge over $200 for a single sheet of paper mailed to Durham, NC from Moscow. $200+ for an opportunity to spend my time contributing to an OSS project in this age of GitHub sounds a little unreasonable. I'd just like to echo this sentiment. I would very much like to contribute to Clojure, but getting a CA from Ankara to NC just isn't practical. I'm lucky in that I'll be in the US for a couple of conferences later this fall, at which point I should be able to send one from a hotel somewhere, but I'm disappointed that an electronic copy is not considered sufficient (especially now that Preview.app on the Mac let's me import my signature using the web cam). I completely understand and agree with the desire for there to be at least a small barrier before one can become involved with Clojure development, but requiring physical mail seems like a biased barrier that is much larger for some than others. -- Joshua Ballanco ELC Technologies™ 1771 NW Pettygrove Street, Suite 140 Portland, OR, 97209 jballanco (mailto:jballa...@elctech.com)@elctech.com (mailto:kmil...@elctech.com) P +1 866.863.7365 F +1 877.658.6313 M +1 646.463.2673 T +90 533.085.5773 http://www.elctech.com (http://www.elctech.com/) -- 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
Re: Evolving the Clojure contribution process and goals
Stuart: Regarding making clojure.test/clojure.string/etc. contrib libraries, does it make sense to also move clojure.core to a contrib style library. The idea here would be that Clojure 1.6 is the bundling of all smaller Clojure lib/contrib subsets, whose version number is always in sync with core. Developers could always grab just the core still. This might also ease some pains for producing and releasing conditional compilations of core (for example, for portable devices). This offsets the breaking change moving forward (the bundle is a migration path) and might make for a better user/developer experience. The new tradeoff is Clojure is now a bundled release, increasing the size of the jar. Regarding triage, would it help if blocking defects were alerted on the weekly emails that Andy sends out? Would you prefer this to be a separate email? I also think some education (a better contributors guide maybe) could help fix some of the other issues you mentioned. To Rich / Stuart / Maintainers of clojure.org - what would have to be in place to make a git-managed, Markdown-based, community-driven documentation site (doc.clojure.org) happen? Ideally this site would also be hooked into a ClojureDocs system (either through an iframe or moving ClojureDocs over to the new project). Would it be possible to handle these documentation contributions outside of the CA, licensing everything some CC license? I also agree with Kovas, even small changes/updates could help the newcomers experience a lot. Thanks everyone for the great discussion so far! There are a lot of great ideas being teased out here. Paul -- 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
Re: Evolving the Clojure contribution process and goals
On Wed, Sep 19, 2012 at 1:12 AM, Andy Fingerhut andy.finger...@gmail.com wrote: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.degran...@gmail.com wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. The only things required for someone to create a new web site dedicated to better Clojure documentation is time, knowledge, and some money. There are several intermingled issues: 1. People want to feel involved. Its the opposite of founding a new project, on your own. That their modest effort will be seen by others, since its a part of this bigger thing. Contributing to clojure.org versus your own personal project are 2 different things. 2. Clojure.org isn't sharing traffic, or google juice.. its a walled garden. Leiningen doesn't come up in the first 5 pages of google search results, for example. If a newbie can't find Leiningen, how are they gonna find my project? 3. People want clojure to be taken seriously, and want a public face that is in the same league as other popular languages, by whatever standards that entails. 4. Clojure.org hasn't evolved much, meanwhile the technology and the community have evolved a ton. That is a vacuum liable to be filled with opinionating. There is a cognitive dissonance there, and people want to resolve it somehow. 5. People are confused about what the purpose of clojure.org is. AFAICT it is a reference guide to the efforts of clojure/core. In that context, not including a reference to Leiningen makes sense. But people are confused if that is a suboptimal oversight, or a conscious decision. 6. People are disturbed by the no-handholding style of 3rd party libraries, and see it as a systematic problem in the community. The figurehead is the obvious focal point of this anxiety. Appropriately so, since it plays a big role in the community culture. So there are many dimensions to play in, to empower/mollify. If you've read this far I highly recommend going back to the survey results and analysis. Some strong words, and strong quantitative measures. http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ I didn’t think it possible, but an even larger proportion of respondents than last year — now up to a third — indicate that documentation is a key problem. This ties into the feedback seen earlier that library documentation is generally not what it should be. To a large degree, this is a self-inflicted wound: both Clojure and its libraries are technologically sufficient and effective and useful, but many, many people are tripping on their way towards using them. Given that the only other problems within 10 percentage points of the documentation issue are largely out of everyone’s direct control [...] the best thing anyone can do to help Clojure succeed is to help make documentation and tutorials better for every skill level and domain, anywhere. I do what I can in my projects and elsewhere; please do what you can, too. -- 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
Re: Evolving the Clojure contribution process and goals
3.) Much like an Emergency Room, there should be a a fast-track to getting smaller patches approved and merged. This is actually not a problem consistent across all areas of the language - some contrib libraries and ClojureScript in particular seem to be getting this *just right*. Is there a way we can adjust the current workflow to fill need? It seems like even with more screeners, patches are sitting idle. One possible solution is if we extended contrib-like ownership into parts of Clojure proper, like clojure.test, clojure.string, etc. Better triage is high on my wish list, too. (Although I think the emergency room metaphor implies he opposite result for smaller patches.) Now that dependency management has improved to the point that Clojure has build-time dependencies down into contrib, another option is to take clojure.test et al out of Clojure into contribs. This would be a breaking change in that people would have to add such new contribs to their maven deps. Stu -- 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
Re: Evolving the Clojure contribution process and goals
Andy Fingerhut: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.de...@gmail.comjavascript: wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. We saw from the Clojure Survey, as well as threads here on the mailing list, that documentation is still something on which we as a community need to work. Could perhaps a different process govern documentation contributions, something more akin to http://docs.scala-lang.org/contribute.html that doesn't involve the CA? How could we best integrate such a project into Clojure.org? Would anyone be willing to help push such a project forward? my guess is that it would be easier to create a new site than to expect someone else to do an overhaul on clojure.org. You would own your own destiny. You would never need to wait on someone else to do something for you, unless it was someone at the company you chose to host your site, or one of your colleagues to do their part. It is quick and easy for clojure.org to add one or several links to such a site once it is up and going. This suggestion ignores the fact that most newcomers are much more likely to head to clojure.org instead of some third party site and expect clojure.org to be at least somewhat helpful. Currently I advice Clojure newcomers to not use clojure.org for anything, it is hopelessly outdated, reference-oriented and will only confuse them more. Unsurprisingly, this does not encourage newcomers as they think that many other things are hopelessly broken and outdated in this community. clojure.org needs change, adding a yet another link won't help. 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
Re: Evolving the Clojure contribution process and goals
Currently I advice Clojure newcomers to not use clojure.org for anything, it is hopelessly outdated, reference-oriented and will only confuse them more. Unsurprisingly, this does not encourage newcomers as they think that many other things are hopelessly broken and outdated in this community. 1. Agreed that the outdated parts of clojure.org should be fixed. I hope to spend some time on that this week. 2. We can and should have better community-driven documentation. Currently clojure.org links out to http://dev.clojure.org/display/doc/Home in a few places, and could link out more. Leadership in making dev.clojure.org excellent would be most welcome. Don't ask for permission, just do it. Cheers, Stu Stuart Halloway Clojure/core http://clojure.com -- 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
Re: Evolving the Clojure contribution process and goals
On Sep 19, 2012, at 12:11 AM, kovas boguta wrote: On Wed, Sep 19, 2012 at 1:12 AM, Andy Fingerhut andy.finger...@gmail.com wrote: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.degran...@gmail.com wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. The only things required for someone to create a new web site dedicated to better Clojure documentation is time, knowledge, and some money. There are several intermingled issues: 1. People want to feel involved. Its the opposite of founding a new project, on your own. That their modest effort will be seen by others, since its a part of this bigger thing. Contributing to clojure.org versus your own personal project are 2 different things. Kovas, have you used ClojureDocs.org? If not, I recommend trying it out. In under 5 minutes, you should be able to figure out how to add an example. One or two people started it, and dozens if not hundreds have added anywhere from 5 minutes to hours worth of extra effort adding examples. Several times in the last few months, there have been discussions on this list about what the documentation should say about a function. It takes me longer to think of what to add to ClojureDocs.org for the function than it does to go through the steps to add it. Your suggestions and mine are not mutually exclusive -- my suggestion is that one enable the other. A few people create an updated site that makes it as easy as ClojureDocs.org for everyone else who is willing to make a modest effort that will be seen by others. I'm not proposing that hundreds of people go out and create such a web site. Whether I did or not, I'm sure it wouldn't happen :-) 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
Re: Evolving the Clojure contribution process and goals
Andy - you're the perfect model of someone stepping up from the community and making the situation better for everyone. I'm sure I speak for a large population when I say, Thank You. For sure, I'd love to see an updated ClojureDocs-like system, hooked up to the build process and integrated into clojure.org. (Including all of contrib and CLJS) Pairing that with ClojureWerkz-style pages for all the contrib libraries would be an enormous leap forward (I'd love for the authors of ClojureWerkz to share the outline of the process that works for them). It would be in those dedicated pages that external links could guide the reader to further material. Kovas, I *very* much agree with all your points and think they are well said. Stuart, can you elaborate a little what better triage looks like? What are the current issues you're facing and what would make the process better for you? The ER metaphor perhaps isn't the best :) What are other ways the community can help get changes pushed along better and integrated? How might we better adjust the process to prevent patched and screened changes from sitting around for long stretches of time? My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Paul -- 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
Re: Evolving the Clojure contribution process and goals
2012/9/19 Paul deGrandis paul.degran...@gmail.com For sure, I'd love to see an updated ClojureDocs-like system, hooked up to the build process and integrated into clojure.org. (Including all of contrib and CLJS) This sounds like a good idea. Pairing that with ClojureWerkz-style pages for all the contrib libraries would be an enormous leap forward (I'd love for the authors of ClojureWerkz to share the outline of the process that works for them). It would be in those dedicated pages that external links could guide the reader to further material. For those who have no idea what ClojureWerkz is, see clojurewerkz.org. Some examples of doc guides for our projects: http://clojureriak.info http://clojureelasticsearch.info http://clojureneo4j.info They all are based on a template git repository that is cloned, modified and pushed into a new repo. All guides are written in Markdown, follow similar structure and use gist.github.com for code snippets. All contributions are the usual github process, everything is CC BY 3.0 licensed. The template repo: https://github.com/clojurewerkz/docslate My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Using CA for documentation sounds unnecessary. Using GitHub, pull requests and writing in Markdown is a much more open process friendly to developers. docs.scala-lang.org is developed that way: https://github.com/scala/scala.github.com. -- 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
Re: Evolving the Clojure contribution process and goals
Paul deGrandis: 4.) What are the limitations behind changing the CA process? Can the CA process be made digital (a scan of a signed CA, SSH shared key, OAuth credential confirmation) or potentially reformed to allow more of the community to easily get involved, especially for smaller patches or doc changes? After looking at similar communities (Scala - http://docs.scala-lang.org/sips/sip-submission.html, Python - http://www.python.org/psf/contrib/), it seems like there are potential improvements we could make as the language, ecosystem, and community evolve. It would be great if someone from clojure/core could explain why CAs have to be submitted via snail mail. Oracle, OpenJDK, ASF, Neo Technologies and several other companies accept CAs as PDFs. From my personal experience with neo4j, it takes no more than a day to submit and have your CA confirmed. Sounds like if something is legally acceptable for Oracle, ASF, OpenJDK and significantly smaller yet not exactly young companies, it can work well for Clojure? The current process definitely does not take a day and is problematic for people who live outside of North America and Western Europe. People in Russia, South America, Asia don't necessarily have the luxury of cheap, reliable, fast snail mail delivery to North Carolina. FedEx and friends charge over $200 for a single sheet of paper mailed to Durham, NC from Moscow. $200+ for an opportunity to spend my time contributing to an OSS project in this age of GitHub sounds a little unreasonable. Last time I asked a clojure/core member about this I was told that's too bad. I don't have an opportunity to go to the Conj, don't have access to clojure-dev and consider myself a pretty active contributor to the ecosystem via clojurewerkz.org. I am sure there are many other people like me in the same situation. Please, clojure/core, explain why the CA process has to be so archaic. 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
Re: Evolving the Clojure contribution process and goals
Stuart, can you elaborate a little what better triage looks like? What are the current issues you're facing and what would make the process better for you? The ER metaphor perhaps isn't the best :) What are other ways the community can help get changes pushed along better and integrated? How might we better adjust the process to prevent patched and screened changes from sitting around for long stretches of time? Here are a few ideas: 1. Please be clear in marking something a defect vs. an enhancement requests. Defects have top priority, and I would guess that I reclassify 30% of the tickets I review from defect to enhancement request. 2. If you have found a defect for which you know of no workaround, shout *loudly*. Put a message on the mailing list, making it clear that you are stuck. These items should get the very highest priority. 3. If your enhancement can be library code, make a contrib library of it. Then you are not tied to Clojure's deliberately more conservative release cycle. I will put some more thought into this, and plan to host an unsession at the conj for people who want to work on it. Stu -- 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
Re: Evolving the Clojure contribution process and goals
On Wed, Sep 19, 2012 at 11:01 AM, Andy Fingerhut andy.finger...@gmail.com wrote: Kovas, have you used ClojureDocs.org? If not, I recommend trying it out. In under 5 minutes, you should be able to figure out how to add an example. ClojureDocs is pretty nice. Incidentally, I'm not personally endorsing any of the observations I made, that's just what I hear in other's comments, reading between the lines. IMHO just a couple links to the essentials on the front page and/or getting started would be helpful to many. Thanks to the clojure survey, there is an objective basis for figuring out what toolchain 95% of clojure users are on. Thanks everyone for their contributions. -- 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
Re: Evolving the Clojure contribution process and goals
On Wednesday, September 19, 2012 11:43:45 AM UTC-4, Michael Klishin wrote: 2012/9/19 Paul deGrandis paul.de...@gmail.com javascript: My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Using CA for documentation sounds unnecessary. Using GitHub, pull requests and writing in Markdown is a much more open process friendly to developers. docs.scala-lang.org is developed that way: https://github.com/scala/scala.github.com. I think a github project with markdown-formatted files is a good way to go. It strikes a pretty nice balance between a wiki (which tend toward being a free-for-all) and a more rigid centralized setup. Pull-requests are good, and there could be a general policy where the main or original author of the document in question has the major say-so about whether changed are merged or declined. Maybe have it look something like this: https://github.com/uvtc/clojure-docs-collection (though it should probably live under an organization, rather than one doc-focused user :) ). Contributors could propose adding new docs via github issues. ---John -- 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
Evolving the Clojure contribution process and goals
Clojure Conj is nearly upon us. Last year there was a very positive meeting to discuss and help improve the contribution process. This year I thought it might be helpful to get some ideas on the table and refined by the community before the Conj. This has also been a common topic in #clojure. I'm doing my best to report my notes from those conversations as well. As always, please be sincere, civil, and constructive. 1.) Clojure.org should have a better host of documentation, especially for newcomers. We saw from the Clojure Survey, as well as threads here on the mailing list, that documentation is still something on which we as a community need to work. Could perhaps a different process govern documentation contributions, something more akin to http://docs.scala-lang.org/contribute.html that doesn't involve the CA? How could we best integrate such a project into Clojure.org? Would anyone be willing to help push such a project forward? 2.) Clojure/dev should announce upcoming changes on the Clojure mailing list and potentially via a blog connected to Planet Clojure This used to happen more frequently, and was a nice way to keep the community included in the evolution of the language. It could even be a weekly column in something as informal as the Clojure Gazette or something monthly if that's more appropriate. Ideally updates would include core as well as contrib. Perhaps someone in the community wants to step up to fill this gap? (I would be more than happy to send out changelogs and summaries to the mailing list) 3.) Much like an Emergency Room, there should be a a fast-track to getting smaller patches approved and merged. This is actually not a problem consistent across all areas of the language - some contrib libraries and ClojureScript in particular seem to be getting this *just right*. Is there a way we can adjust the current workflow to fill need? It seems like even with more screeners, patches are sitting idle. One possible solution is if we extended contrib-like ownership into parts of Clojure proper, like clojure.test, clojure.string, etc. 4.) What are the limitations behind changing the CA process? Can the CA process be made digital (a scan of a signed CA, SSH shared key, OAuth credential confirmation) or potentially reformed to allow more of the community to easily get involved, especially for smaller patches or doc changes? After looking at similar communities (Scala - http://docs.scala-lang.org/sips/sip-submission.html, Python - http://www.python.org/psf/contrib/), it seems like there are potential improvements we could make as the language, ecosystem, and community evolve. An additional project idea: A nice start to unifying the documentation could be gathering all the CC 3 licensed Clojure-related works, organizing them, and linking them together. Anyone want to take it and run with it? Thoughts? Paul -- 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
Re: Evolving the Clojure contribution process and goals
On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.degran...@gmail.comwrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. We saw from the Clojure Survey, as well as threads here on the mailing list, that documentation is still something on which we as a community need to work. Could perhaps a different process govern documentation contributions, something more akin to http://docs.scala-lang.org/contribute.html that doesn't involve the CA? How could we best integrate such a project into Clojure.org? Would anyone be willing to help push such a project forward? I am not personally willing to push such a project forward at this time. I have some suggestions if someone else is. The only things required for someone to create a new web site dedicated to better Clojure documentation is time, knowledge, and some money. If you, perhaps together with a group of like-minded colleagues, have those resources, my guess is that it would be easier to create a new site than to expect someone else to do an overhaul on clojure.org. You would own your own destiny. You would never need to wait on someone else to do something for you, unless it was someone at the company you chose to host your site, or one of your colleagues to do their part. It is quick and easy for clojure.org to add one or several links to such a site once it is up and going. The Clojure cheatsheet ( http://clojure.org/cheatsheet) currently links to ClojureDocs.org, but it would be easy to switch those links to point to another site if something else superseded it (I've edited the cheatsheet significantly 6 months ago, and the links are now auto-generated, and thus easy to retarget :-) Create a site that does everything ClojureDocs.org does and even more, with the ability to add examples specific to Clojure 1.4, and in the future Clojure 1.5+, but otherwise lets examples for older versions of Clojure be displayed until and unless they are tagged by someone as obsolete. It would be cool if it allowed submissions not only for the contrib modules, but was able to quickly import any Clojure library, i.e. write some code that automates most of the steps of adding a new Clojure library to the web site. Even better if people wrote tutorials on how to use a library as a whole and put it on the site, and not only for individual functions. For whoever thinks they might want to do such a thing, expect many thanks, many bug reports and suggestions for improvements, and sometimes complaints that you aren't doing what others think you ought to be doing. If that and what you will learn are enough to motivate you, go for it. Bonus points if you have a team of people working on it that can keep it going even as people move on to other projects in their lives. 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
