Page tree
Skip to end of metadata
Go to start of metadata

The following is a proposal for enabling user feedback for collections of online content managed by Trust and Identity (T&I), including its community groups. The goal is to leverage T&I's existing issue management processes, while recognizing that there are many collections and even more authors of the content. For the purposes of this proposal, a collection is a set of documents related to a common topic (e.g., InCommon Federation, eduroam). Examples of documents contained in these collections are:

  • product/service descriptions
  • terms and conditions
  • reference documentation
  • support documentation
  • help materials within products

For each collection, one or more "owners" is designated. Collection owners may or may not author the content in the collection, but they are responsible for the collection, its scope of topics covered, its overall structure, and (more specifically for this document) they receive and respond to feedback, routing that feedback to specific authors, as appropriate.

How Feedback Is Provided and Processed

In order to provide consolidated help desk services, feedback for collections should be in the form of electronic mail to help@incommon.org, preferably with a subject line that enables automatic assignment to the collection's owners by Front. Service Management will route the feedback they receive to the appropriate collection's owner.

The documents in a collection should contain instructions for how a reader can provide feedback. Normally, this information will be in a footer or end note for each document but may be provided in some other manner, depending on the nature of the collection.

The Collections and Their Owners

The following is the start of a table that will be T&I's authoritative list of collections and who "owns" them. It will be the responsibility of the table's owner to keep it up to date as the collections evolve over time.

CollectionOwnerNotes
FederationAlbert Wu
Certificate ServicePaul Caskey
eduroamMike Zawacki
iTAP (including individual components)Bill Kaufman
Training and ConsultingErin Murtha
Community Engagement and Working Groups ProcessesCommunity
Development
Manager
Position to be filled in 2019.
MACE OID and URN registriesCACTINick as liaison to CACTI.
Trust and Identity Program Advisory Group (PAG)

Dean Woodbeck


InCommon Steering CommitteeDean Woodbeck
InCommon Community Trust Advisory Board (CTAB)Albert Wu
InCommon Technical Advisory Committee (TAC)Albert Wu
CACTINick Roy
General T&I pagesDean Woodbeck
Document StewardshipDocument Repository LibrarianCommunity Development Manager?
This documentAnn WestIncludes assignments of owners to collections.

Linked Applications

Internet2 Wiki

 

 



 

 

 

 

 

 

 

 

 

Example: Technical Documentation for InCommon Participants

Each page in the Technical Documentation for InCommon Participants collection has the following footer:


Please send comments to  with a subject of "Feedback: Technical Documentation for InCommon Participants"


Since it is hosted as a Confluence wiki space, which supports a common template for all pages in a space, adding a footer to that template with the following text:


Example Footer
Please send comments to [admin@incommon.org|mailto:admin@incommon.org&subject=Feedback%20for%20Technical%20Documentation%20for%20InCommon%20Participants] with a subject of "Feedback for Technical Documentation for InCommon Participants"


will add such a footer automatically, such that clicking on the help@incommon.org link will create a mail message to admin@incommon.org with a subject of "Feedback: Technical Documentation for InCommon Participants."


  • No labels

12 Comments

  1. The content owners seem to be breaking down nicely to Service Managers of our services. One missing piece is CACTI for the services of MACE OID and URN registries. It seems like we need an internal Service Manager to own the content and processes for this service that CACTI operates.

  2. We might want to add rows for the InCommon Home page (incommon.org proper), as well as the Internet2.edu related pages.

  3. That is approximately the thinking:

    Federation - Albert
    eduroam - Mike
    Certificates - Paul
    TIER/iTAP - Bill?
    Training/Consulting - Erin
    Community Engagement/Development - TBD ← this role also would have the working group / committee content stewardship, perhaps 

  4. Yes, that seems right to me.

  5. I will need to coordinate with Component Architects on how we operate things around Shib, Grouper and COmanage from a base component standpoint.

    1. Yes, a primary function of a collection's "owner" is to coordinate with the authors of the documents in the collection.  The owner is not necessarily the primary author.

  6. I would also like to understand the framework being consider for using Front and having the ability to delegate and track.

    1. As discussed in electronic mail, Front will be the interface to the community, but each collection will manage the issues it receives according to how the collections' authors coordinate their work.

    2. It would be very lovely if Front can eventually either automatically (via keyword or rule match, perhaps) or manually create/update issues in an (or multiple) issue tracker. That might be a conversation for the services group:

      How do we want to track service requests and incidents? (Yes: this becomes circular if collaboration platform is part of the perquisite)

  7. I am also aware that there really are two related concerns here:

    The starting point of this proposal is "someone needs to mind the ongoing curation of InCommon content/digital asset); we need a way to field input." 

    Those of us who will end up being the steward are asking: "How do we install a workflow that is clear, intuitive (for the folks who have to react to the input), sustainable, and encompasses the entire loop?" 

    1. (Of course, that clear, intuitive workflow is needed, independent of the starting point...)

      1. I agree. They are related but independent. Historically, we like to focus on tools, not the process. The process can be developed independent of the tool (e.g., a RACI assessment of who is needed to do what for each content type/area and a step by step when of the what.).