You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Date

 

Attendees

Regrets

Goals

  • Review, next steps

Discussion items

TimeItemWhoNotes
25 minReview interviews and next stepsAll

How do we "finish" the asset inventory?

25 minRecommendation ProcessAllHow will we develop recommendations?
10 minNext meetingAllWhen do we meet again? What do we need to have accomplished?

Notes

We had started talking about how to make recommendations on the last call, and shared the inventory at the beginning of the week – not surprisingly, with no feedback so far.

Thinking that the recommendations could follow the categories instead of the domains --

  • One way : for example, should we focus on development as a domain – invest in this, stop doing that, tighten up development
    • and we could similarly write recommendations about governance or training
  • Alternative : look at the types of resources, such as email lists, and solve them across purposes based on the best solution for that type of communication
  • Or deal with each asset 
  • Would it be helpful to establish goals or principles to measure our recommendations against?
    • e.g., reduce redundancy to reduce maintenance and improve the ability for people to find things
    • Paul – everything has to justify its ongoing existence – we have a baseline level of noise from having too many things out in the ether – everyone should be able to understand the overall structure so not only the most involved people know where things are
    • May need some temporary resources, like the Hackathon email list – we just need to get rid of them when we're done, but would be valuable to preserve the knowledge that a person participated added to a CRM function for a different purpose – we're better at keeping stuff around than doing whatever would be useful with it and disposing of the original
  • Other goals
    • Having a good amount of material oriented to newcomers (of various types – implementers, developers, technical assessment) – easy for people to make spot judgements, and points out the need for test data
      • Mike – did a little top-level shuffling and created a top-level topic called "considering VIVO" – before "planning an implementation"
        • what is VIVO, why is this semantic, what difference does that make
        • vs. you've decided to do it and what is it going to take
        • That domain belongs with the implementation task group, and ours is more about providing the appropriate platform to support the activities that need to happen
      • vivo.vivoweb.org – having an up-to-date one is our reference implementation – go look at it, and we can make sure that that instance is appropriate for various kinds of implementations. Right now we are relying on our sites to provide us with demonstrable features of VIVO - somewhat risky
        • It can have VIVO publications and presentations
        • It generates value for the organization that runs it
        • Alex – Altmetrics has done integration with Stony Brook – we could use this site to show the add-ons people have done
        • Mike – and a proof of concept for things that might end up in the project, becoming configuration options during the build
        • Becomes the place for profiles for people that don't have an institutional profile, such as Kristi and Melissa
      • is the ORCID functionality something we could turn on – does it rely on having an institutional membership? yes
        • But you can add your ORCID iD to a VIVO without having an institutional membership
        • We could probably get some accommodation from ORCID
    • There's an owner of every piece
    • A clearly defined place for all credentials to be managed
    • Avoid multiple solutions for the same function
      • reconcile GitHub vs. Sourceforge
      • reconcile Google Groups vs. Sourceforge email lists for email
    • General concept of archiving – old wiki material, for example – too prominent where it is
      • 1700+ pages, with the vast majority being 'previous work' and not helpful to people currently trying to use VIVO
        • Jim has done a great job on moving things that only pertain to previous versions somewhere else
        • But we have a lot of other old information
      • Mike - as went through the site, started using the Info macro and tagging pages – can use that to tag older material
      • The 10-step process to a clean and sober VIVO ... starts with recognizing you have too much old content
      • For the conference, have a clear boundary of one year cycles with a bit more to capture the planning for what happened a year ago
  • Suggestion – 
    • Mike would like to write down in proposal format what we might do about our email lists
      • Paul – suggesting not having a special ontology group; Mike – the other DuraSpace projects don't have segmented groups, but just a tech list and a community list and a private steering list for governance, with hydra-all the combination of hydra-tech and hydra-community
      • Has multiple dimensions
        • how do you make them easy for people to join
        • how do you do large batch processes
        • how do you sync with whatever the contact management solution (CRM) is
        • should we do as much as we can in a completely public way, as  on StackOverflow?
        • or should we try to develop a VIVO-specific community using something like Discourse?
    • Would like to suggest that Jim and Jon think about what we might do with our repos – how to get off SourceForge and be completely GitHub based
    • The task forces seem to be operating out of the wiki
    • Six major bubbles with a statement of purpose next to them – Mike will do a text version and Jon will do a diagram
      • vivoweb.org
      • wiki
      • JIRA
      • GitHub
      • an email solution
      • marketing stuff (a bubble with lots of stuff within, like social media outlets,
      • a demo site – vivo.vivoweb.org
      • vivosearch?
    • We seem to be missing some important ontology assets – Jon will add to the original Assets Google sheet
      • The old Google code site for VIVO-ISF
      • the current VIVO-ISF data standard GitHub site
      • VIVO ontology on BioPortal

 

Action items

 

  • No labels