When 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