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]