itsiw/vilf

The Good Taste Guide™ Bay Area

vilf's Issues

PRs go live before merge

On my last PR I noticed that VILF displayed my review as soon as it finished running the CI job to test the build. I believe this was changed when I made the CLI interface so that we could test changes to commands used to build VILF. Specifically, I added

  pull_request:
    branches: [ develop ]

to deploy.yaml. Is this the intended outcome? If not, maybe we should change this so that for PRs we just run up to ./vilf build but don't run these lines?

    - uses: google-github-actions/auth@v0
      with:
        credentials_json: "${{ secrets.CLIMAX_VILF_SA_KEY }}"
    - uses: google-github-actions/setup-gcloud@v0
    - run: gsutil -m rsync -R build gs://climax-vilf-bucket

Contributor form

Remove SFGI stuff

Floating names on map

Showcase review authors

We could have a page that lists all the different review authors with links to all of their reviews.
There could be an author index page and a page per author, or just one giant page with all links.
All the authors need to provide is a unique identifying string, but we can provide more fields for
them to fill in if they want.

Use a data store instead of putting reviews in git

I think the main motivations for this are:

1. Keeping photos in git creates unnecessary bloat.
2. The git workflow is not ideal for non-technical people to contribute.

I think the form at #11 already addresses a much improved workflow for other people actually.
But with this workflow, it shifts work onto @ItsiW to upload people's reviews when he can into git.
If it's not a problem, then we can keep the reviews in git but have @ItsiW upload photos to the bucket.
This way, we solve the problem with the first motivation too without changing much.

If we want to move reviews out of git too, that requires using some kind of static file store on the bucket.
Maybe this can just be JSON format? We could provide a script for @ItsiW to easily migrate new submissions
to this new data store. Automated triggers might be overkill (and could cost additional money, but maybe not much,
especially if Climax is bankrolling).

Allow multiple reviews per restaurant

This ties in well with #20, where multiple authors can review the same restaurant.
I imagine there won't be many double reviews yet, so let's just list them in order of submission on the restaurant page.

This feature does beg the question what color we display on the map.
I think it makes the most sense to show the average rating on the circle (over food and value, equally weighted?).
The color could just be the typical color of the rating rounded to the nearest whole number.

Another cool feature would be to provide a toggle to change what the number and color represent, like:

1. lowest rating
2. highest rating
3. average rating

Testing for PRs

Simple test: does build.py run, let people see any errors