Model the process for TRTF w/ Milestones

[andorsk]

I've used the TSP process with a small modification, adding a group calibration stage, where we figure out if additional WG are needed for Work Items and possibly spin up some process around it depending on the scope.

graph TD
    Initiation -->|scoping, audience, deliverables defined| Calibration
    Calibration[Group Calibrate the scoping with the WG] --> PS

    subgraph Working Item
      PS[Proposal Stage]
      CP[Consolidation Phase]
      DraftPhase[Draft Phase]
      PublicRelease[Public Release]
      PS -->|muliple proposals generated similar to aries-rfcs| CP
      CP -->|consolidate separate proposals into a unified proposal| DraftPhase
      DraftPhase -->|some repo deliverable for an actual proposal| PublicRelease
      PublicRelease --> CommunityFeedback[Community Feedback]
      CommunityFeedback  -->|feedback loop| PublicRelease
    end

Loading

I think we could follow this process, but I'd like to clarify the initiation stage a little better, as that's our current stage:

graph TD
    subgraph Initiation
      GoalSetting[Goal Setting and Objectives]
      Scoping
      Audience[Audience and Stake Holders]
      Requirements
      Deliverables
      InvolvedComponents     
    end

    InvolvedComponents --> WorkingItems[Working Items Spun Up]

Loading

[talltree]

@andorsk, I don't know how to reply in a thread to your message (or whether that's even necessary). In any case here are some thoughts about what you are calling the "Initiation" stage.

In many working groups or task forces, this is often called the "requirements gathering" stage. While that's a perfectly fine term, I find it's inadequate to describe what is really a much more complex, iterative, and multi-dimensional activity.

My suggestion is to break it down into these steps:

First, problem definition. This itself breaks down into iterative steps:

1. What is the overall problem you are seeking to solve? Can you summarize it in one sentence? One diagram?
2. Who are you solving that problem for? Who are the direct stakeholders in your solution? Indirect stakeholders? (That's your audience right there.)
3. What are the constituent problems that need to be solved? Can each of those be summarized in one sentence? One diagram?
4. Continue building that "problem decomposition map" until every stakeholder feels that the problems THEY need to solve fit someplace into that "map".

Note that I haven't mentioned use cases yet. Use cases can be very useful, but they can also be an unending exercise when the problem area is very broad. For example, what are the use cases for a car? For a TV? For the Internet?

I suggest that use cases for broadly useful tools (such as Internet-scale protocols) are primarily useful as a way to uncover and illustrate the underlying problems that need to be solved. For example, the use case of a person needing to go get groceries from a store is one of a thousand use cases for a car. But that one use case reveals the core problem: how do you transport a person and goods in an easy, reliable, safe manner that's faster and more convenient than walking or riding a horse or a bicycle?

Once you have your problem map (which also tells you your scope — what is INSIDE vs what is OUTSIDE the problem map), then you can start to derive requirements.

1. What are the requirements that can be put around the solution as a whole — the entire problem map? Example: What's the maximum price of the car? How long can it take to build? How many will be needed?
2. What are the more granular requirements that can be put around each subproblem? Example: What kinds of fuel(s) are available for the engine? How much can the engine weigh? Must the engine exhaust be treated?

Once you have your requirements, it should be relatively easy to specify the deliverables needed to specify, deliver, and consume the solution.

[andorsk]

@talltree love it. Makes sense. I can work to provide some better support for this flow over the following week.

[andorsk]

This is the render of this flow:

graph TD
    subgraph Initiation Phase
      subgraph PM[Problem Map]
        ProblemDefinition[Define the Problem]
        DefineAudience[Define the Audience]
        ProblemExploration[Problem Exploration]
      end
      subgraph RC[Requirements Collection]
        RequiementsAroundSolutionAsAWhole[Requirements Around Entire Problem Map]
        SubproblemDefinition[Requirements around each subproblem]
        RequiementsAroundSolutionAsAWhole --> SubproblemDefinition 
      end
    end
    ProposalStage
    PM --> RC
    ProblemExploration <---> ProblemDefinition <---> DefineAudience <---> ProblemExploration
    RC --> ProposalStage

Loading

Problem Map Stage:

• What is the overall problem you are seeking to solve? Can you summarize it in one sentence? One diagram?
• Who are you solving that problem for? Who are the direct stakeholders in your solution? Indirect stakeholders? (That's your audience right there.)
• What are the constituent problems that need to be solved? Can each of those be summarized in one sentence? One diagram?
• Continue building that "problem decomposition map" until every stakeholder feels that the problems THEY need to solve fit someplace into that "map".

Requirements Collection Stage:

• Requirements Around Entire Problem Map
• Subproblem Exploration

[talltree]

One more note about the next stage in the process: proposals. I think we might be skipping a stage: design principles.

Before you get to concrete proposals, if the WG/TF members first review the requirements they have identified and then discuss and agree on the design principles that any proposal needs to follow, it can save a ton of time in the generation and evaluation of proposals.

Again, in the Trust Spanning Protocol Task Force, we're able to go super fast because we already had on overall problem space defined (the mission of the ToIP Foundation) and we already did an overall set of design principles for the ToIP stack. That was all in place before we even started on the ToIP Technology Architecture Specification—and that spec already gives us all our requirements for the trust spanning protocol. So that's why, after a brief initiative phase (our first two meetings), the TSPTF is ready to jump straight into proposals.

Many of the overall ToIP design principles also apply here in this TF. However because this TF is tackling a particular trust task protocol within the ToIP stack, it seems to me that it needs to progress through all three stages I've outlined...

1. Problem definition.
2. Requirements definition.
3. Solution design principles.

...before it is ready for proposals.

The good news is that, if we follow this progression, by the time proposals start rolling in, things should move quickly because all the groundwork has been laid.

One final note: these stages are always iterative to some extent. Actually designing and specifying a solution always better elucidates the problems, the requirements, and the design principles. But at least it should feel like an orderly progression/refinement.

[andorsk]

@talltree so something like this fair?

graph TD
    Initiation --> PS

    subgraph Working Item
      PS[Proposal Stage]
      CP[Consolidation Phase]
      DraftPhase[Draft Phase]
      PublicRelease[Public Release]
      PS -->|muliple proposals generated similar to aries-rfcs| CP
      CP -->|consolidate separate proposals into a unified proposal| DraftPhase
      DraftPhase -->|some repo deliverable for an actual proposal| PublicRelease
      PublicRelease --> CommunityFeedback[Community Feedback]
      CommunityFeedback  -->|feedback loop| PublicRelease
    end

Loading

Initiation Phase

graph TD
    subgraph Initiation Phase
      subgraph PM[Problem Map]
        ProblemDefinition[Define the Problem]
        DefineAudience[Define the Audience]
        ProblemExploration[Problem Exploration]
      end
      subgraph RC[Requirements Collection]
        RequiementsAroundSolutionAsAWhole[Requirements Around Entire Problem Map]
        SubproblemDefinition[Requirements around each subproblem]
        RequiementsAroundSolutionAsAWhole --> SubproblemDefinition 
      end
      SubproblemDefinition --> SolutionPrinciples[Solution design principles]
    end
    ProposalStage
    PM --> RC
    ProblemExploration <---> ProblemDefinition <---> DefineAudience <---> ProblemExploration
    RC 
    SolutionPrinciples --> ProposalStage

Loading

[talltree]

@andorsk Yes, you nailed it. Nice diagrams.

Now, per the discussion this morning, we also need to figure out where terminology (and mental model) development fits. I think it is a parallel process that begins with the problem development stage and continues through the drafting phase, but that needs a little more thought.

[talltree]

In case it is helpful, in the Trust Spanning Protocol TF, we tackled the same question and produced this table of WG/TF work stages (published on the ToIP wiki to make it easily shareable).

[guru-barbes]

Helpful indeed!