• OP Blog posts on the presented tools:
  • QGIS VESPA Plugins
  • (Planet)-Trek
  • Jupyter-related activities (Mario /' Baptiste / et al. )
  • App / registry tool design and needs / requirements (Nico / Emily ? / 
  • VESPA newcomer service set up experience (and feedback to VESPA Docs / etc.)

• Cross-workshop - follow-up activities towards #PDW17 Spice web services / possible hackathon activities / cross-experiment tonal matching / 
• What do we do with PlanetaryPy? How do we make it more sustainable / gathering vs. splitting modules/components, i.e. like astropy → #PDW17

for future workshops

• shorter keynotes, more hackathon time + focus on needs and technical problems/needs
• lightning talks important to know what each is doing, to be shorter/sharper
• guidelines of what (lightning) talks should cover needed beforehand (1st announcement)
• Call for needs/requirements/problems to be addressed on community (e..g on 2nd announcement)
• helpful for hackathons to get participants ahead of time to prepare, and/or to have virtual call to prepare (saving preparation time)
• Suitable room setup for hackathons to be planned/prepared
• important to mix devs and users.
• for different hackathons participant blend might be different
• sizing of workshop around 30-40 seems appropriate 
• additional short meetings piggyback on existing meetings (e.g. LPSC, AGU, EGU, EPSC) to follow up in between (VESPA has already some half day VESPA splinter → that could also be an existing option
• value of focused development (e.g. dataset-specific, for e.g. a module creation) during an hackathon
• Not too many parallel activities and not too many hackathon challenges (depending on number of participants)
• Need for continuity between hackathonrs / small followup piggyback meetints / OP / GitHub → post-hacakthon follow up 
• Hackathon not necessarily generating something usable but good to generate ideas and drive developmemts
• Need for participants to express requirements and go though (also ux) design process during the workshop/hackathon (where applicable, i.e. non-strictly coding)
• add use cases to requirements (one could add as a lightning talk requirements a "please describe your use case(s)") - before the workshop (1st / 2nd announcement), e..g place inputs/reqs on a repository/wiki ahead of time
•