Re: [Tools-arch] [Tools-discuss] Draft RFP SoW for "Review of the current landscape of IETF document processing tools"

[Jay Daley <[e-mail]>]

Sorry, some minor changes, please use this version and please remember that if you wish to bid for the RFP then you should either not provide any comment on the SoW, or declare that when providing comment. 

Jay

—— 
# SoW - Review of the current landscape of IETF document processing tools

## Overview

The IETF seeks a contractor to review the current landscape of tools that have been specifically designed to be used by the IETF community to work with IETF documents (I-Ds and RFCs) and to build a dataset about these tools, including technical details, maintenance processes, licensing and others, and further to determine what parts of the document production, management and usage lifecycle each tool supports.


## Deliverables

### Deliverable 1 - Dataset

A dataset about the tools containing a combination of text, simple scales, simple classifications and supporting narrative.  For example, for licensing, a simple classification may include "GPL v3, Proprietary, BSD-like" and more.

The dataset is to be provided as raw data in CSV format.

The data to be collected for the dataset is:

1. A full catalog of tools, including all the relevant tools at https://tools.ietf.org and other tools that are not listed there but are known to be in use. 
2. Details of the maintainer(s) of each tool
3. The licensing of the tool (simple classification)
4. The technical environment each tool is intended to work in (OS, packages, containers, etc)
5. How each tool is maintained, including
    1. where the source code is located
    2. how issues are raised (simple classification)
    3. the level of version control and release management in use (on a simple scale)
    4. how comprehensive the test coverage is (on a simple scale) 
    5. the form of testing framework in use (simple classification)
6. A subjective assessment of the current maintained state of the tool (on a simple scale)
7. A subjective assessment of the suitability of each tool (on a simple scale), based on 3, 4, 5 and 6 above.
8. What stages of the document lifecycle (see below) each tool covers.


### Deliverable 2 -  Document lifecycle

A model of the IETF document lifecycle including document production (authoring, review, format conversion, etc), document access (download tools, search tools, etc) and document usage (extracting certain parts, etc).  This is only to cover the work carried out by the IETF community and not the work of the RFC Production Centre.

There are no templates for this model nor any existing work to build upon and so it is expected that this will be entirely new. 


### Deliverable 3 - Coverage map

Some form of coverage map/infographic showing each tool and each stage of the document lifecycle, the coverage of each stage in the lifecycle and the subjective assessment of the suitability of each tool.  This coverage map should allow at-a-glance understanding of the coverage of each stage and each tool including stages covered by multiple tools and stages not covered by any tool.

This coverage map is to be supplied in any common vector format.


## Requirements

### Selecting the tools to assess

The contractor will be responsible for drawing up the list of tools to be included for approval by the IETF LLC.


### Review and transparency

The IETF is committed to transparency and community engagement and so requires this work to be carried out as follows:

1. All three deliverables are to be developed using a public repository so that interested parties can see the work as it unfolds.
2. The initial list of tools proposed by the contractor will go out for community comment and the contractor will need to consider the feedback and potentially revise the list before the final version is presented for approval.
3. The maintainers of the tools are to be given every opportunity to recommend changes to the data and the assessments within (though the contractor retains the final say in what data they choose to include in the deliverable), which means:
    1. Any issues or pull requests raised by maintainers on the repository are to be considered and responded to.
    2. Once the initial version of the dataset is complete, it will go out for community comment and the contractor will need to consider the feedback and potentially revise the dataset before the final version is delivered.
4. The initial versions of the document lifecycle and coverage map will also go out for community feedback and the contractor will need to consider the feedback and potentially revise these before the final versions are delivered.


### Work of the RFC Production Center

The RFC Production Center (RPC) is solely responsible for two steps in the document lifecycle:

1. The publication of the RFC, which uses a number of internal tools to manage references, assign DOIs and more. 
2. The conversion of the XML RFC into the long term ar PDF/A format for long term archive, which uses commercial software. 

The tools used solely for the two processes above are not within scope for this RFP but these steps should appear in the document lifecycle and coverage map.


## Additional Details

None.

—— 


-- 
Jay Daley
IETF Executive Director
[e-mail]