No projects load. The site is blank except for the header. The error is:

TypeError: projectList.map is not a function

Might also want to lock pan+zoom across the two maps, for simpler comparison.

See also #14.

@waldoj says thumbs up/down voting is "useless...but necessary". Not of any intrinsic/real value for determining quality of proposal, but great for promoting engagement: a casual user may not care enough to comment on a proposal, but if they get an email encouraging them to "stop by and give it a thumbs up" then there's a higher chance of getting at least a minimal level of engagement, from a broader user base.

GitHub reactions API

• Copy about the Mission ( @waldoj )
• Design for placement ( @alecburch )

Link back to test-virginia is going to main page, not state page

Repro:

1. Load project page
2. Click into a proposal
3. Navigate back with your browser

Expected:
List of proposals appears

Actual:
Stuck on loading screen

Create a document about the basic assumptions that underlie this: e.g., that we're using GitHub as the backend, the technical sophistication about each type of user, what kind of agencies or organizations that we expect to deploy it, etc.

Clear sessionStorage and message user to sign back in (in modal?)

Difference between:

and:

The intended permissions are as follows:

1. Any member of open-redist can create a new project.
2. Anyone can create a new proposal.

However, I ran into some last-minute permissions issues trying to make these things possible:

1. It's not enough for a user to be a member of open-redist; the member must publicize his/her membership via open-redist's people page.

I ran into problems with the endpoint for checking all members (whether public or not) 302 redirecting and breaking the preflight request; instead, we use the endpoint for public members and therefore require public membership to create a project.

I'm not sure how to fix this problem; I expected the all-members API request to work, especially if the requester is a member of the org. But it does not.

1. In order to create a proposal, a user must be an owner of open-redist. I believe this is due to the flow used to create a proposal:

• first, a branch is created on the repo;
• then, the PR is issued from that.

If the user is not an org owner / repo admin, the user has no rights to create a branch directly on the project repo; instead, a pull request (proposal) can only be made from a fork. The fix to this is most likely to programmatically (via the API) create a fork and issue the PR from that, instead of creating a branch directly on the repo.

Store zoom/lat/lon in the hash for every map (current, proposed, diff) that supports pan/zoom.

Thinking of use case like e.g. 2003 Texas Redistricting, in which a specific part of the overall district map (in TX 2003, Travis County) is worth zooming in on. Could be valuable to zoom into a place of interest to share / annotate, e.g. on social media, in proposal page comments, etc.

Future versions of this tool-on-GitHub could author and integrate CI modules to provide information about proposals-as-PRs. When an edit is committed and pushed, these modules could generate metadata about contiguity, population count and balance, and demographic / ethnographic information. These metadata could appear on each commit like CI badges.

It's probably out of scope for us to build them for this project, but we can put some design thinking to it and mock something out for future implementers.

Currently, createProposal branches off master only. This makes it possible to issue a proposal only off of the current district map.

This is probably enough for most use cases, especially given we support proposal revisions, but it might be worthwhile to add support for branching off an arbitrary branch (base one proposal on another). I'm running into this as I author sample projects.

Is there any reason why defining the boundaries of a single district would require multiple GeoJSON files? Or can we safely rely on there being a single file per project?

1.0 finally came out, and has a bajillion improvements, notably big speed improvements that might help us with large maps. This should be as simple as updating package.json.

Not sure how to determine ownership of a given repo; might be only one user per repo and check that.

Currently using same logic as Add Project: only showing UI if viewer is a member of the open-redist org.

More broadly, do a scrub through the site with the following auth statuses:

• not logged in
• logged in as non-open-redist member
• logged in as open-redist member

Broken on mobile. Get minimum (read-only?) functionality working on small screens.

Add to the project, even if it's just a line item in the Appendix that describes the sort of widget we think would be useful
Perhaps it's a link to a page with the diffs map (existing and proposed) with comments

Have only tested with deletions.

I'm seeing e.g. some <div onClick={...}> instead of <button>.

Encourage user login when API rate limit is reached

• rename this repo to something more descriptive
• finish documentation
• coordinate timing with waldo
• map diff component
• verbage about what this is and what state it's in, and about how we may use/deploy this in the future (help from waldo on this)

...and more! think this through & communicate with @ericrodenbeck and @iamjimstanley

Add this to step 4.

If all else fails, "Open Redistricting." But surely we can do better.

Not sure what we can do to optimize, but I want to take a pass. It takes upwards of 30s for some diffs to render, e.g. http://openredist.org/#/open-redist/California-State-Senate/4

Might be able to simplify some API calls / sequences with hub.

There are surely more tools that will be helpful here (especially in light of #3). List them.

not logged in
logged in as non-open-redist member
logged in as open-redist member

Everywhere relevant:

• ProjectPage
• ProposalPage

• Add GA tracking string (use Stamen's to start)
• Swap Virginia redistricting GA code

GitHub API returns a 422 (Unprocessable Entity): Reference already exists in this case.