[Fiware-wpl] IMPORTANT: Update on status and planning for coming weeks

[Juanjo Hierro]

  Following my email yesterday, just let you know that I have changed the name of the entries/placeholders in the contribs folders linked to your contribution.

  I would kindly ask you to go there and update the corresponding file linked to each entry so that it now follows the naming conventions that I explained in my email.

  Please, whenever you upload a new file, do so by going to the Admin menu, then navigating to your entry and then uploading the file in the field titled "OPTIONAL: upload new file" in the form.  So, please, don't create new entries, just upload a new file linked to the existing entry.

  Thanks and best regards,

-- Juanjo

On 13/06/11 19:16, Juanjo Hierro wrote:
Hi all,

  This is a message where I would like to inform you about overall status of the project and propose an update on our short-term planning.   I hope it will also be helpful in bringing a shared view of where we are and what we are doing that we can communicate consistently inside and outside our consortia.

  It's a long mail, but please read it carefully.   As always, comments and feedback is welcome.

  Cheers,

-- Juanjo


1. Introduction.  Some basic considerations.

  As you all know, we are currently focused in delivery of the FI-WARE High-level Description document.   This would be a sort of "Product vision" document in line with what the Agile methodology proposes.

  Notice that the true consolidated "Product Vision" document is the one we expect to deliver by end of month 5, i.e., end of September.   Once we get that "Product Vision" ready, we should start materializing our vision in subsequent Sprints (duration of our Sprints should be two months).     By end of month 5 we should also have a first release of our FI-WARE features backlog, made up of the features we have identified ourselves and plan to implement for each and every GE in FI-WARE.   We should be able to develop that backlog independently of the input by UC projects, I mean, we should have a plan/roadmap ready for each and every GE by end of month 5.

  What we are going to deliver in month 2 should be considered an early draft of this "Product Vision".   It's something that is helpful for starting the dialogue with the UC projects.  Kind of: "you know, this is an early description of what we are planning to deliver, your feedback is welcome".    But doesn't need to be a) complete, i.e., meaning there might be things we will declare "work under progress and expected to be finished by end of month 5"  nor b) as exhaustive as it will be by end of month 5.   Indeed, I want only to provide the description of GEs we are rather confident about in our release in month 2.   Anything that we don't considered yet closed should go to the "Question Marks" section (which I'm considering to retitle as "Question marks and work still under progress" or simply "Work still under progress").

  From month 2 until month 5, UC projects will be entitled to generate "request for inclusion" of features to our backlog.   We will see how many of these feature request will finally be accepted and how accepted features will be prioritized against the features we have already identified on our own.   Analysis and management of feature requests coming from UC projects is something we will carry out from month 5 to month 7.


2. Status of FI-WARE High-level Description ("Product Vision") deliverable in month 2.

  Our initial plan was to have a consolidated draft of each of the Architecture Chapters in the FI-WARE High-level Description document by mid June.   Then spend the two last weeks of June to perform some peer reviews and carry out final integration of the deliverable.

  I guess you agree we have to face that it would be rather tough to reach this milestone.   On the other hand, I feel like we have had very fruitful discussions in several of the WPs and we are getting more and more closer to a nice description of the GEs in each chapter.   So I see the bottle more "half full" than "half empty" :-)   Overall because definitively we have to spend the necessary time to agree in a "Product Vision" without feeling so much stressed (to certain extend :-) to milestones that were very tight and hard to achieve since the very beginning.

  Given said this, my proposal would be to delay this first internal integration milestone until June 22 (mid next week) unless I hear any objection from some of you.    Of course, we will have to make all what is in our hands to reach this new date.   I trust on you and I feel that if we keep things going the way they are going, we can meet the new deadline.

  Note that this delay is something I'm just sharing with you.   Feel free to manage this info the way you want with partners in your WP :-)   You can disclose it or not at your own criteria.   May be you wish to keep some pressure on some internal milestone you had setup, for example :-)

  From June 22 until June 30 we will try to make a complete integration of all contributions as to deliver a first consolidated draft of the document.    On June 22 I will come with a proposal on what precise tasks we will carry out during that period and how we are going to manage things, but I can anticipate that the following tasks will be included in the plan:

 *   We will plan peer reviews of those chapters we may consider closer to a final version.   Concrete partners will be assigned this task.
 *   We will setup a number of task forces, typically one per WP, to analyze security issues with regard to each WP.   The task force corresponding to a given WP would involve people from that WP and people from the Security WP.

  By June 30 we will perform an assessment about where we are.   If we have something final, that would be great and we will officially deliver it to both the UC projects and the EC.   If we have something that is still a draft but might be worth disclosing to the UC projects under a notice that it is still a draft, we will announce an official delay to the EC for July 18 but we will disclose the existing draft (with the mentioned notice) to both the UC projects and the EC.


3. Some administrative/management details.

  We will keep the docman system as the way to share versions of the different contributions as well as consolidated releases of the final deliverable at least until June 22.   I want to let you know that we already have SVN (Subversion) available in FusionForge, but I guess it doesn't make sense to migrate right now but keep going until we get this first deliverable finished.    Later, we may migrate to SVN.

  We will keep sharing the contributions in the contribs folder linked to deliverable D.2.2 in the docman system under the FI-WARE project in FusionForge.   However, I will today change the name of the entries in that folder to get something harmonized.    From then on, I expect that all new releases of a given contrib will be uploaded under the assigned entry.  This should be done by going to the Admin interface, then navigating to the entry in question and updating the file assigned to the entry.   You should then assign a name to your contributed file which follows the following name convention:

  "FI-WARE High-level Desc <chapter-name> v<major>.<minor> <date in US format when doc is released> valid until <date in US format when doc will again be blocked for editing a new version>.doc"

 where:

 *   <chapter-name> is a name from the following list:
    *   "Apps" (WP3)
    *   "Cloud" (WP4)
    *   "IoT" (WP5)
    *   "Data" (WP6)
    *   "I2ND" (WP7)
    *   "Security" (WP8)
 *   v<major>.<minor> is the numbering of the version you assign to your contribution (e.g., v1.0 or v5.3)
 *   <date in US format when doc is relased> is the date in which you have closed the edition of the file: (e.g., June 20, 2011 would be "11-06-20").
 *   <date in US format when doc will again be blocked for editing a new version> is the date at which you plan to download the document again and you plan to start editing it again.   If not specified, we will assume you expect to download a new release for editing "the next day (tomorrow) at 09:00am".

  (note: major and minor numbers are not reset when you change the date of a release.   They should be absolute.)

  As an example, you may upload "FI-WARE High-level Desc Cloud v3.2 11-06-18 valid until 11-06-20.doc"

  That file would mean that it is v3.2 of your chapter, released on June 18, 2011.  It will also mean that you don't plan to resume editing of it until June 20, 2011.

  As explained in a previous mail, you should upload new releases of the document (if you have some) no later than 19:00 and, PLEASE, if you have introduced some change in the document, no matter how minor they are, you should update the document in the server at 19:00 and do not touch it until 09:00am the following day.    Besides, you should always download the version that is on the server whenever you plan to start editing your chapter.   Please declare a <date in US format when doc will again be blocked for editing a new version> if you rather don't plan to edit the document the day after.   This would allow Thomas and me to have more time to review it, not just during nights :-)










________________________________
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/20110614/3d157368/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: text/x-vcard
Size: 429 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110614/3d157368/attachment.vcf>