2025/10 - 2025 Q3 Review

Video Discussions
1

@vclay reviews progress on the Q3 objectives and reviews the priorities for Q4.

This video also includes Shout-Outs to the Community

00:00 Introduction
00:20 Shout-Outs to the Community
07:22 Q3 Review
08:03 Enabling Monty to Model Compositional Objects Accurately and Efficiently
10:57 Make Monty Easy to Use, Improve and Contribute to
12:30 Increase External Interest and Awareness
13:34 Figure out how to Model Object Behaviors
14:38 Q4 Priorities
16:13 Improve Monty’s Ability to Model Compositional Objects
17:43 Make Monty Easier to Use, Improve and Contribute To
18:25 Increasing External Contributions to the Project
19:47 Theoretical Progress on how to Utilize Behavior Models

3 Likes
2

I must say, it’s impressive how much you guys manage to juggle with at the same time. You certainly deserve extra help.

On that topic, 3 suggestions to lower the barrier for external contributions:

  1. Create GitHub issues for each action item on the Monty roadmap and provide a short description of your expectations. A good description always has higher chances of attracting a contributor. It would also provide a dedicated per-task space for deeper discussion.

    A lot of open-source projects have “good first issue” labels for simpler tasks, providing easy entry doors for newcomers. Since TBP is also heavily scientific, it would be useful to have tags for tasks that are purely software to distinguish them from the more scientific ones, allowing software folk to see what they can directly contribute to without a neuroscience background. The EnvironmentDataLoader task done by Anna is a prime example.

  2. You could leverage GitHub’s built-in Projects feature, which ties in seamlessly with repo issues. This would allow the community to see the big picture directly on GitHub while simultaneously allowing to peek into each issue for more details. Here are some examples:

  3. Sphinx docs are always good to have! It seems Tristan tried, but it got set aside due to errors? It’s probably related to Conda, so I suppose it might have to wait until Habitat is separated out and the project is pip-compatible.
    Edit: Oops, it was there all along: https://api-monty.thousandbrains.org/

Keep up the good work :wink:

2 Likes
3

Thanks for the kind words! Those are great points!

We currently collect future work items in the future work section of our documentation. There we also have short descriptions for the items (like this for example: Detect Local and Global Flow) The descriptions are not all complete yet and some items are a bit outdated. One of our goals for this month is to update all these items and to add new items (such as the items from platform planning and for modeling object behaviors).

It’s a good point that there is no way to ask questions and interact on the items. Maybe we will eventually move it to GitHub issues and use their project planning features. For now, the idea is that if someone is interested in one of the items, they can post on Discourse to discuss it more concretely (like Anna did here) and/or write an RFC and get feedback that way.

Another thing that we plan to go live this month is an interactive, filterable version of the future work section, so it is easy to find tasks that match someone’s interests, background, and available time. The approach is outlined in this RFC if you are curious: tbp.monty/rfcs/0015_future_work.md at main · thousandbrainsproject/tbp.monty · GitHub

I hope the interactive roadmap together with a comprehensive update to the future work items and descriptions will make it easier for people of all backgrounds to find ideas of how to contribute :slight_smile: Definitely let us know if you have any additional suggestions!

  • Viviane
2 Likes
4

At the moment, a new user has a lot of different things to go over to get a full picture of what’s going on: codebase, docs, forums, spreadsheet, repo issues, PRs, and to a larger extent, videos, papers, and forks. So, trying to narrow it down a bit would be beneficial. I guess the forum-centric approach is fine for now, but as the community grows, it might become harder to juggle that in the long run.

For perspective, I founded and led an open-source project in my spare time for several years, and over its lifespan, my forums accumulated over 23,000 posts from hundreds of users, with most discussions relating to development and customization. The main lesson I took from it is that I should have better leveraged GitHub issues to make it all more accessible and manageable.

It’s fine to keep more abstract future work descriptions in the docs, but action items should probably be filed as repo issues, i.e. treating each one like an RFC. That way, the community can directly see who’s actively working on what, and team members could document their progress in the issues before a PR is opened. Action item issues, RFC issues, and any PRs can easily be associated to one another, so the community can browse the whole chain directly on GitHub.

Looking at Will’s RFC, relying on in-repo JSONs to manually store all that info might make it a bit brittle and less nimble. Again, this would be a good use-case for GitHub Projects. There’s a table view that’s very similar to the proposed widget, the REST API produces JSON that can be parsed for use by Tabular and GitHub Actions, and new columns are easy to add:

image
image739×666 28.2 KB

I guess one drawback is that the community couldn’t directly edit team-made entries like they would with JSON PRs, but then again, simply having such change requests go thru an issue or forum thread would be relatively simple.

These are all suggestions, of course. Just trying to think long-term :slightly_smiling_face:

2 Likes
5

Hi @AgentRev,

These are all great points. The future-work section we discuss in the video will only cover larger areas of work, and these chunks aren’t all related to the codebase. We wanted to store them and have a process for adding to them that’s accessible to the broader community, while still ensuring they go through maintainer scrutiny via the PR process.

I agree that storing fine-grained work items in the docs won’t scale as the community grows.

Also worth noting, when an RFC is approved and merged into the repo, it gets an issue for tracking: Request For Comments (RFC)

If you’re familiar with Producing Open Source Software by Karl Fogel, that’s what we’re using as a basis for our open-source project. We’re definitely interested in hearing thoughts on how we could improve, especially given your experience managing open source projects. Making it easier for the community to find what they need and contribute is a top priority for us, so please feel free to share any ideas.

1 Like