Public broadcasting in Germany receives €8,000,000,000 (eight billion euros) annually, yet it is subject to little or no public feedback, ranking, or even debate on what constitutes value or quality.
We want to change that: With this app you can make your voice heard and propose on which shows your €17.50 per month should be spent.
Visit rundfunk-mitbestimmen.de
This repository contains three important folders:
The backend is responsible to store the data. Who wants to pay for which
broadcast and how much? Users are related to broadcasts via selections in the
database. The response on the selection model can be either negative,
neutral and positive and indicates whether a user wants to give money to a
broadcast. If the response is positive, the amount further specifies how
much to pay for a broadcast. So, the sum of all amounts per user must not exceed
the monthly fee of 17,50€ per month.
The frontend should be as easy to use as possible. The user can login and register, fetch a set of not yet voted broadcasts, decide about broadcasts, assign money and see the public statistics. Most of these actions will send requests to the backend. The frontend should be comfortable to use, e.g. by default amounts are evenly distributed with the option to set the amount explicitly.
We do full stack testing with Cucumber and Capybara. We specify the requirements as user stories in our Github issues and implement them as cucumber features. The cucumber features are a good starting for you to understand the current behaviour and the reasoning behind it.
Clone the repository:
git clone https://github.com/roschaefer/rundfunk-mitbestimmen.gitIf you have docker-compose installed, you can install frontend,
backend and db with a single command:
dev/resetAfter the installation, you can start the entire stack with:
dev/startApp is running on localhost:4200
If you want, you can create some seed data
docker-compose run backend bin/rails db:seed
Make sure that you have a recent version of npm and ruby and EmberJS installed before you proceed. E.g. we have the following versions:
npm --version
# 5.0.1
ruby --version
#ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
ember --version
# WARNING: Node v8.0.0 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js.
# ember-cli: 3.13.2
# node: 8.0.0
# os: linux x64Clone the repository:
git clone https://github.com/roschaefer/rundfunk-mitbestimmen.gitInstall dependencies and run migrations:
bundle
cd frontend
npm install
bower install
cd ../backend
bundle
bin/rails db:create db:migrate
cd ..If you want, you can create some seed data
cd backend
bin/rails db:seed
cd ..
Start the backend:
cd backend && bin/rails sOpen another terminal and start the frontend:
cd frontend && ember serverApp is running on localhost:4200
Run:
cd frontend && ember server --environment=fullstackOpen another terminal and run:
cd backend && bin/rails server --environment=fullstackOpen yet another terminal and run:
bundle exec cucumberThese environments serve the purpose to
- Stub out external services in the frontend, e.g. authentication via Auth0.
- Use a separate test database in the backend, which will be cleaned after each test run.
If you want to run firefox instead of chrome, you can set an environment variable:
BROWSER=selenium bundle exec cucumbercd frontend && ember test --servercd backend && bin/rspecWe use this milestone as priority queue for issues.
High prioritized issues will go to the top. Issues are tagged with
backend and frontend depending on where code needs to be changed.
Because GitHub lacks functionality to display estimation hours, we use Zenhub's browser plugin. Installing this plugin will show you the estimated hours per issue.
Don't be afraid about Auth0. As long as your local installation runs in development environment your login will reach the "Testing" database of Auth0. This will not pollute the production database of Auth0.
- Fork it 🍴
- Pick a user story from the backlog
- Create your feature branch:
git checkout -b [issue number]_my_new_feature_branch - Create
features/[site of change]/your.featureand copy+paste the feature description from GitHub - Boot both frontend and backend as described in the section about testing
- Run
bundle exec cucumber - Append the terminal output to
features/step_definitions/steps.rband write expectations - Run
bundle exec cucumber- tests should fail - Implement the feature
- Run
bundle exec cucumber- tests should pass - Commit your changes:
git commit -am 'Add some feature' - Push to the branch:
git push origin -u [issue number]_my_new_feature_branch - Submit a pull request ❤️
See our detailed contribution guidelines 🔍
Our build server Travis CI takes care about automatic deployment. Approximately 15 minutes after your pull request was merged into master, you should see the changes in production.
See the LICENSE file for license rights and limitations (MIT).