A reply to @Ned's It's Time for a Steem Bounty System!

I’m a back-end developer with user experience and process flow skills but absolutely no artistic sense. My passion (and the primary reason why I am on Steemit) is to crowd-source an artificial intelligence. Since a major part of that is requests and credit assignment (rewards) for good ideas, good code and good critiques, you could say that I’ve been working on a super-set of a bounty system for years.

Presentation

The thing is – and I think that pkattera's *excellent* Competitor Analysis for @ned's proposed Bounty Management System, the wide variety of bounties/contests already posted on Steemit AND all of the bounty hunters' unanswered questions about the exact details and flow make it quite clear (to me at least) that

we don’t need a monolithic bounty system

but a whole ecosystem of different, inter-related but easily created and integrated bounty services.

What we truly need is an Open Pluggable Architecture for the creation of various bounty services to best fulfill a wide variety of purposes. Much of the reason why no one has made a full-blown final proposal is because there are far too many valid use cases.

So . . . . the backbone of the architecture is obviously the Steem block-chain. *ALL* of the formal procedural actions must be required to be taken ON the STEEM block-chain so that everyone can see and verify them. Indeed, all actions must be required to be taken using a standards-based machine-readable format so that tools can be developed, statistics collected and automated verification performed (either by standardized templates or, better yet, via the custom_json operation and all the json_metadata fields). This would allow bounty browsers/trackers to be created that could cross all of the various bounty creation/operation systems and services.

The simplest bounty creation/operation system could be Steemit itself. With standard posting post and awards comment templates, a (very, *VERY* careful) user could create and run a trackable/reportable bounty solely using Steemit that would be picked up by any bounty browser/tracker. [Personally, however, I would vote AGAINST creating such a standard as it would raise the bar for those wishing to create browser/trackers by requiring TWO data collection methods (body-based and metadata-based rather than just the latter]

If someone wanted to create an “award-guarantee” system for such users, they could set up a system where they could receive escrow payments, put a validation comment on that user’s post and then reward the winner(s) when appropriate. Someone else could set up a “guaranteed-fair” judging or reward-analysis service which the user could use in conjunction with the “award-guarantee”. As long as the latter two systems are trusted, *any* user’s bounty that uses them could be trusted (except for any up-vote promises).

A slightly more competent bounty entry system would be one where the user fills out a form and it creates the post for the user (still under the user’s name) with all of the necessary machine-readable information guaranteed to be correctly placed in the json_metadata field. In this case, the bounty entry system would also provide either an easy interface to the guarantee services or the actual services themselves. An upgrade to this would be a service where the provider would post the bounty under their name and add the cash equivalent of all STEEM earned for up-votes to the reward pool (except for a minor fee, obviously).

In particular, I expect the number of judging and reward-analysis systems to rapidly explode. In current systems, these run the gamut from a simple “poster picks a single winner” to extreme cases where an entire human management team is actually provided. For example, I’m currently working on a service which allows for numerous types of voting and rubric scoring on Steemit *without* using the current voting infrastructure because of all the follow-up-vote bots (including Steemian).

This brings me to how we should proceed from here. Obviously, Ned (and others who volunteered funds) should award me mega-SBD for my brilliant and insightful ideas. Next, we should all quickly collaborate to produce a standard schema for bounty data (basically field names and field descriptions to include field types and lists of allowed values) and standard interfaces for each of the various bounty systems (and related systems like an “I-could-create” system). Then, Ned (and others who volunteered funds) can use those standards to quickly create new bounties to replace the current (I would argue obsolete) milestones.

NOTE: I, personally, would really appreciate it if, in the future, UI flow could be separated from UI design. I would argue that it will lead to faster and better results as well since the requester then gets to choose who is used rather than forcing the developer to make the choice.