Should this API be used for traineeships?

[jiripetrzelka]

The current specification only allows to respond with the element student-mobility-for-studies, even though the omobilities API also allows the activity-type student-traineeships. Does this mean that implementers of this API must not include data relevant to traineeship nominations received from partner?

[kamil-olszewski-uw]

Ougoing Mobilities APi and Incoming Mobilities API are currently only adapted to transmit study-related mobility data. In fact, you could arrange with your partner to send data about student traineeships this way, but both of your systems would have to be ready for it. Especially in the case of Incoming Mobilities API, data would be sent inside the "student-mobility-for-studies" element (because there is no other, as you noticed). And it would be impossible to send any data specific only to traineeships. This will change in the future.

[jiripetrzelka]

So what you propose is that I, as a developer, should have individual arrangements with other mobility software providers regarding the question whether we will put status of traineeship mobilities into the student-mobility-for-studies element? I don't think this is feasible. I need to have a clear specification which either says that I am expected to use this element for all applicable traineeship mobilities or for none. IROs can, of course, later decide whether the status of a traineeship mobility will have any relevance for them or whether they will still require a Traineeship Certificate. But as a developer, I am implementing according to the EWP specification, not according to deals with other providers.

So I am expected to put traineeship mobility status information into student-mobility-for-studies and is the other party expected to look into this element for information regarding traineeship mobility?

[janinamincer-daszkiewicz]

@pleys we need instructions from BPOs.

[umesh-qs]

I am not sure how @pleys will help here. Even if he says that we should allow traineeships, API specs will have to be changed. And that will take time.

Hence the immediate solution is to mention in the specification that the API is not designed to be used traineeships and DG EAC does not recommend using it for this purpose.

[kamil-olszewski-uw]

Both API (Outgoing/Incoming Mobilities) have such mention in specification in "Summary" sections of main readme files.

[jiripetrzelka]

@kamil-olszewski-uw You mean this?

Currently, this API describes mobilities of one type only - Student Mobilities for Studies. More types MAY be added in the future.

I see this sentence. But in case outgoing mobilities, it is inconsistent with the fact that the specification introduced the activity-type element. In my opinion, this element should not have been introduced if a proper analysis for the traineeship process has not been done and corresponding APIs (Factsheet, imobilities) are not ready yet.

So what tests are we supposed to run with partners in DEV who want to prepare workflows for nominations? Both SMS and SMP and in case of SMP implement just the omobilities part and ignore the imobilities part or should we test just SMS and ignore SMP? I need some definition of the successful end state that will enable me to request access to PROD with nominations.

[janinamincer-daszkiewicz]

I will ask @pleys and DG EAC for the official statement.

[jiripetrzelka]

@janinamincer-daszkiewicz Can you please shed a bit more light on the process which led to the decision to keep the nominations for traineeships in the MBR and the specification?

As far as I know, the User Surveys concerned only nominations for student mobility for studies. The MBR do not describe any specifics about the current nomination process for traineeships in section 3 or anywhere else in the document. I have not heard any mention of traineeship nominations in any of the Erasmus Goes Digital webinars. My IRO tells me that it almost never happened to them that the receiving institution would require a nomination for traineeships. Who requested this then?

I am not saying that providing data about traineeships through EWP cannot be of some use to some HEIs but I am very perplexed about the overall process. Every step in the analysis and communication process during the recent year would suggest that traineeships are not on the agenda but the result is quite the opposite and largely hidden.

What I miss is, for example, the information whether this feature is supposed to be in the EWP just to cater for the needs of these few universities that require the nomination, or if this is a general shift and the nominations of traineeships will gradually become a requirement for all mobilities in case the receiving party is an ECHE holder.

[janinamincer-daszkiewicz]

@janinamincer-daszkiewicz Can you please shed a bit more light on the process which led to the decision to keep the nominations for traineeships in the MBR and the specification?

I was not participating in these discussions. I have asked RMs for clarification.

[demilatof]

As I asked here

What mobility type could we manage? I see that in the omobilities it will be removed from the README this part:

Currently, this API describes mobilities of one type only - Student Mobilities for Studies. More types MAY be added in the future

whilst in the README for imobilities it is still presente.

And I see that in the get-response.xsd we have as MobilityActivityType both "student-studies" and "student-traineeships".

BUT

in the imobilities get-response.xsd we have only a student-studies element, without any student-traineeships

https://github.com/erasmus-without-paper/ewp-specs-api-imobilities/blob/3ad009c8245ef83fdeb3c37773ecb25f50a0bebb/endpoints/get-response.xsd

Doing so we could nominate students for traineeship, but we cannot have any feedback about the nominations for traineeship by means of the imobility API.

[janinamincer-daszkiewicz]

Answer from DG EAC shared 18.06.2024

Following an internal consultation with the programme team, RMs and our IT team we see that including the traineeship value in the API is of limited benefit and poses significant risks of confusion. Since the BPO-SEG did not explicitly request this,  we kindly ask you to remove this option. This will be resulting in MBR version 2.

@mkurzydlowski, please prepare changes in the specifications.

[demilatof]

I don't know whether to laugh or cry

[skishk]

Following an internal consultation with the programme team, RMs and our IT team we see that including the traineeship value in the API is of limited benefit and poses significant risks of confusion. Since the BPO-SEG did not explicitly request this,  we kindly ask you to remove this option. This will be resulting in MBR version 2.

so are you going to remove this one too? https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/a151f579ba2278dfbb99d19f40cff18212425e1d/endpoints/get-response.xsd#L210

[janinamincer-daszkiewicz]

We will not be touching IIAs.

[skishk]

We will not be touching IIAs.

so some API are managing all kind of mobility and then we arrive in the middle of the process and we found that some kind of mobilities are not managed? :sweat_smile: how could be possible? so all that project only to manage half process?! :confounded: :disappointed:

[mkurzydlowski]

Please review the following changes: https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/pull/56/files/29736b93ee5532bcff8430872d6183bf09a49144..8b85d9b50631711abcd645364b24ac8f0d8526a6