.. _20180305-notes:

2018-03-05 Development meeting

Ian, Kyle, Bryce, Sebastian, Mike, Tommy, Kacper, Craig


  • Updates
  • Discuss software development process
  • Discuss release planning/process
  • Defining done
  • Go over unclear issues, time permitting


  • Started discussing changes to software development process based on NSF feedback. We’re trying to document this.
  • Craig: Working on backup, will have preliminary implementation available for review. Working on software process and release documentation.
  • Tommy: Working on importing Tales (updated mockup from AH). Has full ember/girder/mongo stack working, but identified error during registration
    • DataONE has optional filenames, need to log issue
  • Sebastian: Attended UI meeting (last Weds) with Christina/Rachel/Matt J. They will be proposing new interface features soon. They are working on a shared document.
  • Ian: Holding off on task list for now, since UI might change based on UI meeting feedback. Email exchange with initial thoughts from Christina. Will review this week. Will wait for recommendations before moving forward on UI changes.
    • Q. Usability tests - Should we go ahead and do this and feedback into the process or wait for the first cut? If we do them now, the information could go to Rachel at DataONE, who is already looking at this.
    • Q. How to collect the information? Send to dev mailing list
  • Mike: Identifying events to intercept from Girder. Wonky – create/rename/move don’t have distinct events, must detect/distinguish. Needs alternate assetstore adapter. Can have a preliminary impl next week.
    • Assetstore is nontrivial – maybe we can push something upstream instead of relying on plugins.
  • Bryce: Updated design docs; working on backend integration with DataONE.
    • https://github.com/whole-tale/wt-design-docs/blob/master/mockups/tale-publishing/notes-20180221-ndahm.rst

Release planning:

  • Targetting monthly release process prior to MVP starting with 0.2 end of March. (Craig/Mike/Ian)

Development process:

  • Craig will setup a meeting to discuss with broader stakeholders
  • Discussion of PR, reviewers, and Github approval process. Concern about bandwidth (do we have cycles to deal with review)? Discuss degrees of review (balancing waiting for reviews vs not having them). Would need to dedicate time per week out of allocation to provide feedback.
  • There is a process already at ND through ZenHub, but not through PR. Imposing the PR would change the behavior. There are comments on issues.
    • Q. What does PR provide that current process doesn’t? Mainly transparency.
    • Reviews are at sprint reviews, not formal code reviews, but feedback is provided informally.
    • If not, then we need some way to control which work is included in a release. We need some way to do ongoing work while testing a release.
  • Tommy: Tried Waffle board, which is used for MetaCatUI to track across repos.
  • Mike: Option: trunk as development with creation of release branches. Effective reviews require investment in understanding someone else’s code. Objective ways like testing are better – as is agreeing on design before hand.
  • We’ve converted issues from SmartSheet to tasks in github, but


  • We all commit to complete the UI tests and provide initial feedback this week. Send to dev mailing list. Craig will take action to consolidate.
  • Please look at the MVP project in Github, see if there is an issue in MVP or Pilot project and move to MVP project in progress.

2018-03-05 WT planning meeting Kacper, Craig

  • Create PEP milestones
  • Create issues from AH planning
  • Discuss dev team meeting agenda

Recap what was discussed

  • We have labels, milestones and project boards
  • Labels are just a way of organizing things – but we’ll have some special ones such as PEP for traceability.
  • Milestones are versions
  • We’re not sure yet how to use projects, but limit them to as few as possible
  • We’ll use Github features alone right now and teams can organize into their own Zenhub/Waffle if needed – as long as they don’t remove the core labels and milestones.

Pinning images and docker cache (Design note)

  • Could clean based on time
  • Could use docker image prune
  • Could clean based on usage (more used images cleaned later)
  • Could clean based on size (larger images)
  • Or some combination of all these things.