The Trust and Identity Document Repository is found here.


Introduction

Internet2 Trust and Identity's document stewardship process formalizes the management of documents as they are drafted, proposed, vetted, and approved for use, and published for open access.  It is intended to address any documents that are products of work sponsored by Trust and Identity or one of its community advisory groups. Examples of such products include:

  • Community standards
  • Policies
  • Contract templates
  • Specifications
  • Recommendations and guidelines
  • White papers

Note that any software documentation for developers and end users that is related to a specific release of the software, and is distributed with software, is vetted as part of the quality assurance process for the software release and is out of scope for Trust and Identity Document Stewardship. Documents describing software lifecycle management, overall system architecture, etc., however, are in scope.

CACTI (Community Architecture Committee for Trust and Identity) is charged with oversight of the document stewardship processes.

The foundational document establishing and governing the Document Stewardship process is found here (click on the link to the PDF).

Authorized Sponsors

Submissions to the Document Repository must be approved by a Sponsor.  The authorized Sponsors are::

Note

In the case of a document or report sponsored by InCommon TAC or by CTAB, the document is only considered final and ready to be added to the document repository after approval by the sponsoring body and also by InCommon Steering. This is because InCommon TAC and CTAB are advisory to InCommon Steering.


Getting a Doc ID for a document that will go into the Repository

For a document that will eventually go into the repository, it is recommended to get a document ID and format the document with the needed components during the time that you are developing the document, prior to it being finalized. (You will submit the document to go into the repository later when it has been finalized and approved.)

  • Contact the librarian, ti-librarian@internet2.edu, to get the document repository ID and Persistent URL (which is based on the DOI).  The document will not be placed in the repository and the Persistent URL will not be active until a later stage when the document is final and approved.
  • Follow the steps below to add the needed elements to the document.

Preparing a Document for the Repository

To prepare a document to go into the Document Repository:

1. The cover page should include this info below, though  only the Title, copyright and the licensing info are strictly required

Document Title

Repository ID
Persistent URL

Authors  provide authors names in all cases and their ORCID where possible - e.g.,  
                   David Walker https://orcid.org/0000-0003-2540-0644
Publication Date

Sponsor

Note: You obtain the Repository ID and Persistent URL from the librarian. The authorized Sponsors are listed in Trust and Identity Document Stewardship. See Document Repository Metadata Element Definitions for more information.

https://share-my-id.orcid.org/ is a useful tool for collecting ORCIDs for a group of authors.

2. This copyright and licensing info must be on the first page of the document  (where <year> is the current year).

© <year> Internet2 
This work is licensed under a Creative Commons Attribution 4.0 International License.

See example HERE  

Submitting a Document to the Repository

These steps must be completed before a document is ready to go into the repository.

  1.  Document review phase is complete
  2.  A community consultation has been completed if appropriate 
  3. The sponsor has approved the final version (please see note above on this page about need for InCommon Steering approval of documents sponsored by TAC and CTAB) 

Once these steps are done, send the document to  ti-librarian@internet2.edu  in both of these formats:

  1. text (preferred) or HTML

  2. PDF, unless that is not appropriate for the specific document

You may also submit the revisable (e.g., MS Word) document that was used to create the PDF/text/HTML documents for inclusion in the Development Location metadata element. (See below.) This is recommended if future revisions may be made.

At this time, you may also propose the following metadata elements to the librarian, as appropriate:

  • Review
  • Signature
  • Future Review
  • Supersedes
  • Related Docs
  • Development Location
  • Subject Tags

See Document Repository Metadata Element Definitions for more information about these optional items.

After you submit the document in two formats of the document to the librarian, the librarian will attach them to the corresponding page in the repository and those will become the authoritative copies. 

Here is an example of a repository page that has the attachment of the authoritative doc.

When it's time to update a document

An updated document is a new document with its own new row in the document repository, even though much of its content may be the same as the original document. 
Just as with the original document, the update is subject to review and approval, as specified by its sponsor.

There are a few things to note:

  • The Repository ID of the original document will be listed as a "superseded document" on the superseding document's repository metadata page.
  • The "Deprecated" field of original document's repository metadata page will be "yes."
  • Numbering: When the superseding document is an update to the superseded document, its Repository ID will typically be the Repository ID of the original document after adding 1 to the version number. For example, an update to TI.22.3 would have TI.22.4 for its Repository ID. There are, however, exceptions to this numbering convention.  For example, the superseding document may be completely new, not an update, or there may simply be historical reasons why this was not done,
  • There are additional details for the Doc Repostiory Librarian at  https://spaces.at.internet2.edu/x/Y5iTBg 
  • Note that a revisable version of the older document may be available in the Development Location field of its repository metadata page, as well as other material that may help you.

The "Deprecated" field of a document's repository metadata page will be set to "yes" when its content should no longer be trusted to reflect current practice or thinking on its topic. As noted above, this occurs when a document is superseded by another, but it can also occur without a superseding document

Here is an example of a document that is an update to an earlier document in the repository. http://doi.org/10.26869/TI.105.2

Note the change log at the end of the document, which is a helpful feature to add to any such document. http://doi.org/10.26869/TI.105.2

When it's time to deprecate a document

In order to maintain a historical record, documents are never removed from the repository, unless they were placed in error. Documents that no longer have anything other than historical interest are deprecated.

Here is an example of a deprecated document http://doi.org/10.26869/TI.105.1

Documents that are presented elsewhere in Internet2's or InCommon's website

Typically, references to documents in the repository should link to the documents' metadata pages via their DOI URL (e.g.http://doi.org/10.26869/TI.105.1).

There are times, however, when a document should be presented in a manner that is consistent with the context of the referring page, or when multiple references to the document make link maintenance difficult as new versions of the document are published. This alternative presentation is usually accomplished by creating a copy of the document's text, images, etc. within the platform used to present the referring page (e.g., WordPress for http://www.incommon.org).

See this example.

When a document in the repository is also presented on a webpage, the content "owner"  (note July 1, 2019: we may want to link from here a list of content owners and these pages) of the referring page should:

  • Preface the copy with a statement clarifying that it is not the authoritative copy, and providing a link to the authoritative copy in the repository.  For example,
    • This document is curated under the Internet2 Trust and Identity Document Stewardship program. Download the official text from the Internet2 Trust and Identity Document Repository at http://doi.org/10.26869/TI.34.1.
  • Do not change the text or otherwise change the intellectual integrity of the document.  If you find you need to do this, you should probably be creating a new document with (perhaps extensive) quoting from the authoritative copy.
  • Keep the formatting as close to the authoritative content as practical.
  • Ask the librarian to add a note to the metadata page to indicate that a non-authoritative copy exists, its URL, and who (by name or position) should be informed if the document is superseded or deprecated. For example,

Additional Info

Working group chair and flywheel guidelines with regard to the Document Stewardship process are found here.

Please contact Jessica Fink <jfink@internet2.edu> for more information.

Document Stewardship Process - Framework Docs


See Also

Trust and Identity Document Repository Index

Blog on Document Stewardship (Sept. 2018)

Consultations Home

Community Review of the Doc Stewardship plans

Guidelines for Trust and Identity Working Group Chairs and Flywheels

  • No labels