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

Systematically cover grant process #11

Open
riceissa opened this Issue Nov 25, 2017 · 9 comments

Comments

Projects
None yet
1 participant
@riceissa
Collaborator

riceissa commented Nov 25, 2017

  • Grant stage in relationship lifecycle: enum('planning grant','initial grant','renewal grant','exit grant'). This will help answer high-level questions such as: what fraction of grants are initial vs renewal vs exit? How many new grantees are being found?
  • Predictions associated with the grant (list field, pipe-separated URLs to predictions)
  • Thoroughness of grant application or review process. e.g., Open Phil uses discretionary versus full-process grant.
  • Some field giving structured or free-form information on the expected use of the grant money. (We have something called special_donation_reason that is not used much, but kinda related but different).
  • Some field giving structured or free-form information on the reasons the donor is impressed with the donee (typically based on historical performance of the org or individuals in it, or the ambitiousness of the vision, etc.).

@riceissa riceissa self-assigned this Apr 1, 2018

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 4, 2018

It seems like for grant stage, one rule that should be followed is "if there is only one grant for a (donee, donor) combination, then it must either be a planning or initial grant". I think the following query checks for this (i.e. it should be empty if the rule is followed):

select grant_stage,url
from donations
where grant_stage is not NULL
    and (donee,1) in (select donee,count(*) from donations
        where donor='Open Philanthropy Project' group by donee)
    and (grant_stage != 'planning grant' and grant_stage != 'initial grant');
@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 5, 2018

Grant stage stuff is now at https://github.com/riceissa/open-phil-grant-stage because I decided to do it using a script.

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 5, 2018

'Thoroughness of grant application or review process' is also now covered in riceissa/open-phil-grant-stage (I guess the repo is now misnamed, oh well).

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 5, 2018

Predictions are done. See the following commits:

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 5, 2018

For "Some field giving structured or free-form information on the expected use of the grant money" I would like to see some examples. Does this correspond to the "Purpose" field on a grant page? Or some made-up phrase?

If we take https://www.openphilanthropy.org/focus/global-catastrophic-risks/potential-risks-advanced-artificial-intelligence/george-mason-university-research-future-artificial-intelligence-scenarios as an example, some possible values I can think of are:

  • "To support Robin Hanson's analysis of potential future artificial intelligence scenarios." (if we just take the "Purpose" field)
  • "research" (if we try to shoehorn this into an enum with maybe ~10 values)
  • "research, hiring of a research assistant, teaching buyout" (if we use some of the descriptions in the grant page)
  • "faculty salary, wages, domestic travel, foreign travel, new computer, software" (if we use some of the information in the cited PDF)
@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 5, 2018

By the way, the grant-process branch in this repo is now mostly obsolete because I decided to do the grant stage stuff via the script linked above rather than by hand. It might still be useful as a way to double-check that field, but isn't intended to be pulled into master anymore.

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 7, 2018

I'm trying to use some hacky regex tricks to detect the expected use of grant money. Here are the results so far (see the expected_money_use column): https://github.com/riceissa/open-phil-grant-stage/blob/master/data.csv

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 7, 2018

Also as you can see in the CSV, grabbing the purpose from the grant page is very easy and clean. The problem with the purpose is that in my view, in most cases it doesn't capture the most useful information about how the money will be used.

@riceissa

This comment has been minimized.

Collaborator

riceissa commented Apr 7, 2018

I've been thinking more about the expected use of grant money one. My guess is that the most useful one to include would be an enum that we can then do group by queries on, so that we can say things like "X% of Open Phil grants are for research, Y% are for campaigns, %Z are for prize money, and so on". But to do this well would probably require manually entering the values or at least manually checking the outputs from a script.

My sense is that nobody besides you is even asking these questions, and I'm not sure if anybody else would begin to care if running such queries became cheap. In chat you said (any of) the sample values I provided in the comment above are fine, which leads me to believe that even you haven't thought through this in sufficient detail to know precisely what you want out of this. That makes me feel suspicious about going ahead with a tedious manual task.

For the free-form version, I think the free-form format contains too much information for a human to process by reading the page, and if one were to focus on a small subset of grants, then one could already check this manually pretty easily. So if we just grab the "purpose" field from the grant page that would be easiest, but I'm not sure the value added would be high.

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