Bounty: TOIPTerm v1.0

[dhh1128]

NOTE The issue described below is preliminary (not yet approved by the CTWG for public release). Developers interested in the bounty should watch the ticket. When this note is removed and the bounty is formally approved, we will add a comment to the ticket releasing it for public interaction.

The Trust Over IP Foundation invites software developers to apply for a bounty associated with building a terminology management tool for its Concepts and Terminology Working Group (CTWG).

This tool, TOIPTerm or "TT" for short, will be called by automation (e.g., Github actions), as well as by experts who manage the TOIP corpus of concepts and terms in git repositories. (Ordinary contributors to glossaries will use simpler tools that already exist.) TT will add data integrity, versioning, import, and export to larger processes that build glossaries, specifications, whitepapers, and other artifacts. We expect the tool to be cross-platform and shell-oriented, and to be written in python. A full specification for the tool is located here.

Basic requirements

See "Decisions" in the CTWG's 21 April Meeting Notes.

Bounty Details

The bounty is in the amount of 18,000 USD. It will be awarded as follows:

• 3000 USD is billable at the time of the award.
• 7000 USD is billable at the time of a first demo (explained in "Success Criteria" below).
• The remainder is billable at final delivery.

Process

Interested developers should reply to this issue with a brief statement of interest. You will be asked to attend a CTWG meeting to present for 5 minutes on why you'd be a good match for the bounty. (If attending a meeting is difficult, you could also record a 5-minute pitch.)

Clarification questions about the bounty or about technical requirements should be recorded as comments on this github issue, so that all interested parties can follow the evolving conversation.

Timeframe

The current intent is to award the bounty by vote of the CTWG at its meeting on Monday, May 10. Depending on the number and complexity of proposals, it is possible that this deadline will be moved further into the future.

We imagine that the tool will be completed within approximately 1-2 calendar months.

Success Criteria

1. A "first demo" will be conducted at a CTWG meeting within a few weeks of the award, at a point when the developer judges that work is perhaps 30-40% complete. At this meeting, the developer should demonstrate the following:

   • Code checked in to a repo with an Apache2 license.
   • A working command-line that displays syntax help.
   • Github actions-based CI/CD for the code, with at least one test, and with all active tests passing.
   • A test corpus of at least a dozen terms and their associated concepts, organized into two or more scopes.
   • A stub version of each "high priority" commandline feature from the spec.
   • A list of clarification questions or proposed design choices that they would like to ratify with the CTWG.

2. A "final delivery" demo will be conducted as the gating milestone for the completion of the project. At this meeting, the developer should demonstrate the following:

   • Final code checked in to a repo with an Apache2 license.
   • Working command-line that displays syntax help.
   • Github actions-based CI/CD for the code, with a reasonable number of automated tests that all pass.
   • A working data ingestion process (tt ingest-bulk-data) where the input data matches the ingestible data model described in spec, and the output is data in the defined internal data model.
   • A working data export process (tt export mkdocs) where the tt command can be followed in a script by a call to mkdocs such that a glossary is produced.
   • Working versions of the other "high priority" commandline features from the spec work (tt curate-check, tt curate-link, tt curate-tag -- where all of these work on the internal data model)
   • A PR against this repo, updating the /docs folder with additional insight into how tt works (audience = a developer who would want to maintain it), how it can be extended (audience = a developer who wants to export terminology for a whitepaper), and anything that needs to be adjusted/improved in the spec or in the data model.
   • Github issues suggesting future work items and open bugs for TT.

[RieksJ]

I have created PR51 to add some requirements that I think tools in the toolset should have (specifically on handling scopes and errors). I wonder if there are other requirements we need to specify..