Revision history for CampaignFinanceUpdate
Revision [57787]
Last edited on 2021-07-15 10:27:59 by JamesW [removal of onpoint and galaxy mentions]Additions:
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level. That is, we display: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries.
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries.
Deletions:
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries. Another example is the display on Galaxy: http://votesmart.org/galaxy/#/Mitch-McConnell-53298/Finance-and-Banking-84/funding
Additions:
The goal, as it has always been, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
Deletions:
Additions:
Display 1
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level (galaxy only works for federal level officials and it displays individual campaign finances records). That is, we display: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
Display 2
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level (galaxy only works for federal level officials and it displays individual campaign finances records). That is, we display: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
Display 2
Deletions:
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level. That is, it displays: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
Galaxy
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all federal politicians
==Display 2==
Additions:
Votesmart.org website
Galaxy
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all federal politicians
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries. Another example is the display on Galaxy: http://votesmart.org/galaxy/#/Mitch-McConnell-53298/Finance-and-Banking-84/funding
Galaxy
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all federal politicians
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries. Another example is the display on Galaxy: http://votesmart.org/galaxy/#/Mitch-McConnell-53298/Finance-and-Banking-84/funding
Deletions:
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries
Additions:
Our campaign finance display is buggy and the process for incorporating data from external organizations is broken due to new APIs from CRP and NIMSP. Before it was broken, the process was cumbersome, prone to errors, and required precious IT time. I'm asking for a new process to incorporate data and an updated display to reflect the data provided in the APIs.
The goal, as it has always belen, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
==Display 1==
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level. That is, it displays: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
==Display 2==
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). If we wanted to take greater advantage of the possibilities of the various APIs we could develop various displays for each source API. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change.
>>Quick note: CRP's API has a field for VoteSmart_IDs in the same table as CRP_IDs. This could be super useful in making those connections.>>Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match candidate_ids from other groups to Vote Smart candidate_ids. Since this is automatic and should require little human effort once set in motion, this update could happen as frequently as possible to maintain accurate and up to date information.
2 additional requirements:
~- A researcher should be able to review/edit a full list of matches in case a problem is brought to our attention.
~- There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate.
The research department requests a .csv file or pulls data in some other way from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
Describe the application in detail.
Q: What will the user interfaces look like? The output?
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries
Mockups and diagrams are nice; you can add them below.
First priority is getting up to date campaign finance data on our current website with the current procedure. Please see mantis tickets #5915 (http://mantis/view.php?id=5915) and #6282 (http://mantis/view.php?id=6282).
Second priority is a new process for incorporating data and using the APIs.
Third priority is updating the website to accommodate new data.
The goal, as it has always belen, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
==Display 1==
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). The current appearance is uniform for all politicians regardless of office level. That is, it displays: Summary, Sectors, Industries, and Contributors. In the interest of time, this display can be maintained or only moderately updated to accommodate the new APIs and data.
==Display 2==
User visits our website and researches campaign finance information for various politicians. The campaign finance data displays accurate and timely information pulled from the organization's API that contains that information (state level = NIMSP, federal level = CRP). If we wanted to take greater advantage of the possibilities of the various APIs we could develop various displays for each source API. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change.
>>Quick note: CRP's API has a field for VoteSmart_IDs in the same table as CRP_IDs. This could be super useful in making those connections.>>Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match candidate_ids from other groups to Vote Smart candidate_ids. Since this is automatic and should require little human effort once set in motion, this update could happen as frequently as possible to maintain accurate and up to date information.
2 additional requirements:
~- A researcher should be able to review/edit a full list of matches in case a problem is brought to our attention.
~- There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate.
The research department requests a .csv file or pulls data in some other way from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
Describe the application in detail.
Q: What will the user interfaces look like? The output?
A: The website should look very similar to its current appearance: for example, http://votesmart.org/candidate/campaign-finance/53298/mitch-mcconnell#.VPCliqD3uXs and http://votesmart.org/candidate/campaign-finance/6158/anne-healey#.VPDRJKD3uXv display the Summary, Top Contributors, Top Sectors, and Top Industries
Mockups and diagrams are nice; you can add them below.
First priority is getting up to date campaign finance data on our current website with the current procedure. Please see mantis tickets #5915 (http://mantis/view.php?id=5915) and #6282 (http://mantis/view.php?id=6282).
Second priority is a new process for incorporating data and using the APIs.
Third priority is updating the website to accommodate new data.
Deletions:
The goal, as it has always been, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
To accomplish this goal, it is necessary to create a process for incorporating API data into our database and then to our website or directly into our website.
User visits our website and researches various politicians. The campaign finance data display could be uniform for all politicians regardless of office level. Because this is only one display, it would likely require less time and resources to create and maintain. However, because it would have to accommodate data from multiple sources of varying quality and quantity, the display would not be as thorough as possible from just a single source.
User visits our website and researches various politicians. The campaign finance data could display differently depending on the source API, or in other words the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more of the available data from the APIs and therefore provide a more thorough set of data for our users.
>>Quick note: CRP's API has a field for VoteSmart_IDs in the same table as CRP_IDs. This could be super useful in making those connections.>>Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match their candidate_ids to ours.
A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
The research department requests a .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
Describe the application in detail. What will the user interfaces look like? The output? Mockups and diagrams are nice; you can add them below.
<<Any issues that are anticipated but aren't necessarily appropriate/necessary for initial release? List them here!<<::c::
Additions:
>>Quick note: CRP's API has a field for VoteSmart_IDs in the same table as CRP_IDs. This could be super useful in making those connections.>>Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match their candidate_ids to ours.
Deletions:
Additions:
**User experience**
**Data incorporation**
Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match their candidate_ids to ours.
A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
We already have a link on a politician's bio page in admin [campaign finances] which takes the researcher to a new page where candidate_ids from CRP or NIMSP can be added. I would like this ability to be maintained.
IT assisted import - our current/most recent procedure
The research department requests a .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
This procedure is not ideal because it requires precious IT department time for something that could be done automatically or manually by a research staff member.
This application will not be dealing with non-campaign-finance information. The import/entry process should not be accessible to external users.
Describe the application in detail. What will the user interfaces look like? The output? Mockups and diagrams are nice; you can add them below.
No files
**Data incorporation**
Using the data in the external group's API, the system would automatically populate our database and website with the data for each politician. I imagine this process would be similar to the index_match function in excel the research department uses to match their candidate_ids to ours.
A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
We already have a link on a politician's bio page in admin [campaign finances] which takes the researcher to a new page where candidate_ids from CRP or NIMSP can be added. I would like this ability to be maintained.
IT assisted import - our current/most recent procedure
The research department requests a .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
This procedure is not ideal because it requires precious IT department time for something that could be done automatically or manually by a research staff member.
This application will not be dealing with non-campaign-finance information. The import/entry process should not be accessible to external users.
Describe the application in detail. What will the user interfaces look like? The output? Mockups and diagrams are nice; you can add them below.
No files
Deletions:
Data incorporation
Using the data in the API, the system would automatically populate the database and website with the data for each politician as matched to our candidate_ids. A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
IT assisted import
Research department requests .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
This application will not be dealing with non-campaign finance information. The incorporation process should not be accessible
<<Describe the application in detail. What will the user interfaces look like? The output? Mockups and diagrams are nice; you can add them below.<<::c::
{{files}}
Additions:
User visits our website and researches various politicians. The campaign finance data display could be uniform for all politicians regardless of office level. Because this is only one display, it would likely require less time and resources to create and maintain. However, because it would have to accommodate data from multiple sources of varying quality and quantity, the display would not be as thorough as possible from just a single source.
User visits our website and researches various politicians. The campaign finance data could display differently depending on the source API, or in other words the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more of the available data from the APIs and therefore provide a more thorough set of data for our users.
Automatic Entry - best case scenario
Using the data in the API, the system would automatically populate the database and website with the data for each politician as matched to our candidate_ids. A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
manual entry/editing - necessary backup scenario in case of a problem with the primary option
==Scenario 3==
IT assisted import
Research department requests .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
This application will not be dealing with non-campaign finance information. The incorporation process should not be accessible
User visits our website and researches various politicians. The campaign finance data could display differently depending on the source API, or in other words the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more of the available data from the APIs and therefore provide a more thorough set of data for our users.
Automatic Entry - best case scenario
Using the data in the API, the system would automatically populate the database and website with the data for each politician as matched to our candidate_ids. A researcher should be able to review the full list of matches in case a problem is brought to our attention. There should also be a list of "please review" matches, where the automatic matching was either unsuccessful or potentially inaccurate. This automatic update could happen as frequently as possible to maintain accurate and up to date information.
manual entry/editing - necessary backup scenario in case of a problem with the primary option
==Scenario 3==
IT assisted import
Research department requests .csv file or other data dump from campaign finance organization. Researcher matches external data to our candidate_ids and submits it to IT to import into the database.
This application will not be dealing with non-campaign finance information. The incorporation process should not be accessible
Deletions:
When you are done, consider [[http://mantis.votesmart.org/bug_report_page.php | creating a Mantis ticket]] and linking to this page.<<::c::
User visits our website and researches various politicians. The campaign finance display could be uniform for all politicians regardless of office level
User visits our website and researches various politicians. The campaign finance data could display differently depending on the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more
<<What are some things this application **won't** be doing?<<::c::
Additions:
====@@Campaign Finance Update/Renovation Project@@====
Our campaign finance display is buggy and the process for incorporating data from external organizations is broken due to new APIs from CRP and NIMSP. Before it was broken, the process was cumbersome, prone to errors, and required precious IT time. I'm asking for a new process to incorporate data and a renovated display.
The goal, as it has always been, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
To accomplish this goal, it is necessary to create a process for incorporating API data into our database and then to our website or directly into our website.
User experience
User visits our website and researches various politicians. The campaign finance display could be uniform for all politicians regardless of office level
User visits our website and researches various politicians. The campaign finance data could display differently depending on the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more
Data incorporation
Our campaign finance display is buggy and the process for incorporating data from external organizations is broken due to new APIs from CRP and NIMSP. Before it was broken, the process was cumbersome, prone to errors, and required precious IT time. I'm asking for a new process to incorporate data and a renovated display.
The goal, as it has always been, is to display accurate and useful campaign finance information for individual politicians on our website. Since we don't collect and standardize this data ourselves, we have to get it from somewhere. CRP, NIMSP are the federal and state level organizations with which we have working partnerships. Sunlight Labs has a campaign finance API as well. Brian has provided a menu of these API offerings at CampaignFinanceAPISummaries.
To accomplish this goal, it is necessary to create a process for incorporating API data into our database and then to our website or directly into our website.
User experience
User visits our website and researches various politicians. The campaign finance display could be uniform for all politicians regardless of office level
User visits our website and researches various politicians. The campaign finance data could display differently depending on the office level. Multiple displays would probably require more IT time to get it to display correctly as well as more time for upkeep as bugs appear and APIs change. But multiple displays might be able to use more
Data incorporation
Deletions:
<<Short description of what your application should do.<<::c::
<<Real-life scenarios of how people will use the application. Humor is OK.<<::c::