The Long-Term Health of the DELPH-IN Ecosystem

Overview

Importance

  • Many if not all of us do research enabled by work of others in the consortium
  • The formal existence (ephemeral as it is) of the consortium is also useful in e.g., grant applications

Risks

  • Multiple single points of failure (people leaving or shifting focus)
  • Maintainability of resources/tools, especially those that become tied to a particular person
  • Lack of available expertise/funding for others to step in
  • Building on work of others may or may not make funding seeking easier
  • Allegro/CLIM or other external issues

Successes

Both successful hand-offs and general DELPH-IN accomplishments

  • Jacy maintained across sites/time zones and passed along (qualified success)
  • PET: group of people who can maintain and develop further
  • Joint reference formalism: Development of multiple tdl-based parsers
  • ERG – used in large number of parallel and disjoint initiatives
  • LOGON infrastructure
  • Redwoods machinery
  • Emerging grammars: SRG/LXGram/KRG/NorSource

Strategies

  • Documentation
  • Open source commitment
  • Collaboration on single resources
    • Teams of two or more (at one site), developing together (spread the expertise)
    • Collaboration across sites
    • Continue and enhance tradition of cross-site visits
  • Hand-off period (overlap between successive maintainers)
  • “DELPH-IN dues” to support various tasks that we want
  • Succession plans
  • Put funding in for grammar/tools improvement in larger grants
  • More lively use of mailing lists:
    • Ask questions on the developers list rather than one-to-one
    • Everyone actively working with the technology should be on the developers list
  • Empire building (recruitment)
  • Commitment to maintaining existing functionality on targeted platforms
  • All sites encouraging students who have interest to go beyond tool use to explore the source code
  • Sub-contracting among partners — include in grants funding for another site to contribute
  • Cater to our every whim
    • Citations: Use wiki to create publications list (user-generated); list canonical citations in accessible place
  • Remind ourselves of these issues annually at the DELPH-IN Summit.
  • Visibility/Branding
    • point to www.delph-in.net
    • cite 2002 CLE book
    • Standing committee crafts canonical reference and submits to LREC 2012
    • Canonical (short) ack note
    • DELPH-IN t-shirts (to be worn as we make a splash at 2012 conferences…)

Notes

Emily’s introduction. DELPH-IN is only as strong as our participation in it. DELPH-IN has great value, not only just for adding credibility to grant writings

Yi: concern about when individuals with too much tool ownership departing

All: It’s difficult for one researcher to take over another’s grammar

Antske: It can be a benefit to have more than one person working on a grammar from the start

Yi: JACY is/was a good example of continued maintenance

Francis: Mild dispute that JACY was an unqualified success, since certain parties may have only grasped it in part

Tim: Picking up others’ work can be a funding challlenge

Stephan: …Or it can be the opposite, if you are showing international collaboration

Antske: It may help if people work part-time on the grammar: it would be easier to find people to work on the grammar funded, and publish and may also facilitate collaboration between grammar-engineers (not having them work on the grammar at the same time, this is of course possible with SVN, but this is sub-optimal)

Yi: This maintenance work should be undertaken, even at the expense of personal research goals

Prescott: would an increased sense of community be enabled by somehow increasing traffic on mailing lists?

Francis: one should favor the wider broadcast of an inquiry, rather than the individually targeted missive

Stephan: “more visibile communication would be nice” increased volume shouldn’t be a problem. Nowadays, everyone should be on developers, pretty much.

Francis/Stephan: Developers list is more open than ‘participants’

Rebecca: Should the membership of the standing committee be more visible?

Francis: It is (reads list from website)

Laurie: Re: single points of failure, people leaving: losing a standing committee member can be more debilitating than just a grad student who created a tool.

Francis: The rules of the standing committee may not include procedures for succession.

Stephan: PET is a good example of ongoing maintenance. We hope for optimal ongoing maintenance, but sometimes it doesn’t happen. It is true that LKB and [incr tsdb()] have sub-optimal support at this time.

Dan: “We will find interesting things to collaborate on, depending that the resources that are around.”

Emily: We must be more vigilant about correctly and fully citing work within our own community. Gets “grumpy” when work is mentioned as taken for granted.

All: there doesn’t appear to be a citation listed on the wiki for [incr tsdb()]

Francis: Individual projects should be more tightly associated with the DELPH-IN brand.

Emily: The root url should be more widely included in our mentions of DELPH-IN

Tim/Stephan: Recognizability of “Pargram”

Francis: should we develop a canonical DELPH-IN acknowledgement blurb?

Emily/Stephan: This is a bit off track; returning to successes, such as having multiple parsers within the same formalism.

Stephan: “um, the ERG is a bit of a success… It’s our ‘Charniak parser’”

Dan: I’m not sure I find that a compliment

Francis: LOGON infrastructure as a success?

Dan: Redwoods tools and so forth. Malouf’s early treebanking…

Emily: Speaking of Rob, he is an example of recovering from a key researcher moving on…

Rebecca: I’d feel more comfortable if there was more joint ownership of key systems. We’d be less vulnerable to single-point-of-failure succession issues

Francis: If one needs a fix in [incr tsdb()] one must do it oneself. Less so with PET.

Laurie: The fact that it’s open source doesn’t help some researchers with immediate needs.

Stephan: Solutions to that: 1. “basic benevolence; there are guarantees for basic support” 2. “Look for local ecosystem whiz-kids for help”

Emily: Summarizing (see main slides). Cross-site visits should be encouraged.

Stephan: Tradition for sub-contracting between partners. Budget for this. If you anticipate tools modification, it might be possible to fund the changes you need.

Last update: 2011-06-28 by AntskeFokkens [edit]