How can we mark a Request as passed by QA ?

[inverted-capital]

Currently I do not accept that any of our Request are of sufficient quality to be put into a web liquidity pool that I would promote.

We are continually improving their quality - how do we mark when they are ready ?

Perhaps everything we currently have should be moved to the Drafts folder, and once we both agree one is ready, we move it back to the main folder ?

[inverted-capital]

Can we make 05 Markdown NFT Mode be the first thing we pass, somehow ?

[TemperBead]

Have been thinking about this today and I'd propose Requests are not subject to QA at all.

Here's my thinking - if I had a request which was just "I want a pony", I should be able to put that up. Everyone might think I'm a bit nuts, ignore me, etc, Or perhaps ask - what kind of pony? I know about ponies. The point being that Requests should be just well formatted Dreams, and other than QAing the format, the grist of it can't really be QAd

They also don't need to be as they don't form the meat of any contract, but I think thats a more controversial thing to say so we might need to talk that through. But in essence, the Idea is the thing being contracted and so needs QAd, the Request is just out there and is either well written and gets read, or poorly written and gets ignored.

[inverted-capital]

We had agreement that Dreams were the pairing of a Request and an Idea.

What I really want is QA to pass a Request to be suitable for a Pool. QA on the format can be done in the app, but access to the pool requires some intelligence.

The Request absolutely must be QA'd if it is to have money pooled against it. You can pool against a Request when nobody has a clue how to solve it, then eventually an Idea crops up, somehow it gets executed, and then the Request is deemed fulfilled by QA, releasing the funds against it. That definitely needs QA'ing, unless you run no pool or you have a low quality pool, in which case you're probably running a securities scam maybe without knowing it.

A contract for an Idea must be tied to a Request in our pools, as the Idea needs freedom to move ?

If you want to run your own pools, then yes no need for QA, but for web liquidity pooling, I think this issue is valid ?

[TemperBead]

See your point, and think we're conflating two things here - a Dream as we original imagined it, which can be unformed and at it's simplest just a wild thought, and a Request that's submitted to a Pool, and therefore which as a half decent chance to attracting ideas. Also think we might have misfired on the Dream = Request + Idea.

Here's my thinking.

Originally we saw the Dreamcatcher at its simplest as a place to put up random, potentially poorly formed thoughts about what could be useful, and have the world pick up and riff on them, then pick them up to execute into a thing.

However, now we have Requests/Ideas, we have something more structured. Your point on a Request to a pool needing to be up to scratch is right, but don't want to lose that original thought around Dreams because there's something valuable there about just picking up an app, saying what your Dream is, and having it honed, improved, made more precise then built potentially without you doing anything else.

So here's my proposal.

Requests can be anything from a single line of text to a fully formed and thought through proposal.

However, to have that request considered by a pool, there needs to be structure and QA. Otherwise the pool itself won't be able to make good decisions.

So a Pool can (and should) put in place QA on a Request which needs to be passed before it'll even be considered. We shouldn't as DC dictate what the format for that Request should be - it should be down to the Pool to state what their gate-keeping requirements are for submission. Therefore a Pool would be well advised to stipulate QA requirements, and the QA Authority, if they're not going to get into an unholy mess.

We've created the Request template that we need, based on 'pure' problems. We (in terms of our pool) won't accept a Request unless it passes our QA (currently the two of us deciding that it's complete, correct, and addresses a pure problem.). That's the gatekeeper to our pool.

We can also publish our QA approach for Requests for others to use. But they're not constrained to use that. They could ignore it, and let chaos reign, they could come up with a better approach. But that pool is incentivised to state what the QA gate is to be considered.

However, a Request that is just thrown in the air to see what happens, and not yet submitted to a pool, should also be allowed. That would allow someone to ask for a pony, and just leave it out there, but if they want to ask a Pool for a pony, then the Request needs to pass QA.

So to summarise:

• Request -> Idea -> Project (where the Request is simply picked up without permission by an idea and project, and receives attribution)
• Request -> Idea -> Contract -> Project ( where the Requestor selects an Idea and Contracts for it, but doesn't call on a pool)
• Request to Pool -> Request QA'd for Pool -> Idea -> Idea QA'd for Pool -> Contract between Request, Idea and Pool -> Project

Make sense?

[inverted-capital]

I agree with you. I have added Pool to the dictionary, as QA only relates to Pools. We will supply our edition of Pools, and they can be reconfigured to suit other needs.

QA should be an algo - can be a template, some coded logic, and a group of people or other QAs. It's role is to process Requests, Ideas, and Funds into pass or fail groups.

The vagueness of Requests and Ideas should not detract from the Dream = Request + Idea concept. I say that a super vague Request or Idea is probably a Dream. The author of course is free to define their yawp as whichever of these things they like, but conceptually, a vague Dream is part Request, and part Idea, so I think the Request + Idea concept holds ?

The boundary between Project and Pool is becoming less well defined I think...

[inverted-capital]

What we are missing in our manual version right now is the Pool. I will attempt to make that now.

[inverted-capital]

So now the pool is made, can I close this issue based on the process outlined here where basically the NFAs section of the site acts as a proposal area, and the Pool area only contains items that have passed QA ?

[inverted-capital]

Pretty sure you agreed to close this on our discussion - please reopen if I am mistaken

[inverted-capital]

It was actually opened by me, so I think the opener should have the right to close their own issue :shrug: