Yannick opened the meeting with a discussion of strategy with regard to what formats we use for representing observational data in JEDI.
Two prototypes are being explored now
P1) netCDF (with possible extension to CF netCDF in the future)
- led by JCSDA JEDI team
P2) ODB
- led by UK Met Office
Proposed Timeline:
June, 2018: P1 and P2 integrated into JEDI
Summer, 2018: compare & assess the two prototypes and possibly consider other options
Sept, 2018: Workshop on how to proceed
Sept/Oct, 2018: Decide on which format or formats to support
It was pointed out that observation storage comes in two distinct flavors:
- file format
- in-memory format
We may consider supporting both netCDF and ODB for file formats but we should pick one or the other for the in-memory format, at least for now, based mainly on efficiency (memory, parallel performance, etc).
Then Steve (JCSDA) gave an overview of where things now stand with managing netCDF and other observational input files in the IODA pipeline. The plan is to gradually phase out the GSI observer and replace it with UFO, one observation type at a time (beginning with GPSRO). His slides are included here:
Then we had an update from Adam and Steve from the Met office on the status of ODB. Currently the team is getting up to speed with JEDI and they expect to begin integrating ODB into JEDI in the next week or two.
This was followed by a brief tutorial of ZenHub (led by Mark, JCSDA), encouraging everyone to use it (beginning immediately) for both project management and issue tracking. If you missed it and/or if you'd like instructions on how to set up ZenHub, see the ZenHub Wiki Page.
Some highlights:
Chrome and Firefox have ZenHub browser extensions
- If working with different browser, you can still do everything that Mark demonstrated. It's just that the interface won't be integrated into GitHub (won't see the ZenHub tab).
We want to use ZenHub to foster communication
- Avoid duplicating work
Questions from audience
How do we handle a single ZenHub issue that has multiple assignees?
- Comments can be used to handle discussions among the assignees
- If one person modifies the issue, all assignees get email notification
- Notification levels can be configured
- Part of discussion should be the dividing up of the work among the assignees
- You can subscribe to issues of which you are not an assignee if you want to track them
Can we tie ZenHub issues to particular GitHub branches?
- All pull request show up as items on the project board that you can link to pre-existing items. So, for example, if you started a feature branch to address an issue then when you do a pull request to merge that back into develop, Zenhub will create an issue on the project board assocated with the pull request. Then you can select that issue, scroll down, and you'll see an option to "connect this pull request to an existing issue". So you can do so and you may wish to add a comment to the effect that this pull request resolved this issue.
- There may be a way to link an issue to a particular branch of a repository when you create it but I (Mark) don't know how to do this yet. For now you can just put a comment in the issue mentioning the branch that it is associated with.
When do issues move from New Issue to Backlog?
- New Issue category is like the inbox in your email.
- Default location for the new issue
- The issue shouldn't remain in New Issue for long
- When entering a new issue, it is recommended to place it in either Ice Box or Backlog. This helps assignees/subscribers know about the urgency of the issue.