Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanded Agency Attributes #1209

Open
morisy opened this issue Jul 3, 2017 · 3 comments
Open

Expanded Agency Attributes #1209

morisy opened this issue Jul 3, 2017 · 3 comments

Comments

@morisy
Copy link
Member

morisy commented Jul 3, 2017

Agencies should have the following fields. If these fields are updated, removed, deleted, it should be possible to see those revisions (i.e., so down the line we can check how often an agency's website or Flickr account changes). I'd love an additional optional field for each attribute that credits whomever supplied a given piece of information so we can broadly credit folks, but if that's too much complexity for now it's fine — mostly staff contributions.

general_phone: A non-FOIA main phone number. May often be same number as phone.

  • foia_portal: What it says on the tin. full url
  • facebook <-full url
  • instagram <-full url
  • glassdoor <-full url
  • wikipedia <-full url
  • blog_or_news <-full url
  • open_data <-full url
  • github <-full url
  • yelp <-full url
  • youtube <-full url
  • flickr <-full url
  • agency_oversight <- multiselect agencies (usually an IG or something)
  • records_retention_schedule
  • records_systems (similar to foiamapper)
  • ORI Number (A federally-standardized identification system for law enforcement agencies). We have a spreadsheet to match these. the string is a mix of numbers and letters.

Also some possible changes:

  • Agency Head would be good, but would require creating a new person entity which is a whole new can of worms. Would also be good to track their term.
  • Some kind of budget, but would want this tracked over time (i.e., FY2017 is $100, FY2016 is $80, etc.) and would also need to define what their FY is somewhere.
  • Number of employees by year (Union, exempt, appointed?)?
  • Key elected officials (better for agency)?
  • Links out to legislative trackers (better for agency)?
  • Breaking out mailing addresses/FOIA office addresses vs. physical addresses or other addresses that are useful to have?
  • Good suggestion regarding breaking out acronyms vs. other aliases (think this could be done programmatically to set, but think it would be also good to store these in their own separate fields similar to how emails, phone numbers, etc. are done ... not 100% sure how these are actually stored in the database. I do really like ease of use of updating them now.

For reference, existing fields:

  • Name
  • Jurisdiction
  • Type (very rarely used, multiselect i.e. Police, Library, etc)
  • Status (approved, rejected, pending)
  • User who created
  • Appeal agency
  • Can email appeals
  • Payable to
  • Image
  • Image attr line:
  • Public notes:
  • Stale
  • Manually marked stale
  • Address
  • Location
  • email
  • Other emails
  • contact salutation
  • Contact first name
  • Contact last name
  • contact title
  • FOIA Web Page:
  • Phone
  • Fax
  • Notes
  • Aliases (ie., FBI for Federal bureau of investigation)
  • Parent
  • WEbsite
  • Twitter
  • Twitter handles
  • FOIA Logs
  • FOIA Processing Guide:
  • Exempt
  • Requires proxy
@morisy
Copy link
Member Author

morisy commented Jul 9, 2018

Spoke with @mitchelljkotler Mitch, and one thing we want to do is revamp both existing things that are just URLs (or should just be URLs, like Twitter accounts) and instead of keep them as separate strings, just have a URL type, similarly to how we structure phone numbers, and then a dropdown field that lets you say if it's a Twitter, Instagram, GitHub url.

@TJKenney
Copy link

TJKenney commented Jul 9, 2018

Within a given federal agency, you may need inherited attributes, especially for a records retention schedule which covers all agency records.

At least at the federal level, you could organize the offices into a hierarchy, plot where each RSC is (often above, but sometimes below the records custodian), then use that to inform some of the internal logic.

@morisy
Copy link
Member Author

morisy commented Jul 10, 2018

@TJKenney's suggestion is mostly covered by newly created by related item #1444.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants