How to tell if caller covers the receiving Hei of this mobility?

[GeniusJonathan]

Hi,

In https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/get.md in the permission section states:

• If the caller covers the receiving HEI of this mobility, then he MUST be allowed access to its learning agreement.

As the server how do we know if caller covers the receiving Hei of the mobility? When calling the /get endpoint the caller only passes the parameters sending_hei_id and the mobility_id's. So how do you know who the caller/requester is?

Can somebody please enlighten me? Thanks in advance

[jpbacelar]

No - we use GitHub for reporting issues, not for voting.

Meanwhile we have read your statements with interest - including the ones you removed, urging me to rejoin the discussion (so here I am) - and there are some obvious problems. Let’s start here:

1. You asked how decision making functions in EWP
2. I offered to take up the issue at our next meeting
3. Then you proceed to declare (and then delete) that we fail to follow due process, meaning you make your own assumptions about what those processes are.

Decision making process aside, you repeated several times that not enough discussion has taken place. Allow me to challenge that claim:

1. On the 19th of October we invited all providers (with an EWP MoU) to a meeting where Janina presented the specification changes in detail and where all participants were invited to put forward their feedback.
2. Further to that QS raised questions by email which we did follow up on (contrary to your claims). I believe you were the only party to do so.
3. On the 10th of February we again invited all providers to a meeting where participants were reminded about the planned changes and an account of the progress was shared.
4. On the 2nd of March we had another meeting where the final spec adjustments were presented. Colleagues were invited to flag possible critical issues within the week - all of the presented information was also available on our repositories, as is usually the case, and it’s important to note that at this point we are no longer discussing in which direction to take the changes but ascertaining they are implemented in a manner that everyone endorses. We did receive feedback from other providers, which we also engaged with (obviously).
5. At the March meeting mentioned above we also discussed the calendar for deploying the new API versions. The feedback we received entailed some delays but we proceeded as planned and started upgrading version numbers on March 11th.

It’s not serious to argue that after more than five months, three meetings, hundreds of emails and several rounds of feedback not enough room for discussion was afforded. Instead if feels as though the real issue is that you/MoveOn feel EWP cannot move forward unless MoveOn is in agreement – hence my question of whether MoveOn is ready to respect the opinion of the majority of the community, which objectively takes no issue with the proposed and discussed changes.

Some colleagues have already started implementing the changes we discussed together, and I would urge everyone in the community to do the same, to make sure deadlines are met and the implementations meet the needs and expectations of your users. This is it from our side on non-technical topics until we meet again.

[umesh-qs]

@jpbacelar You are acting so naive here. There are many API changes discussed and suggestions sought in GitHub. It is not for only reporting issues.

I have not deleted any comments. I might have edited some of them for more clarity. But that was done immediately. You might have felt that it was deleted and out of excitement jumped the gun. Please be assured, I always stick by what I write or say.

I am not sure if you are not able to get the reasoning or you are being led to not reason by people close to you. In both the case I believe your limited technical expertise is to blame. And hence I believe you or your team do not want to debate on technical aspects. So here I challenge you again for a technical debate on this.

As per MoveOn, process is not followed. Had there been any process, there would have been at least some people coming out in support if not "majority”. Not sure if there is any process. Please see https://github.com/erasmus-without-paper/general-issues/issues/36 And see the rules of accepting new API changes here https://github.com/erasmus-without-paper/ewp-specs-management/tree/v1.2.1 which is not followed.

Now coming to your challenge (I like challenges), on "not enough discussion has taken place", let me correct your narrative.

1. In meeting on 19th, QS asked what the benefits of new solution are. Only answer given by Janina, was that it will solve all the issues that are there in existing registry. No further details on how.
2. After the meeting QS raised objections via email. There were email exchanges on the objections. After Oct-29th you (your team) stopped responding without being able to justify the proposed changes. Can share the email here or directly to you if you wish.
3. Then the same change was proposed on Feb-10. I saw the recording. No discussion on this or on the points raised by QS. Only mentioned that Janina will implement it. Full stop. Here again Janina mentioned that not a single duplicate will be there after the new registry portal. So, what, she said this so many times before. But at least once, technically explain how?

What were you and your team were doing for 4 months? Why no one responded or discussed with QS, the issues raised? Why these issues pointed by QS, not presented before larger audience?

On this Feb-10 meeting, Girish from QS attended it. He is not a technical person. And there was no mention of any technical discussion in the agenda for the meeting. The call was for giving status updates. I believed you assumed that it was for technical discussion but forgot to mention in the agenda.

4. Meeting on March-02. QS was not invited. Janina is already aware. So, your 2nd March narrative flops, at least from QS perspective. Couldn’t find any recording to see if any points mentioned by QS came up for discussion in this meeting.

There have been cases in past where changes have been reverted even after implementation by almost everyone. And there will be cases in future as well when there is a realization that what was decided at one point doesn't make sense now. So, your argument that, some colleagues have started doesn't cut the ice, if the changes are not worth. And hence I mentioned to put it on hold until it is discussed.

The problem is that there are people in your team who don’t like to be proved wrong. Sooner you fix this better it is for you and this project.

[janinamincer-daszkiewicz]

list down the advantages of the new solution vs existing registry

It will be one of the topics for the incoming tech meeting on 2020-04-06.