Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Action-TC-2017-22 Add pilot proposal OPP-JT #304

Closed
rogers492 opened this issue Aug 11, 2017 · 5 comments
Closed

Action-TC-2017-22 Add pilot proposal OPP-JT #304

rogers492 opened this issue Aug 11, 2017 · 5 comments

Comments

@rogers492
Copy link
Contributor

Add a new pilot proposal based on the rough ideas from @6a6d74 that were discussed at the TC on 10th August 2017.

@rogers492 rogers492 added this to the SC September 2017 milestone Aug 11, 2017
@rogers492 rogers492 self-assigned this Aug 11, 2017
@rogers492
Copy link
Contributor Author

55. JT - Ok, let me outline some rough ideas I have about WIS 2.0:
    1. JT - Say WIS 2.0 will have a set of standards you can layer on top of each other: TCP/IP, HTTP, URL.
    2. JT - Then, if you're publishing data, you could just publish some web pages that are human-readable.
    3. PN - And the actual data could be in an S3 bucket on AWS.
    4. JT - OK, but how would you discover that data? You can use the S3 bucket to hold the base data and combine with a human-readable web page to provide the catalog.
    5. WQ - Isn't that how OpenWIS works?
    6. JT - Yes, but it is complex.
    7. PN - S3 bucket with Elastic Search on top; you could get notified of new data that comes in.
    8. JT - That's jumping to Elastic Search as the solution and inferring that you're indexing by crawling the files.
    9. WQ - An expert can find the model data without metadata; no need for the web page.
    10. DW - Is that just because the metadata is already in the filename?
    11. PN - That's all we're currently doing with our S3 NetCDF files, storing files with WMO headers.
    12. JT - We're getting rid of WMO headers; when the data is visible on the internet you won't need local addresses on private networks.
    13. PN - We'll still need some metadata.
    14. JT - I agree. We've talked about commercial search engines; you want them to crawl web pages to find some structured markup. It is metadata, but not as we employ it currently, which is painful!
    15. PN - That metadata is not our responsibility.
    16. PR - How does the metadata get into the human-readable web pages?
    17. JT - These pages use [schema.org](http://schema.org/) and the metadata is usually implemented as [JSON-LD](https://json-ld.org/) inside the pages. Simplest way to generate web pages, if the service endpoint is static, is write web pages with tags, or generate by parsing. The [ESIP](http://www.esipfed.org/) convention tells you what you should include in NetCDF so you can populate web pages. On Copernicus, ECMWF is managing the metadata in GeoNetwork, then taking it and publishing a web page, not publishing the metadata catalog itself.
    18. SO - What is exposed? How easy do you make it for the end-user?
    19. JT - You only put in what makes it easy to distinguish between the types of data available. If we rely on commercial search engines, they will use sitemaps and crawlers, old technology. One of the things we need to be able to do is retain an authoritative view of what data is published by WIS centres. We would need a simple register to create a list of what data is available. Jumping to solutions again, but maybe we could use Elastic Search to do that.
    20. PR - We are short of time to get a demo ready, and since it's only a pilot, we _should_ jump to some solutions.
    21. JT - So we would need to create a list of data available from the WIS centres. We could test how centres would make their data available: for example - _my site map is here, come harvest my data_.
    22. PR - This sounds as if it would make a good proposal for the demo - OPP-JT.
    23. DW - Could we include subscriptions?
    24. JT - Interesting point: so we might have HTTP URLs, maybe through S3 buckets; so now we have to put files on a queue to be subscribed to, even if it is a simple file or a web service.
    25. SO - It is something tangible; pub-sub is an extension to this.
    26. JT - Yes, we could layer the pub-sub on top.
    27. SO - A hybrid of OPP-2 and OPP-JT.
    28. WQ - I can't see a link between that PoC and OpenWIS v5.
    29. JT - What does OpenWIS become if we strip out the infrastructure?
    30. PR - Cheaper.
    31. JT - Yes, cheaper, easier, etc.
    32. JT - So we do some components that do pub-sub and some that form the metadata. Sounds like I need to write something down.
    33. PR - I could draft OPP-JT from the notes I've taken and you can edit it:
        - [Action-TC-2017-22 Add pilot proposal OPP-JT](https://github.com/OpenWIS/openwis-documentation/issues/304)
    34. JT - Make sure we're clear on the purpose: to publish data as static files.
    35. PR - So refer to the Djibouti User Story?
    36. JT - Yes, a User Story not framed in WIS 1.0, GISCs, global hubs etc.
    37. SO - We could modify the OPP template to bring in how the proposal ties into something we can demonstrate and also relate to Users.
    38. PR - Ok, so a section of the proposal could describe the high level User Story.

@rogers492
Copy link
Contributor Author

  1. Introduction
    The OpenWIS Association hosts multiple open source software development projects that support or enable the exchange of global meteorological information. We use the GitHub platform for our collaborative development. The rules and expectations for participating in an OpenWIS® Project are defined in the Technical Rules and the Code of Conduct.
    As stated in Article 11: Management Structure, there are three main bodies responsible for governance within the OpenWIS Association:
    · the Board;
    · the Steering Committee; and
    · the Technical Committee.
    This document establishes the foundation for the Project Team to begin developing , through an incubation phase, the next iteration of the OpenWIS core software. A new naming convention for the core software is also within scope of this charter.

1.1. Purpose
The purpose of this charter is to outline the scope of this project, identify the contributing members and define their responsibility
1.2. Scope of Authority
This task team is charged with conducting a pilot study on …..
1.3. Authority
The authority for this project comes from the OpenWIS Steering Committee (SC) on recommendations from the OpenWIS TC. Outcomes from this and other pilot studies provide insight into WIS 2.0 specifications, and will ultimately factor into an architectural design and overall OpenWIS 5 plan with timelines.
2. Project Task Overview
Overview of pilot study task.
2.1. Project Task Statement of Need
Discuss the relevance for this project.
2.2. Project Task Scope
Describe the Project Scope here
Describe what the Project team is responsible for:
· Item 1
· Item 2
· Item 3

2.3. Project Task Goals
Describe the Project Task goals here.
2.4. Project Task Deliverables
Provide a bulletized list of expected deliverables for the Project Task:
· Deliverable 1
· Deliverable 2
2.5. Project Task Resources and Roles and Responsibilities
Short discussion on resources to be used in the project task. Tie in table A here.

Resource Name Organization Role Responsibility Time Period needed for resource

Table A– Task Roles and Responsibilities

2.6. Project Task Milestones & Schedule
Table B provides the task milestones and schedule.

Project Task Milestone Begin Date End Date
Milestone 1 3/27/2017 6/1/2017
Milestone 2 6/8/2017 6/15/2017
Table B– Task Milestones and Schedule
3. Task Meetings
Define frequency of task meetings. Regular, ad-hoc, etc.
4. Configuration Management Process
Define process for checking in/out code associated with pilot study

  1. Communication and Reporting

Define interactions with PMC including report outs at PMC meetings
Define interactions with TC
Final brief out of pilot study findings and suggested course of actions
Provide guidance to TC on how pilot study fits into overall modular approach for OpenWIS 5 s/w design

@rogers492
Copy link
Contributor Author

Call the pilot proposal OPP-6: Djibouti (working title).

  1. Introduction

    1. The OpenWIS Association hosts multiple open source software development projects that support or enable the exchange of global meteorological information.
    2. We use the GitHub platform for our collaborative development. The rules and expectations for participating in an OpenWIS® Project are defined in the Technical Rules and the Code of Conduct.
    3. The basic governance of the OpenWIS Association is laid out in the Articles of Association and the Internal Rules.
  2. Purpose

    1. This charter establishes the foundation for the project team to begin developing, through a pilot project, the next iteration of the OpenWIS core software, by outlining the scope of this pilot project, identifying the contributing members and defining their responsibility.
    2. Scope of Authority
      This task team is charged with conducting a pilot study on …..
    3. Authority
      The authority for this project comes from the OpenWIS Steering Committee (SC), on recommendations from the OpenWIS TC. Outcomes from this and other pilot studies provide insight into WIS 2.0 specifications, and will ultimately factor into an architectural design and overall OpenWIS 5 plan with timelines.
  3. Pilot Project Overview
    Overview of pilot study task.

    1. Pilot Project Statement of Need or User Stories
      1. Discuss the relevance for this project.
    2. Pilot Project Scope
      1. Describe the Project Scope here
      2. Describe what the Project team is responsible for:
        • Item 1
        • Item 2
        • Item 3
      3. Pilot Project Goals
        • Describe the Project Task goals here.
      4. Pilot Project Deliverables
        • Provide a bulletized list of expected deliverables for the Project Task:
        • Deliverable 1
        • Deliverable 2
      5. Pilot Project Task Resources and Roles and Responsibilities
        • Short discussion on resources to be used in the project task. Tie in table A here.
  4. Roles and Responsibilities:

Resource Name Organization Role Responsibility Time period resource needed for
Resource_A Org_A Role_A Responsibility_A Period_A
Resource_B Org_B Role_B Responsibility_B Period_B
  1. Milestones & Schedule
Project Milestone Begin Date End Date
Milestone 1 YYYY/MM/DD YYYY/MM/DD
Milestone 2 YYYY/MM/DD YYYY/MM/DD
  1. Configuration Management Process

    • Define process for checking in/out code associated with pilot study
  2. Communication and Reporting

    • Frequency and mode of team meetings, squad/team names, GitHub IDs etc
    • Define interactions with PMC including reports at PMC meetings
    • Define interactions with TC
      • Final report/briefing on pilot study findings and recommendations

@rogers492
Copy link
Contributor Author

OPP-6: WIS Djibouti (working title)

  1. Introduction

    1. The OpenWIS Association hosts multiple open source software development projects that support or enable the exchange of global meteorological information.
    2. We use the GitHub platform for our collaborative development. The rules and expectations for participating in an OpenWIS® Project are defined in the Technical Rules and the Code of Conduct.
    3. The basic governance of the OpenWIS Association is laid out in the Articles of Association and the Internal Rules.
  2. Purpose

    1. This charter establishes the foundation for the project team to begin developing, through a pilot project, the next iteration of the OpenWIS core software, by outlining the scope of this pilot project, identifying the contributing members and defining their responsibility.
    2. Scope of Authority
      This task team is charged with conducting a pilot study on the future WMO Information System, often referred to as WIS 2.0.
    3. Authority
      The authority for this project comes from the OpenWIS Steering Committee (SC), on recommendations from the OpenWIS TC. Outcomes from this and other pilot studies provide insight into WIS 2.0 specifications, and may ultimately factor into an architectural design and overall OpenWIS 5 plan with timelines.
  3. Pilot Project Overview
    Overview of pilot study task.

    1. Pilot Project Statement of Need or User Stories
      1. Imagine a WIS based on a set of common standards layered on top of each other and in which all data is stored in the Cloud as static files,
        • eg: TCP/IP, HTTP, URL.
      2. Imagine that access to this WIS is easy, even on basic infrastructure,
        • eg: internet only.
      3. Imagine that finding the data you want through common commercial search engines is simple and does not rely on a deep understanding of complex metadata,
        • eg: because the metadata is stored as tags in human readable web-pages and is routinely indexed by web crawlers.
      4. Imagine that making new static file data available through WIS and ensuring that it's simple metadata gets indexed automatically is easy, even on basic infrastructure.
      5. Imagine that, once you have found the data you are looking for, subscribing to updates or routine delivery of that data is easy.
      6. Imagine that you have to demonstrate the concept of such a WIS to the TECO conference in early 2018 and that you have to easily convince the audience of the benefits such a WIS would bring.
    2. Pilot Project Scope
      1. Create a demonstration prototype that is suitable for presentation at TECO 2018 by a member of the SC.
      2. The Project team is responsible for:
        • Development of the demonstration prototype software
        • Delivery of a package that will be suitable for demonstration at TECO
        • Any documentation or training required to deliver the demonstration
        • Any supporting infrastructure required to do the demonstration
        • Provision of realistic data for the demonstration.
      3. Pilot Project Goals
        • Demonstrate aspects of the future WIS 2.0 concept
        • Gain support at TECO for the whole WIS 2.0 concept, or at least significant aspects of it.
      4. Pilot Project Deliverables
        • Provide a bulletized list of expected deliverables for the Project Task:
        • TBD
        • TBD
  4. Roles and Responsibilities:

Resource Name Organization Role Responsibility Time period resource needed for
Resource_A Org_A Role_A Responsibility_A Period_A
Resource_B Org_B Role_B Responsibility_B Period_B
  1. Milestones & Schedule
Project Milestone Begin Date End Date
Milestone 1 YYYY/MM/DD YYYY/MM/DD
Milestone 2 YYYY/MM/DD YYYY/MM/DD
  1. Configuration Management Process

    • Define process for checking in/out code associated with pilot study
  2. Communication and Reporting

    • Frequency and mode of team meetings, squad/team names, GitHub IDs etc
    • Define interactions with PMC including reports at PMC meetings
    • Define interactions with TC
      • Final report/briefing on pilot study findings and recommendations

@rogers492
Copy link
Contributor Author

Added as #309

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants