Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
The first open source crowdfunding platform for creative projects in the world
Ruby CSS JavaScript
branch: master

This branch is 4144 commits behind catarse:master

Merge pull request #520 from diogob/migrate_cancan_to_pundit

Migrate cancan to pundit [open review]
latest commit 582b108963
Antônio Roberto Silva devton authored
Failed to load latest commit information.
app fixed project show view
bin Adds binstubs for rspec
config Merge branch 'master' of github.com:catarse/catarse into migrate_canc…
db Remove unnecessary migration
doc Fix conflict on changelog
lib Migrate lib tasks Backer to Contribution
public changed login-box for box class in 500 page
script Removing cucumber and other unused stuff
spec fixed project policy spec
vendor added the default folder for assets
.gitignore Organized seeds and added rake config:show and config:put tasks
.gitmodules removing haml generators submodule
.rspec reset dev
.travis.yml removing jasmine tests from CI because of bug with ruby 2.1
Cheffile Fix display :99.0 not being configured on Vagrant
Cheffile.lock Fix display :99.0 not being configured on Vagrant
Gemfile Merge branch 'master' of github.com:catarse/catarse into migrate_canc…
Gemfile.lock Merge branch 'master' of github.com:catarse/catarse into migrate_canc…
MIT-LICENSE Adding MIT-LICENSE and renaming README to README.rdoc
Procfile Use unicorn_rails as web server in production
README.md making README clear about postgresql-contrib
Rakefile Renaming it to Catarse
Vagrantfile updates Vagrantfile to install ruby 2.1.0
config.ru Renaming it to Catarse

README.md

Catarse Build Status Coverage Status Dependency Status Code Climate

The first crowdfunding platform from Brazil

An open source crowdfunding platform for creative projects

Welcome to Catarse's source code repository. Our goal with opening the source code is to stimulate the creation of a community of developers around a high-quality crowdfunding platform.

You can see the software in action in http://catarse.me. The official repo is https://github.com/catarse/catarse

Getting started

Quick Installation

IMPORTANT: Make sure you have postgresql-contrib (Aditional Modules) installed on your system.

$ git clone https://github.com/catarse/catarse.git
$ cd catarse
$ cp config/database.sample.yml config/database.yml
$ vim config/database.yml 
# change username/password and save
$ bundle install
$ rake db:create db:migrate db:seed
$ rails server 

Translations

We hope to support a lot of languages in the future. So we are willing to accept pull requests with translations to other languages.

Thanks a lot to Daniel Walmsley, from http://purpose.com, for starting the internationalization and beginning the english translation.

Payment gateways

Currently, we support MoIP and PayPal through our payment engines. Payment engines are extensions to Catarse that implement a specific payment gateway logic. The two current working engines are:

  • MoIP
  • PayPal

If you have created a different payment engine to Catarse please contact us so we can link your engine here. If you want to create a payment engine please join our mailing list at http://groups.google.com/group/catarse-dev

How to contribute with code

Before contributing, take a look at our Roadmap (https://www.pivotaltracker.com/projects/427075) and discuss your plans in our mailing list (http://groups.google.com/group/catarse-dev).

Our pivotal is concerned with user visible features using user stories. But we do have some features not visible to users that are planned such as:

  • Turn Catarse into a Rails Engine with customizable views.
  • Make a installer script to guide users through initial Catarse configuration.

After that, just fork the project, change what you want, and send us a pull request.

Coding style

  • We prefer the {foo: 'bar'} over {:foo => 'bar'}
  • We prefer the ->(foo){ bar(foo) } over lambda{|foo| bar(foo) }

Best practices (or how to get your pull request accepted faster)

We use RSpec for the tests, and the best practices are:

  • Create one acceptance tests for each scenario of the feature you are trying to implement.
  • Create model and controller tests to keep 100% of code coverage at least in the new parts that you are writing.
  • Feel free to add specs to the code that is already in the repository without the proper coverage ;)
  • Regard the existing tests for a style guide, we try to use implicit spec subjects and lazy evaluation as often as we can.

Credits

Author: Daniel Weinmann

Contributors: You know who you are ;) The commit history can help, but the list was getting bigger and pointless to keep in the README.

License

Copyright (c) 2011 Softa

Licensed under the MIT license (see MIT-LICENSE file)

Something went wrong with that request. Please try again.