Developer Meetings

From Dryad wiki
Revision as of 07:34, 30 November 2012 by Elenafeinstein (talk | contribs) (November 29, 2012)

Jump to: navigation, search

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 11am-12:30pm Eastern Time.

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

Video/screenshare is available through Adobe Connect at http://dukeuniversity.acrobat.com/dryad

Audio is transmitted via a conference call. The conference number will be announced in the Adobe Connect session.

Meeting Agendas and Minutes

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
    1. 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?
    2. FogBugz isn't open -- do we want/need an open system?
      • If so, do we use Jira (like DSpace), GitHub (like a "normal" GitHub project), or RT (like the rest of NESCent)?
  5. Cleaning up code branches in Git
  6. Rethinking Large File Transfer due to the recent surge in large file requests.
    1. Is FTP reasonable until we have Globus integration?
    2. What is a useful cap on file size for people to re-use?
    3. Should we recommend policy changes to the board?
  7. Meeting schedule around Thanksgiving.

Minutes:

  1. Order of items on the "Recently Published Data" list:
    1. The current method focuses on non-integrated journals, because content from integrated journals has usually spent some time in publication blackout.
    2. 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.
    3. Note that this list will be going away.... The real issue is ensuring that everything appears in RSS/Twitter.
  2. Use of FogBugz/Trello to manage and record development activity
    1. 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?
    2. FogBugz isn't open -- do we want/need an open system?
    3. Thoughts in the discussion:
      1. Customer interactions must be private
      2. Sometimes the general description of an issue includes private customer info as examples
      3. is jira free for private issues?
      4. If we were to use the github tracker, we would need to pay for storage of private issues.
    4. 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
  3. Issue with customer tickets entering the system but never getting promoted to Trello cards.
    1. We need to be transparent about our prioritization
    2. 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.
  4. Cleaning up code branches in Git
    1. We decided to keep the process we have now
  5. Rethinking Large File Transfer due to the recent surge in large file requests.
    1. Is FTP reasonable until we have Globus integration?
      1. We can keep the FTP site for people who ask
      2. We need to evaluate user instructions
        1. Don't encourage users to "artificially" split their files -- do encourage to split in a meaningful way
    2. What is a useful cap on file size for people to re-use?
      1. no cap
  6. Meeting schedule around Thanksgiving.
      1. 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:
    1. Elsevier Integration button
      • 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.
    2. F1000 Widget
      • Everyone liked the basic concept.
      • We decided to continue using the icon from shareicons for the time being.
      • We noted that the current concept has many rounded corners, while the F1000 site uses more sharp corners. Since we expect the widget to be used on many sites other than F1000, we will keep the current design and see what F1000 thinks.
  3. DSpace 3.0 and testathon: Ryan gave a brief update
  4. Using Git:
    • 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.
    • Hilmar also suggested that we be more specific about branch names and the process for approving a pull request. Ryan updated the documentation accordingly.
    1. Should the primary branch be dryad-master vs just plain master?
      • We agreed that the potential for confusion was less if we kept the name dryad-master.
    2. When should we roll out updates?
      • New updates can be rolled out in about 10 minutes, provided no one is actively submitting content at the time.
      • 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.
      • 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.
    3. Version numbering
      • it's reasonable to keep the "main" version number, but we should add a build number that includes the date or commit ID
      • the process for adding the build number needs to be automated
      • 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
    4. PR strategy for new features, since they're not bundled in big releases? (newsletter vs blog)
      • We will publish lists of changes in regular updates (weekly? monthly?)
      • The Dryad newsletter can link to these release notes as well as any blog posts that descrive major features
  5. NCBI LinkOut:
    • 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.
  6. Making the meeting "completely open" (minutes, call number, etc.)
    • 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.
    • 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.