Developer Meetings

Dryad holds developer meetings bi-weekly. These meetings are intended to discuss issues related to the Dryad software. While most of the participants are employed by Dryad, we welcome participation from others in the Dryad and DSpace communities.

Connection Information
Meetings are currently held biweekly, on Fridays at 11am-12:30pm Eastern Time.

Most participants (Dryad staff) will be located in the NESCent Gray Bldg conference room.

Remote participation available through WebEx. Announcements are sent to the dryad-dev mailing list beforehand.

March 20, 2015

 * Review of Data Display Widget and how it uses Cocoon (with special guest Nathan Day)
 * Brief review of Journal Pages code.

February 20, 2015

 * Schedule hackday. Potential topics:
 * Prototypes for distributed architecture
 * Writing test cases for the DSpace upgrade
 * "Maslow's" code review guidelines
 * Reading some code -- Data Display Widget

January 23, 2014

 * Review all nagios settings
 * what else should we be testing? sync to secundus?
 * Dan demonstrate/discuss code in the dryad-utils
 * Dan demonstrate/discuss testing classes
 * Transitional plan for server deployments
 * Maintenance schedule

January 9, 2014

 * Quick process review: FogBugz, Trello
 * Communication with NetFriends and Atmire
 * Testing OS/Java patches on travis and VMs
 * Review initial handoff plans for Dan's duties
 * Needs for developer training

December 12, 2014
(Special time: 11:30-12:30pm ET)


 * Keeping FogBugz clean
 * Trello
 * recurring urgent items
 * priorities on the engineers board
 * Testing issues
 * Automated testing of upload speed & bandwidth (nagios?)
 * Adding/deleting files to a data package
 * Standard database content for testing purposes
 * Documentation standards

Special meeting November 19, 2014

 * Review plans for Dryad integration with Open Tree of Life
 * http://wiki.datadryad.org/Notes_on_Deposit_from_Applications

November 14, 2014
Agenda:
 * Selenium testing
 * Zotero importer
 * FogBugz and "urgent" issues
 * Relationship between FogBugz and Trello
 * How to turn FogBugz tickets into Trello cards and get definitive prioritization
 * Concrete examples: Users who change emails, large file processing
 * Clearing out legacy FogBugz tickets

October 31, 2014
Agenda:
 * Tech review of Data Display Widget
 * Final preparations for PLOS integration
 * Developers available for emergency coverage
 * Automatic testing of server capability
 * Review UI for ORCID integration
 * Google Apps and wiki transition
 * Assignments for pull requests

Minutes:

October 17, 2014
Agenda: Minutes: Action items:
 * Introductions
 * Action items & minutes from previous meeting
 * Touch base on major development projects:
 * Data display widget
 * PLOS integration
 * Google Apps transition
 * ORCID
 * DSpace upgrade
 * Git training for non-developers
 * Introductions
 * Action items & minutes from previous meeting
 * Daisie prepare training for the Git Day. → Still working. Training moved to Nov. 6 to accommodate new assistant curator.
 * Ryan prepare candidate designs for ORCID login (and ORCID linking in submission) → Deferred
 * Get Daisie and Nathan access to the calendars DONE
 * Nathan: document Selenium test configuration for Travis-CI, integrate Selenium tests for dryad-repo (the ones currently working) and create a pull request after updating the .travis.yml config and disabling any non-working tests. Will document current understanding and current issues.
 * Touch base on major development projects:
 * Data display widget
 * Running on dev. Will create a pull request soon.
 * PLOS integration
 * Deployed on dev, waiting for PLOS to test.
 * Google Apps transition
 * Initial setup is in place, but there are many pieces to finish moving.
 * Ryan/Daisie to work out remaining issues with journal email processing.
 * ORCID -- in progress
 * DSpace upgrade -- coming soon
 * Active pull requests -- Everyone will work to move the pull requests through, with high priority
 * Daisie prepare training for the Git Day. (Moved to November 6th)
 * Ryan prepare candidate designs for ORCID login (and ORCID linking in submission)
 * Ryan ask Todd about whether we should merge the calendars.
 * Nathan document current understanding and current issues with Selenium. We will discuss as a major item for next developer meeting.
 * Ryan prod PLOS about testing.
 * Ryan/Daisie to work out remaining issues with journal email processing.

October 3, 2014
Agenda: Minutes: Action items:
 * ORCID login
 * Arrangement of APIs for REST access and widgets.
 * Process for covering technical issues during travel.
 * Review outcomes and action items from the developer retreat.
 * Reviewing Development Process
 * Preventing delays in code review -- having everyone assign reviewers to pull requests.
 * Level of formality for testing, etc.
 * Testing with Selenium
 * Nathan's Selenium/Travis configuration
 * which server to target?
 * can we assume that particular data objects will exist?
 * Git training for non-developers.
 * Git training for non-developers
 * The non-developers need a better way to make edits to HTML pages and config files.
 * Software Carpentry has a lesson for this: http://software-carpentry.org/v5/novice/git/index.html
 * scheduling with the next 30 days → Daisie will organize
 * Thursday 10/30, 11:00-1:00 EST
 * include training both on git and on the development and deployment processes, e.g., pull requests and build/deployment/test framework?
 * edits to web content require iterations that require viewing content and style changes in a running webserver
 * using Vagrant locally or on a remote server (e.g., AWS) as an option for making changes to the site, instead of the dev/staging servers
 * encourage command-line or GUI access to repository? → we will start with command line
 * focus on common command subset, but include overview of git (forking, etc)., include relationship between commandline and Github site
 * preparation for training? e.g., installing XCode command line tools on machines before training
 * Design for ORCID login
 * design review/work needed for current login page, not to be provided by off-staff designer
 * implementation of outcome of design review to be decided
 * usability issues/considerations
 * what expectation is being presented to users around login method?
 * we want to encourage users to login with ORCID, but allow them to use existing Dryad accounts
 * e.g., consider style of TraitDB login page, or Stackoverflow, where visual weight and option for local account creation
 * need to be careful about extent to which users, who may not be knowledgeable (?), are discouraged from logging in?
 * include informative information or links to explain ORCID for those not aware of it
 * Arrangement of APIs for REST access and widgets.
 * Proposal to move widgets into separate git submodules. The widgets are good candidates for separate pieces, because they don’t directly interact with the core Dryad code.
 * Widgets dspace module should be separate from XMLUI
 * Action items:
 * need to map out what the REST API
 * what the API will look like
 * which parts will be supported
 * Review outcomes and action items from the developer retreat.
 * Reviewing Development Process
 * Preventing delays in code review -- having everyone assign reviewers to pull requests.
 * all developers should jump in to review pull request when they come in
 * aim for 1-2 days for a small request, 1 week for larger requests
 * small changes can break the system, e.g., XHTML validity and XSL changes in the payment system
 * Process for covering technical issues during travel.
 * increase in formality of scheduling process and making availability information available
 * PLOS update:
 * REST API running on staging, codebase not reviewed yet
 * could be deployed locally, regardless of external use
 * official PLOS integration is an “all-hands on deck” level
 * Testing with Selenium
 * Nathan's Selenium/Travis configuration
 * which server to target?
 * can we assume that particular data objects will exist?
 * https://github.com/rnathanday/dryad-widgets/blob/master/bin/build_test.sh
 * selenium tests add greatly to the time for travis build/test
 * Daisie prepare training for the Git Day.
 * Ryan prepare candidate designs for ORCID login (and ORCID linking in submission)
 * Get Daisie and Nathan access to the calendars
 * Nathan: document Selenium test configuration for Travis-CI, integrate Selenium tests for dryad-repo (the ones currently working) and create a pull request after updating the .travis.yml config and disabling any non-working tests

September 19, 2014
Agenda:
 * Final preparations for RDA/ODIN
 * Review outcomes and action items from the developer retreat.
 * Reviewing code review -- is the process working now?
 * Testing with Selenium
 * which server to target?
 * can we assume that particular data objects will exist?

Minutes:


 * Meeting was abbreviated due to conflicting staff schedules. We briefly covered some of the RDA prep.

August 22, 2014
Agenda:
 * http://worldwidescience.org/ and Dryad search API
 * How well is development process working? Trello, code reviews, etc., continued from last meeting.
 * Authentication for Dryad APIs
 * Reviewing policies for code review
 * How is it working?
 * Merging and deploying
 * Output from automated tests

Minutes

August 8, 2014
Agenda:
 * Review action items from Developer Retreat 2014
 * Slack integrations -- which tools are critical to integrate?
 * Review API additions to support PLOS integration
 * Jenkins, dev, and git
 * Trello, FogBugz, and all the other communication channels.

Minutes

July 28-29, 2014 Developer Retreat
See Developer Retreat 2014

July 25, 2014

 * Review plans and timeline for ORCID Integration
 * See Google Doc Notes

July 11, 2014

 * Developer Retreat
 * Support services update
 * Wiki
 * Google Apps
 * Slack
 * Automated Testing Dryad Automated Testing - July 2014 Google Drive
 * JUnit Tests (Internal)
 * Travis CI
 * Jenkins
 * Test Environment
 * Examples
 * Selenium Tests (External)
 * Action Items
 * Dan: Provide configuration for running tests in vagrant vm (test database, test config)
 * All: (See above google doc) Verify you can run tests in your dev environment, write at least one internal test
 * Dan: Create wiki page on current state of testing and roadmap

June 6, 2014

 * The future of Dryad email
 * The real question is to Google or to not Google. Many questions came up:
 * Do we need the "Vault" capabilities? Yes. Vault will take care of our document retention policies.
 * Exactly what features are in the various Google plans? See feature comparison list
 * Can we use the nonprofit discount? Yes, once we get nonprofit status.
 * If we start with a paid plan, can we upgrade to the nonprofit account? Yes. See this and [this http://smallbusiness.chron.com/convert-google-apps-not-profit-32253.html].
 * Can we add the Vault capability to a Google nonprofit plan? Yes
 * Can we export Google content if we want to switch providers? Yes
 * How will we process metadata emails? May be able to use IFTTT
 * Although Vault is relatively expensive for the business account ($5 per user per month), it's much cheaper on the nonprofit plan ($10 per user per year)
 * How should we structure Trello, in light of the new Strategic Plan?
 * we don't want to overhaul our process before the ED comes on board
 * it's likely the new ED will have strong opinions about project management
 * Daisie says we need different systems for different scales -- monthly board (project manager's view), daily board (developer's view), year board (marketing view)
 * Laura's recommendations:
 * add deadlines and highlight the things that have hard deadlines
 * make it more agile -- a board is a sprint
 * each card has a reason why it's needed
 * No final decisions were made. Ryan will continue to review this and make minor adjustments, but major restructuring will wait until after the developer retreat.

May 23, 2014

 * File size metadata and external services: https://trello.com/c/54t4olTA
 * The problem: When metadata is exported to some external services, we need to provide a file size for a single bitstream, even though the actual Dryad object may contain multiple bitstreams (with different file formats).
 * The decision: We will always use the file size of the first bitstream. It's not completely accurate, but it is reasonable for the most common use cases.
 * Code review process
 * All developers will participate in code review
 * Ryan and Dan will be the gatekeepers (for now). They will alternate responsibilities so new code can get approved with minimal delays.
 * VM and Vagrant Dryad

May 2, 2014

 * Welcome Daisie
 * Strategy for automated builds and tests
 * Testing
 * continue with Jenkins? Move to Travis?
 * NESCent Informatics Best Practice session on automated testing
 * "quick" vs "full" tests
 * Schedule & technology for future meetings

April 4, 2014
Agenda/Minutes:
 * Hardware updates
 * Usability testing at Evolution
 * Review status of Dryad code repositories
 * Curator access to FogBugz.
 * Give them all accounts?
 * Create a shared account?
 * DataONE Dashboard

March 21, 2014
Agenda/Minutes:
 * Journal name changes -- implications and process for handling
 * Review Mailing_Lists. Two issues in particular:
 * it has always been difficult to steer conversations to dryad-dev
 * ongoing confusion over who receives email at the curator address
 * Hardware upgrades

March 7, 2014
Agenda/Minutes:
 * Journal name changes -- implications and process for handling
 * Server space
 * Immediate disk space needs
 * Future needs for testing with multiple servers
 * Problem content from old Systematic Biology archives

February 21, 2014
Agenda/Minutes:
 * curator notes — review wireframes. Which features seem best implemented within DSpace? Which seem best implemented by integration with an issue tracker?
 * New requirement: Search should apply to the contents of note fields
 * We estimate that the feature as designed would take 15 days of development time. It is likely to be easier to implement this by integrating with an external issue tracker.
 * We will investigate issue trackers and how they would fit into the picture (OAuth support, APIs, etc.)
 * curator/helpdesk issue tracking -- fogbugz? transition to salesforce? or RT? how does this interact with the curator notes?
 * Ryan/Laura will contact salesforce to see if their issue tracker will meet our needs
 * What features are required to support senior/junior curator roles?
 * Sara will summarize this so we can begin to design the feature.

January 9, 2014
Agenda/Minutes:
 * The future of Dryad/DSpace
 * Do we expect our long-term plans to continue with DSpace, or should we consider other options?
 * DSpace pain points:
 * cocoon/XMLUI
 * XMLUI was originally envisioned as a highly modular, easily configurable user interface. In practice, this hasn't worked as well as expected. Some DSpace users are "returning" to JSPUI, with the new Bootstrap-based theme.
 * It's an "old paradigm" UI that is server-focused. Very little work is performed by the client browser. This makes it more difficult to debug problems and roll out minor updates (because they require a server restart).
 * Is the new JSPUI less server-focused? no, not really.
 * Because the current dspace architecture is not modular enough, it is more difficult for us to find contractors who can be immediately productive -- there is a steep learning curve.
 * generally monolithic architecture
 * upgrades are difficult, due to conflicting changes made in Dryad and the core DSpace
 * This is a target of redesign by the DSpace visioning group, but the redesign is likely to take several years.
 * speed of page delivery
 * could be improved by more powerful hardware, but we're still not able to deliver the responsiveness of a heavily client-side application
 * DSpace is not designed for horizontal scalability, so we need to do some re-architecting before we can expand to many servers
 * since dryad has many customizations, we must re-test everything whenever we want to upgrade dspace
 * community trends
 * over the past few years, DSpace/Fedora/Eprints have expanded their core markets, but many "from scratch" repository systems have been developed.
 * Most of the people using DSpace are really aligned with the same core principles. They are all building things that look like "institutional repositories". Dryad doesn't fit particularly well into that use case, and we're starting to stretch the limits of what DSpace can do.
 * Even if our broad feature needs closely align with others in the DSpace community, some of our specific requirements will always be different, which can cause difficulties in designing broadly-applicable features, as well as difficulties in using features that are developed elsewhere in the community.
 * Next steps
 * We will review atmire's estimate of upgrade costs for DSpace 4.0 and determine how best to move Dryad into compatibility with the 4.0 features.
 * Although we are likely to upgrade to DSpace 4.0, we are not committed to following DSpace for the future. It is time to stop viewing DSpace as the major platform that forms the basis of Dryad. Instead, we should consider it to be a set of (highly interconnected) services. We may continue using many of those services, but in some cases we will replace those services with systems that are based on more modern toolkits. As new major projects come up, we will evaluate whether to:
 * use the existing DSpace services
 * build a new service that communicates with the DSpace API
 * build a new service that communicates directly with the database/assetstore
 * Review of action items from the staff retreat
 * dan has pulled the action items out into a separate section of the retreat document
 * laura will organize the action items into projects

November 15, 2013
Agenda/Minutes:
 * Documenting external access (e.g., for FASEB)
 * Emergency technical support procedures
 * Estimating the development roadmap

September 6, 2013
Agenda/Minutes:
 * Payment system
 * Review status of outstanding issues
 * Managing tasks for large projects like this
 * We will transition from the Google Doc into a Trello board. In the future, all large projects will spawn a new Trello board.
 * Needs for report generation.
 * Schedule and next steps for working with FASEB.
 * DOI formats: doi.org vs dx.doi.org
 * Is CrossRef really changing their recommendation? There is only one doc at doi.org that uses the short form.
 * We will stay with dx.doi.org for the time being...
 * Review features in design
 * Update of Publication Metadata Wireframes
 * Large File Technology Improvements
 * The draft Vision statement for DSpace

August 23, 2013
Agenda/Minutes:
 * Reviewed outstanding issues for the payment system
 * Reviewed and prioritized the major issues in the [[Media:Dryad_paymentsys_usabtest_rpt.pdf|usability report]].

August 9, 2013
Agenda/Minutes:
 * Determining the correct level of usability testing for each project. Testing while a feature is in active development.
 * When time permits, Ryan and Mercedes will make document that lays out the steps in developing new features. The document will include details about what level of testing to perform at each phase.
 * When planning each test, we should check whether there are any showstopper issues that will disrupt the testing. Mercedes can plan whether to delay testing until the issue is fixed, or to work around it during the testing.
 * Review prioritization for usability fixes to payment system.
 * Review checklist of tasks before payment system goes live.

July 26, 2013
Agenda/Minutes:
 * Reviewed the current state of the payment system (on the staging server).
 * Documented usability issues with the payment system.

June 28, 2013
Agenda/Minutes:
 * issue tracker /project management
 * There are concerns about which items are tracked in Trello vs Fogbugz and how to prioritize.
 * General agreement that we want to use FogBugz for more detailed tracking of the Trello cards. (Or other tracking system for external vendors.)
 * We need more dedicated support for customer issues. Currently, Elena handles most of this, but it would be better to have someone charged with customer communication and issue prioritization.
 * ORCID Integration
 * Ryan will be discussing this with the DSpace community. We intend to provide as much service to the DSpace community as possible.
 * We need to better publicize the ODIN tool.
 * Timeline for payment system
 * Reviewed current timeline. Since the timeline is getting tight, we will need to focus our efforts to ensure the schedule stays on track.
 * Any other business
 * Laura has developed an Excel spreadsheet that calculates the cost of our various payment plans. Potential customers will find this very useful when deciding which plan to use. Dan and Mercedes will work to turn this into a web-based tool.
 * A submitter has hit an extraordinary combination of usability issues. The submitter didn't do anything "wrong", but he managed to consume a large amount of staff effort and highlight areas that need to be improved before the payment system goes live.

Action items:
 * Ryan ensure all Trello items have associated FogBugz content (where appropriate)
 * Laura ask Martin Fenner if he will write a blog entry about the ODIN claiming tool.
 * Laura document our needs for customer support staff and discuss with Todd.
 * Ryan fix permissions for Orcid Integration page on the DSpace wiki.
 * Laura/Ryan talk with Todd about prioritization for large file uploads, given their interaction with the payment system.
 * Dan/Mercedes meed Tuesday to create the subscription plan calculator tool.

May 17, 2013
Agenda:
 * Covering issues during the Oxford meetings
 * Moving forward with active Trello cards
 * Any other business

April 19, 2013
Agenda:
 * Website redesign and transition back to Trello
 * Planning for Mattison's absence
 * Review of browse functionality in the homepage?
 * Schedule for payment system
 * Misc

March 8, 2013
Agenda:
 * Website redesign
 * Current status, problem areas

February 22, 2013
Agenda:
 * Website redesign
 * Current status, problem areas
 * Review membership form
 * DataONE identifiers
 * Review DataCite/ORCID ideas

Minutes (from Dan):

Website Redesign
 * Recent designs from Jim at http://ibang.com/sandbox/dryad-redesign/
 * Jim working on CSS / styling, Atmire working on underlying dspace/xml
 * Reviewing notes on https://github.com/datadryad/dryad-repo/commit/d6c22d134edfc59d22718a82e069453b2cc00f37
 * Additional CSS classes, jQuery version (Mark)
 * Designs require jQuery 1.7. some dspace themes requires 1.5+
 * Current version is 1.9, and DSpace is using 1.8.5
 * Carousel discussion
 * Initial carousel will contain:
 * basic "Dryad is a..."
 * adaptation of bookmark
 * mission statement
 * announcement of May meeting
 * In future, will add an excerpt from fee structure blog post
 * Ryan asks: Minimumn amount of content for carousel? Laura mentions that 3 is minimum, Mercedes indicates there are 5
 * Is the final content in development, how much to do in next week?
 * Laura: Bookmark can be ready in a week, mercedes agrees, will rearrange bookmark @actionitem
 * Announcement for membership meeting (Adaptation of blog post), Laura can prepare. Same with mission statement @actionitem
 * Four if we keep "Dryad is a...". Consensus is to keep this slide
 * 'Deposit your data' content box:
 * Wording needs wrap fixing and capitalization
 * Hilmar suggests button text is redundant with title
 * Board has given feedback at this point
 * Search box
 * Not much different than mockup
 * Mark considering structural changes to accommodate design. Restrucutre content in XSL
 * Dropdown menus have been restructured, now markup at beginning of page vs end (as in dspace mirage XMLUI theme)
 * DSpace practice is for the menus to be marked up at the end of the source but styled to the top with CSS
 * Mercedes: to investigate screen reader impact of this
 * XSL Work beyond first pass?
 * Some work was done yesterday, commits are being reviewed, merging in CSS/JS changes to support the theme.
 * Restructuring of homepage has not yet begun, estimates a couple iterations between atmire & dryad
 * movement will be quicker with solid template
 * Connect with Dryad box?
 * Still up in the air - laura and jim had a discussion, jim working on designs and will share for feedback soon
 * will likely be an image and set of links
 * Browse for Data
 * Placeholders in for 3 buttons
 * Size of content? More content than was in mockup.  Mercedes does not object to adding/removing content
 * RSS Symbols - only keep for recently published
 * Dryad Mailing list
 * Links to NESCent subscription page (mailman)
 * Hilmar: NESCent handles this with a live form (and subscribes to mailman via scripts).
 * on clicking subscribe, content of box should update with "Subscribed!"
 * Blog:
 * Taller than initial mockup, but a good height match for recently integrated journal
 * nobody objects to height increase
 * Statistics:
 * Items listed by todd not enough to fill the space, need more content to fill this out
 * Possible color, possible graphic
 * mark: statistics should be targeted for what researchers might be interested in - packages per journal, gigabytes of content, popular journals
 * Number of authors, number of data sets. Number of authors isn't a clean statistic
 * Recently integrated journals
 * 6 images would be the maximum to be readable
 * number of covers will be determined whats visible
 * for mercedes Early next week get images resized to see what they look like @actionitem
 * Elena: For online-only journals, make images into a rectangular shape to keep size consistent

Membership Form:
 * Web form to define fields, tied to a google doc spreadsheet
 * Jim converting the form to a proper HTML form
 * Ryan: Will be a static page in Dryad. Similar to feedback form
 * Where does data go? To go in an email to Laura, details forthcoming @actionitem
 * Dan may be implementing backend

Questions about menu options when logged in
 * As a curator, administrative options
 * Menu options are shown from 'Collection'

Search with discovery (mark)
 * most of search options will be replaced with discovery facet
 * search results, facets issue?
 * Have put search into navigation for discovery
 * eliminates search form logic and you see more search results
 * Mercedes: Filtering - results per page was hidden until advanced search clicked
 * Having search bar on side was not best usability
 * Mark: Shorter in height is good, hiding advanced options

Any other areas of dspace that will be affected by reorganizing?
 * In DSpace there are two different search forms
 * in body - home, community, collection, search results
 * also search form in navigation option. Generally there to make search available anywhere
 * For 3.0, this behavior was refined - to avoid having two search forms on a page
 * May want to agree to this practice. Historically search is embedded in options
 * Ryan and Mercedes to address these

Other comments on website?
 * Elena: Detail item, item summary - unable to tell how this will look in Dryad
 * Ryan: these will change as little as possible, mostly it will be fitting the style around the content

DataOne Identifiers:
 * Ryan sent an email regarding identifiers https://groups.google.com/d/msg/dryad-dev/ty9r2NcHFlM/b3bbcEcHrTEJ
 * examples of what identifiers could look like
 * machinery is in place to make possible, but some bugs
 * Anything that's not a DOI does not appear to be part of the DOI
 * version info and timestamp is part of a parameter, same as format indicator for resource map
 * bitstream is part of URL, heartily encouraged to register these as DOIs
 * In favor of this, because it allows machinable use of these identifiers
 * But this may not provide enough context to the file (no metadata attached)
 * Elena: Once a file is downloaded, it could be separated from context
 * Not a good idea to alter files
 * Like adding a license to the top of every source file
 * Hilmar: Encourage depositors to include their contextual data in their submissions
 * No objection to registering bitstream URIs as DOIs

DataCite / ORCID ideas:
 * Brainstorming did not make it into meeting minutes
 * Remind ryan of these ideas
 * Mining ORCIDS
 * Mark: Leverage authority control mechanism in dspace
 * Have done other things to harvest from external sources
 * Associating IDs with authors in dryad - attach identifier to metadata record as auth id
 * Then build associations to ePerson in DSpace.
 * This provides a relationship between ePerson, author, and ORCID captured in dspace. small-scale authority
 * Atmire has been doing this in SOLR, authority core. SOLR documents are attached as authority ID in metadata field in dspace, has had success
 * content is not modifiable by users, but can be aggregated/associated pretty effectively
 * Many cases have several authors with only one author having an ePerson id. Would leverage ability to store identifiers associated with metadata
 * Have ability to claim publications
 * ORCID wants this to happen from ORCID
 * We could provide claiming of dryad data packages (in addition to articles)
 * Author may reference article in their ORCID and dryad could automatically scrape that API
 * Elena: Timing could be when updating dryad records with xref, update article IDs at that time, and send info back

Action items:
 * Mercedes: Rearrange Dryad bookmark into a horizontal format for use in the homepage carousel
 * Laura: Prepare announcement for May membership meeting as an item in the homepage carousel
 * Mercedes: Early next week get cover images resized for the "Recent Journals" on the homepage
 * Ryan/Laura: Finalize membership form and details of where it will send email (adapt the functionality of the feedback form)

January 25, 2013
Agenda:
 * (Mercedes) Review recent mockup updates for website, payment system.
 * (Ryan) Update on selection of payment processor.
 * (Ryan) Update on Dryad VM
 * Speeding git merges
 * Open forum

Minutes:
 * Speeding git merges
 * Anyone can perform the merge, as long as the developer and reviewer both have signed off.
 * (Ryan) Update on Dryad VM
 * VM is working, but not ready for public distribution.
 * (Ryan) Update on selection of payment processor.
 * We're moving forward with PayFlow. Laura Wendell is getting the account set up.
 * (Mercedes) Review recent mockup updates for website, payment system.
 * Mockups are nearly finalized, just going through some "small tweaks".
 * Open discussion
 * Brief discussion of support for CLOCKSS.
 * There will be no meeting in two weeks, due to Ryan's travel.

January 11, 2013
Agenda:
 * (Mercedes) Review plans for user testing
 * (Mercedes) Review recent updates for website, payment system
 * (Ryan) Update on selection of payment processor.
 * (Ryan) ORCID/DataCite integration ideas.
 * (Dan) Review plans for automating LinkOut functionality.
 * Issue tracking? (Github vs FogBugz)

MInutes:
 * (Mercedes) Review plans for user testing
 * Mercedes will be doing informal usability testing with NESCent scientists over the next few weeks. She will update designs as this testing progresses.
 * (Mercedes) Review recent updates for website, payment system
 * Reviewed the designs and provided feedback.
 * Major change: for the initial release of the payment system, we're only supporting vouchers that are associated with journals. We will not be generating and using tokens for vouchers in the initial release. (Though we will keep investigating the usability issues.)
 * Discussion of how much to feature the "Partner with Dryad" box. We need this to be somewhat prominent, at the request of the board. It is unclear whether it will distract/confuse normal users -- our previous usability testing did not address this issue. We will need to focus on this with the upcoming informal testing.
 * (Ryan) Update on selection of payment processor.
 * We have narrowed the list down to three payment gateways. Ryan is analyzing their APIs to ensure they can do what we need. Laura is focusing on selection of the banking system that will attach to the payment gateway.
 * (Ryan) ORCID/DataCite integration ideas.
 * Brainstormed a few use cases for integration with these systems.
 * Issue tracking? (Github vs FogBugz)
 * We will leave the issue tracker enabled on the LinkOut codebase, for testing purposes. But we won't (yet) enable the tracker on the main Dryad codebase. Bug reports will still go to FogBugz.

December 13, 2012
Agenda:
 * (Ryan) Review timeline for developing payment system and new website.
 * (Mercedes) Review current mockups for payment system and website.
 * (Ryan) Update on selection of payment processor.
 * (Peter) Update on LinkOut and handling of PMIDs in Dryad metadata.

Minutes:
 * Reviewed timeline for developing payment system and website. No objections.
 * Reviewed status of selection for payment processors.
 * Atmire has performed a high-level analysis of the processors that are still under consideration. They will need to dig deeper (e.g., registering for developer accounts) to determine whether all of our requirements can be met.
 * Reviewed mockups for the payment system. There was some feedback, but these mockups are nearly final.
 * Reviewed mockups for the website redesign. Mercedes has tried a few different layouts to include all of the feedback from the board. There was some feedback about wording on the site. However, the primary conclusion of this discussion was that the developer group is not the correct group to make decisions on these mockups. Mercedes and Ryan will determine which parts of the design are required/optional, and Mercedes will develop targeted sets of mockups to help make specific decisions. Mercedes will then discuss these targeted mockups with NESCent scientists.
 * When we are ready to begin moving towards implementation of these mockups, we will want to base the new design on the Mirage theme developed by Atmire. Atmire has provided us with a zip file that includes sample pages, which the designers can use as a basis for implementing stylesheets in a DSpace-friendly manner.

November 29, 2012
Attending: Ryan, Hilmar, Peter, Dan, Mercedes

Minutes:
 * Since there were no formal agenda items, we devoted the meeting to a review of open Trello issues.
 * Postgres statement issue -- Dan has reviewed this and recommends that we upgrade the library used for connection pooling. We agreed to test the upgrade. (Note: after initial testing, we decided to push it to production with the next release)
 * We need to think about how documentation should be created and maintained -- the board wants the user-facing documentation to appear through the main Dryad website, but Dryad staff needs to be able to edit it easily (without having to know XML, JSP, or how to redeploy the Dryad web-application). This task was moved to a Trello card.
 * need visual design for navigating the documentation, assuming it will be more complex than the current FAQ design
 * need technical/interaction design for maintaining pages
 * Upcoming meetings will be moved again due to holiday schedules. Next meeting is Dec 13 at 11am EST. After that, we will resume our regular bi-weekly meeting schedule, starting January 11th at 11am EST.

November 9, 2012
Attending: Ryan, Hilmar, Elena, Peter, Dan, Mercedes

Planned agenda:
 * 1) Review current focus areas for Dan and Mercedes.
 * 2) (briefly!) Review plans for Cost Recovery System
 * 3) Order of items on the "Recently Published Data" list
 * 4) Use of FogBugz/Trello to manage and record development activity
 * 5) We need a way to track activity that is "too small" to be tracked in Trello. This is both so we don't lose track of important issues and to assist in effort tracking. Previously, we tried to manage all of this in FogBugz, but it became overwhelming. How can we best track the information while maintaining control of it?
 * 6) FogBugz isn't open -- do we want/need an open system?
 * 7) * If so, do we use Jira (like DSpace), GitHub (like a "normal" GitHub project), or RT (like the rest of NESCent)?
 * 8) Cleaning up code branches in Git
 * 9) Rethinking Large File Transfer due to the recent surge in large file requests.
 * 10) Is FTP reasonable until we have Globus integration?
 * 11) What is a useful cap on file size for people to re-use?
 * 12) Should we recommend policy changes to the board?
 * 13) Meeting schedule around Thanksgiving.

Minutes:
 * 1) Order of items on the "Recently Published Data" list:
 * 2) The current method focuses on non-integrated journals, because content from integrated journals has usually spent some time in publication blackout.
 * 3) We will review how difficult it is to key the order off of file availability dates. Results of the review: It's not highly difficult, but it will take some work -- added a Trello card.
 * 4) Note that this list will be going away.... The real issue is ensuring that everything appears in RSS/Twitter.
 * 5) Use of FogBugz/Trello to manage and record development activity
 * 6) We need a way to track activity that is "too small" to be tracked in Trello. This is both so we don't lose track of important issues and to assist in effort tracking. Previously, we tried to manage all of this in FogBugz, but it became overwhelming. How can we best track the information while maintaining control of it?
 * 7) FogBugz isn't open -- do we want/need an open system?
 * 8) Thoughts in the discussion:
 * 9) Customer interactions must be private
 * 10) Sometimes the general description of an issue includes private customer info as examples
 * 11) is jira free for private issues?
 * 12) If we were to use the github tracker, we would need to pay for storage of private issues.
 * 13) Result: we want to move general tickets into the open -- but first we need to evaluate the capabilities of the systems for handling private tickets -- it's not desirable to have two separate systemss
 * 14) Issue with customer tickets entering the system but never getting promoted to Trello cards.
 * 15) We need to be transparent about our prioritization
 * 16) Ryan and Elena need to make a recommendation for how to respond to various types of customer tickets: don't promise too much, point to open trello cards, etc.
 * 17) Cleaning up code branches in Git
 * 18) We decided to keep the process we have now
 * 19) Rethinking Large File Transfer due to the recent surge in large file requests.
 * 20) Is FTP reasonable until we have Globus integration?
 * 21) We can keep the FTP site for people who ask
 * 22) We need to evaluate user instructions
 * 23) Don't encourage users to "artificially" split their files -- do encourage to split in a meaningful way
 * 24) What is a useful cap on file size for people to re-use?
 * 25) no cap
 * 26) Meeting schedule around Thanksgiving.
 * 27) Decided to have a meeting Nov 29th, 11am

October 26, 2012
Attending: Ryan, Peter, Elena

Planned agenda:
 * 1) Review Cory's 2012 Redesign Mockups
 * 2) Review current code/design for NCBI LinkOut
 * 3) Review plans for Cost Recovery System
 * 4) Future meeting schedule

Minutes:
 * Reviewed website mockups from Cory. Specific feedback included:
 * on data package pages, try putting journal covers beside the package title vs putting it beside the citation
 * add version number and server information somewhere on the about page
 * need to include rss links somewhere easily accessible
 * Reviewed current state of NCBI LinkOut
 * The basic processing is ready. Peter needs a simple URL to access data package pages based on the article DOI. This was available in earlier versions of Dryad, but has been disabled in more recent updates. Atmire will investigate.

Action items:
 * Ryan: determine whether we can remove the log4j.properties file, since we normally use log4j.xml

October 12, 2012
Attending: Ryan, Hilmar, Elena, Peter

Minutes:
 * 1) Trello: We briefly reviewed the current state of the issues.
 * 2) UI designs from Jim Allman:
 * 3) Elsevier Integration button
 * 4) * After reviewing the variations, we agreed to promote one to be the "preferred" button. The new button is very similar to the previous version, but it has a softer, more rounded look.
 * 5) Data Display Widget
 * 6) * Everyone liked the basic concept.
 * 7) * We decided to continue using the icon from shareicons for the time being.
 * 8) * We noted that the current concept has many rounded corners, while the (JOURNAL_NAME_REDACTED) site uses more sharp corners. Since we expect the widget to be used on many sites other than (JOURNAL_NAME_REDACTED), we will keep the current design and see what (JOURNAL_NAME_REDACTED) thinks.
 * 9) DSpace 3.0 and testathon: Ryan gave a brief update
 * 10) Using Git:
 * 11) * Hilmar suggested that we leave old branches in the repository for a period of time, and clean them up quarterly. This allows for a more coherent history when a branch must be re-visited to fix a bug.
 * 12) * Hilmar also suggested that we be more specific about branch names and the process for approving a pull request. Ryan updated the documentation accordingly.
 * 13) Should the primary branch be dryad-master vs just plain master?
 * 14) * We agreed that the potential for confusion was less if we kept the name dryad-master.
 * 15) When should we roll out updates?
 * 16) * New updates can be rolled out in about 10 minutes, provided no one is actively submitting content at the time.
 * 17) * After consulting Dryad usage statistics, we decided that all new code should be rolled out between 7am and 9am Eastern. This time provides a balance between least usage and greatest available developer time to recover from any issues.
 * 18) * We won't specify any particular day for rolling out new features. Rollouts will occur roughly once a week, when it is most convenient for the developers.
 * 19) Version numbering
 * 20) * it's reasonable to keep the "main" version number, but we should add a build number that includes the date or commit ID
 * 21) * the process for adding the build number needs to be automated
 * 22) * since we're moving towards a cleaner design, we may want to hide the version number in an html comment or meta tag -- Ryan will ask Todd how important this is for users to see
 * 23) PR strategy for new features, since they're not bundled in big releases?  (newsletter vs blog)
 * 24) * We will publish lists of changes in regular updates (weekly? monthly?)
 * 25) * The Dryad newsletter can link to these release notes as well as any blog posts that descrive major features
 * 26) NCBI LinkOut:
 * 27) * Work is progressing. NCBI has validated our sample files, but they do not want us to submit our sample files to the main system -- they want the "real" files for the first test.
 * 28) Making the meeting "completely open" (minutes, call number, etc.)
 * 29) * We determined there is no compelling reason to keep anything about these meetings private. Instead, we will strive to get as much community input as possible.
 * 30) * We cannot publish the "private" phone number for Dryad conference calls. As an alternative, we will try FreeConferenceCall.com

Deferred items:
 * 1) Review changes to 2012 Redesign Mockups
 * 2) Discussion of meeting schedule

Action items for next meeting:
 * 1) Ryan investigate FreeConferenceCall.com Done. It looks like a useful alternative, so we will try it next time. --Ryan Scherle (talk) 16:11, 12 October 2012 (EDT)
 * 2) Ryan discuss with Todd whether to keep the version number visible or hide it from normal users.