User:Rando/Donate v2

From Noisebridge
< User:Rando
Revision as of 17:37, 18 December 2018 by Rando (talk | contribs)
Jump to navigation Jump to search

donate.noisebridge.net v2

donate.noisebridge.net (donate) is currently written in Ruby on Rails using rspec for testing.

https://github.com/marcidy/nb_donate

Donate-v2-schema.png

Issues

  1. Very little of Noisebridge's other architecture is ruby.
    1. this creates a maintenance issue
    2. rails doesn't have the greatest reputation
  2. certain functionality is not available or exposed
    1. some critical-ish functionality like subscription cancellations is mention in the code but there is no way for the user to execute or know how to do it
    2. important financial reporting functionality is not available
    3. some nice to have functionality is available but not exposed
    4. the financial models are not aligned with good accounting practices

Implementation Plan

  1. Backend Implementation in Python
    1. Python is the best known and maintainable language currently
    2. using Flask
      1. Django was discussed and had some support, however, Flask is used in house
      2. Flask is growing faster the Django, though Django is still growing
      3. Flask is has more configuration options (can be negative)
      4. To increase support, a Flask class can/should be added to the current Python class schedule to recruit people to maintain architecture.
    3. APIs
      1. Stripe integrates with Python just fine.
      2. Paypal is just contructed links
  2. Front end uses unchanged/minimally changed migrated assets
    1. Donate does not require significant user interaction or front-end behavior implementation.
    2. Re-use of js/css/images/fonts from old doante site will used where-ever possible

The first goal is to get the existing functionality up and running with the same ui / look and feel. Once Complete, items from the road map will be added. However, the main difference is that the backend will use a contemporary model for financial data, which is based on transactions and accounts. This will support, among other things, double accounting and can be reconciled to other platforms and be a repository for all financial inflows and outflows.

Currently everything is a project and spending from the project is tracked elsewhere. this is because the account model is missing. An account is something like the Laser. Money is donated to it, and money is spent on upkeep. The balance in the account goes up and down. right no project balances are just the inflows, e.g. the donations. The amount never goes down.

Projects are implemented with accounts and they now have a goal. E.g. a project will have an amount to reach. Accounts are flexible and can represent any aggregated financial data.

The other difference is transactions. Any time money is moved into NB, in between accounts, or out of NB, a transaction is created. The sum of the transactions creates the entries for double accounting, and should alway sum to zero globally. This allows us to reconcile accounts / spending etc easily.


Phase 1: Build and Test

  1. Create new financial Model
  2. Migrate existing donate models
  3. 100% test coverage on models
  4. implement and test controllers (CRUD behaviors, validaters, etc
  5. implement and test routes/views
  6. implement and test page templates
  7. implement mock API calls for testing and UAT

Milestone: User testing

Phase 2: Migration and Public Testing

  1. Test static data creation (currencies, accounts, projects, Stripe plans
    1. make sure expected outcomes are clear
    2. create static data reports so it's clear what's in the database and how it all interacts
  2. Migration
    1. Create migration scripts from existing database
      1. Certain objects which don't exist must be inferred, e.g. project accounts, strip accounts, noisebridge accounts
    2. Create verification scripts against "production"
  3. Create test environment to bug hunt with users actually playing with code to try to break it. Enlist everyone!
    1. Stabilize codebase against UAT

Milestone: Testing Acceptance

Phase 3: Stripe and Paypal integration

  1. Generate API calls and compare against Production
  2. write tests for any and all outbound financial traffic
  3. Compare traffic in parallel by replaying events in new donate compared to old
  4. continue with User testing on separate environment with full logic

Milestone: Identical outbound calls for same user input

Phase 4: Production

  1. Increase logging temporarily to save all incoming data for change over period
  2. Change-over during a low-traffic time: 10pm berlin on a sunday?
  3. test heavily with incoming donations of all kinds, ask people to donate in creative ways
  4. ??
  5. Profit.