On the dashboard, in the stats section, we should show both the user's total (lifetime points) and their unredeemed points. When they select a prize, the corresponding amount of points should be deducted from their unredeemed points, but not their total/lifetime points.

Make sure that the flash message still shows (I think it will)

In general, I'll update an issue with labels, including the "ready" label, when I feel it is ready for someone to start working on making the changes. We should mention this in the contribution guidelines.

One of the navigations specs fails intermittently. I think when you run just that one spec, it fails every time. When you manually run through the steps in that spec, everything works fine, so I think there is some issue with waiting in Capybara.

When users are logging their "deed" (the number of trash bags collected and miles walked) they should be asked to submit a picture of their trash bag(s).

We should prevent tasks like db:reset and db:populate (which I'm currently developing) from running in production. Rarely, we might want to run these tasks in staging, so there should be a way to override.

Trail raisers are users who are more committed to Greensteps project and have made a financial contribution. They are invited to special events and things like that.

On the dashboard, there should be a prize section that shows a preview of some of the prize options. If they have enough points, they should be able to click on that prize to redeem it, otherwise, it should look kind of grayed out and not be clickable. There should also be a see more button at the bottom of this page that takes them to see all of the prizes. This full list should be broken down by how many points the prizes cost, and again if the user doesn't have enough points, it should be grayed out and not clickable.

It might be good to break this into multiple PRs, maybe the full page first and then dashboard preview second.

The rake task db:populate is used to generate sample data. The users that are generated should have deeds with trash bags and miles.

This should be in a rake task rather than an after :suite hook. Probably want it to run as a part of the default rake task, but not necessarily as a prerequisite to the spec task. It can be annoying to have it check all files all of the time. But it's also helpful to get early feedback when you're doing something ugly.

When a user picks a prize, their info (email) and the prize they selected are added to a worklist that the admins can reference. Once an admin has sent out the prize, they should be able to remove the record from the worklist.

Needs to coordinate with #25, maybe be done in same PR.

Right now, the show matcher ignores what is passed to expect. It just looks to see if the specified page object is anywhere on the page. When we expect one page object to be a child of another, it would be nice to be able to say something like

expect(dashboard).to show :deed_form

This example comes from user_logs_deed_spec.rb. Right now, we can only assert that both objects are on the page:

expect(page).to show :deed_form
expect(page).to show :dashboard

With the way things are now if we were to say expect(dashboard).to show :deed_form it would pass, even if the deed form wasn't a child of the dashboard but was elsewhere on the page.

We should have a controller spec that tests what happens when a trash bag can't be saved.

There aren't currently any validations on the TrashBag model, but we should stub out the save failure anyways.

We should review all views, models, and model attributes and make sure that they are internationalized.

We'll keep this issue open because we should do this review regularly.

If you haven't worked with internationalization (I18n) in Rails before, check out the Rails guide on I18n.

In the DeedForm page object (spec/page_objects/deed_form.rb), we get the input labels via User.human_attribute_name but it should actually be Deed.human_attribute_name. We should figure out why the specs are passing anyways and then use the correct version.

• Use Rolify to handle roles and Pundit for authorization.
• For now, just create an empty dashboard.

The post-deploy script only runs once after the app is initially created on Heroku, so we don't really have to worry about it running on the production version of the app, but if we were to ever recreate it, it would be a problem.

I'm used to that happening automatically.

The Rails core contributors/maintainers discuss a related issue here.

Users can suggest a business where they would like to use their points at.

After they submit the form, we should notify them that they will be notified if their request is approved.

Make sure to link to the Facebook page or group

Right now, trying that causes an application error. Instead, it should just redirect to the welcome page and show an error message.

Users can pin spots that are really trashed and then other users can view a map of these "hot spots"

Create a rake task to run code climate analysis locally in a rake task. Have the task be in the list of default tasks.

I think that ERB will be more familiar and approachable to new developers.

We should take the gems that are listed at the bottom of the file and add them in the correct category above. The first group should have gems that are used in all environments, the next group should have gems that are used only in the development and testing environments, and then the last group should have gems that are used only in the development environment.

Our RuboCop config is set to order the gems in each group alphabetically. You don't have to do this by hand - just run bin/rake after you change the file and RuboCop will alphabetize each group for you. I think RuboCop considers groups to be separated by empty lines. I'm not sure how it would handle the full line comments above the gems, we should probably just delete them. They are there from when the Rails app was generated.

We should delete gems that are commented out.

We're back to using ERB, so we should remove the haml-rails gem and ensure that views are generated using erb and not haml.

I'd like to have number fields that have big increment and decrement buttons and has the default spinners hidden.

Admins would like to have prizes sent out automatically. We've talked about using QR codes and insta-gift (not sure what that is).

At this time, when developers open a pull request from their master branch, Heroku review apps don't automatically deploy PR updates. If the compare branch is not master, then updates to the PR will automatically deploy (after the initial manual deploy).

After running migrations via bin/rake db:migrate, I'm seeing this when I try to run specs:

ActiveRecord::NoEnvironmentInSchemaError: 

Environment data not found in the schema. To resolve this issue, run: 

        bin/rails db:environment:set RAILS_ENV=test

It looks like this will be fixed by the next release of DatabaseCleaner. Until then, we can exclude ar_internal_metadata from any truncation or deletion cleaning done by DatabaseCleaner.

Additionally, it says that the test environment still has pending migrations... but this should have been fixed in PR #34. Any thoughts @stevensona ?

ask if they'd like to redeem their prize now, or wait and get a "bigger" prize later when they have more points.

In PR #53 we talked about having deed records destroyed if a user deletes their account (discussion). Now that I think about it, that might not be the best thing if Greensteps ever needs to query their data for grant purposes. Maybe we should make account deletion a "soft" deletion.

Along with reporting how many miles walked, we should report how many points the user currently has. Each bag of trash is worth 3 points, each mile walked is worth 1 point.

It looks like I wrote spec/page_objects/page_objects.rb to take care of all the including and setup that needs to be done, the code in spec/support/configurations/page_objects.rb is just duplicating some of the code in the other file. Maybe things still work because of Rails's autoloading?

I'm pretty sure we don't need to set up databases and stuff... whoops. But it would be nice to run the db:populate task so that we have data to play around with.

Once the dashboard page gets more complex, it would make sense to have a view/presentation object for it.

Some things I'd like on the list:
[ ] Verify all changes have test coverage.
[ ] I18N is used for user-facing strings as well as in specs.
[ ] Each chunk of code changes matches the style of similar files, specs, classes, etc.
[ ] User experience review: Step through the changes "by hand" in the browser.
[ ] Make sure the issue is linked in the description via a keyword.
[ ] If the Gemfile was updated, make sure Gemfile.lock was too

After merging:

• update issue labels (are any new issues ready to be started now?)
• do migrations need to be run in staging or production? (Semaphore might be set up to do this for staging, I can't remember)

Is there something we could add to the default rake task, and have either Code Climate or Semaphore run that would validate markdown files? It would also be nice if it could check to make sure that all lines are less than 80 characters.

Prizes should have names, quantities, and a "cost" in points (e.g. 10, 20, etc).

In commit c26c8, I added an errors partial for form errors and styled it, but I forgot that Devise uses #error_explanation to wrap it's form errors. We should add styling back in for these divs (e.g. try to update an user's password, but don't enter the current password), and keep the new styling we have for our errors (e.g. when creating a "deed" enter zero for both trash bags and miles).