How does the nesting of Requests and Ideas work in practice?

[TemperBead]

We've got Requests, and could put in nested Requests easily enough. But practically, is that just asking the reader to expand the top level to get all the detail should they wish it. I.e should we stipulate that a nested Request have value in its own right, as without that it's just expanding a doc by adding a new step.

On Ideas, Requests should be available to nest inside ideas, as you may have part of the solution, but not all. And if someone solves this part, you can pick that up and run with it, and solve the bigger request.

And worth stating for completeness - Ideas should also be capable of being nested, on the same principle.

That is, the principle: Requests can embed nested Requests, Ideas can embed nested Ideas, Ideas can embed nested Requests, but at each nesting level it should be possible to pick it up and build that thing without reference to the thing in which it's embedded. Otherwise it's just an expansion because of doc size, which doesn't really provide much value.

[inverted-capital]

Excellent issue.

I think the model should be that a Request is the same as a completed Asset, but it just hasn't been made, or even started. An Idea is the same as a completed Asset, but it hasn't been finished yet. Requests and Ideas are both a form of Forward Asset. The nesting problem is simpler if we do not consider Requests and Ideas separately, but consider only what they would represent once they are completed - an Asset.

To achieve maximum open mindedness, we should only be able to nest Assets - both Forward and Real. The nesting should be actually of a Request, which allows greater potential for interchange, rather than locking the dependency to a particular Idea. Whenever an Asset is published, the dependency tree is snapshotted to give the Asset integrity, but in its Project, the dependencies are defined by their Requests.

Nesting should only ever go down - a Request, or an Idea, should never be able to say anything about things that depend upon it - their business is solely what they depend upon.

Based on that model, we can define a dependencies section in both Requests and Ideas. I think in markdown mode, we should make this list be strictly a list of Requests. How's that sound ?

[TemperBead]

Propose linking this to the Request/Idea doc. It's not blue sky dust for sure, and that seems to be the best place to put it.

[inverted-capital]

How about each Request has a # Dependencies section that lists out the Requests that it depends upon ?

Additionally, I think #32 could be closed by adding in a # Targets section at the top of each Request that list all the Requests that this Request aims to target, and the same for each Idea where it lists the Requests that it targets as well - what say you ?

[TemperBead]

There was something bugging me about where we were going with this so spent a few pomos trying to get it straight.

This is linked to I11 - Request-Idea.

What I was trying to do here is to put create a Request/Idea structure that leads to something that could be submitted to a Pool. Specifically, I11 Proposed Output 1 - "A process diagram and guidance doc that shows how Requests and Ideas interact, with the aim of being either submitted to the DC Pool for QA." It also informs R01 - Dreamcatcher through I11.

Also noting that the aim is to use the experience of getting R10 - Request-Idea and I11 into shape to meet the requirements of that Request/Idea pair.

So we've previously agreed that Requests are pure - that continues to work. In the diagram I've called these 'Wants'.

However, in putting through this mickey-mouse example it became clear that Ideas should consist of zero or more instances of three types of things:

1. Can Do: Something that hasn't been built, but could be built, and if built would meet a Request 'Want' or Idea 'Need'. The implication here seems to be that the person authoring the Idea is in a place to actually do it, but strictly speaking it doesn't need to be, the proposal is that if you pay someone, it will happen. It's a Work Package essentially. So a plan would need to link 'Can Dos' to devs/workers.
2. Have: Something that already exists that can be used without any dev risk, but perhaps with ops risk. This is the Prior Art piece. It then makes sense that a plan needs to link 'Haves' with 'Sources.'
3. Need: An Idea might not 'have' everything it needs or may not 'can do' everything, so it can put out a Need. This could be pure e.g. if they've no idea how to meet that need (and therefore amount to a reference for a Request), or it could be non-pure ('shut up, I just need a hammer, I don't have a hammer. Anyone have a hammer?'), in which case it invites Ideas that 'Have' a hammer.

I've tried to show each of the interactions between these in the usual scrawled diagram.

So proposal one is that we use those three as definitions that will go into the Output 1 mentioned above.

Doing this also threw up an interesting point about what you as a user actually do when you submit something to a Pool. Here are the key points:

1. Because Request:Idea needs to be many to many, then there isn't a coherent idea of what it means to submit a Request:Idea lock. Which Ideas? Which Requests? There needs to be a wrapper - you mentioned this on the last call as an Asset but I'm checking this thinking coming from the bottom up (BTW, agree.) In the diagram I've sketched down what that may look like given that many-to-many relationship. Raises a few interesting features which we've been hoping for:
   1. Even in this mickey-mouse example, it's clear what the high value Ideas (stuff to do) are, based on the number of Requests that they serve. Nice...
   2. There's multiple routes to success for a Request, so when you're asking a Pool for funding, there are multiple levels of funding. E.g. If I were QA, I'd definitely say 'Make Nails', probably would say 'use wood' and may say 'buy eggs', could say 'build a chicken coop'. Either we represent those as different submissions or incorporate them in one.
2. Also, I think there are two levels of QA before being accepted into a pool:
   1. Is it in the right format and semantic level? For DC Pool this would be making sure Requests are pure, Ideas address Requests (possibly with the Can Do, Have, Need structure if you agree.) Possibly also have some qualitative assessment.
   2. Second level of QA is whether it's a good idea by comparison to it's internal options, and by comparison with other submissions. E.g. in the diagram, both the 'Build Chicken Coop' and 'Buy Eggs' routes can pass QA as we've defined it up to this point.
3. The above becomes far less problematic when the Requests and Ideas are left wild - the market will say what the best way is to get those eggs. But Pool = Investors, hence the above.

In the diagram I've proposed a wrapper thing called a Proposal - could just as easily been called an Asset, but I don't want to redraw it for the 12th time. That wrapper includes the original Request, then the cascade of Ideas and Requests that are needed to make it happen. Reason I think this is needed is that there's more than likely always going to be more than one way to meet a Request, which is fine at the dust stage - let chaos reign - but to be considered by a pool I'd argue the one universal would be to actually

My specific ask: does the above make sense to you? Any drift you can see? To my eye this appears to be inevitable when thinking also at the journo.md and mayday.md level, but potentially we can back-burner some of it for now.

[inverted-capital]

I do not agree with the "Can Do, Have, Need" structure. I think you've invented extra items here when we have enough tooling to do this already. I think we can solve this problem by sticking to the model of a Request, and Idea, and a Dream all being actually an Asset, but at different stages of completion.

Each one has:

1. Targets, which are Requests that it aims to satisfy
2. Dependencies, which are Requests that it needs to be able to satisfy.
3. An Asset, which is the valuable piece within it, that it offers to be part of a larger graph of value.

We have Dependencies and so this should be used instead of a new type subheading for Ideas, as you have suggested.

We want to get to a finished asset that has some targets that it aims to satisfy, some thing that it actually does, and some dependencies that it needs to do meet its targets. This should be ample to achieve what you lay out in this issue. Moreover it means that the same format is shared by Requests, Ideas, Dreams, and Assets - which should be our goal as it means the least amount of rules anyone has to learn.

The two levels of QA belongs as a separate issue. If you make one, we can go through it more detail there, but basicaly QAs job is not to reason why - that is the markets job.

I disagree that we need a wrapper as the pool offers no guarantees exclusive attempts to fulfill Requests. QA only approves the targets and the dependencies of any item in isolation. Any resulting graph is equally valid, and the market decides non exclusively which ones get funded and worked on.

It feels like you're trying to control the pool somehow ? The Pool is a big bundle of components that are of sufficient quality that they can be connected together in varying ways, non exclusively, with the market deciding how. The connection metric is directly related to the innovation rate I think. The connections are where the freedom happens.

[inverted-capital]

commit ed488f663 adds Targets and Dependencies, as well as constricts R10 Request-Idea with two complexity constraints.

[TemperBead]

OK, cool.

1. Targets - agree
2. Dependencies - just to clarify, do you mean "in order for this Request or Idea to be completed, we need this other Request to be completed"?
3. Asset - what do you mean by 'within it'? The asset is an output so needs to exist as its own object/file doesn't it?

E.g. here's the tracer bullet we've currently got using the above (noting that A01 doesn't exist yet as the work I11 is proposing hasn't been done yet):

R01 Dreamcatcher Targets: None Dependencies: None

R10 Request-Idea Targets: R01 Dreamcatcher Dependencies: None

I11 Request-Idea Targets: R10 Dependencies: None

A01 Request-Idea Process Doc Targets: I11 Dependencies: None

Is that how you see it? The alternative for the Asset would be to include it in the Idea md file which seems less clean.

On the wrapper, was thinking about it more from the point of view of 'submitting' something to a Pool for funding, but will open up that other issue and discuss there.

[inverted-capital]

FYI the wrapper issue was closed in #35 and we reached loose agreement on Targets, Dependencies, and Assets being sufficient to remove the need for Can Do, Have, Need.