Extending grantProgramme object to give more details about funding programme

[drkane]

Following conversation with @timgdavies, who suggested an issue outlining the use case for allowing the standard to include more detailed information about grantProgrammes

Use case

Funders could publish information about their available funds in a way that allows aggregation of available funds in services like Beehive, Funding Central, TrustFinder. Examples of information that would be included are:

• programme name
• funding deadlines
• minimum/maximum grant amount available
• duration of grant available
• eligibility criteria - types of organisation, etc
• application link
• link to guidance for applicants

For funders this would increase the places where their funding would be seen, and ensure that it is consistently presented in aggregation sites.

Could also form the basis for a common application standard

Solution

I'm agnostic about the solution used, but it could be that the grantProgramme object in the 360giving standard is extended to include the additional details. Grant programmes could then be presented as a standalone list published by the funder alongside their 360giving grants data.

I would guess there is potential to learn from experience of opening up data about contracting opportunities.

Potential blockers

1. Enthusiasm of funders

   Extra work by publishers would be needed to produce and standardise the data.

   Funders may be concerned that it would lead to proliferation of sites, and potentially mass auto-applications, leading to an overload of unsuitable applications.

   Counter to this: would put funders in control of the data. Maybe use robots.txt or similar concept to disallow access.

2. Complexity of data

   Our experience from Beehive is that funders have a range of different ways of describing and setting up their funding programmes, not all of which fit neatly into a common standard.

   Counter to this: standard would need to be designed with the flexibility to include these variations, based on user testing.

[timgdavies]

Note that funding deadlines will need time and timezone information

[timgdavies]

The demand for this came up in conversations with Sarah Barker of OurCommunity.com.au also. Would be good to find a path forward for this in the near future.

[drkane]

Note that funding deadlines will need time and timezone information

agreed. The deadlines would be one of the more complex parts to model - I've seen lots of different concepts, including rolling yearly deadlines, one-off deadlines, multi-stage deadlines, etc.

[drkane]

Further to this I've put together some more detailed thoughts on what a schema might look like and put together a draft schema (which draws heavily on the 360 giving schema).

[stevage]

Hi, just chiming in here - I'm doing some work for Sarah at OurCommunity, on SmartyGrants. For context, SmartyGrants is a software platform used by many Australian government bodies to manage grant programs, including the forms that applicants fill out to apply.

One thing that immediately stands out here is that much of the information attached here at the "Programme" level, is in SmartyGrants modelled at the "Round" level. A Program (say, "Environmental grants") has multiple rounds, (say, "Environmental grants 2015", "Environmental grants 2016" etc) each of which can behave differently. (A round then has multiple Stages, which set the deadlines for things like submitting applications, having those reviewed, decisions made, notifications etc.)

But mostly just saying hi at this stage. :) Still getting my head around it all.

(Btw, not totally related, but just wanted to mention Fiscal Data Package in case you're not aware of it. I did some work on it at one stage. It's a data standard intended for governments publishing all their spending, including grants but also everything else. There may be some relevance.)

[morchickit]

Hi @stevage - (sorry @stevieflow that it's a bit off topic!) welcome on board! As an ex-Open Knowledge International employee I am well aware of the the fiscal data package, I am well aware of it, some good stuff is going on there. If you have any ideas about data packages and 360Giving, let me know !

Back to the topic - @drkane - I like this a lot! We will still need to prompt publishers to actually publish the data, but this is a great start of discussion

[drkane]

Hi @stevage - thanks for the comment, that's really useful.

In terms of the "round" level of data, I think it could be modelled in two ways:

1. If the rounds are simply the same fund with the same eligibility criteria, etc then the fundingRounds list could be used to add new deadlines.

2. If they are changing criteria over time they could add them instead as subFunds.

It's a good point too about the Stages of a programme - dates for submission, review, notification, etc - at the moment this doesn't have a sensible place to put those dates.

[drkane]

So I think my plan is to test this with a couple of friendly funders, and see how they get on. I have a couple in mind but if anyone has any suggestions that would be helpful too.

@morchickit - I'm slightly worried that this might be a bit scary for some current 360 giving publishers and I wouldn't want it to disrupt the rest of the 360 giving work, so it feels important to emphasise that it's just an exploration/experiment and not part of the core work. Might be worth us having a separate conversation.

[timgdavies]

@drkane Great work on the proposal.

Happy to join a discussion about how this could be framed for publishers, and to explore the modelling in more depth.

This has some strong resonances with the 'organization' file in IATI, that sits alongside an 'activity' file, and that provide indicative budgets etc. (I know @stevieflow has looked at these quite a bit)

[mlenczner]

Hi all,

This is something that we've thought about many times since we started Fundtracker. I certainly agree that it would be very useful if it were to be adopted by a critical mass of funders.

We haven't ever put any energy into it, because my analysis is that there isn't a way to get that mass adoption. In fact, as David just mentioned, I think it's the kind of thing that could confuse the funders that I'm in contact with at this moment in time. We are certainly focussing on perceived value with limited fields as early as possible, as opposed to extending the data that is asked for.

Since this (open grants data) is still a small initiative that we all work in, I thought it would be useful to share that perspective.

Best,

Michael Lenczner Director of Powered by Data http://www.poweredbydata.org/, a Tides Canada Initiative | CEO of Ajah http://www.ajah.ca/ +1-514-708-5112

On Fri, Aug 4, 2017 at 5:22 AM, David Kane notifications@github.com wrote:

So I think my plan is to test this with a couple of friendly funders, and see how they get on. I have a couple in mind but if anyone has any suggestions that would be helpful too.

@morchickit https://github.com/morchickit - I'm slightly worried that this might be a bit scary for some current 360 giving publishers and I wouldn't want it to disrupt the rest of the 360 giving work, so it feels important to emphasise that it's just an exploration/experiment and not part of the core work. Might be worth us having a separate conversation.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ThreeSixtyGiving/standard/issues/188#issuecomment-320202046, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKna5JezqNmR7tQLgdXCsc2nh8jHI-Eks5sUuLYgaJpZM4OBBv1 .

[drkane]

Thanks @mlenczner - that's some really useful insight and it confirms some of my worries about the suggestion. I definitely agree that getting funders to publish in this format would be very difficult.

In terms of mitigating this, I imagine that the standard would be much more behind-the-scenes than the 360 giving standard is. In a way we've [at Beehive] already implemented this standard - it's based heavily on the kind of fields we need to collect for Beehive.

I've been thinking about a number of different ways of collecting funder information for Beehive, and I see a standard like this as providing a framework for managing data between those different data collection methods. The methods I have in mind are:

1. Gathering the data by hand (our current [and only] method)
2. Crowdsourcing the data
3. Getting funders to provide it themselves - with the tools to help them do it (eg a nice form)
4. Inferring from published funding data like 360 giving data

[morchickit]

@drkane - to move this to the forum :-)

[BobHarper1]

Forum discussion here https://forum.threesixtygiving.org/t/extending-grantprogramme/40

[stevage]

Btw just one additional comment regarding the "standalone specification" question. I think it would make a lot of sense to break down "the 360Giving Standard" into smaller pieces that are independently usable, but obviously link together. So for instance:

• "360Giving Grants"
• "360Giving Organizations"
• "360Giving Funding Programmes"

As this spec is written atm, it suggests that the funded grants should be included within the Programmes data, which doesn't seem right to me. Instead, there could either be:

• just be an identifier (assuming the consumer of the programmes data knows where to get grants data from, and can link the two using this ID)
• an ID and a URL pointing to grants data (and, possibly, a keyword indicating the format of that data, if it's in some other standard, for instance...)

An example of this kind of thing is Mapbox's style spec's sources element, which can contain a URL which points to a data source conforming to one of their other standards, TileJSON.

[drkane]

@stevage - very good point, we'd need to think carefully about how the standards would interact with each other.

My thinking behind including the grants within programmes was additional to, not instead of the "main" grants data that is published. The idea would be that you could publish a full historic record of a particular programme, including the grants made. You could also publish examples of typical grants - this is someting we do on beehive. But it would be optional, and we'd need to think about potential usage to make sure it's clear.

[morchickit]

This is now in the forum, so closing it here. https://forum.threesixtygiving.org/t/extending-grantprogramme/40

[stevieflow]

I've also removed this from being tagged against version 1