FM Program/JSSv3: Agree on scope, timeframes and what we can realistically deliver as quickly as possible

[mochet]

I have already self-decided on quite an amount of this via the following 2 issues, but it is obviously important and worthwhile to discuss before going forward:

• https://github.com/Joystream/marketing/issues/245
• https://github.com/Joystream/marketing/issues/246

Regardless a discussion and final agreement on scope, deliverables and the immediate future are required to consider and ideally agree to disagree on at least several things (IMHO, but open for discussion before moving forward). I desire a specific approach to developing this project which isn't typical, but I think is the only way to deliver what is required

Scope / Approach

1. IMHO a typical coding approach is going to be too slow and restrictive with respect to the time we have available.

• Code reviews, approvals etc that work for typical projects can end up taking extensive time waiting for testing, consideration of consequences ends up eating not only time but also creativity.
• Very often it seems that obvious, easily achievable changes or additions can take hours, days or weeks to go through traditional processes.

2. Overplanning goes nowhere

• Extensive planning/perfectionism before we have delivered a very basic tool doesn't often seem to end up going anywhere productive based on previous efforts.
• Because of this I have constructed each phase of this project to only employ the most limited planning steps possible.
  • Code review, methodical planning etc all have a valuable role in other areas of the project, but for JSSv3 which started out as a huge list of potentials and never delivered anything (JSS v2 - WIP #518) I will instead be ignoring this.

3. Embracing and agreeing upon an easy tool is critical (for the time being)
   • For the purpose of this initial concept, we simply don't have time to build something for delivery in 3-6 months time.
   • By settling on a basic, easy tool early on we can very feasibly deliver quite a lot, quite quickly--far more quicker than IMHO any other approach would be able to achieve.
   • Changing tools or building custom solutions is always an option later on after the initial time requirement for what we need now has passed.
4. Cut away complexity -- take a read only approach

• By purely focusing on a read only approach--this avoids a huge amount of complexity, technical requirements and skill barriers.
• This allows us the chance to play around with generated data freely and without restriction.

4. For the time being, accept the reality of limitations that exist and think about post-mainnet once we actually get there.

• After mainnet it is possible that a complete custom solution could get the funding and attention required, but no blueprint for this to be made exists.
• If we launched on mainnet and didn't have this on at least decent footing then it might take months for our DAOs features to get attention or full usage--the aim is to deliver something that is workable in advance of this.

Proof of my approach working already exists

• The things I'm about to outline such as the read only approach and focusing on very simple tooling and not utilizing any form of approvals/reviews has a proven track record already and delivered the council leaderboard
• Although manually processed and tedious, nothing else delivered what a simple Google Sheet could:
  • This managed to have 330 fields of data for each council term almost entirely utilizing just on-chain data (before the bounty module, NFTs, social tokens and other features were even added)
  • It had more than 40 visual charts--this provided insight towards the crazy amounts being staked for elections.
  • The charts in particular very easy to screenshot and paste into the Discord chat to give our community a sense of the level of activity on the platform.
  • It could explain details such as having 87 unique elected Council Members and nothing else could
  • Nothing on it went through any form of approval or review, although I did try to incorporate some requests.
• Our DAOs unique features almost always generate lively areas of activity or interest that randomly occur based upon community participation, previous experience of this and having previously been able to rapidly generate insight and/or visuals based on the following have proven to be significantly valuable and interesting to our community in the past:
  • User-generated content (UGC) per hour
  • Proposals created
  • Election spending/stake
  • Platform roles (# of workers)
  • WG spending
  • Membership growth
  • Forum activity
    It did all of this before the Query Node even existed--which makes accessing data far easier. Despite us now having the QN, we still have nothing that even comes remotely close to what a simple spreadsheet delivered long ago... being able to rapidly, easily isolate and extract extreme value in simple visual form that could be easily shared or showcased to any potentially interested user of Joystream.

Value proposition

• AFAIK there is no other current approach IMHO that is aiming to be able to deliver what we seem very capable of delivering prior to mainnet launch.
• Providing essential, valuable overviews of key economic activity in various ways is critical.
  • No exchange or external platform/party is going to spend hundreds of hours figuring out our runtime or Query Node.
  • No exchange or external platform/party is going to look beyond the mainnet token value unless we build and demonstrate the layers that create this value.
  • No one is going to highlight the budget levels of our multiple WGs or election stake amounts unless we have a tool that surfaces this data easily.
• People are drawn to engage and meaningfully participate when they see high levels of activity.
  • We have to show activity to increase it.
• Very few, if any DAOs generate the amount of data that ours does
  • If we can't show the data then it doesn't really exist, except to those that know every aspect of the runtime
• Without a working way that actively delivers and adjust to quickly accomodate changes in what is currently of potential interest or worth highlighting we are throwing away a lot of potential value when it comes to highlighting our DAOs distinct and novel features. No one else is going to put effort into highlighting this information.
• People like seeing things and they like seeing them quickly
  • Being able to very rapidly produce a variety views for our community has extensive value
  • This value proposition also applies to any potential future user/investor/video creator
• Knowledge isn't evenly distributed
  • The number of people who have extensive knowledge of our DAO and its features is very limited.
  • The number of people who have extensive, prolonged and proactive experience in actual governance on our DAO is very limited.
    • Those who can appreciate what views are of value and useful to highlight are restricted to the above two groups of people. This isn't good.
• All views and insights of data that we surface and explore--the UI/UX and other aspects of what we do can be documented and referenced for potential future design iterations of numerous other Joystream products.
• Better understanding how the DAO's features are actually utilized
• Building extensive documentation, heavy utilization and examples of Query Node use for the community.
  • If we do this then we can ideally remove time and resource barriers from external entities integrating with Joystream by providing them proven, easily accessible examples of what data our DAO generates--providing side by side examples of queries with views of the data they can generate opens up a world of possibilities

Obvious & Easiest improvements / focus areas

There are several areas that can easily be positively impacted by what seem like very trivial improvements and seem like they would not take much time at all to action:

• Improve grading/scripting accessibility + automation
  • Start to move the grading process from JSG onto the community
  • Make the scripts, queries and other data very easily accessible
  • Remove the requirement for participants to understand how to construct complex and elaborate GraphQL/QN queries
  • Although we cannot determine exactly how mainnet governance will actually be, all of these should act to vastly help in education and usability of our DAO
  • By lowering the barrier for what are almost essential tools we can dramatically lower the current extremely high skill entry barrier
  • Specifically for areas of our platform that are dependent upon users that are likely less technically proficient users we can hopefully attract a far wider range of prospective users with more interesting voices.
    • To put it more directly: We can find an expert at constructing QN queries and understanding every aspect of on-chain data and we can find an expert in marketing of incentivizing video creators--but we are very unlikely to find both in one person.
• Improve visibility, understanding of the FM program + potential incentives
  • Returns the competitive spirit of participants that has gone away due to information being highly difficult to access.
  • Visuals and easy to use tools for this can easily fix a problem that very much exists and has no current solution
  • Dramatically reduces friction and lost man hours spent trying to understand this system to newcomers
  • Easily increases marketability of the project and value propositions for all types of users
• Highlight and showcasing our communities on-chain activity and our DAOs novel features
  • Very few blockchain projects are able to illustrate their levels of community participation beyond using Twitter/Discord metrics--we have lots of data that is very easy to easily present
  • People are drawn to high levels of activity and communities which thrive. We have to show this to users and not rely upon those who might randomly stumble across our project.
  • Makes it very easy for newcomers and anyone interested to understand our DAOs inner workings and can help to remove the current requirements of reading through extensive documentation

Time Scale

• For this to succeed we need to respect the very limited time scale we have available
  • Mainnet is now scheduled for August 2022 leaving 2 months to play with
  • After mainnet is something that can be considered later on--for the time being we can ignore it and purely focus on delivering something before then.
• Although there is an entire world of possible options and custom tooling available they do not seem likely (IMHO) to be able to deliver results in the compact period of time we have available.
  • The more complex the tooling is that we employ, the harder it is to involve the community.
• We have a very limited timeframe to act upon and fully utilize the data available to generate the most value possible.

Tooling simplicity

• I am specifically quite heavily trying to make sure that we use readily available, almost out of the box and accessible tools that are very easy to develop on.
• This is partly so that I can very easily participate in pushing JSSv3 in the initial directions I am very confident that it needs to go
• This is also so that we can involve as many community members as possible in actively playing around with the huge amount of data that our DAO generates--they might be involved in just playing with views that are already available, suggesting potential new views or even creating their own.