Feedback on workflows to use as a researcher

General
1

Hi all, we’ve put together some guidance for internal TBP researchers on the best workflows to use when implementing new ideas (“Prototypes”) in code. In particular, we’re trying to find a balance between moving quickly and trying new ideas, vs. ensuring that the tbp.monty code base remains stable. More concretely, this influences how we do things like create git branches and forks, and request PRs to review code.

During this process, we’ve also drafted some suggested guidance for anyone in the community doing research. The question we would like to ask is - is this guidance helpful? Do you feel like it gives some useful structure for how to organize an ambitious research prototype? Or does it just feel like unnecessary overhead?

Please feel free to take a look at the current RFC draft here (links to the relevant section). If you are currently working on research ideas in the TBP domain, or are interested in doing so, it would be great to hear from you.

2 Likes
2

If you want to join the RFC discussion on GitHub, you can leave comments on the PR found here: https://github.com/thousandbrainsproject/tbp.monty/pull/430

3

I think this is great, since typical open source projects don’t usually provide that kinda pathway for incremental work. It favorably lowers the bar to entry for potential contributors.

I agree with Ramy about fork limitations imposed by personal accounts, making the “feature fork” paradigm less relevant to the community. Maybe the feature branches section should be before feature forks? i.e. highlighting the most community-friendly approach first, or maybe have it on its own dedicated page

4 Likes
4

Ok great, thanks for taking a look @AgentRev . And good idea, I’ve added a note so that when we integrate this guidance into our documentation pages, we ensure that the best approach for community members (feature branches) is prominent on the relevant page.