> On Aug 6, 2015, at 9:36 AM, Steven Clift <
cl...@e-democracy.org> wrote:
>
> Excellent. Glad to see Canada is covered. (Poplus, see below.)
>
> This does raise an interesting point - the ecology that I seek overall
> for my home state of Minnesota is one where you can based on your
> address also look up who represents you starting at the most local
> level on up. I am impatient seeing effort after effort that repeats
> look-ups for distant and frankly over-proportionately exposed area
> members of the U.S. Congress and maybe gets down to the state
> legislature, Counties, cities, and townships get let out as do other
> misc. elected bodies.
Agreed. For context: (readers can skip the next three paragraphs if they’re not interested in Represent’s operations)
For elected officials’ contact information, Represent covers the federal, provincial (plus Northwest Territories), and about 80 major municipalities. The only unfulfilled demand we’ve received for municipal data is to cover the entire province of BC, as we have several users whose advocacy work focuses on BC. We’ve also received demand for Yukon and Nunavut, but those territories haven’t filled our requests for districts data, on which the rest depends. For districts data, we have much better coverage at the municipal level, with 80-90% of the submunicipal districts by population. This data collection is also largely automated.
In order to fill in the missing elected officials’ contact information at the municipal level, a few provinces aggregate and publish directories of elected officials - however, most of these publish a single email for all of council. We collected this data in the past.
For electoral candidates’ contact information, we regularly work with nonprofits who are independently collecting this data anyhow, and who share their data with us to make available via API. The federal election is larger scale than provincial elections and there is more demand, so in this case we scraped as much data as possible, and worked with nonprofits to fill in gaps (and in some cases correct data published by political parties). The cost-benefit for investing in writing scrapers for electoral candidates is not as advantageous as for elected officials, seeing as the scrapers have a shorter lifetime (i.e. higher cost over time).
> So my thoughts is that:
>
> 1. Your location
> 2. +Your ballot (which knows which districts you are in/who is seeking
> to represent you)
> 3. +Length of term
> 4. +Election results over multiple years
> 5. - Misc. rep. resignations, deaths, etc. + appointments/special
> elections to fill slots
> 6. + Official government/representative submitted "in governance"
> contact information and links
> 7. + Crowd-sourced "in governance" contact information and links,
> especially the often "unofficial" social media links governments tend
> to avoid unfortunately
> 8. + Government jurisdiction/representative body links ... agendas,
> minutes, webcasts, semi-official hashtags
>
> = A comprehensive local-up way to who represents you and where/with
> what responsibilities
I don’t know that 3, 4, 5, 8 are critical to the stack. If the question is “Who represents me?” (so that I may contact them), then history (4), the way in which representatives leave (5), and how long they can be expected to be around (3) aren't critical. (8) is more of a separate project i.e. it can stand on its own. There are many legislation-tracking tools with no direct connection to representatives, so I wouldn’t overburden the stack with a requirement like (8). (Obviously, given the resources, (8) is a great addition!)
> So, how might the Represent API relate to this and how might YNMP
> sites feed all of this more effectively?
From my perspective, the Represent API and YNMP sites are doing this sufficiently effectively already - for the jurisdictions that they cover. The startup cost of deploying a Represent-like API (at the scale of ours) in a new country would be significant - greater than a YNMP site that relies on crowdsourcing (assuming relatively easy access to motivated volunteers). It depends on the intended lifetime of the project. YNMP may be a better choice for one-time projects.
[The following is a bit of a rant:]
The challenge (as you describe below) is getting broader coverage. But data sources like Represent or YNMP are ineffective without a community of users consuming the data to build apps, run campaigns, increase awareness, get-out-the-vote, contact candidates, etc. I don’t think the solution is to make Represent or YNMP more “effective” is some way. The challenge is that there is too little demand within most municipalities (compared to the demand within a country, province, etc.) to make local projects of this sort viable. Will a small town have enough motivated volunteers to populate a YNMP site (assuming some organization with more resources has already deployed the software and loaded the districts data)? Will it also have enough motivated volunteers to do something with that information, and promote whatever they made to the rest of the population? In last year’s Ontario municipal elections (which happen simultaneously in all its municipalities), the only tech projects of this sort (most of which used the Represent API for districts data) that I saw were in Toronto (where there were several projects, many of which were by people who had never done something like this before, which is a good trend), and in a few other cities where there was a single enthusiastic open data/open government software developer (many of which were by the same people as past projects in this field) with the time and interest to build something. This is my experience of the grassroots (i.e. non-institutional) use of the sort of tech stack you describe.
That said, there were many more non-tech grassroots efforts around the municipal elections. And with most of these, it didn’t matter that the people those projects were trying to reach didn’t have easy, direct access to information about candidates. The effort’s organizers would provide that information as necessary. The problems were not related to a lack of technology or data about candidates. They were dealing with a few dozen candidates, and a target few thousand voters. Their tech challenges were mostly met by WordPress, Google Drive, and Mailchimp (and in some cases CRMs like NationBuilder). Let me know if I’m misstating the situation.
We see more tech around federal/provincial elections because you can actually achieve economies of scale when you’re dealing with about 1500-1700 candidates (eventually) for this federal election, with a target of reaching hundreds of thousands of voters (or millions in the case of the most ambitious campaigns). So, the investment in tech pays off. Tech also allows groups to reach people that they would not have otherwise; e.g. most groups lack the resources for canvassers across the country. At the local level, an investment in tech often wouldn't pay off, but that doesn’t mean people aren’t being civic in other ways. And at the local level, strategies like canvassing are more plausible for small groups with fewer resources than at the federal level.
I guess what I’m saying is: I recognize that residents have fewer options to engage with governments via technological means at the local level (except for big/dense cities), but unless this is paired with low access to decision-making across all means, there’s not necessarily a major gap (e.g. as compared to the federal level) for tech to address here (with respect to the stack we’re discussing). I could use pointers to research on this topic, though, and to hear from other people’s experiences. (I do believe there is a significant gap at the provincial level, whose legislatures are about as inaccessible as the federal level, but where there are fewer tools like OpenParliament.ca to support monitoring and participation.)
[This got a bit long!]
> Over the last two decades I've seen 10x more energy invested in
> elections online only to see little effort sustain itself between
> elections to fill the democratic data deficit. Things have turned the
> corner, but the vast majority of local areas where everyday people can
> actually feel the impact of being more digitally connected to
> government remain woefully untouched. So, if national -open source,
> open data- engines for sourcing ballot data can be made viable (to
> this day, much the who represents me data in the US anyway is tightly
> controlled by those who labor to collect to pay for the cost of
> collection, etc.) I see it as the best chance to then build upon it
> after the votes are counted.
I expect the trend of elections capturing a lot of energy to continue, because it’s much more cost-effective to get the people who will implement your policy into government during an election, than it is to motivate representatives to implement your policy once they are already in government. So, it’s not surprising that energy drops after an election - in many/most cases, there is no intention to sustain that energy past the vote.
James