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

Conditions #29

Open
andylolz opened this issue Mar 27, 2017 · 13 comments
Open

Conditions #29

andylolz opened this issue Mar 27, 2017 · 13 comments

Comments

@andylolz
Copy link
Contributor

andylolz commented Mar 27, 2017

Description

The terms and conditions of the activity may also be referred to as benchmarks, priors, or involve words such as “subject to…”. They are specific to an individual activity and explain what the recipient must do in order to be eligible for the funds to be released.

This is only expected if the activity is in the implementation, completion or post-completion phase.

Proposed test

Firstly:

For each current activity,
if `activity-status/@code` is one of (2, 3, 4)
then `conditions` should be present

Secondly:

if `activity-status/@code` is one of (2, 3, 4)
then `document-link/category[@code="A04"]` should be present
@breidertmt
Copy link

What happens if there are no conditions, and therefore no A04 document?

@andylolz
Copy link
Contributor Author

andylolz commented Apr 3, 2017

Interesting – that’s a very good point. (As described above, relevant activities without an A04 document link would fail the second test, regardless of the contents of the conditions element.)

What do you suggest?

@breidertmt
Copy link

IF there are no conditions, I do not think organizations should be penalized. The overwhelming majority of our assistance does NOT have conditions. This test in its current form would penalize organizations for not having conditions which is a business model issue not a transparency issue. I recommend this test only apply if conditions are actually present, not if conditions are populated w/ a no.

@andylolz
Copy link
Contributor Author

andylolz commented Apr 7, 2017

Thanks for this, @breidertmt. We’re in agreement on this, and will look at reviewing the second test accordingly.

@abdulriza
Copy link

This was discussed in previous year assessments and agreed that only activities which have conditions will be subject to A04 documents. Therefore, I guess the proposed test should be;

Firstly:

For each current activity,
i​f activity-status/@code i​s one of (2, 3, 4)
then conditions should be present

Secondly:

i​f activity-status/@code i​s one of (2, 3, 4)
and conditions attached="1"
then document-link/category[@code="A04"] should be present

@YohannaLoucheur
Copy link

All activities have conditions, usually stated in the contract/agreement. Recipients never receive funding without committing to doing something.

That being said, the actual value (to data users) of this information is very unclear. We continue to advocate for the removal of this indicator from the Index.

@agnessurry
Copy link

If there are no conditions, organizations should not be penalized.

@francescafo
Copy link

We (European Commission - DG NEAR) support this. Absence of conditions should not be penalised.

@YohannaLoucheur
Copy link

There are always conditions. The EC does not give out money without any requirements for the recipient to do anything.

When you say that there are no conditions, how do you define conditions? I think that's the issue.

@AndieVaughn
Copy link

We echo Meagan’s point that if there are no conditions you should not be penalized for not having a document.

Is this a change from the previous methodology? For example, is there going to be a manual quality assessment of this field? Previously, USAID was penalized for not having adequate titles and descriptions for the sampled conditions so scored 0 – is this field still dependent on other fields?

@ToonVB
Copy link

ToonVB commented Apr 13, 2017

Echoing @YohannaLoucheur , of course there are always conditions, however, we've always understood the term conditions (in this context that is) as conditions to be fulfilled by the partnercountry (f.i. regarding human rights), not by the implementer, who is bound to implement the project as described in the project documentation.
In the case of BE, there are practically no activities with conditions attached.

@andylolz
Copy link
Contributor Author

Thanks for the comments here.

We intend to modify the second test in line with the suggestions of @breidertmt, @abdulriza, @agnessurry, @francescafo – i.e. exclude activities where conditions are not present.

@YohannaLoucheur
Copy link

This is a departure from the standard, and contradicts the description.

Of course, the incentive will now be for all publishers to stop reporting conditions altogether.

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

8 participants