ERDWCharter

ERG Reference Documentation Working Group Charter

This reflects what we think we are doing. Currently a draft, will be updated as we go.

Current working group members: Olga Zamaraeva, Dan Flickinger, Luis Morgado da Costa, Alexandre Rademaker, Francis Bond, Eric Zinda

Goal

Increase ERG usage by providing documentation that allows a broader set of users to understand and use the MRS output of the ERG

• Broad community (non-linguists and linguists)
• Reduce reliance on limited # of subject matter experts
• Focus on practical usage of the ERG (e.g. Python + ACE + Grammar)

Audience

Anyone who wants to build a system using the ERG

• Research
• Production
• Etc.

Must have computer science experience

• Documentation is focused on building a system
• Users capable of finding, installing and using the Delph-In Python library
• Users who could learn “challenging” languages (Haskell, Prolog, etc)

Content

Conceptual/Overview material

• Variant of: https://github.com/delph-in/docs/wiki/ErgSemantics
• Add linguistics background material (what is an event?)

Case studies

• How does one actually use the ERG?
• Description of the innards of working systems

Inventory

• The public interface: the MRS output
• Variant of:  https://github.com/delph-in/docs/wiki/ErgSemantics_Inventory
• Look at the forum for gaps 

Tools and Processes

• How to use ACE?
• How to get a build?
• Who owns what in Delphin-land?

Process

The ERG Reference Documentation Working Group (ERDG) is the “steering committee” and ensures:

• We are making progress
• We are going in the right direction
• Monthly meetings for a while?

Build a "Sustainable System" for documentation

• Simple and low overhead: Good enough
• Allows for broader contributions
• Recognizes most information is held by a small group of experts
• Can continue beyond this point-in-time effort

The Process:

1. Create a list of topics to write on a public page The list of "todos" Documentation of the process, templates, and process for taking one on

2. Allow contributors to sign up to write a first pass on each

• Focus on good enough!
• Recruit a core group of experts
• …but anyone in the community can be a contributor

3. Author (or others!) can mark a topic for review

• "Needs technical review" and/or "Needs accessibility review"
• Accessibility (i.e. understandability by someone not practiced in the art of linguistics)
• Allows "editors" to search for docs that need a review pass
• Mark the doc as reviewed so future readers know who looked at it