RFC 0014 research while building a stable platform

[Stephen]

RFC 0014

I read through RFC 0014 and have some questions/suggestions that I would like some feedback on before considering a pull request.

I think it might be helpful to consider the various Users and their intent with regard to the system.

This is just a quick (half-baked) pass. I’ve only just really started digging into the materials so if I’m covering ground already discussed let me know.

• Open Source Contributor: primary goal is to improve and maintain the platform

  • Implementor: fixes bugs, improves code, implements specified features
  • Platform Researcher: new feature design, POCs to test/validate TBP theories, support TBP research team - focused on how to implement

• TBP researcher: Primary goal is to test test theory and expand system characteristics in line with theory, may be user of the platform and/or contributor to the platform.

• External Platform Researcher: Uses the platform for experimentation and evaluation of new/modified components (e.g., sensors) that they have implemented - Main interaction is via “feature request” not pull request.

• Non-contributing External Researcher: Uses the platform for their own purposes such as simulations or practical implementations. May Submit bugs and feature requests.

• Third Party Providers: (RedHat model)

• Consumers: Primary goal is in solving one or more specific problems. The nature of the problems that can be solved will vary based on the characteristics of the platform.

  • Solution Architects/Implementers
  • Service Owners
  • End Users

In this order of users:
Concerns go from:

1. customization to configuration
2. Uncertainly to certainty
3. Inefficiency to efficiency
4. Low scale to high scale
   …

In the long run I see two primary facets: A research platform and a service platform.
To me, in order to meet the constraints of these two facets, this will likely require distinct implementations. Specifically where the research platform primarily feeds change into the service platform. But not discounting that what is learned at scale will likely feedback into the theory and the research platform.

[hlee]

Hi @Stephen! First off, welcome to the community!

I think @nleadholm would be able to answer your post; I just wanted to also let you know that there is a complementary RFC (links to an open PR as it is WIP) to RFC 0014 in case you were interested.

[tslominski]

Hi @Stephen, here’s a link to the pull request that also has our discussion on the RFC @hlee mentioned: rfc: RFC Guidance on Workflow for Research Code by nielsleadholm · Pull Request #430 · thousandbrainsproject/tbp.monty · GitHub.

[tslominski]

Hi @Stephen, and thank you for your comments.

I also think that the research and the service platform will diverge in the long term. Here’s a Wardley Map highlighting the split I think will happen in the future (red).

So far, we’re imagining that the research platform will be something like tbp.research, built on top of tbp.monty and facilitating all the research use cases, experiments in particular.

Our current intent is for tbp.monty to evolve into the service platform.

I think RFC 14 Conducting Research While Building a Stable Platform intends to be a guide on how everyone should cooperate on our research and engineering goals while still being tied to a single tbp.monty repository. At some point, when we separate tbp.research, RFC 14 might become less relevant.

We have some challenges to overcome before separating the research and service platforms. One of the current undesirable effects we are tracking for the Platform is (152 Experimental framing is hardcoded into the Platform.) The picture below gives an overview of all the existing coupling we’ll want to remove to enable the separation.

I also anticipate we’ll want another split not yet mentioned: between the service platform and the environment. Right now, tbp.monty is tightly coupled with the HabitatSim simulator. However, you might not need a simulator if you’re running tbp.monty on a robot. You might not need a simulator if you’re running tbp.monty with a virtual environment (e.g., the Internet). So, there is a distinction between Monty and the environment, which I think we’ll reify in the future. We’re tracking both splits in (106 Monty system, Experiment, and Environment are all coupled together.) undesirable effect.

To uncouple all three will require additional interventions beyond separating the research and service platforms.

I hope to share all these undesirable effects and our thoughts on how to unravel them soon. They’re not secret, and I want them to be available to everyone; it just takes some work to put the artifacts together .

---

To check my understanding of what you mean by “feature request” from an External Platform Researcher… Do you mean something like them opening a Feature Request issue on GitHub?

[Stephen]

@tslominski

To check my understanding of what you mean by “feature request” from an External Platform Researcher… Do you mean something like them opening a Feature Request issue on GitHub?

Yes, exactly. Or through a more formal process via implementation partner like in the RedHat model.

[Stephen]

Thank you @tslominski for the informative response. This has helped provide context and scope for RFC 14.

I have interest in both short term and long term architectural discussions, along with an interest in the background theory and the interplay between theory, research, and implementation. In a previous career iteration I researched visual attention (magnocellular attentional capture) and object vs space based attention where “object” was implied from points representing vertices of a dynamically moving/transforming triangle.