# Public and Private Goods - Behavioural Experiment Welcome to the code for running a collective risk behavioural experiment. Participants have a budget and can solve a problem by contributing to either a public or private pot. The public pot is cheaper but requires cooperation. If they fail to solve the problem either way, then they lose all their money. If they manage to solve it, they get to keep their unspent funds. Participants play in groups of 4. In each group, 2 participants start off with a lower amount of funds than the other 2 competitors. In three treatments, the wealth distribution is decided either by a lottery, partipcants' performance in a mental arithmetic task, or a mix of both. ## Getting Started - Local The experiments was built and tested using python 3.8. For best results, please use this same version. We recommend that you create a virtual environment to run the experiment. 1. Create a vitual environment with python 3.8. We recommend virtualenv-wrapper. You can create a virtual environment with the crorect python version by running mkvirtualenv colrisk --python-python3.8 2. Download a copy of this repository git clone git@github.com:chasmani/behav_experiment_public_and_private_solutions_to_risk.git 3. Navigate to the main folder cd behav_experiment_public_and_private_solutions_to_risk 4. Install the necessary requirements pip install -r requirements.txt 5. Run a local server on your machine otree devserver 6. Click on the link shown in terminal, usually it is http://localhost:8000/ 7. From there, you can run individual demos of the experiment or the full experiment. 8. You can create a session for any number of players by clicking on "Sessions" in the navbar ## Getting Started - Running Online on Heroku Deoplyment to herokue can be handled using the heroku cli. This gives the most control and is easiest once setup. To setup, download the heroku cli, setup the heroku git branch and push the changes to heroku. This guide does a godo job of walking through it https://dev.to/lucysuddenly/easy-step-by-step-guide-to-deploying-on-heroku-3m9p You will need to reset the database if there have been any changes to models. To do this you can run `heroku run "otree resetdb"` from terminal on your local machine. WARNING: THIS STEP WILL ERASE THE ENTRIE DATABASE, MAKE SURE YOU HAVE DOWNLOADED ANY DATA YOU NEED BEFORE RUNNING THIS. ## Participant Labels In the current setup, users are prompted for a "participant label" when clicking the link for the app. These need to match participant labels in `"_rooms/participant_labels.txt"`. If you want to set these to e.g. student IDs then change the txt file. Alternatively, we can setup the experiment to run without participant labels, but this will cause 2 participant instances to start if a user opens up two browsers with the link. ## Grouping Users are grouped upon arrival in the effort task. Once they have a group, this group persists across apps and rounds (although the group id may change over the apps). This wil generally work smoothly but will not work if there are small groups of less than 4 or a player drops out. ### Not enough players to form a group On occasion there won't be enough participants to form a group of 4. E.g. if there are 41 participants then there is 1 left over. In this case, the system waits for 20 minutes to try and group the players. After 20 minutes, the player grouping is abandoned. Players are put in thier own group of 1, and the participant is given the `participant.is_dropout=True`. This effectively skips the rest of the app by not displaying any pages. ### Dropouts Players may drop out of a group during the experiment. The rest of the group will continue util they hit a WAitPage at the start of an app. They will then wait there until the WAIT_PAGE_TIME_OUT hits. One that hits the participants are given the `participant.is_dropout=True`. This effectively skips the rest of the app by not displaying any pages. In the main Game app, there is also a wait page while everyone Contributes. The Contribution page therefore has a timeout. If a player doesn't submit a contribution within the timeout then they contronbute zero and are set as a dropout. The rest fo the group continnutes without the player. In either of the above conditions (group not formed or player dropped out), the final page will display a message to tell the user that there was a problem with the experiment due to waiting too long, and that the experiment was stopped early. ## Testing ### Automated Testing A Otree includes some basic testing functionality with bots. The experiment includes tests to check that it all runs smoothly under basic conditions, with bots acting You can run this with otree test This will catch any serious errors with the experiment crashing or not getting to the end under basic bot behaviour. ### Automated Testing B Otree's browser bots are limited so we also wrote some of your own for testing. These can be found and run in browser_bots.py. There are options for testing on a local machine and heroku. And can test for dropouts etc. ### Manual Testing Before running an experiment, we recommend testing some edge cases manually. The test criteria is whether the experience is what we want for the participants, that the game outcome is correct and that data is recorded properly. The etsts can be checked by cimply playing through and checking it all mkaes sense, or checking the data under the Export tab on otree. Things to test include: 1. Having one player drop out from a group. Is that handled gracefully for other participants? 2. Having multiple players drop out from a group. 3. Session with multiple groups. Are the groups consistent across rounds? Especially check what happens if groups arrive at apps at different times, and with players in combinations of orders within and between groups. Also check that the individual group data is not being influenced by players outside of the group. 4. Sessions with as many participants as the experiment will have. More participants require more resources, which may be adjusted on heroku (database, memory, processor etc). More participants also may increase chances of bugs due to request scheduling on the server, if lots of requests are being received together. Do these bugs arise and if so are they handled gracefully? ### Translation There are 3 different types of text to translate. 1. Text that is a part of Otree's core functionality. E.g. Waiting time messages Change the LANGAUGE_CODE in settings.py e.g. `LANGUAGE_CODE = 'fr'` 2. Bits of text that are in python code e.g. the text for questions in forms Translate by making a copy of "lexicon_en.py" and naming it in your language. Add to the "if" statement at the top of all the __init__.py files for each app to load in the correct lexicon file. 3. Templates To translate text in templates, create an "if" statement to check for the LANGUAGE_CODE. Rewrite the main content block below that. See the consent app tempaltes for examples of how to do it.