Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

We need to make it easier for people to contribute to the Clojure project

Clojure's approach to contributed libraries has some limitations that are based upon legacy aspects of the free hosting services the project has utilized thus far.

Two new things open the door to a better system:

  • Github now has the organization notion, and Clojure is now a github organization
  • We now have self-hosting hardware for things like Confluence and Jira

The problem and how to solve it

  • People are resistant to participate in clojure.contrib
    1. Lack of modularity
    2. Shared repo
    3. CA
    4. Non-github workflows (no pulls)
    5. No ego stroke like
  • We can address 1 & 2 by
    • Allowing contrib libs as individual repos under the Clojure github organization
    • These will still be Clojure project destinations according to the CA
    • Project owners and helpers will get commit rights
    • Much more independence on releases etc.
    • For many, it will simply mean using a Clojure repo instead of a personal one
      • As well as adopting Clojure's stewardship policy
      • And build/test guidelines?
      • Having things start and grow there will greatly facilitate moving things into Clojure core libs or including in Clojure releases
    • Curation will remain an issue
      • We want to accept people's early half-baked ideas
        • But may never become fully baked
      • Consumers will need some help sorting out the good stuff
        • Not really different from separate libs on github in this area
        • Use same metrics for evaluation
          • Community adoption
          • Personal recommendations
          • Frequency of updates/fixes/releases etc
    • In addition, we can host a Jira instance for issue/feature/bug tracking and patch reception
      • should be able to make sub-projects for each lib?
        • This versus Assembla where bug tracking is tied to larger project
  • Fixing 3 is a non-starter
    • It is not broken
    • Helping people understand that is an education issue
      • We need our own treatise/FAQ as the Sun one is now gone
  • Number 4 is off the table for the moment
    • Pulls are not that great
      • Difficult for people to evaluate as part of screening/approval process
      • Can't see what you're getting before you get it
      • Leaves a dependency trail on external repos
    • Presumed incompatible with the CA
    • So, patches remain
  • Number 5
    • I wonder how many people will admit to this aspect of Github

Moving forward

While we will eventually want to break up contrib, I think we should experiment with some new libs first. I think cemerick's nrepl or the not-yet-contrib match library might be good candidates. I've spoken to cemerick and he's on board.


  • Stand up a Jira instance.
    • Will we need separate Jira/Confluence user ids? I hope not
    • Jira matters because without it we don't have a place for issues/patches
  • Decide on naming convention for contrib repos
    • seems too top level, but universal prefix (e.g. is awkward
      • not sure there is an alternative
  • Build/test guidelines for contrib projects
    • each repo could differ, but would make a pain for Hudson et al
  • Plan for moving existing contrib libs
  • FAQ for CA
  • FAQ for patches vs pulls
  • Intra-contrib dep policy
  • External dep policy
  • What's missing from this plan?