24th May 2017, WebEx - meeting minutes
- Option 1 versus Option 4 - cost-benefit analysis
- The related action on GitHub is: Action-SC-2017-23
- PR - So we’re continuing with agenda item 1. Would GT please tell us where we’re at with consolidating the feedback on the requirements spreadsheet.
- GT - So after I have all the feedback, I will:
- If more than one version is suggested by a single respondent, I will take the minimum, otherwise I will keep all the requirements where everyone has agreed the version, as they are.
- Add new columns and highlighting to show where there are differences in the versions proposed.
- Publish the consolidated spreadsheet and request more feedback on how to resolve the differences.
- SO - MG has provided our feedback, along with a description of our ideas on how the different versions might develop the architecture.
- BS - We are about 50% of the way through. We expect to finish in about 2 weeks.
- PR - That would be too late, since the SC meeting is scheduled for June 6th.
- BS - Ok, we will try to do it next week.
- PR - Perhaps you could send what you have already, half done, to George now?
- BS - Yes, ok.
- SO - Our approach was to view version 1 as the MVP, with updates based on feedback to get version 2 and version 3; version 3 being the first operational version of the modular approach.
- SO - There were a couple of things LM brought up:
- We might not be able to get to a cut-and-dried recommendation of Option 1 vs Option 4 for the SC.
- We might also want to make a recommendation to the SC on the development approach. I see 4 options here:
- European Dynamics do all the development.
- European Dynamics start the development and hand over to the Association for further development to completion.
- The Association do all the development.
- A hybrid where European Dynamics and the Association work together in some way.
- PR - European Dynamics don’t have enough effort committed to the project to do it alone, and anyway we should be working in an agile way, with, say, LM doing some development, someone else doing some testing, someone else refining requirements as we go etc. Various skills are needed.
- SO - Ok, that sounds sensible.
- NM - We can implement some ideas initially and then work with the Association from there.
- LM - Ok, I agree it would be the hybrid approach.
- MC - European Dynamics will do a proof of concept?
- PR - More than that, they would develop a platform upon which we all build the rest of the application.
- BS - The new functions are not decided. European Dynamics implement a new architecture, then we decide who implements what; as a pilot?
- PR - Not really a pilot; a basis for incremental, modular development.
- WQ - I have the same question as SO: we had a discussion on what approach we will take on development of the new architecture. TC to discuss because there are resource issues. Then we raise who does what with the SC. There are several options.
- SO - I’d like to hear each person’s preferred approach.
- LM - I suggest the hybrid approach; European Dynamics design/build the architecture then the Association help with further development.
- PR - Yes, there would be a continuous dialog even while European Dynamics are building the architecture.
- SO - Once it is determined what the architecture is and which apps will be used, we could hold a Developer Conference.
- PR - The Association and European Dynamics would work together in agile teams, as we have discussed before.
- WQ - Yes, we have discussed this approach ourselves; that seems viable.
- MC - We have concerns about the resources needed because that is not clear.
- BS - Are we sure all WIS 1.0 requirements are needed for WIS 2.0? We don’t want to spend more time on WIS 1.0.
- PR - So, your question is: how much WIS 1.0 do we really need?
- BS - And is it a little bit early to start a WIS 2.0 prototype?
- SO - If we consider it a minimum viable product for a modular WIS 1.0, we could fold some WIS 2.0 ideas into it, to demonstrate that the architecture is adaptable to WIS 2.0.
- PR - Which is why we have the three versions. Version 1 gets us going with the modular architecture; versions 2 and 3 might include WIS 2.0 features if we’re already getting an idea of what those are. In any case, we want to influence the WIS 2.0 specifications by showing what is possible.
- PN - Certain core APIs will definitely be needed.
- DW - Ok, but we don’t know what we will need to build yet.
- PN - We do in terms of some of the top level User Stories. Do we prioritize Discovery or Retrieval, in the cloud?
- WQ - In Toulouse we assumed that some of WIS 1.0 would still be needed. At a minimum we still need to serve WWW data; this is a major User Story whatever APIs we use to exchange the data.
- PN - It’s interesting that you have chosen data exchange as a key User Story; at UKMO we are still intending to use MSS to do the actual data exchange.
- WQ - The spec says you have to exchange metadata and data, it doesn’t say how you do it. Some WIS 1.0 User Stories are still valid in WIS 2.0.
- LM - I’d go further and say that pretty much all of WIS 1.0 will be required.
- PR - I agree, we’re talking about a transition over time from WIS 1.0 to WIS 2.0 eventually.
- LM - We need to consider what the next version is now that we have abandoned OpenWIS4. Given that a redesign is needed for WIS 2.0, then having a modular architecture would be a reason for version 5.
- SO - Do we need a deadline for return of the spreadsheet?
- PR - So shall we hold another TC next week?
- GT - I will need to have received the spreadsheets a couple of days before the TC to consolidate them and send out the version for the meeting.
- PR - Ok, so we could hold the TC next Thursday.
- BS - So Tuesday evening?
- GT - Ok.
- BS - Ok, we will try.
- SO - So how will you capture the differences, GT?
- GT - I will add new columns and highlight the differences.
- SO - Be good if you could summarise the level of differences.
- GT - Ok.
- SO - So do you need us to explain our approach?
- NM - We had a look at what MG wrote. We don’t need to look into that right now; we will during the next stage of the analysis.
- Draft Option recommendations to SC (SC meeting scheduled for 8th June)
- PR - We’ll cover that at the TC next week.
- Issues review
- PR - So everyone should look at the Actions on GitHub (link above) and check if they have any to do for the SC meeting.
- Action-TC-2017-21 DevCon agenda and timing (Leon’s Doodle poll)
- LM - I’ve had 2 responses so far. Please fill in the Doodle Poll, so we have some idea when we might hold the DevCon.
- Action-SC-2017-03 Define patchable - postponed until next meeting.
- Guidance for new developers (wiki pages) - postponed until next meeting.
- AOB
- SO - I wonder if we should create a list of potential contributors to version 5, from the Association…
- PR - Does that sound like a Doodle Poll, LM?
- LM - Yes, Ok, I’ll set one up.
Action-TC-2017-24
Participants
- SO - Steve Olson, National Weather Service, USA [NWS], Chair
- LM - Leon Mika, Bureau of Meteorology, Australia [BoM], Vice-Chair
- WQ - Weiqing Qu, Bureau of Meteorology, Australia [BoM]
- MC - Michael Claudon, Meteo-France, France [MF]
- BS - Benjamin Saclier, Meteo-France, France [MF]
- YG - Yves Goupil, Meteo-France, France [MF]
- DW - Dominic Woollatt, Met Office, UK [UKMO]
- DJ - Duncan Jeffery, Met Office, UK [UKMO]
- PN - Paul Nelson, Met Office, UK [UKMO]
- PR - Paul Rogers, Met Office, UK [UKMO]
- NM - Nassos Michas, European Dynamics, [UKMO]
- GT - Giorgios Triantafyllidis, European Dynamics, [UKMO]
- NM - Dimitris Papadeas, European Dynamics, [UKMO]
- MG - Marc Giannoni, National Weather Service, USA [NWS]
- KS - Kari Sheets, National Weather Service, USA [NWS]
Apologies
- RGb - Remy Gibault, Meteo-France International [MFI]
- SD - Sungsoo Do, Korea Meteorological Administration, Republic of Korea [KMA]
- MP - Mikko Partio, Finnish Meteorological Institute, Finland [FMI]
- CS - Cassie Stearns, National Weather Service, USA [NWS]