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
- Lack of modularity
- Shared repo
- Non-github workflows (no pulls)
- No ego stroke like http://github.com/me-me-me/my-lib
- 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
- But still must combat contrib === stdlib presumption
- 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
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.
Ready To Do
, possibly add separate page for owners)
Decide on naming convention for contrib repos
- Stand up a Jira instance.
- Will we need separate Jira/Confluence user ids? I hope not
- Might need to use LDAP
- Or beg for Open source free license for Crowd
- or suck it up, people have Jira/Confluence/FishEye logins - ugh
- 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
- Test lib candidates
- 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?
- What is the Jira/git story?