Welcome to the SunShot - RE-volv Reinvestment Improvement Challenge Part 1!

RE-volv is a solar energy crowdfunding platform.  The platform allows individuals to donate to solar energy projects.  RE-volv then re-invests the money the projects' saved by switching to solar into more solar energy projects.

The goal is to allow users to pick specific solar energy projects to allocate their RE-volv reinvestment funds toward.

Challenge Requirements

For this challenge, we need to design the additional pages and functionality outlined below.

We don’t have available PSD for the existing site pages but you can copy the overall look and feel from existing website : https://revolv-stage.herokuapp.com/. You can screengrab the needed page as the background of your design and apply the additional requirements mentioned below.

General Notes

1. Set up the RE-volv open-source code according to instructions found here: https://github.com/calblueprint/revolv#installation   You will need to use Vagrant to run the project while developing. Environment Variables setup mentioned here.

2. Write all new Python code according to the PEP8 coding convention (https://www.python.org/dev/peps/pep-0008/) and using Python 2.7.10

3. We don’t have an updated UI prototype for the changes requested, try to reuse existing UI components, and use your best judgement for how it should look like. You fixes should work in responsive view.

4. Updated and new JS/python code should be well documented, use PEP257 for docstring conventions.

5. Update README file if needed.

6. Update Seed script for data generation.

7. Please make sure to create helper/interface to include the common code/functionality.

8. You can access CMS by navigating to /cms.

9. You will need to set up a dummy paypal API key and add it to the .  Create a new paypal API key, and make sure it is set to go to the Paypal Sandbox when testing, so you won’t be charged.  Also note that on the RE-volv staging site (https://revolv-stage.herokuapp.com/) a credit card can be used and will not be charged. PayPal is set to testing mode on the staging site.  To run your development server with your paypal keys:

export PAYPAL_MODE=sandbox
export PAYPAL_CLIENT_ID=...your paypal id...
export PAYPAL_CLIENT_SECRET=...your paypal secret key...

Also please make sure your solution is flexible, use facade design pattern and adapter design pattern (and any other proper design pattern) to enable future extensibility of the solution.

Functional Requirements

Definitions

• - "Revolving funds": these are the funds that a given RE-Volv user has to to allocate to new projects on RE-Volv.  You should consult payments/models.py for information about how this works.  Every user who's backed a project has an amount, that varies month to month, that they can allocate to projects in the future.

 

• - “Donation”: an amount, in USD, that is pledged to a RE-volv project or to the Solar Seed Fund.  When a user makes a “donation” they are giving money directly to a project, or directly to the Solar Seed Fund.  This is different from pledging “Revolving funds” to a project, because pledging “Revolving funds” to a project does not cost the user any money.  Instead, pledging “Revolving funds” deducts from the user’s internal “Revolving funds” credit balance.

Reinvestment fund allocation

Please see https://github.com/calblueprint/revolv/issues/291 for background on how this reinvestment allocation process should work.

• - You can assume that Re-volv will manually set the monthly repayment goes to the Solar Seed Fund, and how much goes to RE-volv overhead. Assume the repayment will take 20 years, so we will have two new fields in project model, one for reinvestment fund (Solar Seed Fund) and the other for re-volv overhead, each field can be a new model with three fields (project, year, and amount), because each year will have different monthly repayment amount and it is the same for all months per year hence the ‘year’ field. So these two new fields will be used when calculating the reinvestment fund goes for each donor per project.

• - On the 1st of the month RE-volv calculates how much money is available for reinvestment (i.e. how much is coming in) and allocates it evenly among the projects posted.  Please see `payments/models.py` to see how this works.

• - This calculation and allocation should happen automatically using a new script named `reinvestment_allocation.py` and placed in a new `tasks` directory.

• - This script should be run periodically using a celery periodic task (http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html), and should run once a month on the 1st of every month.  It should run before the `monthly_reminders.py` script is run.

  • - the schedule should be configurable so that you and reviewer can test this scheduler within few minutes/hours instead once per month :)

• - We will cap the amount of “Reinvestment funds” any given project can receive by the amount allocated to it that month. Please see https://github.com/calblueprint/revolv/issues/291 for how this should work, to clarify the scenario :

  • - let’s say there’s $5,000 in the Solar Seed Fund on the first of the month. And we’re running 5 campaigns that month. Each project is going to get $1,000 that month. Meaning, we always split the money evenly among each project that needs it over the course of the month. However, we want past donors to have a say in which project their reinvestment will fund (even though all the projects get the same amount.) So for the first 15 days each donor has the option to reinvest their Solar Seed Fund Credit in any of the five projects. But once $1,000 of Solar Seed Fund Credit has been allocated to a given project, it stops receiving reinvestments. No one can allocate any more reinvestments to it. Then people can only choose to put their reinvestments into the remaining 4 projects. This continues until people only have a choice to invest in one project. Or, for those people who don’t invest by the 15th, their money will be allocated to the appropriate project by pulling Solar Seed Fund Credit from people in alphabetical order, as described below.

• - If the user does not pick a project to allocate their “Reinvestment funds” toward by the 15th of the month, their “Reinvestment funds” will instead be reinvested directly by RE-volv on the user’s behalf.

• - If it is past the 15th day of the month, the user should no longer have reinvestment funds available to spend.  We will instead allocate their reinvestment funds on their behalf.

• - A new script should be created, named `reinvestment_rollover.py` and placed in a new `tasks` directory.

• - This script should be run periodically using a celery periodic task (http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html), and should run once a month on the 15th of every month.

  • - Again the schedule and scheduler options should be configurable to allow flexibility in testing.

• - This script should move all users’ unused “Reinvestment funds” from the user to individual projects, as follows:

  • - Calculate how much money is still owed to each project and allocate reinvestment funds accordingly.  See https://github.com/calblueprint/revolv/issues/291 for instructions on how this calculation this should work. Also consult `payments/models.py`.

  • - Among donors that did not manually select which project to reinvest their “Reinvestment funds in”, the reinvestments are pulled from their accounts in Alphabetical order by last name until each project has received its allocated amount.

  • - The projects each user arbitrarily allocates their “Reinvestment funds” to will show up in their Dashboard the same way as projects they select directly do.

How users pick a project to allocate “Reinvestment funds” toward

• - When a user has “Reinvestment funds” available to spend:

  • - When visiting a RE-volv project page (e.g. /project/5/), instead of the “Donate” button they should instead see a button titled “Reinvest $X”. The “Donate” button at the top and the bottom of the page should be changed accordingly.

  • - The reward options on the right hand side should be inactive : they shouldn’t appear as having a pointer cursor on :hover, and they shouldn’t be clickable.  They should still appear, though.

• - When a user has “Reinvestment funds” available to spend and they click on the new “Reinvest $X” button, a new modal should appear that should look similar to the current “Confirm donation” modal:

• - After picking a project to reinvest their Reinvestment funds toward, a modal dialog should appear prompting them to give a normal donation to the project:

• - Clicking on “Donate!” should cause the usual donation modal to appear, and continue with the usual donation process.

• - Clicking “Not now” should close the modal.

• - After “Reinvestment funds” have been allocated to a project, those funds should be reflected in the project’s total funding amount, e.g. the “$Y donated” and “N% funded” figures should reflect this reinvestment.  Please consult  payments/models.py to understand how “Reinvestment funds” and normal donation funds relate to each other.

  • - Modifications to how these reinvestment funds are structured in the database, etc may be required here.

Reinvestment page

A new page should be created to highlight projects the user can allocate their “Reinvestment funds” toward.  This page is linked from the reinvestment email that goes out.

Wireframe:

• - The reinvestment page layout should have the same global website layout (header/footer/navigation) and should re-use elements in the website where possible.

• - The projects widget will match the projects widget styling in /projects and landing page.

• - Clicking on project will take the user to project details page.

Emails to donors

• - On the first day of each month, every user who's ever donated to a project on RE-Volv should receive an email. Only users who are marked as “subscribed_to_updates” (see below) should be emailed.

• - The email should read:

  • - Subject: "You have ${X} in RE-volv funds! Pick a project to support solar energy in a new community!"

  • - Email content for plain text and HTML provided below in screenshots.

    • - The primary button in the email should link to the “Reinvestment page”.

• - Email template should be configurable, you can reuse existing templates/emails/emails.yml to configure the email.

• - The links contained in the email should automatically login the user when clicked. The user should not have to manually log in again if they’re not already logged in.

  • - The automatic log in should be implemented using the `django-seasme` project: https://github.com/aaugustin/django-sesame

• - There should be an unsubscribe option in the email to allow user to unsubscribe to updates :

  • - A new “subscribed_to_updates” field should be added to the `RevolvUserProfile` model that is, by default, True.

  • - The bottom of each email, both plain text and HTML, should include a link to unsubscribe users. This link should take the user to the RE-volv site.

  • - The backend of the link will mark their user account as no longer “subscribed_to_updates” = false, and render a successful message in a new page.

    • - The page header/footer and layout should look like current website, the message will be displayed in the main area with proper styling.

    • - Preferred this backend to be flexible to accept new types of unsubscribe, i.e. the link accepts unsubscribe_type parameter (for now we will have single value = “unsubscribed_to_updates”). For future we can use it to unsubscribe from other features.

•  - A new script should be created, named `monthly_reminders.py` and placed in a new `tasks` directory.

• - Running this script should send emails to the relevant users, as described above.

• - The emails should be sent using the regular django email system, as used in other parts of the codebase.

• - The emails script should be run periodically using a celery periodic task (http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html), and should run once a month on the 1st of every month.

• - Wireframe for email:

• - Email content (plain text):

“””

From: RE-Volv Team

Subject: You have $<X> in RE-volv funds! Pick a project to support solar energy in a new community!

You have $<X> in RE-volv funds! Pick a project to support solar energy in a new community!

Click here to back a project with your $X in funds:

<Reinvestment page URL>

“””

Browser Compatability

- IE10+

- Latest Google Chrome (Windows & Mac OS)

- Latest Safari (Windows & Mac OS)

- Latest Firefox (Windows & Mac OS)

- Latest iOS Safari

- Latest Android Browser

HTML

- Provide comments on the page elements to give clear explanation of the code usage. The goal is to help future developers understand the code.

- Please use clean INDENTATION for all HTML code so future developers can follow the code.

- All HTML code naming should not have any conflicts or errors.

- Element and Attribute names should be in lowercase and use a "-" to separate multiple-word classes (i.e.. "main-content")

- Use semantically correct tags- use H tags for headers, etc. Use strong and em tags instead of bold and italic tags.

- No inline CSS styles- all styles must be placed in an external stylesheet.

- Validate your code- reviewers may accept minor validation errors, but please comment your reason for any validation errors. Use the validators listed in the scorecard.

CSS

- Provide comments on the CSS code. We need CSS comments to give a clear explanation of the code usage. The goal is to help future developers understand the code.

- Please use clean INDENTATION for all CSS so developers can follow the code.

- All CSS naming should not have any conflicts.

- As possible use CSS3 style when create all styling.

- Use CSS to space out objects, not clear/transparent images (GIFs or PNGs) and use proper structural CSS to lay out your page.

- Only use table tags for tables of data/information and not for page layout.

- Use variables with well-chosen names. Use some sort of naming convention.

Github repository

- The source code exists in github https://github.com/calblueprint/revolv

- The repo contains a very detailed deployment instructions for the application

Platforms

- HTML

- CSS

- Python

- Django

- PostgreSQL

Technologies

- HTML

- CSS

- Python

- Django

Final Submission Guidelines

Deliverable

- Git patch file of the changed code.

- Detailed deployment guide with verification steps.