[Fiware-wpl] Summary of conversation with Arian

[Juanjo Hierro]

Hi all,

  As I have told you, I have a long confcall with Arian where I addressed a number of topics.   Here you find a summary of the main points addressed.    I have already commented several of them during our joint WPLs/WPAs confcall but I guess it didn't hurt to keep them here since they I have them as part of my notes.

  I would like to raise your attention regarding point 6 which has to do with rejection of costs for the 1st year.   Point 7 about the third Open Call may be of interest to some of you as well.

  Don't hesitate to ask, if you have any question.   Any feedback is also welcome.

  Best regards,

-- Juanjo


1. About checkpoint 1 - "Whitepaper including common usage scenarios for the GEs for wide dissemination (Use Case Projects and Third parties)"

  I explained Arian that our proposal was that this whitepaper replaces the FI-WARE Product Vision document (which is available on the public wiki and one of the things many visitors most probably try to read) and should be based on keeping the Overview, Terms and Definitions and Reference sections, then adding sections on usage scenarios.

  As an example of scenarios I provided the following to him

  *   "Developing context-aware applications" within the Data/Context Management chapter, which would elaborate on how several of the GEs in the Data/Context Management chapter can be used to create a smart context-aware application, with some case example
  *   "Supporting an Open Data approach" also within the Data/Context Management chapter, which would elaborate on how to support an Open Data approach, particularly applicable to SMART cities, using GEs in the chapter but also establishing links to the Apps Chapter
  *   "Supporting Crowd-sourcing" which would elaborate on how to use some of the GEs in the Apps Chapter to support crowd-sourcing of applications.
  *   "Identity Management and controlled access to APIs" which would elaborate on how to use some of the GEs in the Security Chapter to support controlled access to APIs exported by FI-WARE GEs or registered applications by client applications on behalf of authenticated users
  *   "Setting up the virtual computing infrastructure to host applications", which would elaborate on the steps followed by application providers to deploy applications on a Cloud based on FI-WARE Cloud Hosting GEs, and what happens "behind the scenes" executed by FI-WARE Cloud Hosting GEs


  He confirmed that these usage scenario descriptions are the kind of usage scenarios that they expected would be covered in the proposed whitepaper and he confirmed the approach was ok for him.   He didn't see any issue dropping contents from the current FI-WARE Product Vision despite this was one formal deliverable.   It was accepted as it was, so what we do with it afterwards, is up to us.

2. Resubmission of specifications

   I explained to Arian that FI-WARE deliverables were structured in a manner that would allow sharing information with Use Case projects as soon as it was available, without waiting for having all the details fixed.   The complete Open Specification of a given FI-WARE GE comprises, following some best practices of existing standards, a table of contents like the following (aligned with what we stated in the DoW):


  1.  Overview
     *   Introduction
     *    Usage Example scenarios
  2.  Basic Concepts (this may include a description of the underlying conceptual model)
  3.  Main interactions
(here, a description of the external behavior exposed by the GE will be provided and this would be essentially covered by explaining how interactions with the GE, through the APIs it will support, are expected to work)
  4.  Basic Design Principles (this includes, among other, non-functional features any valid implementation should support)
  5.  Detailed Open API specifications
  6.  Glossary of terms and definitions
  7.  References

   Points 1-5 as well as point 7 were provided as soon as possible making it part of the FI-WARE Architecture deliverable.  This way, we could share with UC projects part of the specifications as soon as possible, without waiting for the finalization of the detailed API specifications.    Therefore, when we delivered the FI-WARE GE Open Specifications deliverable we just submitted the Detailed Open API Specifications part.   I explained to him that this may have been misunderstood because we didn't explain this very well when the deliverable was submitted.    Arian explained to me that he had double-checked with reviewers whether they took into consideration contents of the Architecture Description of GEs while evaluating the Open Specifications deliverable and they confirmed they did.

  Anyways, he agreed that it would be preferable to submit the complete specification of each GE now that we have to resubmit the FI-WARE GE Open Specifications so that he was fine with the approach we have decided to adopt that implies re-structuring the wiki to ease generation of the complete specs of each GE.

3. Submitters to the 2nd and third Open Call

  This was one question that may not be of so much interest to FI-WARE partners.   I just need to confirm whether submitters that were selected in the 1st Open Call could submit a proposal to the 2nd Open Call.   Arian confirmed they can't (this, we already know, also applies to the original FI-WARE partners).


4. Date at which consortia selected through the 1st Open Call can start in the project.

  I wanted to ask whether there was any restriction/rule to apply regarding the date at which new partners, selected as a result of the 1st Open Call, may join.   Concretelly, whether that date could be earlier than the date of the approval of the amendment of the DoW where the new partners appear.   Arian told us we could agree on whatever date is more suitable, provided it is first of a month but it actually can be earlier than the date of approval of the amendment of the DoW.

  For your info, we most probably will agree with IBTT (selected for the BM&BE topic) beginning of November while will agree with KYARA (selected for the middleware topic) beginning of October.


5. What to do with the MAC (Market Advisory Council) and SC (Scientific Committee)

  We haven't started the MAC and SC yet.   The first because we wonder whether we should reconsider their creation at the light of recent discussions dealing with a new governance structure for the FI-PPP.   The second because we wonder what sense it has to have it when we have the FI-PPP Advisory Council that is plenty of high-qualified scientists.

  I told Arian that we were wondering whether we may cancel at least the SC which clearly overlaps with the FI-PPP Advisory Council.

  Arian agreed with that decision so we will capture it in the amendment we are closing.   Regarding the MAC, we agreed to keep it still in the amendment and decide after the next project review.


6. Rejection of costs as reported in the 1st year project review report.

  The first year review report included the rejection of a % of the justified costs.   However, I explained that we were wondering how the actual number of PMs to be rejected will be calculated.   Particularly, with respect to rejection of 50% of the costs associated to the Open Specifications deliverable because assignment of PMs to deliverables in WP3-WP8 is unclear in the DoW or NEF.    He said that he had estimated that effort in development of the Open Specifications was 50% of the total effort at least during the 1st year of the project (he agrees it could become less as the project evolves).    He also said that he made that estimation based on responses I gave during the review.   I told him that I could never have told him that development of Open Specifications was 50% of the costs and remind him the mail send on July 19th where I share with him how efforts in WP3-WP8 were assumed to be distributed among the different deliverables (this, as you may remember was a distribution we applied for applying rejection of cost reports internally):

  *       Contributions to WP2 deliverables: 10%
  *       FI-WARE Open Specifications: 20%
  *       SW Release: 40%
  *       Installation and Admin Guides: 7,5%
  *       Users' and Programmers' Guides: 7,5%
  *       Unit Testing Plan and Report: 15%

  Therefore, I kindly ask him to reconsider such calculation, overall considering that rejecting 50% of the reported costs was, per se, already though (I told him I don't believe that our specs are half the way to an acceptable specification).   I wonder whether he will do so.  I'm scheptical about his response, unfortunately.

  Arian told me that rest of the costs in WP3-WP8 would be temporarily rejected because the deliverables related to the SW release and related documentation (guides and unit testing plans) hadn't been submitted before the review.   This is something somehow expected.   I understood that they will accept or reject costs related to this deliverables during our next review, so we should be all aware that the next review will have impact in this respect.


7. 3rd Open Call

  We have a short discussion regarding scope and topics for the 3rd Open Call.   Arian rather believes that we shouldn't take any decision before results of the next review and even until we have analyzed, looking at the proposals of selected proposals, what projects in the 2 phase of the FI-PPP will demand.   They are also considering asking to use part of it to fund partners that may help to promote FI-WARE in the wider community of developers.    They will send an official letter stating their position in this respect.


8. State of the art analysis deliverable.

  I asked for dropping this deliverable.   I explained that I believe we shouldn't spend too much effort doing things than others with whom we want to compare are not doing nor will do (e.g., Apache or OpenStack open source communities, or even someone like Amazon or Google).   Are they producing anything that may compare to a deliverable like this ?   Of course, I explained that I understand that we need to do some kind of "benchmarking" against what others are doing but this is something that may fit within the Exploitation deliverables.   In any case, there were quite more urgent/crucial things to solve at this point.

  Arian agreed to drop the first release of this deliverable.   He thought that it might be worth keeping the rest because, among other things, would help to complete the Analysis of the Art part of any proposal to the Technology Foundation continuation project in phase 3.


9. Withdrawn of some partners

  Here I mostly reported Arian about the withdrawal of NSN-Hungary and that we hadn't found a replacement yet.   Not much to say here.



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20121010/3d14df76/attachment.html>