22nd - 23rd March 2017, Toulouse, France - meeting minutes

  1. Welcome and introductions
    1. JT - Welcome everybody.
    2. JT - The agenda is somewhat formulaic, because there are certain things the Steering Committee must discuss at the annual meeting.
    3. JT - Last time we met, in Seoul a year ago, the intention was to have quarterly meetings. That didn’t happen, so please accept my apologies. If we think we need a 3 month or 6 month meeting, then we can arrange to hold a meeting remotely.
  2. Approval of agenda
    1. JT - Is everyone happy with the agenda?
    2. JT - Noting that we have the flexibility to vary the discussion of some items as we go, the agenda is approved.
    3. JT - Also, we will pause the SC meeting tomorrow at 3pm, to have a couple of hours of the Board Meeting; this is so Emma, our Treasurer, can join us via WebEx.
  3. Declaration of delegates

    1. JT - Here’s reminder of the rules for the SC meeting:

      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. JT - So, we are quorate, even if WQ can’t hear us. Whenever WQ is not on WebEx, MDA is proxy.
    3. {The list of delegates, proxies and other participants is at the foot of these minutes}
  4. Approval of previous minutes
    1. JT - Any issues with the previous minutes? Hearing none, the previous minutes are approved.
  5. Outstanding actions
    1. PR - So, just running down the list of SC actions outstanding on 15th March, in reverse order:
      • 2016-32: EE - Check with Michael Robbins for fees related to trademarks.
        1. EE - I dealt with this last year and sent you something.
        2. JT - I can’t recall what the outcome was. Would you please follow-up with PR.
        3. EE - Ok, I’ll revisit.
        4. EE - Action-SC-2016-32 Check for Trademark fees
      • 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.
        1. JT - CLOSED - I will cover this on the agenda.
      • 2016-30: JT - Let’s put targeted communications on the agenda for the next SC meeting.
        1. JT - CLOSED - I will cover this on the agenda.
      • 2016-28: JT - To write a strategy paper on: Where we can deliver the most value for the broader community in the near future.
        1. JT - CLOSED - I will cover this on the agenda. I have not written a strategy paper, but that has been overtaken by events around WIS 2.0 strategy recommendations to CBS and anticipated approval by Exec Council. We can add most value by continuing OpenWIS development and contributing to the WIS 2.0 Technical Specifications and running pilot projects.
        2. MDA - Yes, the Association will bring a lot to 2.0.
        3. JT - What is the view from CBS?
        4. MDA - At the CBS last November, a strategy for the development of WIS 2.0 was proposed. During the management meeting a month ago, we looked at the way to implement WIS 2.0. We need a clear understanding of the stakeholders needs and we need to run a pilot project.
        5. MDA - CBS is looking at a project in Region I (Africa) or III (South America), because they are currently less involved in WIS.
        6. MDA - We must be sure to meet the requirements of the GDPFS. There is currently work going on in data processing and it is important that WIS 2.0 meets their requirements so that they don’t have to develop further.
        7. MDA - We must be sure WIS 2.0 is the answer to climate system requirements.
      • 2016-26: RGb - Provide to the Association the feedback received so far from users to TC and SC.
        1. LLG - CLOSED - RGb has provided a summary of the feedback
        2. LLG - Several features have been requested, the details are in the powerpoint; for example:
          • Singapore has requested improvements in Security.
          • There are also comments that OpenWIS is not so easy to manage.
        3. MDA - I have been in contact with Moscow; they have tried to use it more, to the full solution, but it is still too complicated for them to manage alone.
        4. MDA - I have had an exchange with India, but they are lost with it.
        5. LLG - We worked with Russia in their own framework, so it is a very specific solution. Now, they want a more standard solution; we are in the early discussion stage.
        6. LLG - India is difficult to progress; they are really interested but they are looking at all the options. We will try to discuss in future. Maybe they will be joining the Association? We’ll wait and see.
      • 2016-24: LLG – Clarify in the communications plan.
        1. LLG - CLOSED - Apologies, not clear what was expected, so discuss later under the agenda item.
      • 2016-23: RGib - email info about who is using OpenWIS to both TC and SC.
        1. LLG - CLOSED - This is covered in the powerpoint from RGb: feedback
      • 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?
        1. JT - CLOSED - I discussed it with Michael, but anyway the current process doesn’t use a click-thru.
      • 2016-20: JT/PR - Talk to Michael Robbins about whether an umbrella agreement would have legal standing.

        1. JT - CLOSED - The assumption is that one umbrella agreement covers all contributors from an organisation, as stated in Annex A to the Internal Rules:

          ‘You’ (or ‘Your’) shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with the OpenWIS Association AISBL. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor.

        2. JT - So basically, an organisation is a single contributor.

      • 2016-19: RGr - Investigate appetite for a project proposal with DWD.
        1. RGr - CLOSED - This was in relation to AFD. I exchanged a couple of emails. It’s the tool we’re using in the cloud-project. Should I continue? Last year we approved multiple projects in principle.
      • 2016-18: MDA - Find out if NMS Canada is interested in bringing MetPX under the OpenWIS umbrella.
        1. MDA - CLOSED - I discussed MetPX with Michel Jean. I also discussed Canada as Associate Partner. The discussions stopped because there is a new CIO in Canada. But they are happy to put MetPX in.
      • 2016-17: WQ - To do a project proposal relating an investigation work package for the OpenWIS Core.
        1. WQ - CLOSED - Done nothing apart from what we did in OpenWIS development. (Will be covered by v5 PoC later)
      • 2016-16: JT - Clarify articles that may appear to force other people to pay for your project.
        1. JT - CLOSED - If you recall last year’s discussion, we were talking about the meaning of the equal contributions clauses, Articles 10.2 and 10.3. These clauses are about finances for running the Association, not for running projects. We can use these contributions to provide tools, but not to cover costs of software development for a project. So, we can cover the costs of Association websites, repositories etc.
        2. JT - The SC must make a budget recommendation to the Board for approval, so we have mechanisms in place to ensure sensible decisions are made about what Association contributions are spent on.
        3. MDA - But how can I be sure that MF is not obliged to contribute to a project it is not interested in?
        4. JT - Because there is no obligation. I will update the Internal Rules to clarify this, by Friday. I will summarise my proposed changes when we cover new projects.
        5. MDA - The action was to check.
        6. JT - Yes and the only binding thing is equal contributions to the Association, which the Board have to approve anyway.
      • 2016-15: WQ(TC) - Define the roles in the development process - see JT doc.
        1. WQ - CLOSED - This was discussed at the Developer Conference and documented since. We discussed it further during the TC.
        2. JT - Ok, we should update the Technical Rules to clarify the roles now used in the development process.
      • 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.
          1. JT - Ok, so we keep this open until we have a Board Risk Register.
      • 2016-13: JT (through Michael Robbins) get legal advice on whether the articles shelter the contributors from litigation.
        1. JT - I did discuss this with Michael but I don’t recall the conclusion. Article 21.2 does say ‘that no member can be held personally liable’, but it doesn’t mention partners and contributors. Need to bottom that out and add to Risk register. May need to update the Articles.
      • 2016-12: JT - Make sure the role of User is clear in the internal rules.
        1. JT - CLOSED - I’ve been through the Internal Rules and Articles; there is no mention of User(s).
        2. JT - So when we update the Technical Rules, the User role should be defined.
      • 2016-08: MDA/JT will award Leon a certificate as formal recognition of his contribution.
        1. MDA - CLOSED - Apologies, this slipped out of my mind.
        2. WQ - We cannot accept a financial reward. I did mention that the SC and Board were appreciative.
        3. MDA - In WMO you have this celebration where outstanding work is rewarded.
      • 2016-04: WQ - TC to agree lifecycle patching strategy.
        1. WQ - We addressed this to some extent in Seoul. Did we cover it with the even/odd Release number?
        2. JT - No, the patch is the 3rd digit, for example 3.14.8. When we talk about the TC work plan we need to say how we will respond to security issues and do a patch release. SO, is that sufficient?
        3. SO - Yes, that makes sense.
        4. WQ - CLOSED - Ok, yes, we did have a patch release, 3.14.6, for the XSS vulnerability. That is the patching strategy.
      • 2016-03: WQ – TC to define ‘patchable’.
        1. PR - CLOSED - Originally this meant in Goal/Metric 1.2
        2. KS - We need to be able to patch Java etc.; it’s a big concern for us.
        3. JT - Do you want a change to the Technical Rules? Ask your Security folks what they mean by patchable and then add that to the rules.
      • 2016-02: WQ – Define ‘good test coverage’ as a percentage (with TC).
        1. WQ - Does this mean in our own code?
        2. JT - Yes, move away from a subjective definition of ‘good’ to something measureable. So put objective metrics of test coverage in the Technical Rules. We have improved, but there is always room for further improvement, so we just need a guideline.
        3. LLG - I don’t know if we have a pragmatic software quality statement.
        4. SO - We need to identify that, we don’t have it now.
        5. JT - So, we need a good objective definition of software quality.
        6. WQ - We got the current software from AKKA, but now we could put the quality rules in place at the start. So now we are suggesting we put something explicit in the Technical Rules.
        7. JT - Do SC want to approve or review the software quality statements or are we content to let the TC handle it?
        8. LLG - It should be light-weight, although it is very technical. A general overview approved by SC perhaps?
        9. WQ - Do the Technical Rules have the same authority as the Internal Rules?
        10. JT - Internal Rule 11 talks about Technical Rules. It says the TC shall make Technical Rules, it doesn’t say the SC approves them.
        11. MDA - I think that’s right; SC only needs to be aware of the changes.
        12. JT - Would be nice if the TC report back on progress with the Technical Rules and objective measures definitions.
  6. Election of chairperson (“SC Chair”) and vice-chairperson (“SC Vice-Chair”) of the Steering Committee (see Article A13.5)
    1. JT – I have nominated myself as SC Chair for a further term. Are there any other nominations?
    2. JT - Hearing none.
    3. JT - Nominations for SC Vice-Chair?
    4. LLG - RGr, do you wish to be SC Vice-Chair?
    5. RGr - Yes.
    6. MDA - Ok, I thank LLG for the great job he has done for us as SC Vice-Chair. I now nominate RGr as Vice-Chair.
    7. JT - Vice-Chair needs to be one of the delegates, so RGr would replace MDA as SC delegate; Ok?
    8. MDA - Ok.
    9. JT - It comes into force 30 days later, so MDA, you are still the delegate for this meeting.
    10. JT - We also note that Sungsoo Do has replaced Okki Lee as both the TC and SC delegate for KMA (by prior email).
    11. JT - Any more nominations? Ok, hearing none, let’s vote.
    12. Vote:
      1. RESOLUTION-SC-2017-01:Resolution: vote: 7-0 in favour - JT is elected as SC-Chair.
      2. RESOLUTION-SC-2017-02:Resolution: vote: 7-0 in favour - RGr is elected as SC-Vice-Chair.
  7. Election of chairperson (“TC-Chair”) and vice-chairperson (“TC-Vice-Chair”) of the Technical Committee (see Article A14.3)
    1. JT – In terms of nominations so far, WQ has withdrawn, so thank you WQ for all your efforts and dedication as Chair of the TC for the last few years.
    2. JT - I have one nomination, for TC-Chair or TC-Vice-Chair: SO
    3. JT - Are there any other nominations?
    4. SO - I spoke to LM and he said he would stand for TC-Vice-Chair, so I nominate LM.
    5. JT - Any more nominations? Hearing none, let’s vote.
    6. Vote:
      1. RESOLUTION-SC-2017-03:Resolution: vote: 7-0 in favour - SO is elected as TC-Chair.
      2. RESOLUTION-SC-2017-04:Resolution: vote: 7-0 in favour - LM is elected as TC-Vice-Chair.
  8. Recommendations to the Board regarding admission of new Members (see Article 6 and Internal Rule 4)
    1. JT - So where are we with the ECMWF partnership?
      1. BR - We have the budget. Our lawyer has returned the contract to RGr and Michael Robbins.
    2. JT - And what about Indian Met Department (IMD)?
      1. MDA - I have nothing to add to what I said before about the contact with IMD.
    3. MDA - Also, I mentioned Canada earlier.
    4. MDA - I have been in contact with the Chinese Meteorological Administration (CMA). They are trying to send a person to work with us at MF for 6 months, to see if they want to join for work on WIS 2.0, from July until the year end.
      1. JT - Interesting that they are identifying that new work is to be done and that OpenWIS is a place to do it.
    5. MDA - I had discussions with IMD at CBS and email exchanges since, but what they really want is someone to install the software for them. I explained that is not the role of the Association.
    6. MDA - Environment Canada discussions started last year, but I have not met the new CIO (of one or two months). Michel Jean (Director General) is willing to join but I need to meet the CIO.
    7. KS - Do we know at what level?
      1. MDA - Canada - Associate; CMA - Strategic.
    8. KS - Our experience with IMD is that we went and installed the system for them.
    9. KS - Is Canada looking for a DCPC?
      1. MDA - Yes, a DCPC.
    10. Anyone aware of any other potential new partners? Ok, none.
    11. JT - So, we need to make recommendations to the Board.
    12. JT - Last year we recommended that ECMWF be allowed to join as an Associate Partner.
      1. RGr - Michael Robbins prepared the draft contract and it was sent to ECMWF. There were a few comments from the ECMWF lawyer, but it’s all legalise. {RGr referenced a CONFIDENTIAL document, not copied here}
    13. JT - OK, so there are no new recommendations for Partners.
    14. JT - Also, we are not recommending any changes from Partners to Members.
    15. JT - Ok, let’s look at the ECMWF Partner Agreement.
      1. RGr - Most comments are legal, so I am unable to say whether Gregor or Michael is right.
      2. JT - Can we get Gregor and Michael to discuss online?
      3. RGr - So, regarding the interpretation, isn’t it the view of the SC that counts?
      4. BR - So, don’t we just need another iteration?
      5. JT - The work plan is the Kanban board.
      6. RGr - Regarding 4.4, is the SC accepting that suggested change and change to the Internal Rules?
      7. JT - There is nothing in the Articles that says a partner can leave. So, let’s amend Internal Rule 5 to make that clearer.
      8. RGr - Regarding 9.1/9.2, there is a question about VAT.
        1. MDA - The annual contribution is 10k Euros; would ECMWF pay less if they had to pay tax?
        2. RGr - So the 10k Euros is without VAT?
        3. MDA - Talk to the tax expert about what tax might be due and ask about the specific ECMWF case.
        4. RGr - We also need an email from ECMWF to say that they will be paying on an annual basis.
      9. RGr - Regarding 12.2.4?
        1. MDA - …currently twice… Ok, escalate to the Board meeting.
      10. RGr - Regarding 19.1, that is answered by Michael.
      11. RGr - Regarding 22.2, escalate to the Board meeting.
      12. RGr - Regarding 23.2, escalate to the Board meeting.
  9. Strategic positioning of OpenWIS Association activities
    1. Retrospective review of OpenWIS Association performance since SC-2016, Seoul
      1. JT - It is the role of the SC to prioritise the programme of work for the Association. The TC say what to do; the Board approve.
      2. JT - Last year we said:
        1. OpenWIS v3.14 would be released in April 2016.
        2. OpenWIS v4 would be released in March 2017.
        3. {For details of how that went, please refer to the report from the TC at section 10.1}
      3. JT - So we have a solid 3.14 release that has been approved for deployment in 2 organisations. Congratulations to the technical team.
      4. JT - We have gone open source; we have opened the repositories and declared a license.
      5. JT - We have brought the complementary tool excel2wis into the repository.
      6. JT - We have established the foundations for OpenWIS4 using Core GeoNetworkv3. Any comments DW?
      7. DW - As NM said, the more we layer onto Core-GeoNetwork, the more complex it gets. So we should use Core-GeoNetwork as much as possible.
      8. SO - We hope the GeoNetwork community will be cordial and excited about our proposed changes.
      9. JT - It would be useful to send somebody to the annual Core GeoNetwork meeting.
      10. JT - We’ve revamped the website so that all the rules and project stuff are visible. And we will have the Forum soon.
      11. JT - We have drastically improved the system architecture, although there is still work to do.
      12. JT - And there is more to do on distributed development, though we have made progress. The team was fragmented in Melbourne, 2 years ago, and not understanding what each other wanted. Since Seoul we’re more organised and still getting better. I am happy to point people to OpenWIS to show how to do distributed development.
      13. MF - At the GISC-WISC meeting in Melbourne recently, there was recognition that the Association is a success at working together.
    2. Review the continuing need for the OpenWIS Association
      1. JT - Given that we are talking WIS 2.0, the evolution expected by that and CMA enquiring about joining, I propose there is still a need for the Association.
      2. MDA - Even if we don’t get new members, the work is impressive and should continue.
      3. JT - Any other comments? Ok, all happy.
    3. How do we see OpenWIS Association evolving?
      1. JT - I think we have already discussed this.
        1. We have discussed how we transition to support WIS 2.0.
        2. We have discussed how we provide a better home for development projects.
      2. WQ - Also, I think we are getting more mature in our collaborative development; that’s a good sign.
        1. JT - Yes, we will continue to evolve a maturing, federated, software development process.
    4. Future requirements of WIS Centres
      1. MF (ET-WISC Co-chair) presented: Future Requirements of WIS Centres - ppt / pdf
        1. MF - It’s been an interesting few days; everyone here seems familiar with WIS 2.0.
        2. MF - The one thing I would urge you to do is to record the test results that demonstrate OpenWIS is compliant with WIS 1.0 and publish them on your web site.
        3. JT - Are there any particular recommendations you want us to endorse?
          • MF - No.
        4. MDA - When we worked on the first version of OpenWIS, we worked on SIMDAT. Are we considering applying for funding to do the investigation?
          1. JT - Earlier, we said there was no opportunity for further collaboration going.
          2. JT - SIMDAT was an EU funded project on grid-computing. We developed software that influenced WIS 1.0 Technical Specifications.
          3. JT - Should we seek funds or engagement from outside OpenWIS? We could pursue Option 4 using our own funds, or we could seek Horizon 2020 funding.
          4. RGb - Any plan to converge WIGOS and WIS? They are similar.
          5. MDA - WMO tried to merge WIS into WIGOS, but I explained that WIS is underlying infrastructure that serves several programmes.
          6. WQ - We could get funding from WIGOS or WMO?
          7. JT - Would Horizon 2020 or WMO be best?
          8. MDA - Horizon 2020; we would have to wait for Congress in 2018 to get funds from WMO.
          9. JT - So much of the Horizon 2020 funding is around Copernicus; BR are there calls that fit?
          10. BR - Not sure.
          11. JT - So, ECMWF is already managing around Copernicus. MDA, how do you want to proceed?
          12. MDA - ECMWF are close to the Directors etc. So BR could evaluate whether there are any calls in Horizon 2020 that are relevant to OpenWIS.
          13. JT - Just remember, there is a lot of admin and commitment involved in seeking this sort of funding.
      2. Evolution of WMO Core Metadata Profile
        1. JT - I’ve talked about this. Metadata could look quite different for WIS 2.0. I don’t know any more than that.
        2. MDA - So you no-longer believe that ISO19000 will be a feature of WIS?
        3. JT - If you look at INSPIRE, they have moved to more flexible standards, so I would look to leverage those.
        4. WQ - Internally, we just use JSON and MongoDB, not ISO.
        5. JT - The NM demo uses Elastic Search, which also uses JSON.
        6. BR - So, Core-GeoNetwork will support D-Cat?
        7. JT - I think it already does.
      3. How we support WIS Data Policy inside OpenWIS
        1. JT - Currently we have:
          1. WMO Essential = no access control.
          2. WMO Additional = additional policies apply - but these will vary from dataset to dataset.
        2. JT - For international data exchange, we encourage OPEN BY DEFAULT data access. Restricted terms and conditions should be by exception.
          1. But, is it even possible to enforce access control based on trust of the user?
          2. We can specify the LICENSE (data policy), so that the user knows what they should do.
          3. Once data is in the GISC Cache, access control is based on rules implemented by the GISC and trust that the user complies with the License. This is no worse than the ‘Additional’ data already shared on the GTS.
        3. JT - There is no way to uniformly synchronise the ROLES (eg: institutional, NMHS, academic/research, commercial/private sector, etc.) or AUTHORISATION policy for data in global CACHE between all the GISCs, because all the GISC implementations work differently. Also, it is further complicated if a user has multiple roles, because a user would need to select which ROLE they are in when they are accessing the data.
        4. JT - Where data is accessed via a SERVICE, authorisation can be enforced at the end-point:
          1. The user DISCOVERS the service via the WIS Catalogue.
          2. The service-end-point (eg: at DCPC or NC) may be subject to access control - determined by local policies.
          3. Only when data is put into the global Cache do you lose control.
          4. The metadata record from the WIS Catalogue describes the License/data policy.
        5. JT - We don’t want to restrict access to metadata, at least not within the WIS Catalogue.
        6. JT - So I recommend that we give up trying to be clever in OpenWIS by trying to INFER the access control policy for data in the global Cache.
        7. JT - That said, do use Groups and Roles as GeoNetwork intends, to manage the metadata creation, approval, publication and maintenance workflows.
        8. JT - Note that local OpenWIS installations may choose to restrict access to metadata, if local policies require this, but this is a much simpler case, as there is no need to synchronise metadata or authorisation policies with other catalogue instances.
        9. JT - So, we need take no further action to support WIS Data Policy inside OpenWIS.
    5. Review of Strategic Goals and Metrics (3 year horizon)
      1. JT - Goal 1
        1. We have already assigned actions to the TC to define software quality metrics at 1.1 and 1.2. Goal 1.3 can be removed because it isn’t a quality metric.
        2. PR - Action-SC-2017-39 Update Goal 1
      2. JT - Goal 2
        1. Metric 2.1 - change to ‘latest release’.
        2. Metric 2.2 - change to ‘all running a version less than 1 year old’.
        3. ADD Metric 2.3 - ‘verifiable compliance with Tech Specs’.
        4. PR - Action-SC-2017-54 Update Goal 2
      3. JT - Goal 3
        1. Metric 3.1 is ok.
        2. Metric 3.2 - change to ‘…requires a simple config change only’.
        3. PR - Action-SC-2017-55 Update Goal 3
      4. JT - Goal 4
        1. Metric 4.1 - change ‘…requirements, particularly from GDPFS and CSIS’.
        2. PR - Action-SC-2017-56 Update Goal 4
        3. Metric 4.2 - ok.
        4. Metric 4.3 - ok.
      5. JT - Goal 5
        1. All ok.
      6. JT - Goal 6
        1. Metric 6.1 - TC should talk to IPET-DD to request up-to-date metadata guidance.
        2. SO - Action-SC-2017-40 Update Goal 6
      7. JT - Goal 7
        1. This goal is ‘Search algorithms in OpenWIS software favourably rank quality metadata’.
        2. PR - This was suggested by BR last year.
        3. JT - Ok, ask BR to suggest a definition for Metric 7.1.
        4. BR - Action-SC-2017-41 Update Goal 7
      8. JT - Goal 8
        1. Metrics all ok.
        2. KS - Do we want something in there about having good documentation?
        3. JT - OK, would you be able to draft an additional metric describing ‘good’ documentation?
        4. KS - Action-SC-2017-42 Update Goal 8
      9. JT - Goal 9
        1. Metric 9.1 is ok; we have work in progress to establish new projects.
        2. Metric 9.2 - Probably needs to be a more general measure of improvements to the development process. I suggest PR drafts a new metric describing how to measure maturity of process, by next years annual meeting.
        3. PR - Action-SC-2017-43 Update Goal 9
      10. JT - So when do we want to review these? Ok, Let’s set all these actions for the SC in June so we can review then.
      11. JT - Are these goals an adequate guide for the work of the Association?
      12. SD - We talked a lot about metric 9.1 in Seoul. I suggest we are clearer about what we expect.
      13. JT - Ok, then would you please draft some words for Paul on Metric 9.1.
      14. SD - Action-SC-2017-44 Update Goal 9
      15. MDA - We have 9 goals and 8 of them relate to OpenWIS-Core. I think we are missing goals for the Association itself.
      16. JT - What do you suggest?
      17. MDA - We should have additional goals about expansion and being active on WIS 2.0.
      18. JT - The OpenWIS Association is now active in the development of WIS 2.0, so how would we measure that?
      19. RGr - These are the goals of the Core project, rather than the Association; they are PMC goals, not Association goals.
      20. JT - That’s true; a lot of the things we do in the SC/TC should be in the PMC.
      21. MDA - Each delegate should propose what the goals of the Association should be.
      22. JT - Ok, so each delegate proposes 3 goals for the SC in June, for the Association rather than the Core project, and with metrics to measure progress over the next 3 years. There will be some overlap, so we’ll probably end up with a good number. PR, if you could move Goals 1 to 8 to the Core project page and change the title of the current Goals page to ‘Goals and Metrics of the Association’.
      23. JT/SD/RGr/KS/WQ/MV/LLG - Action-SC-2017-45 Goals for the Association
      24. PR - Action-SC-2017-46 Move Goals to Project Page
      25. PR - Action-SC-2017-47 Change Goals Page Title
      26. JT - While you’re doing that, on the OpenWIS Project page, change all OpenWIS Project to OpenWIS-Core Project etc.
      27. PR - Action-SC-2017-48 Change OpenWIS to OpenWIS-Core
    6. Recommendations to the Board
      1. JT - Medium term goals; 3 year strategy
        1. JT - So we have some work to do in the SC, but no recommendations to the Board until afterwards.
        2. MDA - Shall we arrange a Board meeting after the SC?
        3. JT - Ok, we could follow the June SC with a Board meeting in early July.
        4. JT - So the SC will be around midday UK time on June 8th. The Board meeting will be on July 5th, at a time that is convenient for KMA/BoM.
        5. PR - Action-SC-2017-49 Schedule June SC Meeting
        6. PR - Action-SC-2017-50 Schedule July Board Meeting
  10. Review of recommendations from Technical Committee
    1. Report(s) from Technical Committee March 2017, Toulouse, France
      1. SO - Development
        1. The first release of v3.14 was v3.14.1 in January 2016, with the first stable release v3.14.5 in April 2016. The latest release is v3.14.7, which was released in November 2016. We are currently working on a v3.14.8 and after that we are ready to put v3.14 into maintenance mode.
        2. We have also been working on a development release of OpenWISv4 and a first version of that, OpenWIS v4.0.0, is now out and available as a demo instance.
        3. We held a Developer Conference in Washington DC in September 2016, where we formulated a better structure for the website and a package for an open source release (v3.14.7). We went open source in November 2016 with the package and improved website and announced that at CBS.
      2. SO - Operations
        1. Most centres are running v3.12 or 3.13, with 2 centres running v3.14.
        2. From the survey we find that the difficulty of the security service installation is a common issue.
        3. Most centres are taking over a week to do a full install, although the 2 centres using puppet have got this down to a couple of hours.
      3. SO - Proposed work plan for 2017
        1. For OpenWISv4 we are adopting an Overlay approach to the integration of Core GeoNetwork v3 into OpenWISv4.
        2. This will require some training and up-skilling. We have put the Developer Conference for 2017 on hold; we will do some training in the new techniques and then evaluate what the Developer Conference would cover.
        3. At the Developer Conference in 2016 we did a loose compliance check against the 1.0 Technical Specifications; we plan to develop formal tests for this, during this coming year.
        4. We discussed improvements to the development processes, including the introduction of squads and features and the level of engagement we might need with the Core GeoNetwork community. We also discussed how we would deal with external open source contributions and we will update the SC on that later.
        5. We have completed the trial of Forum software options and have chosen Discourse, so we will set that up. There will be a small ongoing cost to support that.
        6. We are also looking for continuing financial support for the development platforms, for example the MF servers.
        7. We also decided to continue with the AWS CI environment and to adapt it for use with OpenWISv4.
        8. Currently, we are planning a development release of OpenWISv4 (OpenWIS v4.1), by September 2017, followed by a stable release v4.2 in January 2018, for operations by March 2018.
        9. We ran a workshop session that generated a prioritised list of work items and we expect to start allocating the work at the next TC meeting.
      4. SO - Future strategy for OpenWIS-Core
        1. We have discussed how we would move forward from OpenWISv4/GeoNetworkv3 to take advantage of newer technologies, by considering an OpenWISv5 proof-of-concept developed for us by NM.
        2. One aspect we want advice from the SC on is: how much time we spend on OpenWISv4 versus OpenWISv5?
      5. SO - New projects
        1. MF presented on their excel2wis tool for generation of metadata, which we are recommending the SC adopt as a second Association project.
        2. MF also presented their work on Harnesses and we are recommending that we adopt a common approach to development of Harness components.
      6. JT - So if we look back over the past year, how do you think the technical group have performed?
        1. SO - Been a strong year. We’ve worked through a number of issues. Bringing European Dynamics on-board has also been a strength and a good path forward.
    2. Resolution of issues referred to SC (if any arising)
      1. JT - No issues have been received.
    3. Approval of strategic programme and work plan(s)
      1. JT - Looking forward, we are establishing feature-driven development.
      2. PR - Which will be a small change, just a slightly enhanced use of Kanban and GitHub.
      3. JT - I propose that we draw a line under OpenWISv3. If a security issue arises we will patch it, but it is in maintenance mode.
      4. MDA - Have you been through the requirements and checked there are no critical issues?
      5. WQ - We would fix any new critical issues in OpenWISv4, except for security issues.
      6. DW - Some improvements in OpenWISv4 might be backward-compatible.
      7. WQ - That would be a bonus.
      8. DW - So v3.14.8 will be the maintenance release, the latest.
      9. WQ - v3.14 was mainly an uplift of the middleware, no real new functionality or features.
      10. SO - The open source release (v3.14.7) did include the patch for Java.
      11. JT - The PMC/TC is responsible for identifying when a patch release is required and coordinating that activity.
      12. PR - v3.14.8 also contains the last updates from MF. The ForgeRock issue is not a blocker; we will work around that, make the release and then put 3.14 into maintenance mode.
      13. JT - So, on to OpenWISv4 then. We said a development release in September and an operational release in calendar Q1 2018.
      14. JT - There are significant deployment implications then for operational WIS centres, around the new Core-GeoNetwork and other changes.
      15. JT - We’ve mentioned things like bulk-subscriptions and containerisation, but what functional improvements are actually planned?
      16. DW - They are listed in the output from the TC workshop.
      17. SO - The list is on GitHub: OpenWIS4 issues. There are about 95 issues and we prioritised about 11 of them (labelled MUST).
      18. WQ - Sorry, I couldn’t attend the workshop, but I have some thoughts to add on this.
      19. WQ - Personally, I would go further with maintenance mode. I am encouraged by the v5 architecture discussion. Given the issues with Core GeoNetworkv3, JBoss etc, it’s still probably worthwhile doing a minimum viable product (MVP) version of OpenWIS4, so that we get some improvements, like bulk-subscriptions. So, release one version of OpenWIS4 at the end of this year and then look at OpenWISv5, starting early next year and, by the end of 2018, have an architecture like the one NM presented. Maybe a bit aggressive, but why put all that effort into v4 if we not using it for very long? Think of the features we really want, in v5. What is the feeling of the floor?
      20. DW - v4 is a waste.
      21. MDA - A v5 meeting the future requirements of WIS?
      22. WQ - A bit of both. We don’t have new requirements yet, but we can see some of them. By doing v5 we can shape the requirements.
      23. JT - I wanted to discuss as well… we keep talking about v4, v5 and WIS 2.0, but what do they each support? I came here thinking v5 was for WIS 2.0 and v4 will only support the existing Technical Specifications. If we stop working on v4 then centres will have new requirements coming up but we wouldn’t deliver until v5.
      24. JT - I propose recognizing the NM architecture proposal and that under a v5 project we do a pilot implementation of what we anticipate the WIS 2.0 Technical Specifications will look like. After January, we take what we learned from the v5 pilots and port that to v4. So v4 will support existing Technical Specifications, v4 never will.
      25. WQ - The basic WIS functions will still remain.
      26. NM - Because v4 and v5 are very different, any v4 work won’t be reusable, except, perhaps, a small percentage. If we want something to support the current Technical Specifications then the closest we have is v4.
      27. NM - We can anticipate v5. The question is, how do we want to balance the work between v4 and v5?
      28. NM - Also, v4 is someone else’s product that we have modified; v5 would belong to the Association.
      29. JT - So we can’t easily port v5 to v4?
      30. NM - Correct.
      31. LLG - Also, the other way.
      32. MDA - It’s not clear to me what is v4, what is v5.
      33. KS - v4 is continuation of the current architecture and Technical Specifications; v5 is new Technical Specifications, what we think we know, plus a new architecture.
      34. DW - If WIS 1.0 isn’t like WIS 2.0 then working on WIS 1.0 stuff is a waste of time, unless WIS 1.0 is in WIS 2.0.
      35. KS - Yeah.
      36. WQ - My point as well. I’m pretty sure the v5 architecture can satisfy both WIS 1.0 and WIS 2.0 Technical Specifications.
      37. KS - The good bits of WIS 1.0 would be in WIS 2.0.
      38. RGr - We haven’t yet the Technical Specifications of WIS 2.0. The ideas around WIS 2.0 are completely different. Right now we have a bit of metadata and a huge part of data in it. In WIS 2.0 we will move away from the data we have now. I can’t imagine having bulk-subscriptions in WIS 2.0, so that would be a waste.
      39. RGr - Ok, it’s a gamble, but ideas are so different that I don’t think we can count on reuse of v4 in v5, except some metadata; cache etc. will disappear.
      40. BR - From a pure development point of view, with a micro-services architecture you can change services easily, so why not start that approach in v4?
      41. NM - The problem is the missing back-end. v3 is what you used up to now. v4 is the back-end Data Services with a new front-end from Core GeoNetworkv3. So we took an external project (GeoNetworkv3) and added the v3 Data Services and then called it v4. The coding was mainly glue. From now on we have to work on fixing the 95 issues. All those fixes are trying to make Core GeoNetworkv3 compatible with our needs.
      42. NM - So with v4 we aren’t starting from scratch and doing micro-services. If we wanted to start that architecture right now we would develop the v5 micro-services architecture to support the current Technical Specifications and change later to support the 2.0 Technical Specifications.
      43. LLG - Will v5 use Core GeoNetwork?
      44. NM - No, we replace many of the functions of Core GeoNetwork.
      45. JT - Metadata management is quite heavy-weight.
      46. WQ - We are working with the v4 architecture for about a year now and it is almost incompatible; you wouldn’t choose to marry them together. Once you have the new v5 architecture you have more light-weight services and a lot of benefits from that.
      47. WQ - If you are asking me to spend more energy on v4… well, we still need to maintain it, but do the minimum.
      48. WQ - Maybe we go straight to v5? Probably a step too far. But, go to v5 as soon as possible, do current Technical Specifications and then do the future Technical Specifications as they appear. The technology we looked at for v5 addresses all the WIS 2.0 ideas.
      49. JT - So, the key point appears to be: get onto the new architecture as soon as possible and use it to support both the old and new Technical Specifications.
      50. MDA - So are we adding to Core GeoNetwork?
      51. JT - Yes, cache, Data Management, etc.
      52. MDA - v5 start from scratch, but with Core GeoNetwork for metadata?
      53. JT - But ultimately the metadata won’t look like it does now, ISO etc. But we do need to support operations for the next 5 years and we don’t know yet how we will make the change.
      54. NM - We won’t need Core GeoNetwork, we’ll have our own harvesting etc.
      55. MDA - have you looked at the cost?
      56. NM - No.
      57. MDA - That is key.
      58. SO - There isn’t a simple way forward, so we may need to proceed carefully. There will be such a paradigm shift that we need to consider training etc. We want it to be successful and demonstrate how you move from this environment to that environment.
      59. JT - Ok, to summarise…
      60. JT - The question is: how do we transition from v4 and existing Technical Specifications to, in at least 4 years time, WIS 2.0 with new Technical Specifications?
      61. JT - The proposal from the TC is to make significant architecture improvements to support the anticipated WIS 2.0 Technical Specifications.
      62. JT - The challenge is to determine how to make the transition.
      63. JT - Yesterday, we agreed to start a new project to develop our ideas on WIS 2.0.
      64. JT - Constraints:
        1. WIS 2.0 Technical Specifications will not be approved until 2020.
        2. So we need to support the WIS 1.0 Technical Specifications for 4 years.
      65. JT - WQ, your aspiration was for an OpenWISv4 MVP, followed as soon as possible by a move to the new architecture, while still meeting current Technical Specifications.
      66. WQ - Yes.
      67. JT - And as new Technical Specifications evolve we would add them into the system, which would be highly componentised.
      68. NM - That would be much easier in the v5 architecture than in the v4.
      69. WQ - Yes and it would also save some effort overall.
      70. JT - I want to ask each of the delegates what their position is… do we all understand the proposal from WQ?
      71. NM - Do we need to define the MVP for v4? How much work would it be?
      72. WQ - The TC discussed having a v4 release by calendar Q1 2018. The most important things are on the Kanban and issues tracker. We would get them fixed; no more new stuff.
      73. JT - So we’re continuing with Core GeoNetwork, looking at priority issues, about a dozen?
      74. PR - If you define the MVP as the list of issues we labelled as MUST in the workshop: MUST, there are currently 13. But that won’t be all we have to do. We have to adapt to using some of the new Core GeoNetworkv3 features, we said we will do compliance testing and anyway, general testing will throw up new issues.
      75. DW - And there are some missing features that need to be put on top, stuff AKKA put into GeoNetworkv2. We don’t know what all of these are, but things like Data Access Policies.
      76. JT - So we need further analysis to identify all that other work.
      77. JT - So let me play that back. The MVP is defined as:
        1. Core GeoNetworkv3
        2. Fixes for the priority issues (MUST)
        3. Fixes for any non-compliance
        4. Anything else v3 has that we need to put back into v4.
      78. JT - The roadmap aims for calendar Q1 2018 to deliver that.
      79. WQ - Yes.
      80. JT - Does anybody feel we shouldn’t do at least that?
      81. DW - The less complicated security services is a benefit; so are the new features of Core GeoNetworkv3 that we want. But there aren’t that many, so it’s not that much different from v3. So why not just improve v3?
      82. BS - Because we are waiting for the better metadata discovery features in Core GeoNetworkv3.
      83. DW - Ok. There is still work to be done there; I like the new tree feature too, but it’s not sufficient.
      84. JT - So this is part of the gap. So, BS, for you the new interface is important.
      85. MDA - Sorry, which version?
      86. JT - The new Core GeoNetwork is version 3, which we will use as part of OpenWIS version 4, to support Technical Specifications version 1.0.
      87. SO - Let’s frame the question: are we talking about how much to include in OpenWIS v4.2?
      88. JT - Yes, so spend 1 year on an OpenWISv4 MVP; is this the minimum we should do?
      89. SO - Most of the top issues were well aligned from the four workshop teams, so yes, that’s the bare minimum.
      90. DW - There are other things missing that will need to be fixed. Features that were in Core GeoNetworkv2 but are not in Core GeoNetworkv3: stop-gap metadata, synchronisation, reporting. Do we need these? So we might go backwards in some areas, but ok, it depends how important they are. We have the MF excel2wis metadata tool, so maybe we use that. Do we need the Alerts Page? We do need a way of alerting the System Admin.
      91. SO - A couple of things come into play here:
        1. Even though we are event driven, we are fixing the release date.
        2. We are aligning to squads and features. A new approach with some unknowns, but possibly quicker results. I am hoping the developer pool will be larger.
      92. PR - We’ll see where we are when we’ve delivered the training.
      93. JT - Because we’re agile, we have scheduled delivery, so we’ll release in September and January, if we’re willing to spend one year to get to MVP.
      94. MDA - So we’ll have a version 4 which is considered better, but it may not have all the features of version 3?
      95. RGr - MVP equals comply with Technical Specifications 1.0.
      96. JT - Yes.
      97. DW - Some compliance will be added.
      98. RGr - No, we have been audited and we are compliant.
      99. RGr - So, what is the cost?
      100. MDA - I don’t know where we are with OpenWISv4; near the end or near the beginning?
      101. PR - There is not much more to do that is entirely new. We developed much of the functionality we need to add to Core-GeoNetwork with GeoCat. It’s just that we didn’t like the way they did it, so we developed the Overlay approach to give us more independence from the GeoNetwork code and community.
      102. NM - The overlay approach allows independence from Core-GeoNetwork, but it adds some complexity, so if we throw it away in one year, it’s not worth it.
      103. MDA - We’re not throwing it away in one year. I don’t understand what is missing and what is the cost.
      104. JT - I don’t believe the TC has estimates for the tasks in the MVP.
      105. NM - If we want to develop v5 then we will throw away v4.
      106. MDA - We may consider v5 if you prove that v5 is a lot cheaper than v4 and that we can have it in less time.
      107. JT - Continuing with v4 is one of our options. We need a cost estimate for that.
      108. JT - If we continue with v4 then we start the new architecture later.
      109. WQ - The current v3 is still our operational system.
      110. JT - So v3 is still our flagship.
      111. WQ - Yes.
      112. JT - So, there may be some v3 maintenance. Can we afford v3 maintenance, v4 development and investigating the new architecture all at the same time?
      113. WQ - So after calendar Q1 next year, v4 is operational and maintenance mode; so that is when we start investigating the new architecture.
      114. JT - So if we choose to develop v4, we have to postpone new architecture work for a year.
      115. MDA - What about the option to forget v4?
      116. JT - Could we get an MVP based on the new architecture in one year?
      117. RGr - No. We have been working on v4 for two years, so v5 in a year is a dream.
      118. MDA - So can we develop v3 further?
      119. WQ - It doesn’t look good if, as an open source project, we don’t have a new version.
      120. WQ - Regarding whether we can have v5 in a year, I don’t know, but we can’t compare it with the OpenWIS we have now, that took 10 years. Now, using micro-services, it is much quicker to develop due to technology advances. We probably can, but can’t guarantee.
      121. MDA - But how long would it take to define, 1 year, 2 years?
      122. WQ - We already have a definition, based on the current system. We could make a v5 that does just what the v3 system does now.
      123. MDA - So in 12 months we could have a new system?
      124. WQ - Yes and it could be better.
      125. DW - It would help if we all saw NM presentation.
      126. MDA - Yes.
      127. JT - We said we would have finished v4 by now, 2 years ago, but, we only finished v3.14 six months ago, so we’ve spent most of our time and effort on that.
      128. JT - So let’s summarise the options:
        • Option 1:
          • continue developing v3
          • stop working on v4
          • develop WIS 2.0 pilots in new architecture and evolve pilots to meet WIS 2.0 Technical Specifications circa 2020.
        • Option 2:
          • put v3 into maintenance mode
          • develop v4 on Core GeoNetworkv3
          • develop new architecture for the WIS 2.0 Technical Specifications
        • Option 3:
          • put v3 into maintenance mode
          • work on v4 MVP for 1 year
          • then develop new architecture for WIS 1.0 Technical Specifications
          • then evolve that to support WIS 2.0 Technical Specifications
        • Option 4:
          • put v3 into maintenance mode
          • stop working on v4- develop MVP on new architecture in 1 year and release
          • evolve that to meet WIS 2.0 Technical Specifications
          • wouldn’t need to be MVP, just functional release in 12 months
      129. MP - When will the WIS 2.0 Tech Specifications be ready?
      130. JT - 2020-2022; having WIS 2.0 as the Technical Specifications for exchange.
      131. RGr - The WIS 1.0 software will survive until at least 2025.
      132. MDA - I am expecting to have a software starting to be used by 2020.
      133. JT - The Implementation Team, that I am running, are trying for an incremental implementation plan.
      134. RGr - So, there is going to be a transition or migration over some years.
      135. PR - So we will have software that can support both WIS 1.0 and 2.0 and is upgraded as things change.
      136. JT - I think Option 3 is too many architectural changes in 2 years.
      137. {Everyone agreed - Option 3 is removed}
      138. JT - Option 1 doesn’t deliver new user features for 4 years.
      139. JT - Option 4 has more risk associated with it because of the new architecture. However, WQ and ourselves both said we’re already working on these architectures elsewhere, so that’s ok.
      140. KS - How compatible is Option 4 with the squad system?
      141. PR - It’s compatible.
      142. MDA - Squads?
      143. PR - An improvement to the development process we discussed at the TC. It helps to focus on delivering finished features by assigning each feature to a sub-team.
      144. MDA - What is the benefit of having a v4?
      145. WQ - Are Options 1 and 4 almost the same?
      146. DW - In Option 1 we continue v3 development, but in Option 4 we develop v5.
      147. RGr - The main difference is that you consider v5 is not compliant with WIS 1.0 in Option 1, but in Option 4 it is also compliant with both. We don’t know how much of the current Technical Specifications we are going to keep.
      148. WQ - I don’t think that is true. We will do things that will work with both and we do know what some of the ideas are; it will not be totally different.
      149. DW - v5 with WIS 1.0 requirements, new architecture, with indication of new 2.0 Technical Specifications. v4 will all be thrown away, so with v5 we throw less away.
      150. JT - In Option 4 we may use vanilla Core-GeoNetwork as a stand alone editor, but it is integrated with the new architecture. So, some design work to get the MVP on the new architecture.
      151. RGb - So, we have started on Option 2 and the development of OpenWIS4, with the goal of being independent of Core-GeoNetwork?
      152. JT - No, the Overlay approach allows us to just plug-in our code to Core-GeoNetwork.
      153. RGb - Are we sure that this Overlay approach will still work in 2018?
      154. DW - We need to figure out what the AKKA glue was and replace it in OpenWISv4.
      155. RGr - But we don’t know what the cost of the options are. So, at the end of the day:
        • Option 1 might cost €
        • Option 2 might cost €€€
        • Option 4 might cost €€ or €€€
        • can we afford them?
      156. SO - Option 4 is riskier but may be a better path. The alternative is Option 2.
      157. DW - Another issue is where each organisation is moving, for example WQ/BoM is going for this new architecture anyway. So are UKMO and NWS. Eventually, v3 will have support issues, whereas v5 looks to the future, so Option 4 is strategically aligned.
      158. BR - You can reuse Harnesses, as micro-services, so don’t need to port everything. You can have an adapter for your SOAP services.
      159. NM re-presented OpenWIS5
      160. MDA - Have you considered having separate customer interfaces?
      161. NM - Yes, but it introduces a lot of security complexity.
      162. PR - Simpler to have multiple instances, each dedicated to a specific role.
      163. MDA - Which components serve Technical Specifications 1.0?
      164. NM - This architecture would work for any Technical Specifications.
      165. JT - So we’re assembling components, not building from scratch.
      166. DW - Which is useful for building a virtual GISC.
      167. BS - We already have Docker components for v3.14, without so much effort.
      168. MDA - I’m still not convinced that Option 4 is cheaper than Options 1 or 2; we need a better cost estimate.
      169. RGb - Not sure I understand the benefit of the private cloud.
      170. DW - So they are a DCPC or NC.
      171. RGb - So this is not a new feature, we can do this in v3.
      172. BR - So are we 1% or 90% through v4?
      173. JT - There’s an action on the TC to do that estimate.
      174. DW - I’d say about 15 to 20%.
      175. WQ - We uplifted the middleware. The only new thing was to plug in Core-GeoNetwork.
      176. BR - So that broke a lot of features?
      177. WQ - Well, some features are gone. If we abandon v4 now we are not losing much.
      178. MDA - So, UKMO, you invested a lot of effort.
      179. JT - We spent about £30k with GeoCat. We’re not looking to recover that from the Association. We’re not emotionally attached to v4. Two years ago we didn’t know that WIS 2.0 was coming; our target has changed.
      180. MDA - So Option 1 or Option 4?
      181. JT - With Option 2, if we decide we want to use Core-GeoNetwork for 4 years, that’s ok, but we would be waiting longer for the new architecture and evolution to WIS 2.0.
      182. MDA - If you don’t have WIS 2.0, which option?
      183. JT - We can still use Core-GeoNetwork standalone to do metadata management, but my gut feeling is Option 4 is my preference.
      184. WQ - I agree, rather not integrate Core-GeoNetworkv3 and the new architecture now.
      185. MDA - I like that; Core-GeoNetworkv3 would not be the core of the system.
      186. JT - So if we still need to edit ISO19115 metadata, then let’s use Core-GeoNetworkv3; but that decision is up to the TC.
      187. WQ - So if Option 4, we have to agree the design and one option is to use Core-GeoNetworkv3 as the metadata editor.
      188. JT - So MF has a preference for Option 4.
      189. MDA - Option 1 could be cheaper, no?
      190. WQ - Not necessarily; if you delay development of WIS 2.0 then you just delay the cost, not save it.
      191. JT - Option 4 is the preferred option, pending cost analysis, with Option 1 as a fall-back. With Option 1 we’re in investigative mode for longer.
      192. WQ - So with Option 1 we don’t go operational for 3 to 4 years; why?
      193. JT - To inform the development of the WIS 2.0 Technical Specifications.
      194. DW - Option 1 might become Option 4 at some point.
      195. MDA - I’m not convinced. Not sure ‘evolve v5’ is cheaper than starting from scratch.
      196. JT - Because we’re using a micro-services approach, we’d be plugging in different services, but still have the old metadata etc.
      197. WQ - So WIS 1.0 still valid; presentation is different.
      198. RGr - It is difficult to answer because we know what is not going to be in WIS 2.0, so:
        • no exchange between 15 sites,
        • no global cache sync,
        • unlikely to be ISO19115 metadata.
      199. RGr - Costs are around those 3 elements, so cost to redevelop those would be high for something we are going to throw away.
      200. RGr - We could work on improving v3 instead, making it easier to deploy etc.
      201. RGr - Considering how WIS 2.0 is going to be different, we spend a lot of time and money on something we bin.
      202. RGr - So perhaps an interface between v3 and v5 and we evolve v3.
      203. JT - We have already tasked the TC on how they would develop v4 by calendar Q1 next year Action-SC-2017-21 and what costs are involved Action-SC-2017-22.
      204. JT - So Option 2 is moribund.
      205. JT - Option 1 includes v3 with Dockerisation, a valid option, but we need more information on costs and risks.
      206. DW - So v4 is not having more work done on it?
      207. JT - OK, so here’s the proposal:
        • Ask the TC for a cost estimate for Option 4; report back in 3 months (June 2017).
      208. WQ - And also a comparable cost estimate for Option 1, with pros and cons of each option.
      209. JT - Ok, let’s vote on that:
        1. RESOLUTION-SC-2017-05:Resolution: Task TC with:Action-SC-2017-23 Future development options report; vote: 7-0 in favour.
      210. JT - So approval of the strategic programme and work plan is deferred, pending the action above by the TC.
    4. Identification of investment required from OpenWIS Association required to deliver the work plan
      1. JT - Can we summarise the key budget recommendations so far?
        1. JT - MF servers = 1700 Euros per year.
        2. JT - Do we need to renew the domain name?
        3. LLG - Yes, we do every year and we did it 3 months ago.
        4. JT - Domain name = 150 Euros per year.
        5. JT - AWS = 2000 USD per year.
        6. JT - Discourse hosting = ? To be confirmed.
        7. JT - Are there any others?
        8. SO - No.
        9. JT - Last year we said we would hire a Technical Author, but we didn’t so we paid nothing for that.
        10. SO - I don’t think we need that at this time.
        11. JT - So that’s all the costs to run the Association?
        12. SO - Yep.
    5. Review of Lead Developer role
      1. JT - With LM becoming TC Vice-chair, do we continue with the Lead Developer role?
      2. PR - I don’t think we need that now, we will have a lead developer for each squad.
      3. RGr - Could have as PMC chair, so that LM as project leader chairs the PMC.
      4. PR - Won’t the TC still be the PMC for OpenWIS-Core for the foreseeable future? We can work out what we want as we begin to use squads.
      5. JT - I propose that we decommission the Lead Developer role.
        1. RESOLUTION-SC-2017-06:Resolution: Decommission Lead Developer role:Action-SC-2017-12 Decommission the Lead Developer role; vote: 7-0 in favour.
  11. Risk review and development of mitigation plans
    1. JT - The 3 items in the earlier action on PR (Action-SC-2016-14 Add new risks to Risk Register), require us to create and maintain a Risk Register.
    2. JT - We should all consider what risks there are to the Association and how we mitigate them. Here are some I have noted recently:
      1. JT - Since the Articles do not mention Contributors, they are not covered by the rules. Article 21.2 should mention them, but since changing the Articles is hard, do we just add it to the Risk Register for now?
      2. JT - The ForgeRock repository closure; a risk that needs a mitigation strategy.
      3. JT - The CLAs have not been filled-out; easy to resolve if we all just do that.
      4. MDA - Do we, the members, also have to sign?
      5. JT - Yes, we all do, that’s what it says in the Articles. PR, you will have to update the form for adding a list of contributors.
    3. JT - Any other risks?
      1. PR - There is the bank account issue.
      2. JT - Yes, we created a new bank account with ING but they’re not talking to us; we’ll cover that at the Board meeting.
    4. JT - Ok, I encourage you all to think about risks and let PR know so he can keep a list.
  12. 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
      1. JT - You may recall that I presented a paper on project governance at the meeting in Seoul, last year: Support for multiple concurrent projects within the OpenWIS governance framework.
      2. JT - I intend to insert the proposed amendments into the Internal Rules, as a supplement. So I have taken the text we agreed last year and added it to [my copy of] the website. Shall we go through it?
      3. MDA - Yes.
      4. JT - So the proposed changes are as per RESOLUTION-AM-2016-09, agreed by the Board last year.
      5. JT - They are in pull-request #145: edits to describe governance for multiple projects
      6. JT - [Scrolls through the proposed changes]
        1. MDA - I have a question about participation. So, it’s not default that a member or partner can join a project; it is the decision of the PMC?
        2. JT - At project charter stage, MF could register an interest; you’re talking about later, when the project has already started?
        3. MDA - So the existing PMC may decide they don’t want us?
        4. JT - Yes, but you could escalate that to the SC.
      7. JT - Another thing to note: imagine we become a self-sustaining project and not all contributors are members or partners. A PMC may elect contributors, not members or partners, to the PMC. Is unanimous consent appropriate? Also, if a project leader needed to be replaced, is unanimous consent appropriate?
        1. MDA - Unanimous is hard to achieve.
        2. JT - Simple majority then?
        3. MDA - I would prefer 2/3 majority as used at ECMWF.
        4. JT - Ok, I will adjust to say 2/3 majority of PMC.
      8. MDA - How do I reach this page, on the website?
        1. JT - It’s a new branch, not the master. I am editing it on GitHub as we speak.
      9. JT - So the PMC decide what they want to do and the SC hold them to account that they do what they said.
      10. JT - Everyone happy with those small editorial changes?
        1. ALL - Yes.
        2. JT - Ok, that change is done on GitHub.
      11. LLG - What about leaving a project?
        1. JT - There’s no explicit rule, you just leave.
        2. LLG - But, perhaps that can be a problem, maybe cause a delay for the project.
        3. MDA - So the project will no-longer be able to meet deadlines. Should that be a constraint?
        4. JT - So, just looking at the paragraph: Amendments to existing projects, which mentions, regarding the assessment of level of contributions, previous contributions. If you lose reputation, you won’t get accepted onto projects in future.
        5. JT - Maybe we use the phrase reasonable endeavours to describe the level of commitment expected?
        6. WQ - Yes, reasonable endeavours is ok.
        7. JT - I would suggest it is part of project delivery.
        8. MDA - I don’t think so; we are amending the way the project will be run.
        9. JT - OK, how about a new paragraph: Member and partner commitments?
        10. WQ - Yes, ok.
      12. JT - There are a bunch of other changes associated with this section, just typos and editorial stuff I noted as I went through it; I’ll skip over those.
      13. JT - I have added a couple of extra Internal Rules under the PURPOSE section:
        1. Rule 2.10:
          • The Association may host multiple concurrent open source software development projects (“Projects”) and foster community around each of those projects.
          • Projects shall be governed according to the procedures defined in the OpenWIS Project Governance rules supplement.
        2. Rule 2.11:
          • The term “OpenWIS software” shall be taken to mean the software deliverables produced by the Projects of the Association.
        3. JT - Are those changes ok?
        4. ALL - Yes.
        5. MDA - But today, we have just the OpenWIS-Core.
        6. JT - Yes, just be clear in communications whether we mean the software or the Association.
      14. JT - So, under Rule 6, I have added the definition of a Contributor to Rule 6.1:
        1. JT - A Contributor is a person contributing to code and/or non-code activities within a Project. Individual Contributors pay no fees or subscriptions.
        2. JT - Happy?
        3. ALL - Yes.
        4. MDA - Why do we need to include this?
        5. JT - Because people need to see that they don’t need to pay 10,000 Euros to contribute.
      15. JT - Under Rule 6.4, I have clarified Associate Partner eligibility to participate in the TC. I have also done the same for Contributors and added a column for that to the table.
        1. WQ - A Contributor has no status as a member or partner?
        2. JT - Correct. So they have no rights to appoint delegates to committees or propose new projects etc. It’s in the table.
        3. WQ - If they are a contributor to another project, not OpenWIS-Core, isn’t this too specific?
        4. JT - No, this means the Association, not the project.
        5. MDA - ‘Access to software’; what does that mean?
        6. JT - They can download any Association software from GitHub.
        7. JT - They are eligible for the TC, if they have the right skills. Ok?
        8. MDA - No, we don’t have that in the rules. They are not contributing in-kind.
        9. JT - They are giving us their time; they are individuals, not organisations.
        10. JT - Note that I am not proposing that Article 14.1 is updated to mention the PMCs, because that would require consent from the King of Belgium.
        11. JT - Also note that Article 14.2 doesn’t say that they have to be a member or partner to be on the TC; they only have to demonstrate competence.
        12. JT - All are eligible to be on a PMC.
        13. JT - All happy?
        14. WQ - Didn’t quite get the last one; what’s the terms of reference for the PMC if everyone can be on it?
        15. JT - We talk about the PMC in ‘Initiation of new projects.’
        16. MDA - Are you a PMC member by default?
        17. JT - No, you are eligible to participate.
        18. MDA - Subject only to qualifying criteria?
        19. JT - We have statements about who can serve on it. The PMC vote them onto it.
        20. MDA - But we don’t explain the process.
        21. JT - What do you recommend?
        22. MDA - I don’t know.
        23. PR - So think of BR as an example. ECMWF are not yet a partner, but we have BR on the TC/PMC because we all agree that he is technically qualified, competent, etc.
        24. MDA - Yes, add the statement about the qualifying criteria.
        25. JT - Ok, so I am adding the statement from the TC paragraph. And I have broken it out. Happy?
        26. WQ - I thought MDA was saying that the PMC may still refuse a request to join, even if qualified.
        27. KS - You may leave, but still be happy for the project to continue.
        28. MDA - Can I attend the PMC, even if I have no skill?
        29. JT - You can attend the meeting, but you’re not on the PMC. If I now change ‘participate’ to ‘serve on’, to make it clear you’re on the committee. Then where it says ‘participate’, you’re just in the room.
        30. JT - Ok?
        31. ALL - Ok.
      16. JT - Just added Rule 6.9:
        1. Contributors shall comply with the OpenWIS Code of Conduct.
      17. JT - Additions to Rule 7:
        1. Rule 7.6: For every Project established within the Association, the Steering Committee shall, in accordance with Article 13.2, create a Project Management Committee with responsibility for leading each Project.
        2. Rule 7.7: The Steering Committee shall appoint a Contributor as the Project Leader for each Project Management Committee who has, in their opinion, the appropriate capacity, training, skills and/or experience to lead the associated Project.
        3. JT - So initially, the SC appoint the project leader. Ok?
        4. ALL - Yes.
        5. Rule 7.8: The Technical Committee shall operate as a cross-Project technical architecture / design authority body that provides technical oversight; (i) monitoring, guiding, and influencing the software architectures used by Projects, (ii) new Project mentoring, and (iii) maintaining and revising the Technical Rules of the Association.
        6. JT - Ok?
        7. ALL - Yes.
      18. JT - Rule 11.1; I just added Contributors.
        1. Ok?
        2. ALL - Yes.
      19. JT - So in Rule 2.10, I’ve added a link to the Rules Supplement:
        1. Rule 2.10: Projects shall be governed according to the procedures defined in the OpenWIS Project Governance rules supplement.
      20. JT - So is everyone content that we make all those changes to the website in accordance with RESOLUTION-AM-2016-09?
        1. ALL - Yes.
        2. JT - Ok, pull-request #145 is merged and closed. Does GitHub regenerate the website straight away?
        3. PR - Yes, it takes a minute or two.
        4. JT - Ok, there it is, the website has been updated already!
    2. Small changes that the Board agreed last year
      1. RESOLUTION-AM-2016-07: Clarification of the Internal Rules on Associate Partner eligibility to participate in the TC.
        1. JT - Here is the pull request on GitHub:Amended Rule 6.4 as per RESOLUTION-AM-2016-07
        2. JT - We will close this pull-request without merging - an amended version of this change was applied as part of #145, as agreed earlier.
      2. RESOLUTION-AM-2016-08: Rule 9.1 change, declaring that license is chosen from OSI list.
        1. JT - Here is the pull request on GitHub, where you can see the changes to the file: Amended Rule 9.1 as per RESOLUTION-AM-2016-08
        2. JT - Ok?
        3. All - Ok - #143 merged and closed.
    3. New changes for recommendation to the Board
      1. JT - I have prepared a small change that adds a partner contract termination clause, Rule 5.13.
        1. JT - This is pull request #146: amendment to TITLE 5 adding partner contract termination clause
        2. JT - All Ok?
        3. ALL - Yes.
        4. RESOLUTION-SC-2017-07:Resolution: vote: 7-0 - in favour - Recommended to Board - Add a partner contract termination clause.
      2. JT - I have updated Rule 6.3 to reflect our conversations on in-kind contributions:
        1. Rule 6.3 [after table]: An Associate Partner may, by mutual consent with the Association, substitute an agreed in-kind contribution for the Annual Contribution fee of €10,000.
        2. JT - This is pull request #147: updated rule 6.3 to allow in-kind contributions by associate partners
        3. JT - All Ok?
        4. ALL - Yes.
        5. RESOLUTION-SC-2017-08:Resolution: vote: 7-0 - in favour - Recommended to Board - Update Rule 6.3 [after table]: An Associate Partner may, by mutual consent with the Association, substitute an agreed in-kind contribution for the Annual Contribution fee of €10,000.
  13. 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. JT - I will just bring the section Initiation of new projects up on the screen, to remind us of the process.
        1. JT - So, for each potential new project, we are asking:
        2. Does it match the purpose of OpenWIS Association?
        3. How / if the project governance could / should be integrated into OpenWIS?
        4. Whether any other Members or Partners want to contribute resources to the project?
      2. JT - So let’s just list the projects we have for consideration today:
        1. FMI SmartMet Server
        2. WIS 2.0 / OpenWIS5
        3. excel2wis
        4. OpenCDMS
        5. Weather API Specifications
        6. RGr - WIGOS? Probably the requirement is still not clear enough.
        7. SO - During the TC, we suggested a common approach to Harness components. The idea is that, as we look at how GISCs/DCPCs work, they all have their own set of interfaces. So we could have a generic Harness, if we think: local data store, ingestion, extraction, ad-hoc subscriptions in various ways.
          1. BS - So we have a shared template for building a Harness, rather than starting from scratch.
          2. MDA - Is this a new project?
          3. JT - Data harness was always out of scope.
          4. BS - So, an API with OpenWIS and with local data, as an example.
          5. RGr - A good part of the code will be reusable with some tweaking.
          6. JT - So if UKMO was contributing, we would help with templates and contribute to the growing set of Harnesses.
          7. MDA - But is that a new project?
          8. PR - An alternative to a new project would be to have a Harness component repository within the OpenWIS GitHub.
          9. JT - All ok with that? Ok, so the recommendation is, not a new project, but a new repository under OpenWIS-Core.
      3. MV - FMI SmartMet Server
        1. Information provided with the agenda: SmartMet Server on GitHub:) and as described here and here.
        2. MV presented SmartMet Server
        3. MDA - What will it be used for in Copernicus?
        4. MV - To provide INSPIRE services, mostly.
        5. MDA - Can you show us some outputs?
        6. MV - Yes, I can show you the FMI public web pages, which are using SmartMet.
        7. RGr - So you get the JSON back from SmartMet Server and then the web page or app renders that.
        8. MV - What would it mean in practice if SmartMet Server was under the OpenWIS umbrella? We would like to build a community of contributors.
        9. BR - What about CLA, IPR etc?
        10. JT - Each project has its own OSI license. SmartMet Server already has this. We concluded that we would have one CLA that works for all projects. It says: I give permission for the OpenWIS Association to use it forever and you can’t take it away. You still own the IPR of how it is right now. As other people contribute the IPR becomes shared, but you can always fork it back again.
        11. MV - We are seeking collaboration and feedback. We run our own PMC and we have about 5 developers. We open sourced to get more features and to speed up development.
        12. JT - Currently, it sits in its own repository. In practice it doesn’t matter where it sits. Do you want to move it to OpenWIS?
        13. MDA - Would there be an impact on the Copernicus project?
        14. MV - No.
        15. JT - There would only be one project, used by FMI and all other contributors.
        16. JT - You can always copy the fork for safe keeping; we fork our UKMO OpenWIS build to Stash.
        17. BR - What matters is that people can merge changes.
        18. JT - Would you comply with the OpenWIS Association Technical Rules? There are a number of practical things to work out.
        19. JT - But, before we do that, does it align with the OpenWIS purpose?
        20. {general agreement}
        21. JT - So, the SC agrees that it does.
        22. JT - We will need to consider whether we need one GitHub organisation or two. We will need to discuss that with the TC and then the SC can make the decision.
        23. RGr - Do we imagine loose coupled projects or tight coupled? It’s important we have only one umbrella. We should have one view that opens out to the various projects.
        24. JT - So the Association web site is where you find all Association projects.
        25. DW - Would there be a separate TC?
        26. JT - There’s only one TC; there are multiple PMCs.
        27. MDA - what is the role of TC vs PMC? The TC give global rules but will not decide what is done in each project?
        28. JT - Correct. So, that is described in the document I referred you to earlier: Support for multiple concurrent projects within the OpenWIS governance framework.
        29. BR - Ok, FMI will continue working on the software for their own needs.
        30. MDA - So who is the SC for? SmartMet Server? OpenWIS? FMI?
        31. LLG - We have two kinds of project: OpenWIS, based on a WMO concept, the FMI project, based on FMI’s own requirements. So how is the governance applied?
        32. RGr - So we end up with multiple forks, like many open source projects.
        33. DW - Just want a partnership that provides promotion and technical contributions.
        34. JT - If you want to bring it into the OpenWIS Association to develop the future of the project, then the governance happens under OpenWIS Association, until you split. Is the Director of FMI happy that the OpenWIS Association SC steers the development of SmartMet Server?
        35. RGr - So clarify the concept of ‘owner’.
        36. JT - The PMC is responsible for making a plan, but SC approve it. PMCs figure out their own resources. The PMC lead would be on the TC. But, does the SC need to approve work plans for projects? Can you imagine having a conversation like the one about WIS 2.0?
        37. MDA - It cannot be like that, because not all SC members will take part in the project, so the SC cannot drive the project.
        38. JT - The SC is for the Association.
        39. MDA - So SC decisions are global to all the projects. So the SC should not be steering the OpenWIS-Core project.
        40. JT - SC might be making decisions about suitability; the PMC should be driving the project.
        41. BS - So, would a project join just for the governance?
        42. RGr - The PMC is still not in place; will it work for FMI SmartMet Server? So, the description of the PMC can be amended if needed.
        43. JT - The project governance changes are due to be published soon. I’ll go through the articles and rules and see what needs to change about the way the SC/TC/PMC works.
        44. MV - Work with the TC to determine how the SmartMet Server project might operate within the Association in practical terms (eg: where should repos be, how would PMC work etc). Draft a Project Charter and report back to SC in June on feasibility.
        45. MDA - Do we also have all the elements needed to set up a new project? Suppose we all want to participate, FMI will come with a roadmap, Copernicus also have requirements; what will be the process to introduce our requirements?
        46. JT - You get a seat on the PMC if you are putting resources in. If we left it entirely to FMI then ECMWF would be concerned. People on the PMC are those most engaged in developing the project.
        47. JT - Do any other partners anticipate contributing resources and using SmartMet Server?
          1. JT - At UKMO we have no C++, so we probably wouldn’t be active.
          2. BS - At MF we could perhaps use it or test it.
          3. JT - And so contribute that way with documentation and test reports etc.
          4. JT - The PMC would manage RFCs.
          5. BR - We will be using it as part of Copernicus. We will be contributing, but we will be keeping the IPR.
          6. JT - So you keep the IPR but assign a perpetual license.
          7. BR - The background/foreground IPR belongs to OpenWIS.
          8. MDA - The project will be reporting to Copernicus. ECMWF can be on the PMC and bring the money to the table to get what they want.
          9. JT - Would MF be interested in contributing?
          10. MDA - Maybe. I need more information. We have some software that does this, but, maybe.
          11. KS - I am intrigued. We have a C++ developer. Maybe.
      4. WIS 2.0/OpenWIS5
        1. JT - So is this a new project?
        2. LLG - Do we need to conclude our discussion about OpenWIS4 vs OpenWIS5?
        3. MDA - A new project for WIS 2.0.
        4. JT - Ok, don’t call it OpenWIS5. A new project for whatever the software is that will meet the WIS 2.0 Technical Specifications.
        5. PR - Initially, it will just be the go-to place for the documentation.
        6. BR - Ok, so give it a code name.
        7. MDA - It is really important to start work on this.
        8. MV - What form will it take?
        9. JT - OPAG-ISS will develop the WIS 2.0 specifications, which we, individually, can influence. So, we should write a project charter, using a code name. Can you suggest a code name BR?
        10. BR - Eh?
        11. LLG - So this is to experiment with technical architecture and interpret new technical specifications.
        12. JT - We would start with some pilots; it may morph into some software.
        13. MDA - Do we have information on cost or manpower in the charter?
        14. JT - What we agreed last year was that the charter covers the scope and duration of the incubation phase.
        15. MDA - What is the process to bring a new member or partner into this project.
        16. JT - You mean CMA? They would have to join the Association to be on the PMC. Or, they could be individual contributors if they didn’t want to influence them.
      5. excel2wis
        1. JT - So, we accept excel2wis into the existing OpenWIS organisation and put the repository there, rather than set up as a new project?
        2. ALL - Yes.
      6. OpenCDMS
        1. JT - Bruce Bannerman forwarded me an email. The main points from that are:
          • There has been no further substantial development at this stage.
          • The initial bid for GFCS funding via CSIS appears to have been torpedoed
          • There appears to be growing support for Open-CDMS from within WMO. This may see the concept opened up to other domains, such as hydrology.
          • We have several other funding bids out there
          • It appears that climate data management, data rescue and CDMS funding is becoming a hot topic.
          • EC requested the CCl MG to put together a strategic plan
          • Bill Wright is putting together a draft for this year’s EC
          • If it gets approved, there may hopefully be some funding for:
            • Maintenance of several existing open source CDMS
            • A Prototype of Open-CDMS
          • Bruce Bannerman is currently about to start a few months work on some Open-CDMS related tasks. I’ll need to liaise with you both on some aspects:
            • A high level proposal for an Open-CDMS Prototype, based on the roadmap that I did two years ago.
            • A revised Roadmap for CliDE and Open-CDMS
            • Ideas for work packages that will help to start building an extended Open-CDMS community. We’ll present these at a CDMS developer’s meeting proposed for the end of this year.
        2. JT - So, at this point, I suggest we take no action.
        3. MDA - Do we have the project charter?
        4. JT - Bruce hasn’t done it yet.
        5. MDA - What’s the meeting in the last paragraph?
        6. JT - It’s not an OpenWIS meeting.
        7. MDA - Should we attend?
        8. JT - Not as OpenWIS Association.
      7. Weather API Specifications
        1. JT - At the UKMO, we are about to redevelop our web APIs, using RESTful web services, for gridded and point data. Over the coming 18 months, about 12 FTE will be working on these new end-points.
        2. JT - Developing the specifications for this API would be a good shared project. The output would be common patterns for weather data access using REST. We discussed this at a previous meeting, but we took no action. If we collectively take action now to develop these patterns, then there is a good chance they will become standardized.
        3. KS - SO is keen.
        4. LLG - WMS, WCS?
        5. JT - Not OGC web services, RESTful web services.
        6. BR - So, here is a flowchart for a REST API we are working on at ECMWF. It provides for genuinely asynchronous web services.
        7. JT - Discussions about the payloads are also needed.
        8. BR - this is how it works:
          • If the data is ready
            • you get a 200
            • you get the data
          • Else
            • you get a 202
            • you get the url of where to get the data later.
        9. JT - Is ECMWF happy for us to reuse this?
        10. BR - Yes. You will find a client in several languages.
        11. LLG - For big data?
        12. BR - Yes.
        13. JT - Is it worth a project charter?
        14. MDA - Yes.
        15. LLG - Can you give an idea of a use-case or proposal?
        16. JT - So, we’ll describe the purpose in the project charter.
    2. Identification of opportunities to participate in calls for proposals in externally funded projects
      1. JT - Should we be interested in Copernicus? Or is it easier as individual organisations?
      2. MDA - Individual.
      3. JT - Any others? Hearing none.
    3. Recommendation to the Board regarding new projects to establish
      1. JT - There are no recommendations for new projects, until project charters are ready.
  14. Outreach, communications and community
    1. Recommendations to the Board regarding admission of new Partners
      1. JT - There are currently no recommendations regarding the admission of new partners.
    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
      1. JT - Yesterday, we asked BR to check for any Horizon 2020 (EU) funding calls to support evolution of WIS 2.0. So, KS, SD, WQ, are there any funding calls in your regions?
      2. KS - I could look into it.
      3. WQ - I doubt there are any in Australia, but I can check. How much are we asking for?
        1. MDA - In Europe, usually you are asked to provide half of the funding. So, for a €2M project, €1M funded by the EU and €1M funded by the Association.
        2. JT - So, say a 3 million AUD project.
        3. WQ - So we’re looking for half?
        4. MDA - That is the way it works in Europe; the manpower we are putting into another project is half the project cost.
        5. WQ - Ok.
      4. JT - Anything in KMA?
        1. SD - I don’t think so.
      5. JT - We said we wouldn’t ask WMO because of the delay. But for next year’s SC we could put that on the agenda; how we engage with WMO.
    3. Management of Contributor License Agreements (CLA)
      1. JT - The CLA has been published on the website for a while now.
      2. JT - We are using a manual process rather than a click-thru, at this stage.
      3. JT - So the CLA needs to be agreed by each of our Legal departments.
      4. JT - Article 9.7 says that: All member and partner contributors (staff and contractors) must sign the CLA.
      5. JT - So, all delegates must get the signatures of all contributors:
      6. WQ - The lawyers at BoM made some comments.
        1. PR - Yes they did; they are with Michael Robbins for review. We are still waiting for responses from everyone else. We will need something from you all, even if it is ‘no-comment’, which will be taken as acceptance. Would it be helpful if I sent a reminder?
        2. ALL - Yes.
        3. ok, will do:
      7. PR - The CLA is an Annex to the Internal Rules, so you will find the link at the foot of the contents page for the Internal Rules:
      8. PR - Within the agreement text is the obvious link to the form itself (Sign me up!):
      9. PR - You will also find a link to the page that describes how contributors should be dealt with and how the CLA forms are managed:
      10. MDA - So, why do we need these?
        1. JT - To protect contributors and the Association from any rights issues; to avoid the SCO-Unix problem.
        2. MDA - Where are we keeping them? Do we have a paper copy? A backup?
        3. PR - They are kept in the GitHub repository, so it is backed up as part of the GitHub infrastructure. Also, because the repository is distributed, everyone who has forked it has copies.
        4. JT - Perhaps MF can take a printed copy and put it in a safe? Check with MF legal whether a hardcopy of each signed CLA Form is required:
      11. WQ - I thought it was only external contributors who needed to sign these; does this apply to members and associate partners too?
        1. JT - The relevant article says that all members and partners and contributors must sign the CLA.
        2. WQ - Ok. Am I signing for myself or for BoM?
        3. JT - ACTION-SC-2016-20 from last year was on me to discuss jurisdiction of an umbrella agreement. So, in section 1.Definitions, of the CLA, I have provided a clause that allows a contributor to be an individual or an organisation.
        4. WQ - Do we see any difference legally, between BoM signing and WQ signing as an individual?
        5. PR - We still need the GitHub-IDs of each individual contributor and their names.
        6. WQ - This paragraph is trying to make the life of the contributors easier, so, Ok.
      12. PR - So, shall we say the SC in June will review the final comments on the CLA?:
    4. Community growth strategy
      1. JT - In general, we’re content to grow what we’re doing by building better software and experience and expertise, as we do that. We have some other organisations interested in joining. We’re not in a rush to get lots of external contributors. If we get some, then ok, but we’re not actively seeking any. Does that sound right?
      2. RESOLUTION-SC-2017-10:Resolution: vote: 7-0 - in favour - We will not actively seek external contributions for the next year.
      3. JT - As we look ahead, we want to engage more with the OSS community, so, should we try to engage with some OSS conferences? For example:
        • FOSS4G
        • OSCON
        • Community Development Leadership Summit
      4. WQ - For what reason?
      5. JT - Well, we might go to FOSS4G to better understand the context for OSS development and to promote OpenWIS.
      6. WQ - If we have the time and resources, then maybe.
      7. JT - A few years ago, UKMO sponsored a hackathon at FOSS4G, for £25,000. As well as running the hackathon, we put posters up, did presentations etc. We might want to do that next year, it’s too late for this year’s event.
      8. KS - FOSS4G this year is in Boston. By engaging with FOSS4G, we might network with GeoNetwork, show them what we’re doing and maybe attract them to what we’re doing.
      9. JT - So for next year we would need to think about it this year. Should we investigate, make a proposal?
      10. JT - What happened after the FOSS4G we sponsored was we got our tools put on the OSGeo DVD and increased the number of users.
      11. MDA - We need to understand the benefits.
      12. KS - We should at least go to give presentations, to raise awareness.
      13. JT - So, let’s ask ourselves what the benefits might be:
        1. FOSS4G - probably the best fit. So do an analysis of how we might engage in 2018; just turn-up, present, or sponsor?
        2. Identify other conferences that we might, as individual organizations or as the Association, send people to. Find out the dates for submissions etc. and decide if we should put something in.
      14. MDA - Is this to present the Association or the software?
      15. JT - To be decided. Could be interesting to do both.
      16. JT - KS, is NWS sending somebody to FOSS4G this year?
      17. KS - Don’t know yet.
      18. JT - Could you look at how the Association might engage with FOSS4G?
      19. KS - Yes.
      20. JT - Ok, then UKMO will consider if there are any other relevant events.
      21. JT - Maybe we could even hold our Developer Conference at FOSS4G?
      22. JT - As we promote ourselves as providers of OSS and develop pilot projects for WIS 2.0, we may find that others, JMA, say, might take our software and use it, without making a contribution. I think that would be fine; we would be supporting WIS.
      23. MDA - I hope that will happen.
      24. KS - Maybe IMD would do that.
      25. MDA - In India, they are running OpenWIS?
      26. LLG - No, the tender was cancelled.
      27. MDA - As it is today, they will never be able to install it themselves.
      28. JT - It’s fine too if others just want to take some of it.
      29. KS - Yes, they may fork our repository and use or modify it, but never put back.
      30. JT - Anything else on community growth? Ok, hearing nothing.
    5. Communications plan
      1. JT - Last year we prepared for WMO CBS. Are there any WMO meetings this year that we want to prepare for?
      2. WQ - WMO Executive Council?
      3. JT - The submission deadline for that passes in 6 days. I’m not sure the Executive Council is the right place to tout software.
      4. WQ - Rather than the Association?
      5. JT - We only have one software currently. Perhaps mention pilots for WIS 2.0?
      6. MDA - Too early; WIS 2.0 will not even be a side event this year. In 2018 there will be a side event and it would be good to say what we are doing on WIS 2.0. Also, we will be clearer ourselves. I will consider it.
      7. MDA - I don’t know where we could go to present what we are doing. At CBS we discussed OpenWIS, but not sure we get valuable feedback.
      8. JT - We’re not ready to go specifically to talk OpenWIS.
      9. MDA - This year, there is the WMO Workshop on Information Management; we could put the effort into that. I think it is in September.
      10. JT - MDA, I imagine you’re involved in that?
      11. MDA - Yes, I could consider that too:
      12. JT - So I think we have concluded that there is nothing specific for the Communications Plan right now?
      13. ALL - Agreed.
    6. Review need for Community Manager and any other new roles
      1. JT - We’ve already said we’re not ready yet to employ a Community Manager. So I propose that we look at the document we circulated at last year’s SC and just check if we should be doing any of those things now. We could take that away and report back.
      2. MDA - Ok, yes, we’ll report back.
      3. JT - LLG, would you be able to look at the Community Manager role to see who could be doing what?
      4. LLG - Ok, yes:
      5. JT - PR, would you attach the description of the Community Manager role to the minutes?
      6. PR - Ok, yes:
      7. Description of Community Manager role
  15. Recommendations to the Board regarding the creation of ad-hoc committees or subsidiary bodies
    1. JT - We are not recommending the creation of any subsidiary bodies at this time.
  16. Finances of the OpenWIS Association
    1. Challenges arising from existing funding mechanisms
      1. MDA - We have an issue that relates to in-kind contributions to the Association. A lot of new members would prefer in-kind manpower contributions rather than money. We don’t define the equivalent of €10,000 contribution as an in-kind contribution.
      2. JT - When the fees are spent, they are spent to help the Association, not to help a project. So, in-kind cannot be just to a project; it has to be for the Association facilities or other help to the Association as a whole.
      3. RGb - If you want to improve some software by manpower then is that a problem?
      4. JT - You can affiliate with any project, there is no need for equal contributions.
      5. MDA - So, you are contributing to the running of the Association; what is the equivalent of €10,000?
      6. JT - 20 days.
      7. MDA - Ok, so long as it is stated somewhere.
      8. RGb - How do you control that?
      9. JT - The Internal Rules talk about in-kind payments.
      10. MDA - But we would close the door to some.
      11. JT - You can be a contributor without being a partner or a member.
      12. MDA - But I won’t be able to sit on the committees.
      13. JT - If you prove your good-standing then you can be elected to the PMC. You can only propose a new project if you are a partner or member.
      14. MDA - What about Russia, say? We would like to have them on-board, but they cannot contribute to the Association.
      15. JT - So removing the in-kind clause would be a problem?
      16. MDA - Yes, could close the door on some.
      17. RGr - So if we are discussing a real contribution, we can work with them to see what works.
      18. JT - So, in-kind contributions shall be mutually agreed prior to contract signature.
      19. MDA - Agreed by who?
      20. JT - The SC.
      21. RGb - Not the Board?
      22. MDA - Will be a Board decision in the end, but it cannot be a project contribution.
      23. KS - So if not project related, it’s very limited.
      24. JT - So, they could run the Forum, say.
      25. RGr - Ok, why exclude the projects? The annual budget is less than 10,000 Euros for the Association.
      26. MDA - So I can give 10 FTE, but I cannot sit on the Board?
      27. JT - So we just say that in-kind contributions will be by mutual consent prior to acceptance into the Association.
      28. JT - OK, I’ll draft that this evening.
      29. JT - Action-SC-2017-52 Internal Rule on in-kind contributions
      30. JT - There is nothing in Internal Rule 6 about in-kind, so we can add one.
      31. MDA - Look at Internal Rule 4.10, that’s where it mentions in-kind.
      32. PR - So why not wait until it comes up, as RGr suggested?
      33. MDA - But people look on the website and it is not mentioned.
      34. JT - So we direct them to Internal Rule 6, where they see the fees; it doesn’t mention in-kind. Then as the president, if an organisation comes along and says: I don’t want to pay 10,000 Euros, but I’ll put some effort in, we’ll play it by ear. And I could amend Internal Rule 6.3 to say that Associate Partners may make an in-kind contribution, to be mutually agreed within year; only for annual contributions, between the Associate and the Association, in place of a financial contribution.
      35. MDA - Ok.
    2. Review of need for additional finance 1. JT - We have over 395,000 Euros in the account.
      1. JT - I propose that we need no additional funding this year. Vote?
      2. RESOLUTION-SC-2017-11:Resolution: vote: 7-0 - in favour - Recommended to Board - No additional funding required this year.
    3. Preparation of budget for 2017/18
      1. JT - So we’ll through the budget and list the items.
      2. EE - Last year, we put 1000 Euros in for Trademark transfers.
      3. JT - So the items we have so far (Euros):
        1. MF servers = 1700 per year
        2. Tax expert = 1200 per year plus VAT
        3. Late payment fine = 50
        4. Trademark transfer = 1000
        5. Domain name renewal = 150
        6. AWS CI environment = 2000
        7. Promotional material = 500
        8. Discourse Forum = 1200
      4. JT - We decided we didn’t need the Technical Author or the Community Manager.
      5. JT - So total anticipated expenditure is 7800 Euros for the year. Anything else?
      6. EE - Bank account fees of about 150 Euros.
      7. MDA - I have not been able to sort the bank account with ING. We will have to go through the process again; go to Brussels and do all the paperwork on one day.
      8. RGr - I have a couple of others. First, shall we give up with ING? Shall we ask the tax expert if he can help us?
      9. JT - Yes, he may know banks predisposed to AISBL. We have a problem, not being able to spend our own money, so let’s get some help.
      10. RGr - I will ask what he can do and what it would cost and then report to the Board.
      11. MDA - So add provision for that help.
      12. JT - Ok, how about a 2000 Euro contingency?
      13. MDA - Ok.
      14. RGr - Second, when we move the 390,000 Euros to Belgium, we need to check any tax aspect. In theory, the contributions come from members to the Association, so the Belgian tax system may take, say, 10%.
      15. JT - If that happens then we’ll hold an emergency Board meeting and amend the budget.
      16. RGr - So, I’ll check with the tax expert.
      17. RGr - Action-SC-2017-51 Money transfer tax
    4. Budget Recommendations to the Board
      1. JT - We expect about 8,000 Euros expenditure and about 2,000 Euros contingency, so a budget of 10,000 Euros.
      2. JT - So, recommend to the Board?
        1. RESOLUTION-SC-2017-12:Resolution: vote: 7-0 - in favour - Recommended to Board - an annual budget provision of EUR 10,000.
  17. Any other business
    1. MV - FMI are happy to host the annual meeting next year, in Finland.
    2. WQ - None.
    3. SD - None.
    4. KS - None.
    5. MDA - None.
    6. LLG - None.
    7. JT - PR and I were having thoughts about how to gather the requirements for the analysis that we asked the TC to do. We propose to send DW to Athens for a few days to work with European Dynamics. We would like BS to be there as well, to improve the quality of the outcome. We were also wondering if NWS and MFI would want to participate?
      1. WQ - What is this about?
      2. JT - The cost estimates for building the v5 architecture, based on the Options 1 and 4 we discussed earlier. We’re looking to quickly feed the requirements to European Dynamics so they can provide these estimates in time for the June SC.
      3. WQ - Ok.
      4. MDA - Yes, MF will send BS.
      5. PR - We recognize that the cost of attending in person would be difficult, especially for BoM and KMA, so we’re proposing this as a first-cut, which we all review and refine later.
      6. MDA - Ok, yes, it’s a good idea.
  18. Summary of recommendations to the Board
    1. PR - recommendations:
      1. Add a partner contract termination clause, Rule 5.13 - pull request #146: amendment to TITLE 5 adding partner contract termination clause
      2. Update Rule 6.3 [after table]: An Associate Partner may, by mutual consent with the Association, substitute an agreed in-kind contribution for the Annual Contribution fee of €10,000 - pull request #147: updated rule 6.3 to allow in-kind contributions by associate partners
      3. No additional funding required this year.
      4. An annual budget provision of €10,000.
  19. Closure of the meeting
    1. JT - So, we’ve agreed an ad-hoc SC meeting on 8th June 2017. Draft agenda:
      1. Review the costed proposals from the TC on the work plan.
      2. Assess the goals for the Association.
      3. Review the project charters from KS and JT.
      4. Review the funding calls.
      5. Review the legal comments on the CLA.
    2. JT - We also agreed to hold an ad-hoc Board meeting on 5th July 2017. Draft agenda:
      1. Review SC recommendations on the work plan.
      2. Review SC recommendations on the project charters.
      3. Election of officials.
      4. Risk management review.
    3. JT - Thank you all for your hard work. I look forward to seeing you all in Finland in 2018. The meeting is now closed.

Participants

  • JT - Jeremy Tandy, Met Office, UK [UKMO], [delegate], Chair
  • MDA - Matteo Dell’Aqua, Meteo-France, France [MF], [delegate] (proxy for WQ for afternoon sessions)
  • WQ - Weiqing Qu, Bureau of Meteorology, Australia [BoM], [delegate], (WebEx)
  • SD - Sungsoo Do, Korea Meteorological Administration, Republic of Korea [KMA], [delegate]
  • KS - Kari Sheets, National Weather Service, United States of America [NWS], [delegate]
  • LLG - Loic Le Gallou, Meteo-France International [MFI], [delegate]
  • MV - Mikko Visa, Finnish Meteorological Institute [FMI], [delegate]
  • SO - Steve Olson, National Weather Service, United States of America [NWS]
  • RGb - Remy Gibault, Meteo-France International [MFI]
  • MP - Mikko Partio, Finnish Meteorological Institute [FMI]
  • BS - Benjamin Saclier, Meteo-France, France [MF]
  • RGr - Remy Giraud, Meteo-France, France [MF]
  • BR - Baudouin Raoult, European Centre for Medium Range Weather Forecasting [ECMWF]
  • PR - Paul Rogers, Met Office, UK [UKMO]
  • MF - Mark Francis, Met Office, UK [UKMO]
  • DW - Dominic Woollatt, Met Office, UK [UKMO]
  • NM - Nassos Michas, European Dynamics, [UKMO]