Juanjo, Alex, Pier Garino, Lorant, Andreas, Torsten, Hans, Juan Bareno/ATOS Juanjo: -Summary from the AB meeting: 2 parts in the meeting. First - HLD presentations, all the chapters, split into 2 days. It took 5 hours the first day, 1 hour the second day. Second part: how to work with the notion of backlog. Important to share with WPL/WPA-s - we need to rollout in FI-WARE. Aspects related to the template were addressed for the backlog and about how we would run the process, what tools would be put in place and so on. -Number of notes with remarks, Thierry sent additional notes that we can review. Starting with Juanjo's. -In general terms the presentation was welcome. One of the positive comments was that people now understand better what we have offered to deliver and that concept of GE has become more clear to them because at the beginning this concept was very abstract, but now they really understand better what we mean by GE. -In general they are eager to know more details and understand better what we plan to deliver for each of the GE that we identified. We provided more details, because of that they want to know even more to really understand precisely what we are going to deliver, what interfaces we plan to support, to really evaluate how they could use the services we provide, what will be the impact of using our GE-s in their design. Juanjo explained that it needs to be refined over time but we cannot precise right now in all respects. But this is a positive thing that they want to know what interfaces we want to support. -One comment for the official delivery scheduled next week is that they believe that if we want to support a concrete standard interface/spec, we should clearly state that. There are a couple of examples: OMA in the pub/sub enabler - point was that this was not clearly stated. We have to review in general when we want to follow a given standard, if not already explicitly stated in the current description. -Additional general comment is that they feel like the document lookes like it has been developed by separate teams - missing cross references, terms that should be used more consistently across the document - sometimes similar terms in different chapters and not with the same meaning. Juanjo explained we are solving this right now. -Additional comment was that although we are complete in scope, there might be some gaps that may correspond to the needs they have - how are those gaps covered. Led to a discussion how to open the budget of the open calls. Juanjo told them that part of the budget will be used to cover gaps that were already identified (not all GE-s are enablers for which there is an asset), but there might be other gaps derived from the inputs from them. We explained that it is important that they provide the necessary input to identify those gaps. -As a complement to these comments all of them made a request to set up some tools to communicate with different chapter teams to ask questions and clarifications about docs, Juanjo wanted to discuss this because we need to agree on what we provide them as means for allowing them to ask and exchange information and answer questions they may have on the GE-s. -Juanjo takes a look at the minutes of Thierry, no generic points were mentioned there. Discussion on why OMA was chosen instead of other standard, Juanjo explained that we don't want to support multiple pub/sub mechanisms in the platform, we have to make our choices. Number of questions about particular GE-s - general comment to contact the teams to ask clarifications. For ASE there was discussion on what we mean by SLA management, this was clarified and explained that it has to do with the availability of the service, not what the application is doing in itself. -Lot of confusion at the beginning, they thought the part with the connected device interfaces is about IoT - they wondered why is it not there - these doubts were solved. -Question about reference to the TMF and FI-WARE position wrt that - we could not give a good answer. Should add in the document for the final delivery. -Security/trust/privacy: some of them explained that they found some gaps, elements they thought would be necessary to cover as a common GE across different domains, but they didn't find that. E.g. encryption in general and public key management. -What do we think could be the steps/instruments to set up communications and indeed is it a good idea - nice to have communication, but we have a risk that we receive a tsunami of clarification requests and answering these may become a lot of work. Juanjo: mailing list per chapter using the same ID for the mailing list and add a suffix. Could be put in place for the starting. Was discussed that we should have better tools - a task force was set up to come to the next AB meeting (end of August) with proposal for other social, collaborative tools to get in touch with other use case project. Management of innovation, forum - was proposed as one possibility. TID would like to take a look at tools like JCard useful for SW development, maybe useful for collaborative projects as well. In the meantime FI-WARE committed to put in place these means, concretely mailing lists. Alex: Excel spreadsheets to get them organized and keep track of them. Juanjo: it is important that for sure if someone makes a question and we provide an answer, we should keep a trace of that. We could put in place this mechanism in a way to generate this FAQ or spreadsheet mentioned could be a tool generating this. Alex: comments are useful for internal work on the doc. Keep record of the changes/responses - it could be Excel or more modern cooperation tools. Juanjo: how would it work with Excel? Columns with the questions and the answers? What format? Alex: templates that can be use for document reviews. Each row would represent a comment, question or request for clarification. Document the exact chapter, status of the question, the doc has been changed to address that and so on. Juanjo: 2 things - the format of what we aim to generate as a result - could be a table, useful to create the personally asked questions/content that we upload. Second aspect is how to monitor/follow-up the states of each comment and whether it has been addressed or not, how etc. Juanjo would favor using instead of spreadsheet a tracking system, there would be a workflow, producing the content uploaded as a contribution to the FAQ and change this in the document as well. Juanjo: DOW - we promised to put a tracking system to the external world/usage areas - boundary. Alex: agrees. Pier Garino: mailing list should be first answer. In favor of collaborative tools, forum's solution for instance - free to use. Managing them is difficult. So in favor of a tracking tool like bugzilla. Concern: we add overhead. Torsten: objects against mailing lists/tools. Should be based on tasks/activities. Interface between UA projects and us is that they provide user stories/requirements at the end, these are the main concepts that communicate. From our perspective it's the GE. Both of them are in the agile system that we are supposed to keep. Juanjo: 2 different interfaces - one has to do with the creation of backlog - will be elaborated later. Here we are working on a very concrete point raised by UA projects - I need clarification on what you mean by the concrete section of the HLD. Torsten: of course, there might be questions about the content. There could be a structure or we don't have that but have 1 person responsible. We don't need the interface between UA and FI-WARE too broad. Any questions could be attached to a GE, if this is available, we keep track of the backlog, we can create a new task for this element, the task solving a problem or a misunderstanding. Should do the collaboration as focused/concrete as possible. Alex: same system as we keep the stories? Juanjo: difficult to understand for him. It was agreed that we have to start working to set up the backlog for the different enablers in FI-WARE. UA projects understand they are capturing requirements from end users and they will map them to features they would like to see as features in FI-WARE - this we would handle in the backlog. Previous to that we should handle if they do not understand something. They may need the answers in order to provide an input, a request for a feature. Agrees that anything that has to do with asking for a feature and a GE should be handled through the backlog. Answering doubts, clarifying things is different. The resolution of that leads to FAQ corner maybe in the website. Doesn't need to need to a generation of an entry in the backlog. Agree on this? Maybe we should say: there are 2 mechanisms - clarification for things you don't understand in the doc - should lead to the development of FAQ, second channel is anything to do with asking features, through the backlog. Rejected if proposed to the first channel, limited to doubts, clarification. Could we agree with that approach? Andreas: does not understand the concept of answering questions - they should go to global technical activities, somebody who has an overview. If we answer p2p manner, we have exploding communication. Juanjo: for comments/questions we should provide to them only one mailing list? Andreas: not mailing list, system where it can be posted/commented/answered when people can take a look what were the questions before. Otherwise people will ask the same question several times. Juanjo: so in favor to a tracking system? Andreas: yes, and all answered questions to be made available to all people. Juanjo: then we have to agree then about the management of the incoming tickets - handled centralized, allocated to a WP team. Andreas: agrees Hans: fine with the last proposal ATOS: also agrees with this Juanjo: the tool we put in place would be a tracking system. We have to analyse them Torsten: we have forge Juanjo: yes, we can use that or activate other plugins not currently activated. Needs to doublecheck with people from infrastructure Lorant: proposes forge per techincal chapter Juanjo: no strong opinion on this Alex: it is important to know who is asking the question. If opened for the public later on? Juanjo: we should be able to identify the person, should not be an issue. Alex: easier for us if we receive many such questions to understand who is asking what and have few contact points with the UA projects Lorant: maybe just 1 per UA Juanjo: we have to decide tracking system per chapter or per whole. Alex: filter per specific WP? Juanjo: yes, so that we can categorize questions to go to a particular chapter. Later on the changing of this field instead of opening a ticket in another tracking system. Would go for one single tracking system with ability to filter tickets on chapters and to doublecheck that the tool we use supports this. This would be the starting option to explore. -Juanjo: before communicating with the UA projects, Juanjo will send an e-mail to us. Definition of the backlog and how to organize the work -Juanjo sent a template that was agreed for the backlog. Hopes it is more or less self explanatory. For the sake of the time Juanjo will not go through this in very detail. In general it has everything that would be needed to explain a feature that would be requested from a given enabler in FI-WARE. -Points that we need to take into account: -backlog would be used by some UA projects for managing the development of the use case applications, but not all UA projects will follow that path -everyone recognized there are 2 levels that we have to take into accound when embracing the backlog. In a first approach UA projects will interview end users, they would start identifying trends that are high level descriptions of areas they cover, epics that are topics they cover, up to user stories. These later are something concrete that a development could take an input to develop a given part of a use case application. They will follow this process this month, the user stories may generate are not in the format or the way that are useful for FI-WARE. They need to translate things into features they would require from FI-WARE that are meaningful for us. They realized finally that the exercise they have to do when they deal with a user story (end user) from their perspective they need to think how to implement that user story. When analyzing this, they may come with a given need that they have to submit to the FI-WARE path. There are 2 level of users - we have end users, meaningful for UA projects - these are the actors and the main characters in their user stories, but in the backlog the user is the app developer, that is the use case project. They have to generate entrance that is relevant for the platform as part of the process to find out how to solve a user story they might have identified. They will try to implement this. The backlog will have a mix of entries relevant for use case projects for which the notion of user will mean the end user, others will be users for the platform, that is the use case project. It was identified that there is a need to establish that certain field identifies what the user means for a particular entry. -in parallel we ourselves should be able to start filling up the backlog with features with entries for the GE-s that we idntified that we plan to address in the project. Regarding the backlog UA projects and FI-WARE will work in parallel streams therefore: use cases for the FI-WARE platform and us defining entries for the GE-s that we identified. -To start working, a tool will be put in place - Agilefant - Concord will set up this tool. Will make it available before July the 20th. We will start ourselves to work filling the entries corresponding to different chapters and GE-s. -A given UA project when discovering that for implementing a user story they need something from the platform, they may initially formulate an entry, but may not be able to assign this to a particular FI-WARE chapter, because they might not know where this will be address (they may also know). If don't know, we should discuss with them, determine how these entries will lead to either assignment to a chapter in FI-WARE or categorized to 'common enabler' but out of the scope of FI-WARE. This will mean negotiations with them. Is the model clear? -Alex: makes sense. Will there be education on the tool? -Juanjo: we need to set up the tool first (Concord), then some training would be setup, the tool is quite easy, should not be that difficult. -Alex: best practices, metodology - we should agree on -Juanjo: will be addressed during the coming weeks -Juanjo: another thing is about the distiction of the different levels of granularity that we would cover in the backlog. For this Juanjo plans to provide concrete definitions of what an epic, user story etc would be with some examples. Provided along with the accessibility to the tool. We should be able to start filling entries in the backlog -Lorant: no questions at this point -Juanjo: will send an e-mail on details, maybe it is better to write this down. -Pier Garino: guidelines to use the tools - even it takes time - is it possible to provide sort of video capturing the screen and highlighting the main items/actions to use the tool? -Juanjo: agilefant.org already provides this info, even a video, online demo where one can play with the tool. We are not going to use all the features of agilefant, just those ones with the management of backlog entries. -Pier Garino: if looks up the website, might learn in a cold start way, from scratch. If there is a preparation of short demo of what to use of the tool for our purpose only, this would be a warm start. Several partners in his partner were asking the same on forge - took some time to reply to all of them. There are tools capturing screenshots/video what you are doing, just to start doing that. -Juanjo: true, but we may say let's wait and do not start until we have this tutorial/manual and then we may become bottlenecked. Juanjo takes the point and maybe something should be produced what highlights what to use and what not to use. Such manual we should not wait to be perfect -Alex: training sessions were mentioned - could we record them so that other refers them later? -Juanjo: will check. Not sure what technology we could use, there might be some possibilities, point taken. -Hans: agrees with Pier Garino -Andreas: would like to see an example of the life cycle of the backlog -Juanjo: realistically, we could devote the second part of July to carry out the training, prepare the tutorials, additional documentation for the lifecycle of entries, transcoding of UA user stories to FI-WARE user stories, maybe before starting to create entries in a wild manner. -ATOS: no comments/questions -Juanjo: in the AB the way how agilefant will be used was discussed, we need to create docs for this. Some of the UA raised the issue that the planning that we had in place was very tough, they anticipated they may be late. AoB for AB: -No questions on the arch board Where we are: -IoT: will produce final version by end of the week. No input from security. Question marks are referring only to security, might add 1 or 2 points based on the received comments. -Juanjo: one generic comment - unique selling point section. It becomes (like ASE people recommended) "critical product attributes". Juanjo would like feed -IoT: agrees -Pier Garino/Hans: Juanjo - peer review with cloud hosting chapter, comments were received? A: shared with Juanjo and Alex end of last week concerning a point the cloud edge definition. Worked on a proposal to modify the text so that there are less conflicting between the 2 enablers from the 2 different chapters. More in general reviewed the content of cloud hosting, they are adding comments to the document, taking as a baseline the purpose to identify points difficult to understand by the readers. Purpose is to send it tomorrow to Alex for revision and decide whether to accept comments or not. -Juanjo: suggestion is to discuss on the weekly conf call on Friday during 15:30, go through them there. -Pier Garino: OoO for several weeks, agrees to discuss it with Alex. -Juanjo: recommends 15:30. Alex can't make it. Recommends that Juanjo and team synchronizes. -Juanjo: takes the call with them, go through most of the thing and understand the insight on the comment. Alex will work on Sunday. If any doubt, Alex will contact Juanjo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-wpa/attachments/20110714/6e320353/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy