FutureTopicsForAllHandsMeetings


 * 1) Prospects for outreach workshops at conferences
 * 2) Planning for certification
 * 3) Display of content from other repositories - e.g. DataONE, DataCite
 * 4) API
 * 5) DataONE Member Node current status and plans
 * 6) Ideas to cultivate champions or ambassadors (researchers, librarians, etc)
 * 7) ORCID Integration: considering the various ways these identifiers should be used in the metadata we consume, produce and display, and what features could be enabled by having an (initially very incomplete) mapping of our names to ORCIDs.
 * 8) Metadata registries: examples, roles w.r.t. digital repositories
 * 9) Automated/semi-automated generation of metadata
 * 10) Metadata validation and lookup services
 * 11) Automating metadata quality control/comprehensiveness reporting
 * 12) DryadLab
 * 13) Mechanisms for linking a single record to secondary (e.g. companion) papers, either ones with no new data or with altered data
 * 14) Data reusability guidelines and SOP for curators
 * 15) * Synopsis: Many of the data packages in Dryad have limited reusability. Reasons include data formats that aren’t machine-processable (e.g., tree as image instead of text format); data files or formats that have metadata stripped (e.g., fasta, newick); spreadsheets with multiple tables in them; lack of README file, or lack of sufficient explanation of columns etc in README. Sometimes there are straightforward alternatives that could be suggested to the depositor, but being aware of them requires domain knowledge. Can we develop criteria, lists of preferred format alternatives, applicable metadata reporting standards, etc, that are sufficiently simple so a curator can apply them easily without unduly adding to the curation burden?
 * 16) Platform lock-in
 * 17) * Synopsis: The Dryad repository early on made the architectural decision to be built on top of DSpace. One of the deciding arguments at the time was that DSpace would allow Dryad to have a fully functional user-interface faster than any of the competing platforms (or building from scratch) would. This promise largely materialized. However, whether other promises, such as joining a global community of institutional repositories, have paid off similarly is much less clear, and in fact almost all other data repositories that have since come online have taken a different choice. Moreover, the DSpace codebase is large and highly complex with many dependencies. It has to serve many clients almost all of which are unlike Dryad. As a consequence, adding or modifying features requires deep specialized expertise and extensive training, which makes development more expensive, poses barriers to nimbly adjusting development direction as well as resources to shifting priorities, and has shown to cause subtle bugs that are difficult and time-consuming to track down. In this light, now seems a good moment to re-evaluate our major architectural choices as well as asses which viable alternatives exist.
 * 18) *Comments.
 * 19) ** Dan - I think this is a worthwhile discussion, perhaps too broad to get any real perspective in a 1 hour session?
 * 20) ** Jane - Although I’m not a developer, I also think this is a very VERY worthwhile discussion. I appreciate why we went w/DSpace in the beginning, but I do wonder if the limitations we face outweigh the benefits.  I agree w/Dan that 1 hr. is not nearly enough time; but, I think we could spend an hour in a meta-discussion on how we could move forward w/more meaningful discussion on this topic. Question: is it time to consider a new functional requirements document?  I think this also impacts future ideals w.r.t. curation models.
 * 21) Low-hanging development fruit - what’s ripe for automation / improvement?
 * 22) * Synopsis: There are many small maintenance-style tasks in Dryad that require developer effort. While a lot of tasks have already been automated or integrated, there are still periodic tasks that could be scripted or engineered to avoid repetition.  It may be worthwhile to get some perspective on these activities, see what’s taking time, and optimize them away.  For example, many tasks related to journal integration (adding and showing covers, updating configurations, recently integrated covers on homepage)
 * 23) * Comments:
 * 24) ** Jane - yes. I’m not sure this comment is directly in response to this item, but I remain a strong advocate of our automating the reporting.  I guess this is not really a maintenance activity, but some discussion on how that’s been progressing, and when-where-how we may see that transpire would be welcomed.
 * 25) Static content editing for everyone
 * 26) * Synopsis: Making changes to non-repository content, such as FAQs and other information on datadryad.org is a fragile process requiring re-deployment of the entire Dryad application. This increases the friction to non-developers making changes to simple markup and raises the probability of error/downtime.  There are many ways to improve this workflow, and it seems like a good time to discuss alternatives.
 * 27) * Comments:
 * 28) ** Mercedes - Sounds like a good discussion to have. If we can optimize the workflow, small fixes can be made to Dryad much faster.
 * 29) Metadata goals for 2014
 * 30) * Synopsis: Metadata has been an important facet of Dryad’s development. Our simple, low-level model, automatically parsing citation metadata; limited use of CVs (controlled vocabularies), etc., has, in many ways, allowed us to progress rapidly.  To date, there has been limited if any complaints about metadata quality, although there is evidence of quality compromise.  We also put MRC, etc. team goals to pursue automatic metadata generation on hold, given curation foci, staff changes, etc..  Would a discussion on metadata goals and priorities for 2014 be worthwhile?  The work w/ORCID is an important step, but other issues/goals could be considered too.
 * 31) **Sara - Also, I wonder whether metadata could be used to help track reuse.
 * 32)  Dryad grant funded annual and final grant reporting
 * 33) * Synopsis: I would like to give our annual and final reporting attention as a group, unless Todd and Laura believe this is more of an administrative thing, and not a good use of retreat time.  Even so, I would like our report to be shared among team members and accessible.