smartcasual / jingle-jam Goto Github PK

Ability to have one bundle of 25+ games bought as a donation.

https://imgur.com/a/Ov10tg7

Realised this is list of donators not donations, I'm guessing all the donations have been made when not logged in? So it has no user to link to?

API access via webhook / websocket to payment system to link into our existing donation reader / twitch overlay app (must include real time data for each donation including donation amount, donator name, email address and donation comment).

Ability to top up donation without buying another bundle. Leave a new donation comment (which is pushed to the API including the new donation amount).

Localisation slows development down considerably but it's one of those things where once it's in, it's not so bad to maintain.

If we're doing it we should commit to doing it from day one of proper development, as it's always more effort to go back in after.

See if we can more aggressively cache bundled gems.

Most cukes don't require it, so it's just wasting resources.

Ability to adjust what percentage of your donation goes which charity - ideally using sliders on the UI clearly showing the percentage of your overall donation and the monetary split.

Different streamers (ie not just Yogscast) to be able to run their own Jingle Jam streams and see how much they have raised (not just the overall total) - these streamers should have a custom donation link to track the amount of donations they have driven and have some kind of admin panel access to this information

Plus when new keys are added, any new donations will automatically get assigned the keys - there is no way to prioritise existing donations

Ability to have lower price point(s) for lower value items.

When editing a bundle definition, if you change the price of the game, it will not update on save.

Twitch drops based on amount donated.

Embedded Twitch Stream (Yogscast) within the webpage.

Donate directly from Twitch and get the Bundle.

This may be a little complex in terms of business logic, how we assign donation amounts to bundle tiers.

Add paypal as a payment option

Ability to leave a donation message to be read on/shown on stream when purchasing bundle

Pre-order the bundle (and perhaps receive one game instantly).

Provide a (heavily cached) public feed and/or data dump of public donation info (timing, amount, "display name" of donator if given, etc).

@03gibbss Do you know any reason not to give out this data? The only part I can see as a concern is the donator's name, but in this case it would be the name they gave to display against their donation, the same on showing up on the ticker, so I'm inclined to take the Blizzard approach of "if someone could do it tediously with pen and paper then it's OK".

Currently you only receive keys for your first donation, every subsequent donation over the minimum bundle amount won't give you an additional bundle.

• Maybe this is fine? If this is how we want it to work, then the wording needs to be very clear that you only receive the bundle once.

• Maybe the better option is to give the user a button to opt out of receiving a bundle, this allows them to receive multiple bundles if they want, but also gives them just the option to make a donation without receiving a bundle

• Donations on behalf of others is a to-do ticket which ties in with this

“Advent Calender style” release schedule - a new game(s) added to the bundle each day.

Likely Rollbar.

The admin interface is currently missing this functionality, which is necessary for admin-admins to do their admin.

Ability to donate below the bundle price (and not receive the bundle - purely a donation).

Some aspects of the application have limited testing, these needs to be improved as we move out of PoC.

Most of the current crop of issues were copied over from the initial brief, and need to be either closed or bumped back to to-do if there's still work remaining.

Not super fluent in Ruby development, but I was poking around the codebase and was trying to determine if the stack is setup for queued messages with service workers consuming the queue to perform large operations in a FIFO flow. The fact that this service historically is always under large degrees of traffic, I'd imagine that message queuing would be an extremely important must for scaling purposes. The most I saw was that Jobs directory, but it didn't seem fleshed out yet, unless I was missing something. Queuing would be important for many operations such as sending emails, code unlocking, and donation processing. Is everything planned to be a monolith or would workers be split out so they could scale independent from the web services? Also would the message queue be offloaded to it's own service like SQS or Beanstalkd? Or is it all pulling from the DB?

I added a new game to the existing bundle at set it to £10:

https://imgur.com/a/6dgIUo3

I created a second bundle and added only the witness to it:

https://imgur.com/a/BHlUYmR

I made a new donation of £60 (this account had already made donations to receive the bundle before). After the new donation there is a second key for The Witness (presumably from the new higher priced bundle), and no keys for the new game:

https://imgur.com/a/5XWzkqA

However, on the admin pages, the key for the new game has been assigned:

https://imgur.com/a/maIokPQ

Not entirely sure where this key has been assigned to. Maybe it is linked properly, just not showing correctly on the front end?

I added a few extra keys, made a fresh donation from an incognito window, and it assigned keys as intended:

https://imgur.com/a/V7ByM9L

Going back to my logged in window and making a new donation assigns a key for the new game:

https://imgur.com/a/GjrwRkx

Not sure this is an issue after all, I later made new games, added them to existing bundles, when a donation was made from another account it automatically assigned keys from the new games to all existing donators it seems.

Immediately or once fraud checks have been done, either via email or a protected 'key redemption' page on the website.

Update gems and ruby versions etc. Make sure the site is functional.

https://imgur.com/a/iAnkXI1

https://imgur.com/a/VxZb42U

Not sure on how best to fit this, if slider is at 0 then automatically lock slider? That also feels a bit unintuitive. To be honest I think having a button to lock the slider feels a bit weird anyway, but I'm not sure removing it would make it any more logical...

Likely TOTP.

Pay what you want model to enable higher donations (and still get the bundle).

Add permission levels, control access to e.g. game keys, donator info. Ensure access is checked for donators viewing their own keys.

Suggested admin permission levels:

• Support; can view donation, bundle, and donator info
• Data Entry; can view and edit games, bundle definitions etc, but not game keys
• Game Keys; can view and edit game keys
• Admin; has permissions of Support and Data Entry, plus can create/modify admin accounts for Support or Data Entry
• Full access; can do/see everything, including creating all non-full-access accounts (which should be very limited and probably added by hand)