RPVNetwork

Grassroots Network of the Republican Party of Virginia

I'm on the home stretch with the KGGOP website, working on the volunteer signup form and it dawned on me -- has anybody ever considered integrating the RPV's centralized signup effort with local units? This would ultimately get us more volunteers on the ground where the metaphoric rubber meets the road. Here's the idea. Take the script & DB for the current RPV volunteer sign up form. and produce a template that each unit can use on their own site. Design an administrator interface where the designated person (chairman?) for each unit has access to their county or city's data ONLY. (this ought to be a pretty simple query to write) When prospective volunteers sign up on RPV.org, they select their county/city if known and the data goes into that unit's sub-section of the database. If a volunteer signs up on a local party website, their data also goes to RVP. Obviously, security / permissions would be an issue to be addressed and if RPV would feel more comfortable with a trial run, maybe starting with an experimental project with a couple of units might be an idea. Views? It might be one small step toward implenting the general thinking behind Shaun Kenney's excellent letter to the RPV on grassroots, empowering local units, use of new technologies, etc etc. Heck, there's a lot of opportunities in Web 1.0 that we've not yet tapped into, much less Web 2.0....

Views: 34

Replies to This Discussion

I've had some comments / questions off-list that I thought it might be useful to address. One is the issue of compatibiilty --different unit websites using different platforms, different scripting language, etc etc.

What I had in mind was a completely plug and play interface that would be hosted on RPV.org -- local unit websites would just link to their county's version of the form. WAY easier tihat way and way easier to control quality, privacy issue compliance, etc. Each unit could upload their own top graphic / page chrome to make it look like part of their site, but it would be an RPV.org subdomain or subfolder. The form itself would need to be be the same basic template for everybody - the only variable being each unit would have different options listed in the data field for precinct, if known (drop down menu?)
Kathryn Coombs said:
I've had some comments / questions off-list that I thought it might be useful to address. One is the issue of compatibiilty --different unit websites using different platforms, different scripting language, etc etc.

What I had in mind was a completely plug and play interface that would be hosted on RPV.org -- local unit websites would just link to their county's version of the form. WAY easier tihat way and way easier to control quality, privacy issue compliance, etc. Each unit could upload their own top graphic / page chrome to make it look like part of their site, but it would be an RPV.org subdomain or subfolder. The form itself would need to be be the same basic template for everybody - the only variable being each unit would have different options listed in the data field for precinct, if known (drop down menu?)

Hmm. I dunno, but if it was me attacking this problem I'd be tempted to go with http://civicrm.org and modify the source to permit selective authz to certain custom data fields (maybe do it based on county of residence). It's fairly easy to customize and expose registration forms to capture what you need to drill down and id people you need to help out. I threw together a quick example here - http://www.virginiaright.com/user/register. Everyone's pretty much using PHP so the cross platform stuff should be an issue.
civicrm.org is pretty impressive -- thanks for the link. Glad to know there's an open source solution out there. I wouldn't think this would need to involve completely redesigning what RPV currently has or starting from scratch. I'd think it would be relatively easy to add to the system they've currently got, if it turns out this is something that units would find useful -- add the precinct field, add another level of permissions, add the unit-specific front end template. If there's sufficient interest on the part of units, maybe RPV could have its web design consultants take a look
Kathryn Coombs said:
civicrm.org is pretty impressive -- thanks for the link. Glad to know there's an open source solution out there. I wouldn't think this would need to involve completely redesigning what RPV currently has or starting from scratch. I'd think it would be relatively easy to add to the system they've currently got, if it turns out this is something that units would find useful -- add the precinct field, add another level of permissions, add the unit-specific front end template. If there's sufficient interest on the part of units, maybe RPV could have its web design consultants take a look

Well, all you'd really need to do is convince RPV to give you their data in CSV (the low tech answer) and you can suck it all into civicrm. You could conceivably use an RSS feed as well but that would require a bit more effort on both ends (obviously).
I don't think RPV's gonna let their databases out any time soon
Jim Huber -- great to see you on here. Pls input with your expertise as this is an area where you really know your stuff.
Kathryn Coombs said:
I don't think RPV's gonna let their databases out any time soon

Guess I was being naive. :)

Anyhow, one (important) thing I forgot to mention is if you do decide to install and test drive civicrm make sure that you allocate at least 32M of mem to php. You'll chain crash your site if you don't :P
Definitely think better coordination would be a plus. My concern is quality control,and not so much the DB/programming details. When the units have their DB and RPV has it's own, data will diverge in different directions. So whose info is the best? I can really overthink this one. Instead, I will regale you all with a relevant story about the Loudoun GOP...

The Loudoun GOP had it's own voter DB that it updated. It got it's info from RPV (who obtains and massages data from SBE), along with updates. But as far as I know, we didn't send info to RPV. The benefit was that we controlled the data. The problem was that the data from RPV (rather, SBE) sucked. The problem with RPV/SBE's data is when new people register, SBE can easily add them. But SBE doesn't know when people die, leave, or move within the state, so there are lots of people that don't belong. I've heard about campaigns using the list we had, and not only was the person no longer at that address, neither was the house. NoVA is so transient, that we need to get the data scrubbed and until RPV/SBE's data gets better, we have to check their data as we import it.

I guess for just a volunteer sign up form, it's not so complicated. But if we wanted to think about sharing more voter ID data than just that, it gets tricky. And I am not even talking about the DB programming aspect - just the rules involved. Maybe that civicrm software has a solution to this. Haven't looked it over very much yet.

Also, speaking of templated pages... I think RPV wants to offer templated unit sites, with content and data provided by RPV. Now that the November elections are past, I think they might spend some time on it.
All volunteer information stemming from online database submittable forms should also be converted to KML format so that we can have a digital representation of our volunteer base on a Google Earth of ArcGIS globe. The technology exists and is easily adaptable to existing websites.

BTW I "run" the RPVB website.
Max Shapiro said:
All volunteer information stemming from online database submittable forms should also be converted to KML format so that we can have a digital representation of our volunteer base on a Google Earth of ArcGIS globe. The technology exists and is easily adaptable to existing websites.

BTW I "run" the RPVB website.

Yep. If you happen to be running CiviCRM under Drupal you can already do this. Grab the module here: http://drupal.org/project/civimap. D6 port is underway.
Jim Huber said:
I guess for just a volunteer sign up form, it's not so complicated. But if we wanted to think about sharing more voter ID data than just that, it gets tricky. And I am not even talking about the DB programming aspect - just the rules involved.

What exactly are the rules for handling the data? I'm a software engineer with very little political/campaign background, so I'm completely ignorant of such things. Also re: the transient nature of NOVA, perhaps correlating against credit reporting agencies and other consumer streams? Or would that be against those rules?
Brad, I have a vision for a GIS Analysis and Comm system using ArcGIS or GE, I have enough background in programming to be extremely effective in communicating exactly what it is I want and how I want the back end to look. Is it possible you would be interested in collaborating on such an effort? I have sources of funding.

Brad Smith said:
Jim Huber said:
I guess for just a volunteer sign up form, it's not so complicated. But if we wanted to think about sharing more voter ID data than just that, it gets tricky. And I am not even talking about the DB programming aspect - just the rules involved.

What exactly are the rules for handling the data? I'm a software engineer with very little political/campaign background, so I'm completely ignorant of such things. Also re: the transient nature of NOVA, perhaps correlating against credit reporting agencies and other consumer streams? Or would that be against those rules?

RSS

****************************

 

U.S. DEBT CLOCK

****************************

 


 

 

(sales help fund this site)

 

Badge

Loading…

© 2022   Created by Tom Whitmore.   Powered by

Badges  |  Report an Issue  |  Terms of Service