9th - 10th March 2016, Seoul, Republic of Korea - meeting minutes

  1. Welcome and introductions
    1. JT - Welcome all to the OpenWIS Steering Committee meeting.
  2. Approval of agenda
    1. Approved.
  3. Agreement of working arrangements

    1. JT reminded the meeting of the relevant Articles and Rules pertaining to the operation of Steering Committee meetings:

      A Delegate may represent up to one (1) other Member or Strategic Partner, besides the Member or Strategic Partner which appointed him or her, at a meeting of the Steering Committee. A written proxy, signed by the Member or Strategic Partner giving the proxy, shall be required for that purpose. The represented Member(s) and/or Strategic Partner(s) shall then be considered as present. (Article A13.8)

      A meeting of the Steering Committee shall be quorate if at least three-quarters of the Members and Strategic Partners are together present. Delegates may be assisted by advisers at meetings of the Steering Committee. (Article A13.9)

      Except where these Articles of Association require any matter to be decided unanimously, decision and recommendations of the Steering Committee shall be made by simple majority of those Delegates present. Each Delegate shall have one vote. (Article A13.10)

      Associate Partners may attend Steering Committee meetings as observers. WMO representatives may attend the Steering Committee meetings as observers to represent the interests of OpenWIS users. Observers may contribute to discussions but have no formal role in making decisions. (Article A13.13)

      Resolutions and decisions of the Steering Committee shall be recorded in writing and made available to all Delegates. (Rule R8.14)

    2. The working arrangements were agreed.

  4. Approval of previous minutes
    1. Approved.
  5. Review Action-tracker
    1. PR - As you can see from the Action-tracker, there is only one outstanding action: SC-2015-2 WQ – Ensure the TC holds a design review for the monitoring.
    2. WQ – We’re waiting for design info from WMO; WQ/RGir chair the WIS Monitoring Project.
  6. Declaration of proxy (see Article A13.8)
    1. JT – So, for the record, let’s be clear who represents each organisation at this meeting:
      • Matteo Dell’Acqua (MDA) represents Meteo France
      • Weiqing Qu (WQ) represents Bureau of Meteorology
      • Remy Gibault (RGib) is acting proxy for Meteo France International
      • Jeremy Tandy (JT) represents UK Met Office
      • Jeremy Tandy (JT) is acting proxy for National Weather Service
      • Mikko Visa (MV) represents Finnish Meteorological Institute
      • Okki Lee (OL) represents Korea Meteorological Administration
    2. JT - Seven (7) members are represented, therefore the meeting is quorate.
  7. Election of chairperson (“SC Chair”) and vice-chairperson (“SC Vice-Chair”) of the Steering Committee (see Article A13.5)
    1. MDA – Regarding the tenure - 1 year seems too short – should we change to 2 years?
    2. RGir – That is defined in the articles of Association, so we would need to ask the King of Belgium! However, the version of the articles published by the notaries was corrupted in the PDF. I have asked the notaries what to do and am awaiting an answer. Maybe we could include this rule change if we have to republish?
    3. JT – It doesn’t seem right to change the meaning in that way.
    4. MDA – I agree, we will need to change them at some time for other reasons and should leave it until then.
    5. JT - Where articles are unclear the internal rules clarify.
    6. MDA - So in the internal rules we could say that by default the tenure is 2 years and that re-election is routine unless others want to stand?
    7. RESOLUTION-SC-2016-01:Resolution: vote: 7-0 in favour - Amend Internal Rules to say that default tenure is 2 years unless others want to stand for election.
    8. Call for nominations from amongst the Delegates
      1. JT – The nominations so far received are:
        • JT as SC-Chair;
        • LLG as SC-Vice-Chair;
      2. JT - Are there any further nominations? No? Ok, let’s vote.
      3. Vote:
        1. RESOLUTION-SC-2016-02:Resolution: vote: 7-0 in favour - JT is elected as SC-Chair.
        2. RESOLUTION-SC-2016-03:Resolution: vote: 7-0 in favour - LLG is elected as SC-Vice-Chair.
  8. Election of chairperson (“TC-Chair”) and vice-chairperson (“TC-Vice-Chair”) of the Technical Committee (see Article A14.3)
    1. Call for nominations from amongst Delegates
      1. JT – Many thanks to WQ for chairing the TC last year. WQ is content to continue for another year so I nominate WQ for TC-Chair. No other nominations have been received.
      2. JT – TC-Vice-Chair is currently Bob Bunge. However, NWS are moving internal responsibility for OpenWIS so Bob nominated Steve Olson (NWS). Steve has good technical credentials and NWS are getting more involved now.
      3. JT – Any other nominations? None? Ok, let’s vote.
      4. Vote:
        1. RESOLUTION-SC-2016-04:Resolution: vote: 7-0 in favour - WQ is elected TC-Chair.
        2. RESOLUTION-SC-2016-05:Resolution: vote: 7-0 in favour - SO is elected TC-Vice-Chair.
  9. Recommendations to the Board regarding admission of any person as a Member of the Organization
    1. JT - Have there been any formal requests for membership?
    2. MDA - No.
  10. Strategic positioning of OpenWIS software development activities
    1. JT – So the SC role is to guide/direct the work done in technical committees.
    2. Retrospective review of OpenWIS Association performance since SC-2015, Melbourne
      1. WQ – We have done a good job and achieved a lot. The uplift was a big job and we should be proud of that.
      2. MDA – I see a lot of emails etc about technical progress. Also we have the legal framework established and a bank account etc. Now we have all elements in place to run the Association from now on.
      3. OL – We tend to take what we have for granted. Last year I visited Japan and China; they are working alone while we have this collaboration. This is good because we share resources. We have to make OpenWIS successful first then we can be more ambitious.
      4. MDA - A key element is to make the OpenWIS software a success. As for JMA and CMA, well we tried to involve JMA but it did not work; they have money and resources to do everything on their own.
      5. JT - When we look at what we have achieved we see a great foundation for working together. We had a challenging technical problem to solve. It was difficult to patch and maintain; now it is much easier to work with, we’ve done the hard part. We’ve spent time doing things that don’t deliver new features such as increased test coverage and automated tests. We’ve done a great job re-engineering the software. Although we haven’t added new features, it needed doing to create a sustainable software product for the future. We want it to be the best software for operating GISCs/DCPC etc in the WMO community. We’re just one of a crowd at the moment but we can make it stand-out going forward. We’re trying to make it attractive to the 191 WMO members to participate. There is little at the moment to make people want to, unless they are running a GISC. There wasn’t a compelling reason for JMA to join. We need to make our good performance visible to people outside the Association.
      6. OL – It is not desirable to just have OpenWIS - competition is good and healthy.
      7. MDA - There are other met services that are using the software but not contributing - eg: Morocco. Maybe we should try to work on that - get feedback?
      8. BB - others will contribute eventually.
      9. WQ – It may be possible to get feedback through say the TT-GISC forum etc.
      10. BR – But many NMS don’t have developers.
      11. RGib - MFI don’t get much feedback from customers, we could collect User requirements and request more feedback.
      12. WQ – How about User group workshops like for UM, to get honest feedback from users?
      13. OL – But distinguish between the developer community and the user community. Some may join development later. We still need User level experience/feedback. OpenWIS is niche software so won’t become a very popular OSS project.
      14. JT – We should consider how we expect people to contribute to development but also help Users to use the software better. We’ve made great strides as a development collaboration but were not developing our user community very well.
      15. BB – We’re still building our development community.
      16. OL - The past is the mirror onto the future. Look at MetPX, a good OSS project; don’t expect huge numbers of people working on MSS software.
      17. WQ - We’ve come together for the common task of running a GISC, we’re not expecting many people to join in.
      18. JT – Even for our own organisations it is still too hard to get people to understand where to start and to onboard new developers. For example, when you have a 3 month block of development effort you want to spin up in a few days.
      19. WQ – Yes we still need these docs so we can improve the way we develop.
      20. JT – And if we can make it easier for ourselves to contribute then we might attract others.
      21. BB – there’s a balance. A lot of effort is spent getting development process and deployment working properly - then spend time getting other developers joining.
      22. JT – Resume, 4/5 years ahead of us and now seeing it ramp up.
      23. MDA - Our software is not freely available so it is hard for people to get it.
      24. RGir – There is some confusion between helping develop the software and joining the Association. People may not have developers but may still be interested in joining the Association.
      25. OL – Don’t confuse expansion of the Association with expansion of the community. If the Association has more members it makes it more difficult to manage. We want to add more developers but retain control. We have the responsibility for ensuring OpenWIS remains a viable software.
      26. BB - It comes down to governance so that people that are contributing can rise to a level of influence. You have rules about that.
      27. RGir – What about the Community Manager role? We are missing the task of expansion of the user base. The user base potentially is about 500 institutions. Should we give this task to the Community Manager or someone else? Do more than MFI are doing through customers?
      28. JT - Apart from MFI we haven’t addressed expansion of the user base.
      29. WQ – So probably time to do more on that front.
      30. RGib – MFI always present to customers about OpenWIS partners etc, but their main objective is WMO endorsement.
      31. OL - We have to have great OpenWIS software; outsiders won’t make it great despite the contributions they will make.
      32. WQ - What is the WIS strategy that is influencing what OpenWIS does and what would make it great?
      33. JT - MDA will be giving us an update later.
      34. BR- The definition of great is software that will cope with changes from WMO.
      35. JT - We talk about expansion but we take no action.
      36. BR – Just to be clear, user-base means people who install the software.
      37. RGib – Currently there are 13-15 OpenWIS users.
      38. WQ – There are only 15 GISC but more than half are using Openwis and there are DCPC etc too.
      39. JT - Item 10.4 covers measuring performance of the OpenWIS Association.
      40. RGib – MFI have installed mainly for use as a DCPC: Kenya, Indonesia and Singapore, with a GISC at Casablanca. However General Climate Centres need catalog software so we will use OpenWIS for this purpose at Botswana and Indonesia too. Also, Moscow is using a module of OpenWIS.
      41. MDA - Do we have the poster? It had an updated list/map.
      42. RGir - Only for GISCs. We had contact with Ukraine, but not sure they did anything with the software.
    3. Definition of strategic objectives for a sustainable OpenWIS Association
      1. JT – The OpenWIS Association has potential for broader scope, to work on other projects as well as the OpenWIS software.
      2. What are the medium-term goals of the OpenWIS Association?
        1. JT - Medium term is over the next year or two. Here are some I think we are all clear we are committed to:
          • Stabilise OpenWIS software to a supportable version with adequate, automated test coverage;
          • Ensure that OpenWIS systems operate efficiently, are inherently secure and conform to relevant standards (see Article A13.2i);
          • Automated deployment of the OpenWIS software;
          • Improved user search and data acquisition experience (through functional enhancements of user portal- GeoNetwork 3), and
          • Readiness for open source community engagement.
        2. RGib – We would also like the OpenWIS software to be more customisable; the Indonesian portal wasn’t easy to customise.
        3. BR – Also, the back-end should be more customisable.
        4. JT – We also want to establish and operate a second project to show we can support other initiatives of value to our organisations.
        5. OL - Will CDMS be a distraction? I advise caution.
        6. RGib – although we are considering a new project, we started OpenWIS to tackle the new protocol from WMO. There will be more so we should focus on those.
        7. OL - Explore first and then commit to new projects when we are sure we can achieve success. We risk a lack of focus if we are too ambitious.
        8. JT - Agree - we mustn’t distract from the delivery of the OpenWIS software project. We don’t want to siphon resources from existing efforts onto new projects. But, there are activities we might want to do that would attract new resources.
        9. JT - in terms of the medium term goals - what positive things do you want to achieve in the next 1 to 2 years?
        10. RGib – MFI would like to focus on exchange of met data and start to integrate the OGC protocol. At the very beginning of WIS, WIGOS and WIS were coupled; maybe now is a good time to converge again? We could be a leader.
        11. BB – I think the WIGOS standard is well done; maybe some confusion around meaning of metadata: provenance, measurement methods; some overlap but also distinct differences.
        12. OL - In the 80’s there were many failed attempts to standards eg: OSI. TCP/IP beat OSI because it was a working protocol. When we have a working OpenWIS then it will be meaningful to incorporate WIGOS etc. WMO should pursue how WIGOS etc should be incorporated into WIS.
        13. MDA – Presently WIGOS things are not clear even for people involved, even though we have a manual.
        14. BR - WIS was not delivered in time so we can’t blame WIGOS for going a different route.
        15. MDA - But what are the goals for OpenWIS for the medium term? We need to focus on the OpenWIS software. But keep in mind we are a collaboration, so there is a lot of scope to share resources and budget. So MF should start another project to show that the Association really is a collaboration. But we should consider that OpenWIS is a success.
        16. RGir - Ok, but what is a success?
        17. OL - When we see the WMO community running OpenWIS GISCs, DCPC, NC…
        18. MDA - OpenWIS is already a success, it is already running GISCs etc.
        19. OL - I wouldn’t define this as success. I would say it is when most WMO centres are using OpenWIS for GISC, DCPC, NC.
        20. RGir – But then WIS is not a success, so OpenWIS can’t be.
        21. JT - The project we have been working on so far is about delivering software to implement WIS. Success for the OpenWIS project is about doing something tangible that helps realise the WIS strategy. The original vision was that other people outside the GTS would use WIS to share data; that is not happening yet. So, should we encourage people outside the traditional community?
        22. RGib - We are using OpenWIS to implement INSPIRE.
        23. WQ - What are our medium term goals that we can achieve? We want to make great software. We have laid the foundation, and we have GeoNetwork 3 coming in, so based on that we will introduce new features. We want features that make it operate as we expect.
        24. OL - We have to deliver 4.2 in March next year.
        25. BB - For me, having a good community and governance is success.
        26. WQ - In terms of collaboration we can claim it is a really good example of international collaboration. We need to do more but we are on track.
        27. RGib - NinJo - is that working better?
        28. JT – I don’t think it is an open source project.
        29. OL - Success of OpenWIS as envisioned by WMO was that OpenWIS would be used by other commissions.
        30. JT – so, to summarise what we have discussed so far: Success relates to making the success of WIS tangible. How can we help that? How can we attract end users from other domains and demonstrate that we have end users coming to the portal to find stuff?
        31. RGib – By INSPIRE I meant Download, View services etc.
        32. MDA - Currently the only way we have to find the data is through the metadata, but we can’t currently describe these other kinds of data, so it will not work for other domains.
        33. WQ - We discussed this at the TC, that the metadata will have to be changed and that there are implications for the software.
        34. RGir - When you assess performance you define targets and then measure against them. In the OpenWIS Association we have TC, SC, Board. So success of TC relates to TC objectives, SC to SC objectives, Board to Board objectives.
        35. BR - You need to attract users and new communities.
        36. OL - The metric to measure success must relate to the quality of the software.
        37. WQ – So, two kinds of goals: goals for the Association and for goals for the software. So for the Association - expand the user base, expand number of projects.
        38. JT - Many Association goals will relate to OpenWIS software because that is the main focus, but they are not restricted to that.
        39. JT - In terms of the TC, we can measure success against the technical plan – ie: deliver on time.
        40. JT - The SC needs to provide direction so that the software delivered does the right thing.
        41. JT - In terms of the value we expect in the medium term: we said - OpenWIS software is being used to reach new communities; but the metadata issues mean we are a bit stuck - but we can focus on NC/DCPC.
        42. MDA - Usability is a possible metric.
        43. JT – How about a Usability measure that ‘a non-WMO community member can use OpenWIS to find some data’.
        44. JT - So over a 2 year timescale: in Mar 2017 we release the GeoNetwork 3 version. Then we see DCPC deployment.
        45. OL – For other commissions, not just CBS.
        46. JT - Or outside WMO.
        47. OL - Are other WMO commissions the most important?
        48. RGir – But we need meaningful metadata. There is no guide on how you create meaningful metadata. So we could use Association to work on such a guide, based on experience with DCPC/NC etc.
        49. JT - My Task Team are working on the metadata. We could take the Task Team guidance and write the templates to show how the guidance is applied.
        50. BR - You can also ensure good metadata has a higher search score.
        51. WQ - For me the problem is how you describe the data well, which we don’t do now even though we conform to the standard.
        52. MDA - But this is difficult because the data owner will describe it from their viewpoint, and not from a viewpoint helpful to the end-user.
        53. RGir - So the guide needs to explain how to produce metadata that is better.
        54. BR - So longer abstracts are better, so score length of abstract to order search results.
        55. RGir - So Google has guidance on how to improve your search results as a metadata provider.
        56. JT - So our search algorithms should list quality metadata first.
        57. BR - Maybe JT, your Task Team should define quality metadata.
        58. JT - So in the medium term our goals would be:
          • Stabilise OpenWIS software so it is supportable with good test coverage.
          • Simplify the deployment of OpenWIS software.
        59. OL – We need to agree on the concept of deployment: to prod, pre-prod, etc.
        60. JT – The TC can decide the details:
          • Readiness of the OpenWIS software project for engagement with open source community. We want to do this for ourselves anyway.
          • Making the OpenWIS software easily customisable, for deployment at WIS centres, both for front-end and back-end. So that there is reduced effort in allowing it to look like the customers own systems and reduced effort in integrating with own infrastructure and internal services.
        61. RGir – We are currently using the Dissemination Harness which uses the old API, but it’s not good enough. Should we make those (currently SOAP) interfaces better?
        62. BR - I would simply like to register my REST service in OpenWIS.
        63. WQ - Look at redesigning the SOAP interfaces so that they are more usable by external services.
        64. OL - Rather than customise you might want to turn something off.
        65. BR – Yes, make them pluggable.
        66. JT:
          • Demonstrate that the OpenWIS Association provides a reusable collaboration framework that doesn’t distract from our main project. Key point is that it doesn’t siphon resources off our OpenWIS software project.
          • Show that OpenWIS software is being used to reach new communities, eg: integrating OGC services, making search / discovery better, improving the user experience.
          • Help the community produce better metadata. Produce guidance and for the OpenWIS software project to use it.
        67. BB - Work with the GeoNetwork community, this is something they want too.
        68. JT – The goal of the Board is to make sure the Association is healthy and meeting the goals of partner organisations.
        69. MDA - The Board should have a vision, so at least one goal.
        70. OL - Do we have an objective to create operational quality software? The SC should have that objective.
        71. JT:
          • Deliver software that meets operational needs of WIS centres. Metric: it is deployed operationally within all Member and Strategic Partner organisations?
    4. Is there a continuing need for OpenWIS and how such a need could be met?
      1. JT – Clearly, we all agree there is a continuing need.
    5. How do we see OpenWIS Association evolving?
      1. JT – So to summarise, we expect the OpenWIS Association to:
        • Create open source releases, but we’re not expecting a large open source community.
        • Continue to provide a quality product to attract more OpenWIS software users and grow the membership.
        • Remain focused on the OpenWIS software product, but start a new project at some point.
        • How do we establish community around the OpenWIS software?
    6. Future requirements of WIS Centres
      1. Future WIS strategy - Matteo Dell’Acqua, Chair WMO ICT-ISS
        • MDA slides (slides not provided).
      2. Evolution of WMO Core Metadata Profile - Jeremy Tandy, Chair WMO IPET-MDRD
        • JT - The ISO metadata standard has been around for 10 years. A new standard has been published, but it has only minor improvements. Nothing has been mentioned yet by INSPIRE or other infrastructure projects about adopting this new standard. However, we still have a challenge getting our metadata to a better quality. So, the ET decided to postpone the decision about adopting new standard for 2 years and instead focus on providing guidance about implementing metadata better using the existing standards.
    7. Identification of metrics and targets for OpenWIS Association performance
      1. What can we measure? - Paul Rogers
        1. PR – So at the TC we decided to try the Kanban approach to managing delivery. The main thing we’re trying to manage in Kanban is the workflow, with the objective of ensuring consistent high quality products and releases. The focus is on limiting the work-in-progress to control complexity and risk and to make sure things get properly finished before starting something new. The current backlog status should be visible to all and clearly related to the services we are developing. There are cumulative flow diagrams and charts that can be used to track these things, and we will probably use GitHub and maybe some other tools, but rather than go into detail now, I’ll work up a proposal with the TC. We’ll start using these methods for v 4.
        2. ACTION-SC-2016-01: PR - make a proposal for Kanban backlog and metrics, agree with TC and then circulate to SC.
    8. Recommendations to the Board
      1. Medium term goals; 3 year strategy:
        1. Stabilise OpenWIS software to a supportable version with good test coverage
          • Metric 1.1: Good test coverage (what %? – TC to define)
          • ACTION-SC-2016-02: WQ – Define ‘good test coverage’ as a percentage (with TC).
          • Metric 1.2: Patchable (needs TC work to define this)
          • ACTION-SC-2016-03: WQ – TC to define ‘patchable’.
          • ACTION-SC-2016-04: WQ - TC to agree lifecycle patching strategy.
          • Metric 1.3: OpenWIS 4.2 released by end of March 2017; ready for operational deployment.
        2. Delivery of OpenWIS software that meets needs of operational WIS Centres
          • Metric 2.1: At least two Member or Partner organisations have deployed OpenWIS 4 and accepted it for operational use by Q4 2017… quality assessment.
          • Metric 2.2: All Member and Partner organisations have deployed OpenWIS 4 by Q4 2018 … adoption level
        3. Make OpenWIS software easily customisable for deployment at WIS centres
          • Metric 3.1: To be able to integrate with a new data-source or dissemination component (that is exposed via a REST web service API) without needing to modify source-code; configuration changes only.
          • Metric 3.2: Basic customisation (e.g. colour, theme etc.) of web-based UI requires CSS change only … note dependency on GeoNetwork.
        4. OpenWIS software is being used to reach new communities
          • Metric 4.1: OpenWIS software is used by operational centres to meet ‘wider’ data portal requirements; and these portals are being actively used
          • Metric 4.2: (Meta)data exposed by operational centres running OpenWIS software is discoverable via search engines (Google, Bing, Yahoo, etc.)
          • Metric 4.3: OpenWIS software is being used to make data exposed by web-based services discoverable
          • Do we know how people want to use WIS to discover content and services?
        5. Usability of the OpenWIS software is improved
          • Metric 5.1: ‘Normal’ users (not WMO data managers) can easily find data and the related services
          • Metric 5.2: Setting up a subscription doesn’t require reading guidance documentation (!)
        6. OpenWIS software helps metadata authors produce ‘better’ metadata
          • Metric 6.1: Metadata editor provides Templates corresponding to Guidance topics from IPET-MDRD
        7. Search algorithms in OpenWIS software favourably rank ‘quality’ metadata
          • Metric 7.1: TBD
        8. Readiness of the OpenWIS software project for engagement with open source community
          • Metric 8.1: OpenWIS Development Process published; transparent project governance in place
          • Metric 8.2: GitHub repositories public
          • Metric 8.3: Project website published
          • Metric 8.4: Documentation for on-boarding new developers available
        9. Demonstrate that the OpenWIS Association provides a reusable collaborative framework
          • Metric 9.1: Another project is started without adverse impact on OpenWIS ‘Core’ project
          • Metric 9.2: Average increase in Kanban work package velocity over time (Small, Medium, Large)
  11. Review of recommendations from Technical Committee
    1. Report(s) from Technical Committee 7-8 March 2016, Seoul, Korea - Weiqing Qu, TC Chair
      1. Review of development over the past year, since Melbourne 2015
        • OpenWIS 3.14 operational release expected in April 2016
        • Security testing complete - 2 critical issues found and fixed.
        • Functional testing complete - awaiting update on one outstanding issue #32 - Remy Giraud. (RGir update - Dom mentioned non-WMO data. Need clarification from Dom)
        • OpenWIS 4.x development release expected in June 2016
        • Scalability issues with metadata harvesting; working with GeoCat to fix.
        • Majority of enhancements to GeoNetwork 3 complete.
        • Still work to do on adopting GeoNetwork features and adapting OpenWIS.
        • Open Source - announce at CBS Nov 16
      2. Development Strategy
        • Sticking with J2EE and light-weight container preferences
        • Automated deployment
        • Automated Security Service deployment expected to be ready for April
        • Puppet currently best candidate for automation approach - UKMO will share their work.
      3. Future development
        • Adoption of GeoNetwork 3 in OpenWIS 4.
        • Mainly concentrate on new features - backlog to be populated and prioritised by TC and proposed to SC governance process - to be described by Jeremy.
        • Application of Roles and Groups to accreditation and authorisation, for data as well as metadata.
        • Streamlining deployment so that a system can be reinstalled within 1 hour.
        • Improving set up of bulk subscriptions from User perspective.
        • Deprecation of SOAP, replacing with REST over long term (2-3 years).
        • Investigate the use of Message Queues - possibly leading to a new project in the future. Possible adoption of pub/sub paradigm.
        • Investigate/influence the WMO metadata model and Data Policy.
      4. Going open source (governance, collaboration development environment, improvement in use of GitHub, development policies, developer documentation, project website, use of the forum etc)
        • Adopt a more flexible development methodology and match with governance changes - eg: Kanban.
        • Adopt a fixed operational release schedule approach so that operations can plan for releases - beginning with a 12 month initial cycle - set for March 2017. Development and emergency patch releases can occur at other times as required.
        • Adopt the odd/even release number system.
        • Promote the June 2016 Development Release (4.1.0) as the open source launch release.
        • Improve developer community documentation, both for our own use and to attract open source collaborators in future. Appoint a Technical Author to quickly convert our existing documentation (say 10k euros worth of effort).
        • Adopt Markdown and surrounding tools as documentation standard and appoint a document custodian from the partners.
        • Documentations – for user, developer, administrator (how we manage the documents, in what form, where etc).
      5. Other Business
        • Propose a Developer Conference in 2016 and budget accordingly, to focus on OpenWIS4/GeoNetwork3 and onboard the new developers.
        • Dev/Test servers established by Meteo-France: decide how to utilise effectively. Assess usefulness in March 2017.
    2. Review plan for going ‘fully’ open source
      1. JT – Although we expect to complete the 3.14 release fairly soon, work on version 4 is well advanced and the architecture is quite different from version 3.14. Therefore, it makes more sense to make the version 4 code public, rather than having potential developers looking at the older version 3 code and architecture. I suggest that we use the development release version 4.1, due about June time, for this purpose. We can then go open source any time after that, once we have the docs ready.
      2. WQ – Yes, that seems reasonable.
      3. ACTION-SC-2016-05: PR - Do some more detailed tasking around production of docs for open source.
    3. Resolution of issues referred to SC (if any arising)
      • JT - no issues arising.
    4. Approval of strategic programme and work plan(s)
      1. RESOLUTION-SC-2016-06:Resolution: vote: 7-0 in favour - To recommend this strategic plan to the Board.
    5. Identification of investment required from OpenWIS Association required to deliver the work plan
      1. JT - Technical author - EUR10k
      2. JT - Continuing costs around development environment and cloud tools - roughly the same as next year.
      3. JT - SonarQube etc
      4. JT - About $200 pcm all told
      5. JT - Black Duck – was supposed to inform us about licence issues etc. However, customer service is poor so we’re looking for an alternative.
      6. ACTION-SC-2016-06: - BR - Put someone at UKMO in touch with ECMWF about using PALAMIDA
      7. MG - OWASP – An automatic report on library vulnerabilities is now included in the routine build. Reporting some high and medium priority issues at present, which will need to be investigated.
      8. JT – Maybe we’ll need to remove/update some libraries; that’s a question for the next TC.
      9. JT - OpenWIS Core is released under GPL3 - other projects will choose an appropriate open source licence.
      10. WQ - do we still need to check our licences for purposes of open source release under GPL3?
      11. JT - Yes, so we will try PALAMIDA.
      12. RGir - The cost of the cloud servers MF have set up is covered until March 2017.
      13. ACTION-SC-2016-07: WQ - TC to review the use of these servers in Jan 2017 and decide whether to extend.
      14. JT - Developer Conference; for the event this year the OpenWIS Association covered the 2k budget of sending Lead Developer, should we do that this year?
      15. MDA – No, the policy is that members cover travel costs other than in exceptional circumstances.
    6. Approve OpenWIS release roadmap
      • JT - there is no fixed roadmap now that we are using the new development process. We have agreed a Development release in about June and a stable release in March 2017. We also said the Kanban board (work packages) must be visible to all participants. So we should publish the candidate features and the progress against the list of features.
    7. Review of Lead Developer role
      1. JT - currently Leon Mika is doing a superb job in coordinating the development efforts across the teams. Leon is always available, has good sense and strong technical knowledge.
      2. ACTION-SC-2016-08: MDA/JT will award Leon a certificate as formal recognition of his contribution.
      3. JT - Should we continue with the Lead Developer role? All - Yes.
      4. BB - Put it within the project governance.
      5. JT - Would be great if Leon could continue in that role.
      6. ACTION-SC-2016-09: WQ - Confirm that Leon will continue in the role for the next 12 months.
    8. Review need for Community Manager role - Jeremy Tandy
      1. JT - Paper attached; similar to Melbourne with a few feedback comments included.
      2. JT - Are we ready yet for a Community Mgr?
      3. BR – I would wait for v4.2
      4. RGir - Ok, but the recruitment process could take 4-6 months. So should we start in time to have them for then?
      5. OL – It is still too early to see the clear benefit of a Community Manager at this time.
      6. JT – It seems we all agree that we’re not ready right now. We may be ready in 12 months.
      7. WQ - What are the implications for costs? Why not wait until we are sure we will fail without it.
      8. JT - Success was defined as making sure we meet our obligations to WIS by producing operational software. We don’t expect a sudden increase in contributors even when we go open. So in the short team we don’t need a Community Manager, we just need to set a review date for this decision.
      9. OL - Does the Community Manager contribute to producing the quality operational software? Not likely for the time being.
      10. BB - Open source geo-spatial foundation had a Community Manager that brought in money but has now disbanded that role and is no longer getting that money. The domain we are working in is exciting and many developers in universities would welcome the opportunity.
      11. WQ - We could share the Community Manager work between us.
      12. RGir - The ‘marketing’ will be important at some point, so we should say who (one or two of us) are doing that.
      13. WQ - MFI?
      14. RGib – Yes we are for OpenWIS, but not for OSS.
      15. JT - We recognise that the role is important for the health of the community in the long term. But we don’t need to do it quite yet. When we go open source and people have the opportunity to contribute, we will need to assign these tasks, to members and partners. At some point we may find that this role is needed or even self sustaining. So let’s review it then.
      16. MDA - Will we find the resources to do the job?
      17. JT - We will to do some of the job; we can do it ourselves for now.
      18. ACTION-SC-2016-10: JT - As part of going open source we need a Communications Plan.
  12. Risk review and development of mitigation plans
    1. JT – I propose that we hold quarterly SC calls - so schedule for June - and look at the risks for the Association. The TC manage the technical risks and escalate them to the SC when needed.
    2. BB – The risks around management of IP and code provenance review won’t wait until June.
  13. Recommendations to the Board to make and adopt, alter, supplement or repeal the Internal Rules
    1. Support for multiple concurrent projects within the OpenWIS governance framework - Jeremy Tandy, Bruce Bannerman
      1. JT - So first we’ll have a presentation from BB, who has 15 years experience of working with OSS projects.
      2. BB slides on OSGeo
        1. MG - Who does testing for OSGeo?
        2. BB – The User Community and Developers.
        3. OL – Are there any financial contributions?
        4. BB - Mainly for the FOSS4G annual conference event, in the form of sponsorship. Projects fund themselves. FOSS4G will usually make a small surplus.
        5. JT - So OSGeo provide a small amount of infrastructure eg mail lists.
        6. RGib - How do I become a member of the OSGeo Foundation?
        7. BB - Join the mail lists.
        8. RGir - Would the MetPX project join the OpenWIS Association?
        9. BB – It’s more than the software, there’s the community too.
        10. JT - So we could invite them to bring MetPX into the OpenWIS Association.
        11. OL - OpenWIS is built on top of existing software
        12. JT - So are all these other projects in OSGeo. We can be good OSS citizens by contributing back to these projects. They will then reciprocate.
        13. OL – The OpenWIS user base is very small, while geospatial is very large.
        14. JT - GeoCat were interested in us contributing ‘subscriptions’ to GeoNetwork.
        15. WQ - We will only ever have a small user base, but that’s not a problem; if other OSS communities are doing things that work well, we want to learn from that.
        16. RGir - pycsw is a small 2-man project.
        17. BB - We may find it easier to extend an existing project rather than develop our own.
        18. JT - With GeoNetwork we extended some of the core GeoNetwork and also built some packages specific to OpenWIS.
      3. JT paper on multiple projects
        1. ACTION-SC-2016-11: JT - Publish Articles, Internal Rules and Board etc on our website.
        2. OL - Is it not possible to have multiple projects without changing the internal rules?
        3. JT/WQ - The internal rules are not clear about how we run projects. This needs to be clear to ourselves and for others.
        4. RGir - In French we have singular software rather than plural software(s), so it is explicitly singular.
        5. JT - So we may need to clarify this in the articles in the future.
        6. ACTION-SC-2016-12: JT - Make sure the role of User is clear in the internal rules.
        7. OL - As soon as we change the internal rules, does the OpenWIS software become a project?
        8. JT - Yes.
        9. WQ – Does it cover removing PMC members?
        10. JT - The process needs to cover that, probably escalated to SC for a decision.
        11. BB - How are Contributors tied in with articles?
        12. JT - They are not because they are not partners or members. We need to say they comply with the Code of Conduct, which we need to write down.
        13. ACTION-SC-2016-13: JT (through Michael Robbins) get legal advice on whether the articles shelter the contributors from litigation.
        14. WQ – Is the PMC subordinate to the SC or the TC?
        15. (JT captured a discussion about the roles of Technical Committee/Steering Committee/Project Management Committee, in real-time, in a diagram on-screen. The meeting finally agreed this Committee Role Structure)
        16. JT – Ok, so we agree that the TC will continue to operate as PMC for OpenWIS Core for the time being so that the articles don’t have to be changed.
        17. ACTION-SC-2016-14: PR - RISK for Board Risk Register - That the articles of the Association are not fit for purpose regarding, particularly: Article 14.1 Architecture role of TC, Article 9.1 No mention of contributors, Article 21.2 Indemnity of partners and contributors.
        18. ACTION-SC-2016-15: WQ(TC) - Define the roles in the development process - see JT doc.
        19. ACTION-SC-2016-16: JT - Clarify articles that may appear to force other people to pay for your project.
        20. RESOLUTION-SC-2016-07:Resolution: vote: 7-0 in favour - JT is tasked to amend the Internal Rules to reflect what we have discussed here today about managing multiple projects.
    2. Flexibility in choice of open source license
      1. JT - We agreed last year that projects could choose any licence accepted by Open Source Initiative.
      2. JT - Let’s refer to the OpenWIS software project as OpenWIS Core.
      3. JT - The OpenWIS Core project will continue to use GPL3.
      4. JT - I propose that we change rule art.9, to say that each project shall declare which OSI licence they use.
      5. BB - SC should have a veto in case of incompatibility between the licence chosen with other licences of dependent projects.
      6. RESOLUTION-SC-2016-08:Resolution: vote: 7-0 in favour - JT is tasked with changing rule art.9, to say that each project shall declare which OSI licence they use.
  14. New opportunities for collaboration
    1. Review proposals for projects that are compatible with the purpose and objectives of the OpenWIS Association and in the interest of Members and Partners
      1. Status update on OpenCDMS - Bruce Bannerman
        1. BB - Funding applied for; may get answer sooner or later within next 12 months.
        2. JT – So BB is not looking for funds from OpenWIS, just a governance process and development process to execute. Before OpenCDMS has funding it will be difficult to commit to a specific level, would need to produce project charter.
        3. BB - Our CDMS is end of life (at BoM), so we would be investing.
        4. JT - If BoM had sufficient funds to make a start only, then that would be sufficient to start a project under auspices of OpenWIS.
        5. RGib - Do you see this as a single global project or more modular so that we could develop some modules?
        6. BB - Yes, were talking about a programme so we just need to agree the rules so the components would work together.
        7. JT - CDMS fits within the purpose of the organisation. It is important to our community and has begun to determine how it could fund and sustain itself. So it looks like a good candidate for an OpenWIS project. It is likely that volunteer contributors will come forward to help with a project about climate.
        8. BB - 10/12 developers have already shown interest in contributing to a climate related project.
      2. Data modelling and tools to support the integrated observations, observations metadata, discovery metadata, data provenance, data IP, QA/QC - Bruce Bannerman
        1. (BB - second presentation - on data management – no paper)
        2. BB - Trying to describe the big picture relating to the data management and then tackle the biggest pain points. Observations lifecycle and consistent QA flags is one example.
        3. JT – How about a workshop, perhaps to generate project proposals, some of which might be suitable for OpenWIS. We might all think about WIGOS and say, configure metadata for OSCAR. Maybe something around bringing data services alongside the discovery portals. But early in the life, to figure out what the scope is.
        4. WQ - I think this is a very high level view, we would need to understand more details about why we do certain things.
        5. MDA - I wanted a workshop on lifecycle of data - we could organise that as part of work on WIS-Part C.
        6. OL - CDMS has a good specification and regulations etc. Looking at OpenWIS, we started way back on Simdat etc and we had prototypes etc. Is there any tangible software people can look at? Perhaps CDMS could use a similar approach. When we house a project under OpenWIS it should be mutually beneficial to OpenWIS core and OpenCDMS; I don’t see that in the current presentation.
        7. JT - The purpose of the Association is to work on exchange of global met data, which covers CDMS; there is no requirement to be directly related to OpenWIS core.
        8. MDA - There are potential common components eg: the catalog.
        9. WQ - Even without that linkage - CDMS is a tangible OpenWIS concept.
        10. BB - There are many systems that call themselves a CDMS; they have no clear definition of requirements or reference to WMO requirements. We have come up with a clear statement of requirements, but none of the existing systems meet these. So we need to start with a good data model and developing a set of components which will bolt together on existing OSS where we can, for example linux, postgres, mapserver, thredds, geonetwork, qgis…
        11. JT - One of the other concerns is about the size of project - you need to start with OSS to attract funding. If you have a commitment to fund and deliver a start then you can begin a project.
        12. OL - Yes, distraction is a potential issue.
        13. BB - We could dev in BoM or OSGeo but I believe the OpenWIS Association is the best fit and we want to collaborate with our peers.
        14. JT - We protect our credibility by badging projects as incubator projects.
        15. RGib – Don’t you think this big project is a risk for OpenWIS?
        16. JT - We did say we could start with modules.
        17. RGib - Maybe we should try to find modules that are a common interest so we can all contribute.
        18. WQ - OL was worrying that we will neglect OpenWIS core - we won’t, we will be working very hard to continue work on OpenWIS core. These projects don’t have to use OpenWIS core.
        19. BB - we want to.
        20. WQ - Ok.
        21. RGib - I believe a huge project is important for the Association and I like the idea of offering participation around the room. But, I think we have to find a way of doing CDMS in a way we might be able to contribute without covering the whole project.
        22. JT - We should have this debate when a project proposal gets submitted, we then create the project charter and then vote on it. I think it is clear that we should request the project charter for CDMS and then continue the debate.
      3. Post-processing algorithm exchange / code repository - Jeremy Tandy - no paper
        1. JT - Something we all do and could share more.
      4. Weather-on-the-Web - Jeremy Tandy.
        1. JT - Phase-1 involves establishing a standardized mechanism to provide site-specific forecasts to content aggregators (e.g. Google, Bing etc.) for onward publication. Encoding (e.g. using schema.org vocabulary, see ISSUE #362) plus server and client application reference implementations.
      5. RabbitMQ/AMQP
        1. JT - May also be a proposal - would any members be able to draft something?
        2. WQ - Do we just want to explore if pub/sub works or look at whether we would use it in OpenWIS?
        3. ACTION-SC-2016-17: WQ - To do a project proposal relating an investigation work package for the OpenWIS Core.
        4. ACTION-SC-2016-18: MDA - Find out if NMS Canada is interested in bringing MetPX under the OpenWIS umbrella.
    2. Identification of opportunities to participate in calls for proposals in externally funded projects
      1. JT – I’m not aware of any – anyone else? No.
    3. Recommendation to the Board regarding new projects to establish
      1. JT – We’re not recommending any right now. At a suitable time (within the next 12 months) BB/JT will work up a project charter.
      2. JT – If MetPX are joining then MDA will produce a project charter
      3. JT - UKMO will discuss project proposals for NWS suggestions
      4. RGir – AFD, a 20 year old file distribution software. It’s a one man OSS project in the same situation as MetPX; old stable software.
      5. OL - Why bother with it?
      6. RGir - AFD has no API etc so requires some extra development; it might complete an end-to-end dissemination harness for OpenWIS.
      7. ACTION-SC-2016-19: RGir - Investigate appetite for a project proposal with DWD.
  15. Outreach, communications and community
    1. Recommendations to the Board regarding admission of new Partners
      1. JT - MDA talked to Canada - will have another go.
      2. BR – For ECMWF, the paperwork has gone up now.
      3. JT - is the SC ready to recommend ECMWF as an Associate Partner?
      4. RESOLUTION-SC-2016-09:Resolution: vote: 7-0 in favour - ECMWF is recommended as an Associate Partner.
      5. JT - Any others? No.
    2. Recommendations to the Board regarding engagement with third-parties to participate in consortia responding to calls for proposals in respect of externally funded projects - see also item (14.2)
      1. JT - None known.
    3. Management of Contributor License Agreements
      1. Contributor License Agreement
      2. JT - A lot of contributors won’t want to physically post a form to our Belgian address. I suggest we amend the Internal Rules… see JT paper.
      3. BB - Why not have an umbrella agreement?
      4. ACTION-SC-2016-20: JT/PR - Talk to Michael Robbins about whether an umbrella agreement would have legal standing.
      5. JT – I suggest an online CLA form
      6. BB - Not sure click-through will be valid
      7. ACTION-SC-2016-21: JT/PR - Work with Michael to determine legal validity in all territories of a click-through online CLA - and validity under Belgian law. Refer to legal contact of IRM?
      8. Example CLA management service: CLA Assistant - (MG gave a demo of a click-through CLA)
      9. BB - One OSS project that wanted to change its licence had to contact every contributor, so they needed a list.
      10. JT - So this would be a simpler way to manage the licence agreements than managing paper copies.
      11. ACTION-SC-2016-22: JT - Come up with suitable method for managing CLAs. Bring back to SC to approve by correspondence. Update CLA process and forms if approved.
      12. JT - SC confirm that a single CLA for all projects is preferred. And that we have an online system that manages the CLAs (otherwise TC will have to manage all the paperwork).
      13. NOTE: This needs a robust mechanism to backup/restore/copy the signed agreement. We must resolve this before our OSS release.
    4. Development of community growth strategy (discussion)
      1. JT – I think it’s too early for this.
      2. RGir - The idea of the growth strategy for OpenWIS core is that we have people become users, then contributors, then members.
    5. Provision of developer community resources
      1. JT – We covered this earlier.
    6. Communications plan
      1. JT - how will we communicate our OSS release. How will we communicate our stable release. We wanted to improve communications from MFI about which of their customers are using OpenWIS.
      2. ACTION-SC-2016-23: RGib - email info about who is using OpenWIS to both TC and SC.
      3. JT – As RGib said, MFI users are mainly interested in being endorsed by WMO; they don’t see other benefits of OpenWIS.
      4. JT - so our communications plan needs to be clearer about the benefits of being a contributor. Community building is a secondary concern, after building quality software. We said there are tasks that need doing to communicate about the project that fit in the role of the Community Manager role and that we would allocate those tasks as we approach our OSS release. We agree that we will do that later, to coincide with the open-source release
      5. ACTION-SC-2016-24: LLG – Clarify in the communications plan.
      6. RGir - Also we wanted to improve the content on the website.
      7. ACTION-SC-2016-25: RGib - Improve the existing web-site (nothing grand).
      8. RGib – We can provide to the Association the feedback received so far from users.
      9. ACTION-SC-2016-26: RGib - Provide to the Association the feedback received so far from users to TC and SC.
      10. MDA - When we go open source, send CBS an email to announce it. Also include in the plan how we communicate at the CBS meeting.
      11. MDA – We should also communicate about enlarging the scope of the Association and explain the difference between that and the core software, especially to the other commissions.
      12. JT – A 3.14.4 stable release will occur in less than a month. Then a development release around June, maybe another development release a little later, then a stable 4.2 in March 2017.
      13. JT - So how do we communicate that the OpenWIS Association not just about meeting GISC obligations, but has a desire to increase the portfolio of projects, providing more opportunities to collaborate and draw on other resources? We need to communicate to WMO members that the Association is more than just the software project; any thoughts?
      14. MDA - Not a lot of thoughts. I have mentioned to the WIS Secretariat in WMO. They are interested in what we are doing but not ready to engage. I presented to JMA, but that was not a real success.
      15. JT - Are they just hearing WIS?
      16. MDA - I think they understand there are opportunities to collaborate but don’t seem interested in OSS, or they’re not ready to share development with another organisation.
      17. MDA - WMO Secretariat could spread the message and provide feedback on met services looking for services.
      18. MDA – At JMA we talked for 2.5 days!
      19. OL - Make it clear what we expect from JMA: is it to expand OpenWIS or get expertise from JMA? Once it is OSS they will look at our code and might be able to contribute.
      20. MDA – I have discussed with DWD. I will go to present what is the Association and aims. AFD may be of interest. We’ll meet in Germany and see what happens.
      21. BB - Lead by example; look at Recommendations 11.31 and 11.4, WMO Secretariat understood the argument; It will come over time.
      22. RGir - If we go to DWD and JMA about OpenWIS core they are not interested because they see WIS as super-GTS and nothing more. In order to attract people we may want to show more than OpenWIS core. MF have been working on producing metadata from an Excel spreadsheet; it is easier for a normal user. So we could show some of these things, publish in GitHub, perhaps.
      23. JT - Publish with a licence.
      24. RGir - we are going to many WMO meetings in the next few weeks/months, so we could do a shared presentation that we all show. It will be minuted and will start growing.
      25. JT - In taking the initial steps, do you have something?
      26. MDA - We have slides, we can prepare something.
      27. ACTION-SC-2016-27: RGir – prepare a presentation.
      28. WQ – Regarding AFD, if it is already OSS and has a main developer, then do we need to deal with DWD.
      29. RGir - If we work with DWD that also has political as well as technical merit.
      30. BB - Building the community; open spatial services for delivery of data. Many NMS are already collaborating on OGC services so that would be a good way to collaborate.
      31. JT - Met Ocean Domain WG for example.
      32. OL - Why do we want to engage with DWD, Canada etc? It should be mutually beneficial. Be careful we don’t lose focus and get distracted. Canada might ask why join OpenWIS? We must improve the quality of our operational software so that it is better than DWD, JMA etc.
      33. MDA - Another way to see it is that they have their own software and are not going to switch, but if we collaborate they may see that has benefits and then take the OpenWIS software.
      34. RGib - We should remain focused on OpenWIS. Why do we want to add MetPX, just to add a new product?
      35. JT – The reason is that it may provide a capable dissemination service
      36. RGib - my concern is that we will get new specifications from WMO and we should use the Association to tackle that.
      37. WQ - Even if OpenWIS software fall apart but OpenCDMS is a success then the Association is a success.
      38. OL - We shouldn’t forget the main mission.
      39. WQ - What I said is a worst case scenario; if you have 10 projects and a couple fail then the organisation is still a success.
      40. OL - We will release 4.2 and then there will be a version 5.
      41. RGib – MetPX is a good example; we all have a MSS running already. The WMO future direction is cloud; the GTS is the past.
      42. RGir – MetPX is not a MSS, it’s a working queue based system we can learn from.
      43. JT - What we saying is, if the owners of those projects see merit in moving to OpenWIS Association (without impacting our resources) then we’ll give them a home.
      44. RGir – Also, they have technology we may use in the OpenWIS core.
      45. OL - It doesn’t add any value unless we incorporate their code into OpenWIS code.
      46. JT – I challenge that.
      47. OL - Just putting MetPX under our umbrella doesn’t do much
      48. JT – There is the mutual benefit from exchange of expertise, but it also becomes an attractor of contributions from a broader community. We want to improve our release process, docs etc and these shared benefits come from working together. It is not a displacement activity.
      49. BB – The benefit is it increases the potential number of contributors to OpenWIS.
      50. MDA - MSS is bust so we don’t want to invest in it.
      51. MDA – OL, you mention that the success criteria is develop and deploy OpenWIS. But start a new project is also a success criteria because what we have done up to now may continue for a while but it will not realize all our aspirations for the Association.
      52. JT – We are stronger together in OpenWIS core and as an Association
      53. OL - Great companies repeat their success by repeating what they do well. Starting a new project is not a success criteria, having another successful project is a success criteria.
      54. JT - Why did we start OpenWIS together?
      55. WQ - Because it is a big commitment and we wanted to share the work.
      56. JT - There are other tasks in our community that are too big to do alone.
      57. BB - And empowering that project to be successful.
      58. RGib - I am not sure we will be together on a new project. WIGOS is one, OGC services another.
      59. JT - We will meet again as a Steering Committee in 3 months time. Would someone take the lead in producing a strategy to say what future work will be the focus of our work together .
      60. ACTION-SC-2016-28: JT - To write a strategy paper on: Where we can deliver the most value for the broader community in the near future.
      61. WQ - OPEX 2019?
      62. MDA - When we started work I suggested OSS and ICAO said “No way!” We started a project anyway.
      63. JT - SC need to define clearly the vision of the Association.
      64. OL - We know we need to improve the quality of our software. OpenWIS started as inter-commission activity. What’s the next important commission?
      65. MDA - This is a WMO problem, we have not delivered on WIS, so other commissions are not interested.
      66. JT - To manifest the WMO vision of WIS.
      67. OL - Support WIGOS is something we can do.
      68. MDA - WIGOS is at the very beginning. 15 years ago we put a lot of energy into defining WIS. Let’s wait until WIGOS know what they want.
      69. JT - In the larger community we want to engage with the Internet of Things (IoT). OSCAR is being built but it’s premature to suggest we spin up a project around that. Let’s come back to this and the communications question again in 3 months.
      70. JT – We’ve started using the term OpenWIS Core to describe the software we use to run operational WIS centres. We need a name for this software so that we can clearly distinguish it.
      71. ACTION-SC-2016-29: OL - Come up with an appropriate name.
      72. JT - We need to be clearer with people whether were just asking for contributions or whether we are asking people to become members/partners. It is important that the rules make the role of contributor clear.
      73. JT - We also need to make it clear that we have robust governance around running multiple projects for the benefit of the community. How should we do this? Can we address these topics in the slide deck?
      74. WQ - The message should be that we have OSS governance set up and what it is. Then welcome everyone.
      75. OL - When we communicate we should target the message; it should be the WMO community first.
      76. JT - There is also the geospatial community.
      77. OL - we don’t ignore other communities but it should be in the met/hydro/ocean community.
      78. JT - The OGC has a met and hydro WG which includes many capable people, so there are 2 communities that overlap (WMO/OGC)
      79. JT - Bruce also has traction with the Commission for Climatology. Perhaps add Hydro Commission as well.
      80. JT - The current commission structure may change.
      81. JT - In terms of communicating, is there anything else?
      82. BB – What about writing for Journals?
      83. JT - Which journals?
      84. MDA - Meteorological Technology International
      85. WQ - Operational Newsletter within Observations
      86. MDA - Might need to involve WMO Secretariat for that, and they are not currently interested
      87. OL - Present at AMS, Matteo?
      88. MDA – Yes.
      89. BB – There is an organisation called Join Up that focuses on OSS projects, so could put something out once we have strategy and governance etc and have the material ready on our website.
      90. ACTION-SC-2016-30: JT - Let’s put targeted communications on the agenda for the next SC meeting.
      91. RGir – Ok, I’ll have the draft slide deck (see action above) ready for a June SC. If we plan to approach DWD we could have a couple of slides that show how we think AFD might fit. Same for Canada and MetPX.
      92. MDA – What about the ET-WISC in Melbourne in May, should we have the slides for then?
      93. JT – That’s not much of an opportunity because they’ll only hear ‘OpenWIS Core’.
      94. WQ - I think the opposite, so let’s tell them about open source etc.
  16. Recommendations to the Board regarding the creation of ad-hoc committees or subsidiary bodies
    1. JT - we’re not recommending any; we had a discussion about PMCs but decided the TC does that.
  17. Finances of the OpenWIS Association
    1. Challenges arising from existing funding mechanisms - Matteo Dell’Acqua
      1. MDA - The EUR200k contribution for Strategic Partner was set because that was what we all originally put in. This mechanism may not suit new projects. So OpenCDMS, for example, may have to contribute. Say Met Morocco wants to join, we would ask for EUR200k euro, but I’m not sure this works. So, what would a mechanism be, that allows people to engage and sit at the SC?
      2. JT – Let’s distinguish between SC which is high level direction and PMC which guides a project: Met Morocco could contribute without any upfront costs. When we set up a new project the members of the PMC will be drawn from those who set up the project.
      3. WQ - But how will the Association be sustained in the long term (financially)?
      4. MDA - Why would someone be an Association Partner?
      5. JT - They get a seat on the PMC.
      6. WQ – So the only funding source is from the original members.
      7. MDA - So what are the future funding sources?
      8. WQ - OSGeo run the annual conference to raise funds.
      9. MDA – We need a funding mechanism to sustain the Association and we need to revisit the funding from partners at some point.
      10. JT - Participation in externally funded projects will bring in funding.
      11. JT - Association Partners pay 10k euro…
      12. MDA - But the Association will provide the development environment, which costs money. If we spend all the existing funds what do we do?
      13. JT - The articles say the partners pay equal contributions.
      14. JT - Apache will accept donations and contributions. If we demo our OSS credentials in delivering to Region 1 etc, could we qualify for funds from VCP or DFID etc
      15. JT - So there is a role for a Sponsor. Apache explicitly say Sponsors have no role in governance.
      16. OL - Apache/Eclipse are great OSS projects but we don’t have to copy them, we are great in our own way. We are a non-profit so we should manage costs.
      17. MDA - But non-profit does not mean we don’t spend money
      18. JT – A sponsor is an organisation that pledges annual donations etc.
      19. BB – There are international fund sources.
      20. JT – So you could imagine Tanzania have support in UK DFID to deploy a CDMS. Clearly, we need to be careful what commitments we make.
      21. WQ - We need some idea of what regular annual income we can expect as a minimum and the security of that.
      22. JT - The Association Partner is the only mechanism we have for collecting annual fees. We could use the conference but not sure we have enough community to generate revenue from that. Currently we have no Associate members.
      23. MDA - We have to explain how the Association is run. At some stage you arrive at Strategic Partner and Associate Partner have to explain what they get.
      24. JT - In the governance process I tried to be clear why you would want to be a partner rather than a contributor. As a contributor, you can only observe and talk at SC, you can’t vote. You can propose new projects and you can be on the PMC. A Strategic Partner gets all that too, but also gets a vote on the SC. If something fits within the articles the board accepts what the SC wants to do, so effectively you are participating in the leadership of this community.
      25. OL - To attract Associate Partner we need to deliver benefits, so why do Associate Partners join?
      26. JT - They would get a seat on the PMC and influence/choose work-packages.
      27. OL - ECMWF is a friendly partner but even for them it is not simple to join. How do we demo clear benefits to the other 191 WMO members.
      28. JT - We aim to create quality software that meets operational needs. Organisations want to use it to meet obligations; they then see it is valuable to them; they then fix bugs and contribute; they then decide they want more control over where the Association is going and join as Associate Partner. It’s a long journey with a number of steps.
      29. MDA - How do you specify the TC?
      30. JT - It’s mentioned in the articles. It says the SC choose the Chair and Vice-chair of the TC and such other members as they require. There is no mention of Associate or Strategic Partners.
      31. MDA - In internal rules ‘eligible to participate’ doesn’t mean you get a seat?
      32. JT - Eligible means you could get a seat, not that you will.
      33. RGir - But there is no TC selection process, so eligible means you will.
      34. JT - So I propose that the selection process should be delegated to the Chair of the TC.
      35. JT - They get a seat on the TC for OpenWIS core because it is also a PMC and they are participating.
      36. RGir - Why not just say you will get a seat on the TC?
      37. BB - We need the best people on the TC to steer us, not political appointees.
      38. WQ – Otherwise, the TC has been weakened.
      39. BB - People can’t argue with the published rules.
      40. JT – I suggest we change ‘eligibility’ to ‘right to appoint’ and also scrub the phrase ‘following election by SC’.
      41. RESOLUTION-SC-2016-10:Resolution: vote: 7-0 in favour - Recommended to Board that we change ‘eligibility’ to ‘right to appoint’ and also scrub the phrase ‘following election by SC’.
      42. JT - Article 14.2 of the articles says … we must respect the articles in the internal rules.
      43. JT - Options: eligible to be in TC subject to qualification in article 14.2.
      44. OL - We don’t need to change the rules to appoint ECMWF.
      45. JT – Correct.
      46. MDA - My organisation will expect to appoint to TC; the right person with the right skill.
      47. JT - Imagine you had no-one with the technical skill? We are introducing the concept of the PMC and partners have the right to be on that.
      48. MDA - So Baudouin could contribute without being an Associate?
      49. JT - Yes
      50. BB - How about use of logo as a benefit of Association partnership?
      51. JT - I propose a vote on: eligible to be in TC subject to qualification in article 14.2
      52. OL - It can’t be just anyone from the whole wide world.
      53. JT - Yes, it can, according to the articles. On the PMC they get to control the work packages which is a really strong incentive.
      54. RGir - It’s either the SC or the TC chair.
      55. JT - I propose a vote on: Eligible to be in TC subject to qualifying criteria in article 14.2
      56. OL - Baudouin can sit on TC as himself rather than for ECMWF?
      57. RGir - Yes.
      58. OL - So the Association could fall apart?
      59. JT/RG - No, because they get a seat on the PMC
      60. JT - I propose a vote on this clarification: eligible to be in TC subject to qualifying criteria in article 14.2.
      61. RGib - I require clarification on the JT proposed change.
      62. MDA - An Associate Partner will get a TC seat so long as they have the right skills. Worst case, they don’t get a seat on the TC, but that is unlikely.
      63. JT - I propose a vote on this clarification: eligible to be in TC subject to qualifying criteria in article 14.2.
      64. RESOLUTION-SC-2016-11:Resolution: vote: 6 in favour, 0 against and 1 abstained - Recommended to Board - clarification: eligible to be in TC subject to qualifying criteria in article 14.2.
      65. JT - We recognise there is a challenge to year on year funding. We need to clarify how we would seek additional year on year funding. We could seek funding from organisations that seek developments from within the broader met community, by showing the value of OpenWIS projects to that community. Being an OSS community should give some credibility. We have no sponsors at the moment. We agreed we’re too small to charge for the Conference. We agreed there may be opportunities to participate in externally funded projects, but we would need to be clear in our commitments to those projects.
      66. JT - We have the mechanisms in place to ask for more funds from Strategic Partners and Members and Associate Partners have the option to contribute. Such funding requests require a unanimous board vote.
      67. BB – The option with most potential is to seek funds from sponsors, but the Association would need to develop a value proposition for sponsoring organisations.
      68. ACTION-SC-2016-31: BB - Will help develop a value proposition. But I’m not ideal; people in WMO have that experience, so I will ask around to see if I can identify the right people.
      69. JT – MDA, are you content we have covered that item?
      70. MDA – Yes, thank you.
    2. Review of need for additional finance
      1. The SC agreed that we have no need for additional finance at this time
    3. Preparation of budget for 2016/17
      1. MV is now absent - SC proxy is MDA.
      2. JT – I suggest the budget we set last year is used as the basis of this year’s, but that we add some new items.
      3. JT - Firstly: skills to setup website content: technical author/designer. I propose an upper budget limit of EUR20k for that with a target of half that; any thoughts?
      4. OL - We are non-profit, so we should try to reduce costs and we agreed EUR10k at the TC.
      5. JT - Yes we did, but for budgetary purposes we would like to agree more. The max that EE, MDA, or JT can sign-off is EUR10k, so we will have to have it signed off by the board anyway.
      6. OL - I mean that we should try to reduce the amount if possible.
      7. RGib - What is the purpose of this budget?
      8. MDA – Some effort to structure the content/docs professionally.
      9. WQ - We don’t have the skills to do the structure properly.
      10. JT – An information architecture for the website.
      11. MDA - MFI will coordinate?
      12. MFI – Yes, but not sure we need to spend that amount of money.
      13. OL - We can spend some seed money.
      14. MDA - This is less than EUR1000/day. I think we will need to spend more to get the job done properly and quickly.
      15. RGib - I will have to check if MFI can do some of this.
      16. WQ - We want admin, user, dev docs in a consistent style, not just the web site, it is the design/style of the docs.
      17. JT – Yes, how best to style and organise the information. I just had a similar quote for work in UK of GBP400 per day but we don’t know how many days are needed. I am proposing an upper limit of EUR20k.
      18. RGib - So maybe MFI could somehow reduce the cost.
      19. WQ - How much have we in the bank?
      20. RGir - EUR395k.
      21. OL - If it goes to the improvement of the code quality, I would spend more money, though I agree there is a need.
      22. WQ - Docs are a key part of the software delivery.
      23. MDA - Having this information for users on the website is important.
      24. MDA - So can we say EUR15k.
      25. OL - We will spend whatever we set as a budget.
      26. EE - We could spend more by agreement of the members at the time.
      27. JT - Rule 10.6: any expenditure in excess of the annual budget…
      28. MDA - No, that’s the annual budget.
      29. JT - So when we calculate the size of the annual budget, we will add EUR10k for the technical author?
      30. ALL - Agreed.
      31. JT - Onto second budget item: any fees we will incur when transferring from MFI.
      32. EE - No taxes are expected.
      33. JT - We would need to reimburse MFI; any idea how much?
      34. EE - Just some bank fees, shouldn’t be much.
      35. MDA – It will be euro to euro, so make no provision.
      36. JT – Next: repeat ongoing costs:-
        • Amazon platform costs - USD150 pcm - USD1800 per yr, so round to USD2000 per yr.
        • Renewal of openwis.io website - EUR150 per yr
        • WQ - Do we pay for the trademark?
        • ACTION-SC-2016-32: EE - Check with Michael Robbins for fees related to trademarks.
        • WQ – I think it was about EUR1000, but not sure if that was just for 1 year.
        • Software management tools - also about USD150 pcm - so say USD2000 per year.
        • Last year we budgeted for EUR500 of promotional material, suggest the same this year.
        • Last year we had EUR2000 for legal fees.
        • RGir – As we said, there is an error in the submission to the Belgian Gazette, so we may need to pay for re-publication. The notaries haven’t said we will have to pay, but let’s allow, say, EUR200.
        • Last year we had EUR1000 for misc such as transfer of trademarks. That hasn’t happened yet, so let’s keep it in the budget for this year.
        • Last year we set aside EUR84k for the salary and expenses of the Community Manager. We spent none of that and we don’t expect to hire one this year either, so we will not set aside any budget for that this year.
        • So the total comes to about EUR15,850, give or take a bit on the EUR/USD exchange rate.
        • EE - We should set aside EUR150 to cover bank and credit card charges.
      37. So that takes us to - EUR16,000.
    4. Budget Recommendations to the Board
      1. MDA - So we will recommend an annual budget provision of EUR20,000 to the board.
      2. RESOLUTION-SC-2016-12:Resolution: vote: 7-0 - in favour - Recommended to Board - an annual budget provision of EUR20,000.
  18. Any other business
    1. JT – Any other business? Let’s go round the table.
    2. BB – I’m thinking of putting together a project for open spatial services - WFS, WMS etc. Some of the existing services need to be extended to cover BUFR etc, support for time-series etc.
    3. JT – Ok. Please email the proposal to the SC mail list (through SC rep WQ)
    4. JT – Ok, so no other business.
  19. Summary of recommendations to the Board
    1. PR - Re: Section 7. Election of chairperson (“SC Chair”) and vice-chairperson (“SC Vice-Chair”) of the Steering Committee (see Article A13.5):
      • The SC recommends an amendment to the Internal Rules to say that ‘the default tenure is 2 years and that re-election is routine unless others want to stand’.
    2. PR – Re: Section 10.4.2 Identification of metrics and targets for OpenWIS Association performance – Recommendations to the Board:
      • The SC recommends the following strategic goals for the next 3 years:
        1. Stabilise OpenWIS software to a supportable version with good test coverage
          • Metric 1.1: good test coverage (ACTION for TC)
          • Metric 1.2: patchable (ACTION for TC)
          • Metric 1.3: OpenWIS 4.2 released by end of March 2017; ready for operational deployment.
        2. Delivery of OpenWIS software that meets needs of operational WIS Centres
          • Metric 2.1: at least two Member or Partner organisations have deployed OpenWIS 4 and accepted it for operational use by Q4 2017… quality assessment.
          • Metric 2.2: all Member and Partner organisations have deployed OpenWIS 4 by Q4 2018 … adoption level
        3. Make OpenWIS software easily customisable for deployment at WIS centres
          • Metric 3.1: to be able to integrate with a new data-source or dissemination component (that is exposed via a REST web service API) without needing to modify source-code; configuration changes only.
          • Metric 3.2: basic customisation (e.g. colour, theme etc.) of web-based UI requires CSS change only … note dependency on GeoNetwork.
        4. OpenWIS software is being used to reach new communities
          • Metric 4.1: OpenWIS software is used by operational centres to meet ‘wider’ data portal requirements; and these portals are being actively used
          • Metric 4.2: (Meta)data exposed by operational centres running OpenWIS software is discoverable via search engines (Google, Bing, Yahoo, etc.)
          • Metric 4.3: OpenWIS software is being used to make data exposed by web-based services discoverable
          • Question: Do we know how people want to use WIS to discover content and services?
        5. Usability of the OpenWIS software is improved
          • Metric 5.1: ‘normal’ users (not WMO data managers) can easily find data and the related services
          • Metric 5.2: setting up a subscription doesn’t require reading guidance documentation (!)
        6. OpenWIS software helps metadata authors produce ‘better’ metadata
          • Metric 6.1: metadata editor provides Templates corresponding to Guidance topics from IPET-MDRD
        7. Search algorithms in OpenWIS software favourably rank ‘quality’ metadata
          • Metric 7.1: to be decided.
        8. Readiness of the OpenWIS software project for engagement with open source community
          • Metric 8.1: OpenWIS Development Process published; transparent project governance in place
          • Metric 8.2: GitHub repositories public
          • Metric 8.3: project website published
          • Metric 8.4: documentation for on-boarding new developers available
        9. Demonstrate that the OpenWIS Association provides a reusable collaborative framework
          • Metric 9.1: another project is started without adverse impact on OpenWIS ‘Core’ project
          • Metric 9.2: Average increase in KANBAN work package velocity over time (Small, Medium, Large)
    3. PR – Re: Section 11.4 Approval of strategic programme and work plan(s)
      • The SC recommends the TC work plan to the board.
    4. PR – Re: Section 14.3 Recommendation to the Board regarding new projects to establish
      • No recommendations.
    5. PR – Re: Section 15.1 Recommendations to the Board regarding admission of new Partners
      • The SC recommends ECMWF as an Associate Partner.
      • The SC recommends that MDA resumes discussions with the Canadian met service.
    6. PR – Re: Section 15.2 Recommendations to the Board regarding engagement with third-parties to participate in consortia responding to calls for proposals in respect of externally funded projects - see also item (14.2)
      • No recommendations.
    7. PR – Re: Section 16. Recommendations to the Board regarding the creation of ad-hoc committees or subsidiary bodies
      • The SC recommends that the Internal Rules are clarified on Associate Partner eligibility to participate in the TC.
    8. PR – Re: Section 17.2 Review of need for additional finance
      • The SC recommends no additional finance is required this year.
    9. PR – Re: Section 17.3 Preparation of budget for 2016/17
      • The SC recommends an annual budget provision of EUR20,000.
  20. Closure of the meeting
    1. ACTION-SC-2016-33: JT - Set a date for the next SC in June 2016.
    2. JT - Meeting closed, thank you all.

Notes (provided with the agenda)

  • Item (7) ‘Election [for SC chair and vice-chair]’: note that “The SC Chair and SC Vice-Chair shall serve a twelve month term and shall be eligible for re-election at the end of the term. There shall be a limit of four consecutive years on the term that an SC Chair or SC Vice Chair may serve. […]” (Article A13.6)
  • Item (9) ‘Recommendations to the Board regarding admission of new Members’: Article A13.3i indicates that the SC may make recommendations to the Board regarding admission of new Members. Candidates must fall within one of the following categories: (i) National Meteorological Services recognised by the World Meteorological Organization; (ii) Government Organisations which hold a mandate or authority to carry out weather and climate research and services; (iii) Other Public Organisations which, in the opinion of the Board, are constituted for a purpose which is compatible with the purpose and objectives of the Association; or (iv) Other Non-Profit Organizations (including Non-Governmental Organisations) which, in the opinion of the Board, are constituted for a purpose which is compatible with the purpose and objectives of the Association (Rule R4.4). Also note that “Applications for admission as a Member should be made in writing and addressed to the Chairperson of the Board. […]” (Rule R4.5). In assessing applications for admission of a new Member, the following matters should be considered: (i) The willingness of he candidate to abide by the Articles of Association and these Internal Rules; (ii) The compatibility of the candidate’s corporate purpose with the purpose of the Organization; (iii) The financial soundness of the candidate; (iv) The scientific and technical capability of the candidate and the compatibility f these capabilities with the Association’s purpose and its current and future strategic programmes and work plans; (v) Whether admission of the candidate would best serve the interests of the Association and its existing Members and Partners in ensuring that the purpose and objectives of the Association are met; and (vi) Any other matter which the Board reasonably feels may have a bearing on its decision (Rule R4.8).
  • Item (10.2) ‘Retrospective review of OpenWIS Association performance since SC-2015’: What have we achieved? Is OpenWIS Association meeting expectations of Members and Partners?
  • Item (10.3) ‘Strategic objectives for OpenWIS; Medium-term goals’: examples of objectives include- (i) stabilise OpenWIS software to a supportable version with adequate [automated] test coverage; (ii) ensure that OpenWIS systems operate efficiently, are inherently secure and conform to relevant standards (see Article A13.2i); (iii) automated deployment; (iv) improved user search and data acquisition experience (through functional enhancements of user portal- GeoNetwork 3); and (v) readiness for open source community engagement.
  • Item (10.7) ‘Identification of metrics and targets for OpenWIS Association performance’: the intent is drive an increase in rigour for OpenWIS operations, clarity in what we aim to achieve and accountability for achieving that outcome.
  • Item (11.1) ‘Report(s) from Technical Committee’: Article A14.1 outlines the scope of advice to be provided by the Technical Committee.
  • Item (11.2) ‘Review plan for going fully open source’: Referring to action SC-2015-21; we need to determine when the GitHub repository will be made public (open).
  • Item (11.3) ‘Resolution of issues referred to SC’: Article A13.2ii notes that the SC should adjudicate on issues about requirements, design, implementation and standards where established procedures are unable to achieve an outcome in line with the objectives of the Organization.
  • Item (13.2) ‘Amendment to Internal Rules; flexibility in choice of open source license’: Rule (R9.1) asserts that GPL3 shall be used to license OpenWIS software; this should be amended to reflect the agreement from SC-2015, Melbourne, that projects operating within OpenWIS governance framework may choose any license that has been accepted by the Open Source Initiative (OSI).
  • Item (14.2) ‘Identification of opportunities to participate in calls for proposals in externally funded projects’: The decision to participate in such calls should be approved by the Steering Committee, having due regard to the available resources; the existing strategic programme and work plan of the Association; and the interests of the Association’s Members and Partners. (Rule R2.5)
  • Item (15.1) ‘Recommendations to the Board regarding admission of new Partners’: Persons or organizations wishing to become a Partner of the Association should submit a written request to the SC Chair (Rule R5.4). Candidates for the granting of Strategic or Associate Partner status should fall within one of the following categories: (i) National Meteorological Services recognised by the World Meteorological Organization; (ii) Government Organisations which hold a mandate or authority to carry out weather and climate research and services; (iii) Other Public Organisations which, in the opinion of the Board, are constituted for a purpose which is compatible with the purpose and objectives of the Association; (iv) Other Non-Profit Organizations (including Non-Governmental Organisations) which, in the opinion of the Board, are constituted for a purpose which is compatible with the purpose and objectives of the Association; or, in the case of Associate Partners, (v) Private companies which, in the opinion of the Board, have a corporate purpose which is compatible with the purpose and objectives of the Association (Rule R5.5).
  • Item (15.2) ‘Recommendations to Board regarding engagement with third-parties to participate in consortia […]’: Subject to unanimous confirmation by the Board that doing so furthers the objectives of the Organization, the Organization may participate in consortia […] in the context of calls for proposals in respect of externally funded projects.
  • Item (15.3) ‘Management of Contributor License Agreements’: there is currently no mechanism in place to manage CLAs signed by contributors; who should be responsible for maintaining the CLA database and how should it be done?
  • Item (15.3.1) ‘Example CLA management service’: CLA Assistant is an open source project from SAP (see https://github.com/cla-assistant/cla-assistant) that integrates CLA management with GitHub identifies and workflow. A hosted instance is provided at https://cla-assistant.io/.
  • Item (15.5) ‘Provision of developer community resources’: we need to determine the set resources required to support a ‘wider’ open-source software project; e.g. development policies, developer documentation, project website, use of the forum, use of GitHub issue tracker and wiki etc. Do we want to contract a technical author to get things set up?
  • Item (15.6) ‘Communications plan’: should we publicise OpenWIS at WMO CBS- if so, how. Are there any other conferences, events or organisations that we should engage with?
  • Item (17.2) ‘Review of need for additional finance’: Article A10.2 indicates that should additional finances be needed beyond that generated through membership fees, subscriptions and contributions, then equal contributions shall be made by Members and Strategic Partners, and additional contributions (either financial or in kind) should be made by Associate Partners on a voluntary basis.

Participants

  • Jeremy Tandy [JT], Met Office, UK [UKMO], Chair
  • Matteo Dell’Acqua [MDA], Meteo France, France [MF]
  • Weiqing Qu [WQ], Bureau of Meteorology, Australia [BoM]
  • Leon Mika [LM], Bureau of Meteorology, Australia [BoM], (telephone)
  • Bruce Bannerman [BB], Bureau of Meteorology, Australia [BoM]
  • Remy Gibault [RGib], Meteo France International, France [MFI]
  • Remy Giraud [RGir], Meteo France, France [MF]
  • Baudouin Raoult [BR], European Centre for Medium Range Weather Forecasting [ECMWF]
  • Paul Rogers [PR], Met Office, UK [UKMO]
  • Martin Gollogly [MG], Scisys UK [UKMO]
  • Mikko Partio [MP], Finnish Meteorological Institute, Finland [FMI]
  • Mikko Visa [MV], Finnish Meteorological Institute, Finland [FMI]
  • Okki Lee [OL], Korea Meteorological Administration, Republic of Korea [KMA]
  • Hyekyoung Lee [HL], Korea Meteorological Administration, Republic of Korea [KMA]
  • Sungeun Park [SP], Korea Meteorological Administration, Republic of Korea [KMA]
  • Chung Shin Park [CSP], Korea Meteorological Administration, Republic of Korea [KMA]
  • Emma Edwards [EE], Met Office, UK [UKMO], (telephone)

Apologies

  • Robert Bunge, National Weather Service, USA [NWS]
  • Steve Olson, National Weather Service, USA [NWS]
  • Loic Le Gallou [LLG], Meteo France International, France [MFI], Vice-Chair