Better infrastructure for contributed libs

...

• Stand up a Jira instance.
  • Will we need separate Jira/Confluence user ids? I hope not
    • Might need to use LDAP
      • http://www.opends.org/
      • doesn't do much for Jira
    • Or beg for Open source free license for Crowd
      • http://www.atlassian.com/software/crowd/
    • or suck it up, people have Jira/Confluence/FishEye logins - ugh
    • or:
      • http://confluence.atlassian.com/display/DOC/Delegate+user+management+to+use+JIRA+logins
  • Investigate sub-project support.
• FAQ for CA (Rich?)
  • I've attached a copy of Sun's CA FAQ to this page
• FAQ for patches vs pulls (Rich?)
• Guidelines for lib owners (review and update Guidelines for Clojure Contrib committers, possibly add separate page for owners)
  • build/test guidelines: you must use maven or leiningen. When in doubt, meet at the pom.
  • Intra-contrib dep policy: allowed, use maven/leiningen
  • External dep policy: allowed, use maven/leiningen.
    • not so fast, we'll at least want to restrict to certain licenses
  • Note that internal deps (and especially external deps), while permitted, greatly reduce the ability of the lib to ever be promoted into Clojure.

Naming convention for contrib repos

• github.com/clojure/prefix.name  = clojure.prefix.name package
• prefix can be data/tools/math/core/java/io

Decisions Needed

•  
• Test lib candidates
  • nrepl (http://github.com/cemerick/nREPL)
  • Unifycle (http://fogus.me/fun/unifycle/)
  • match (http://github.com/dcolthorp/matchure)
• After test candidates, Plan for moving existing contrib libs (talk to Sierra)
• What's missing from this plan?
• Are there stories we can tell in time to promote the conj?

...