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

Compare with Current View Page History

« Previous Version 5 Next »

Reading Session #4: Digital Content and Infrastructure Needs of Research Faculty
Led by Jennifer Schaffner, Susan Kroll, Mackenzie Smith
Links: A Slice of Research Life available at http://www.oclc.org/research/publications/library/2010/2010-15.pdfhttp://www.oclc.org/research/publications/library/2010/2010-15.pdf.
Scholarly Information Practices from the Online Environment available at http://escholarship.org/uc/item/0kr8s78vhttp://escholarship.org/uc/item/0kr8s78v.

MacKenzie's objections to Kroll's Report:

  1. How valid is this research at your individual institution (each university is a snowflake...)
  2. There is tension but still trying to move ahead even though administration is telling you that you can't
  3. Senior Faculty behave differently than rank and file researchers
  4. Mission and marketing - how do we market what we are already doing

Other notes:

Coeus - MIT http://coeus.org/

Faculty want help with: structuring their notes and datasets, negotiating publication licenses, funding requirements, authority work, customizable personal webpages, and keeping up to date with their iterations.

Review Ithaka's faculty survey

www.rin.ac.uk - patterns of info use and exchange case studies

"pre-print is a more authentic representation of their work" - Kroll's study found that this is the feeling of faculty


Sustainability and Revenue Models
for Online Academic Resources
An Ithaka Report
May 2008
http://www.clir.org/dlf/forums/fall2010/sca_ithaka.pdf


Reimagining METS An Exploration

http://www.clir.org/dlf/forums/fall2010/METSNextGeneration.pdf


U.S. Government Printing Office’s Federal Digital System (FDsys)

http://www.clir.org/dlf/forums/fall2010/FDsysFactSheet.pdf


Closing the Digital Curation Gap

http://www.clir.org/dlf/forums/fall2010/CDCGflyer.pdf


Twitter summary:http://wiffiti.com/screens/41933summarized: http://summarizr.labs.eduserv.org.uk/?hashtag=dlf2010


Agile Project Management:

http://agilemanifesto.org/

working software, customer collaborations, responding to change, individuals and interactions

Characteristics of agile:

plan as you go, feature-breakdown structure, user stories, release plan, story boards, deliver as you go, learn every iteration, adapt every thing, manage team

"Information radiators"

empowering and trusting people, providing a constant feedback

change happens frequently

requirements are not well-defined

new technology or public domain

customer isn't sure of what is desired

Delphine uses agile/scrum at Penn State - calls some members of her team "ingesters"

NCSU - refer to powerpoint for books to read

resources:

http://agileforall.com/blog

blog.mountaingoatssoftware.com

Books: http://library.mit.edu.ezproxyberklee.flo.org/item/001270790

http://mv.ezproxy.com.ezproxyberklee.flo.org/toc.asp?site=bbbga&bookid=8392

notes from Emily's presentation:

Product backlog is supposed to be prioritized. But library staff have a difficult time prioritizing issues against each other. They work best talking generally about what they think should be part of a given iteration. Then we negotiate with them about what we think we can accomplish. The IT product manager plays a large role in determining final priorities here.

Testing – “the weakest link”. For smaller projects w/o massive codebase, when is it faster and better to automate testing? No QA experts, so try to utilize product teams with regular updates throughout the cycle. In the end, developers and IT product managers have to do first pass at QA testing. Have not done a good job defining acceptance tests for each piece of functionality.

Our group is responsible both for real-time support and development. How to handle? Working toward documenting time spent on real-time support emergencies in JIRA and track how much effort spent on that vs. development. This feeds our estimation of how many hours are available for each person for each cycle; assume some time goes to support.

Timeboxing of efforts within a 6-week development cycle helps keep us from getting bogged down in large implementations that go on for months and months and keep team from working on other projects. Instead, focus on the outset on a simplified set of work that can be accomplished in 1 cycle and then re-evaluate institutional priorities at the end of that cycle. This reduces feeling of black box stall on any given project.

 Users hate seeing nothing. Using these methods, more people have seen some results faster. Incremental improvements that happen regularly produce much more positive feedback and energy both within the development team and out to our customers in the library.

Adapt to changing priorities. For example, move our EZProxy Administrator tool to the top of the list as needed for Shibboleth integration. We would not have been able to do this without causing problems if we had been already committed to months of development and a huge feature list for ReservesDirect, our course reserves system. Constant re-evaluation also always priorities within a project to change – since we haven’t committed beyond the current cycle this is easy to accommodate.

Greenhopper & JIRA

Google docs & JIRA

  • No labels