Closed janinamincer-daszkiewicz closed 1 year ago
It depends on what exactly we want to report. If we want to know about the number of all signed and valid LAs, we should skip the point "the last existing version of LA is approved". If we want to know the number of all signed LAs, for which there is no need to perform any additional actions (i.e. they do not have any modification proposals awaiting approval of the receiving university), then this point should be taken into account.
Please, have a look at this proposal. Can you calculate such statistics in your system? Is this clear for you what the statistics means on the business level?
Do you see any other interesting statistics concerning LAs we might want to have?
Our proposal for today is the following (we will discuss it on 2022-06-22 at the Infrastructure Forum meeting):
LAs for outgoing:
LAs for incoming:
Is this more clear now?
The latest description:
LAs for outgoing (sending HEI):
LAs for incoming (receiving HEI):
LAs for outgoing: How to translate 'awaiting receiving HEI's approval'? Is this including or exclusing LA's where the latest version got a comment-proposal from the receiving HEI?
It means that we wait for the answer. If we have got the answer (acceptance or rejection) we do not wait. The ball is now on our side. Do you think it is better to reformulate to make it more clear?
So I could translate points 1 and 2 for outgoing LA to: 1 = there is at least one approved version AND
2 = there is at least one approved version AND this version is followed by at least one version for which sending HEI received an approval or not receive any evaluation.
Questions: For 1: LA's where the latest version is evaluated with a comment by the receiving HEI are excluded from the statistics. For 2: LA's where the approved version is only followed by versions where the receiving HEI provided comments are excluded. Could you explain the business logic behind this choice please?
I understand your point. For outgoing we do not count rejected LAs. On the contrary for incoming we count them. This is not consistent. From the business perspective may be the most interesting is how many LAs which have once been approved do not need further processing or the final state of LAs. So may be this is what IROs would like to have?
LAs for outgoing (sending HEI):
Does it make sense?
Statistics where discussed at BPO meeting on 12/07. Some feedback:
Good idea. The latest description:
LAs for outgoing (sending HEI), all statistics grouped and ordered by the academic year
LAs for incoming (receiving HEI), all statistics grouped and ordered by the academic year
In case that helps to get some idea, this is how we do it. In the admission system in which we handle LAs for incoming, cycles must be taken from XML, because we do not keep them in a separate column.
-- 1. Number of LAs for incoming. SELECT COUNT(la.id), (xpath('//n:receiving-academic-year-id/text()', la.content::XML, ARRAY[ARRAY['n', 'https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/get-response.xsd']]))[1]::TEXT academic_year FROM irk_learningagreement la WHERE (la.id IN ( SELECT DISTINCT ON (la2.sending_hei_id, la2.omobility_id) la2.id FROM irk_learningagreement la2 ORDER BY la2.sending_hei_id ASC, la2.omobility_id ASC)) GROUP BY academic_year ORDER BY academic_year;
I have a question for this section: "5- Number of LAs incoming with the latest version awaiting receiving HEI’s approval" Some of the LAs are waiting because after receiving a CNR we cannot properly GET the LA due to technical reasons from the student's university. Should I include those LAs in this number?
Some of the LAs are waiting because after receiving a CNR we cannot properly GET the LA due to technical reasons from the student's university. Should I include those LAs in this number?
I think so, you do not have the approval in your system yet. Does this situation persist? Have you contacted your partner? Do you need assistance in getting in touch?
Some of the LAs are waiting because after receiving a CNR we cannot properly GET the LA due to technical reasons from the student's university. Should I include those LAs in this number?
I think so, you do not have the approval in your system yet. Does this situation persist? Have you contacted your partner? Do you need assistance in getting in touch?
Yes, we have contacted and sometimes there is no response. Other times, we get inquiries from people who are not IT people and it is very difficult to make them understand what is happening and what we need. I would like to say that EWP is consuming a lot of resources after we have implemented it, having to contact each of the partners to solve the problems. It's not being easy at all.
Yes, we have contacted and sometimes there is no response. Other times, we get inquiries from people who are not IT people and it is very difficult to make them understand what is happening and what we need.
There will be relationship managers hired in the project who will help us to resolve such issues faster.
I would like to say that EWP is consuming a lot of resources after we have implemented it, having to contact each of the partners to solve the problems. It's not being easy at all.
The same is true for every deployed IT system. This particular system is deployed on a very large scale. It takes time, yes, but I am optimistic.
Formal specification is discussed in https://github.com/erasmus-without-paper/general-issues/issues/42.
I have a problem with the statistics of LA. For example, this month I have less OUT LA than the previous month depending on the criteria I take into consideration. This is due to the fact that the LA, although a CNR has already been sent to be signed through EWP and at the time was accounted for as a new LA, has been reconverted to traditional for technical reasons attributable to the other partner and has not been able to be resolved. So, if I count the CNR that I sent as an agreement because it is consistent with what I already sent the previous month, this agreement, once converted to traditional, will never have an approval through EWP. I don't know if I'm explaining myself.
On the other hand, we have many IN LA that have been initially approved but many universities are not prepared to negotiate the modifications with EWP, which in addition to causing us many problems, can distort the statistics.
And finally, what to do with the LA of the students who resign?
The statistics we collect are primarily intended to take into account the workload incurred by both parties, network traffic, etc. and not the final state as such (e.g. we don't want to report the current number of approved LAs for non-canceled mobilities only).
If the student resigns, but the LA has been previously signed by all parties, then we should include it in the statistics.
If the first version of LA has been rejected and no new proposal has been created, LA should also be included in the statistics.
But if the first version of LA was shared via EWP and then deleted without receiving partner's approval or rejection, then it should not be included in the statistics because the receiving HEI was unable to make a decision about that LA.
LAs Outgoing Stats endpoint: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/stats.md. LAs Incoming Stats endpoint: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-la-cnr/blob/stable-v1/endpoints/stats.md.
During the Infrastructure Forum meeting today we discussed the possibility to gather the following data from each HEI in the EWP Network:
From the sending HEI, those LAs for outgoing students which meet the conditions:
Do you agree that this statistics will properly show the picture of system in operation and activity of local IRO staff? Could you. please, check if this description is clear and you can easily gather such data?
Could you share this statistics with EWP tech team? As yet unofficially, we will not yet share it with anybody outside the team.
After we gather some opinions we will ask DG EAC for their opinion and their ideas how we will be gathering such (similar) data in the future.