Accommodating crowdsource


#1

@Julian shared this on the Github: We have been working with the Coop Group to enable them to release their Local Community Giving Fund data. This fund gives approximately £18 million per annum. There are a number of categories where the funding model doesn’t map perfectly. These are to do with award dates and disbursements.

  • People apply to have their project supported at the point of application they are asked for an idea of how much money is required for the project - I have mapped this to Amount Applied For

  • A decision is made on a date to allow the applicant to be highlighted as a local cause that members can support. As this is for all intents and purposes a funding decision I have mapped this to Award Date

  • The crowdfunding element is then allowed to run for a number of months and at a certain point an amount will get paid on a date - I have mapped this to Disbursement Transaction:Transaction Date

  • The fund per cause will have reached a certain amount and this will get paid - I have mapped this to Amount Awarded

I am not sure at the moment if the causes get more money than they say the project will cost. Is the mapping correct?

He resolved it by making the decision that the Award Date is the point in which the fund stops taking money and releases the funds.

Any other way we can solve this in the future?


#2

I think what you’re saying is reasonable and fits with the model. If there is a profile page for each crowdsourced project it might be useful to use that in the URL field.

How are you mapping disbursement transactions in spreadsheet? The Standard has some guidance http://standard.threesixtygiving.org/en/latest/reference/#transactions.

The 360Giving Data Standard also allows for the reporting of three types of transactions:

  • commitmentTransaction
  • disbursementTransaction
  • applicationTransaction

These do not currently have nice human readable titles, but can still be added as spreadsheet columns if needed.

To create the column titles, refer to the 360Giving JSON Schema and use the JSON pointer paths as column titles. e.g. commitmentTransaction/0/id

The multi-sheet template has a tab for disbursements, but as with the above guidance, you would have to create the fields yourself.

So I don’t think that a column title Disbursement Transaction:Transaction Date will be standard-compliant as it technically doesn’t exist as a human-readable title (I say this while lacking the experience of having tried it). It seems that the column should be called disbursementTransaction/0/transactionDate

It should also have an id: disbursementTransaction/0/id (which could be based on the grant identifier) and a disbursementTransaction/0/value. I think (if there is only one disbursement) that this would be equal to the award amount.


Also

He resolved it by making the decision that the Award Date is the point in which the fund stops taking money and releases the funds.

But hasn’t this already been used for

A decision is made on a date to allow the applicant to be highlighted as a local cause that members can support. As this is for all intents and purposes a funding decision I have mapped this to Award Date

?


#3

With the use of Transactions, I think there are arguments that could be made for an against their use. It could be said that all grants would have some sort of transaction involved, but it’s not necessary to use

for example, with

A decision is made on a date to allow the applicant to be highlighted as a local cause that members can support. As this is for all intents and purposes a funding decision I have mapped this to Award Date

To me this seems to describe a commitment to provide funding, even if the amount is unknown at this point. This could be a commitment transaction (i.e. commitmentTransaction/0/transactionDate), and then the Award Date matches the date of the disburement? I’m not quite sure if an actual transaction has taken place, or if one has to at that stage to have taken place at the point of commitment to use the field, as there’s not much guidance in the Standard.


#4

In the end the Coop decided it was better to have the Award Date as the rough date of the payment and Amount Awarded final amount paid. It was considered too onerous/risky to split it into the constituent decision points, even though I think it would be a more accurate picture of the funding process.


#5

Thanks @Julianlstar and +1 for the simple approach. So crowdsourcing can be accomodated, it’s just that it’s not going to be very obvious from the data that this was the approach to giving used.

There is probably some more that could be done to make the Transactions elements more helpful, so that they can be utilised better, perhaps with examples of how those might relate to decision points - with crowdfunding being a workable example. As you point out, it will depend on the appetite from publishers for doing that as it takes a good bit of extra work.