@theoryshaw Do I understand that discussion correctly that we can't set it up since we don't host our own instance? (But they're working on it). I can't find a guide anywhere and can't find any relevant buttons in the app.element.io interface
@theoryshaw I can't find a way to release that handle. I've changed the description to "OSArch Chat - Open Source in Architecture"
So we could make a Space called "Open Source in Architecture" and have "OSArch Chat" & "OSArch organization" as rooms under the space (we should think about names before we jump into creating things. It seems like the handles are fixed. once created.)
@theoryshaw I can't find what date(s) we've agreed for future meetings.
@duncan your suggestion sounds good to me.
In the notes, it says first Saturday 20:00 UTC
I created an .ICS file here for everyone. Please let me know if this works for everyone's timezone. I created it via https://ical.marudot.com/
Unfortunately, I can't make our April 2nd meeting.
Would everyone be open to rescheduling next wed, thurs, or friday at 20:00 UTC?
Sorry for the hassle.
I can't do Wednesday or Thursday. I don't know who he's mentioned it to but Dion wrote to me today that he will be out of the game for a little while, he's now a father (congrats @Moult) . I don't know if that means he's not coming to a meeting, but he's not commented on the forum since the 18th, so I don't expect to see him anytime soon.
So, is today's meeting at 20:00 UTC still on?
I think it is important to have @theoryshaw present.
I am open to reschedule for another day, perhaps for next Saturday?
@brunopostle@Jesusbill do you have no dates at all which are a "maybe"? We're going to have trouble finding a date otherwise. There are already only three good dates.
Answered poll. thanks. @duncan did you end up setting up the steering committee's matrix room? I think we got the quorum on that. :)
Is a good medium for 'pinging' peeps.
@theoryshaw said:
Good initiative. As things evolve I'm interested in trying to off load the historically messy process of governance to 3rd party technical platforms-- in the evolving spaces of DAO's or similar.
It would be nice to reinvigorate the steering committee again.
Used AI to brainstorm on this one. https://chatgpt.com/share/69dbcb5e-5688-8328-a7ee-97e73dbd009a
Perhaps AI can give us the confidence to hack together a 3rd party technical platform, around the tools we already use.
Thoughts? or any other AI brainstorms?
What is a steering committee for? I can think of two things:
Enforcing a code of conduct, 'Be excellent to each other' works fine until it doesn't, as projects grow bigger than a handful of people they eventually need a code of conduct.
Observing the spending of funds, ie. it isn't necessary for the committee to decide spending, but it needs to be there as a guarantee that funds are being spent on the project people are donating to. I can see an imminent issue that people haven't been donating to fund AI credits/tokens, the assumption is that donations are paying developers and hosting costs, but this is now a possible expenditure.
@brunopostle
On formal CoC's. These are divisive, and seem to get weaponized.
They should be unnecessary, but the simple statement: "Be professional, be civil, or you can leave." is all that should really be needed, especially in a project like this where acting like a fool could be damaging to your business and/or professional reputation.
If the community enforces standards we all have a duty to maintain decorum when someone starts misbehaving. Once there's a CoC it becomes someone else's responsibility/problem to start policing it, i.e. it's another task to find a resource prepared to do the work.
Hands up if you have read every CoC for every project you have contributed to, or interacted with? I know I haven't. I can't actually think of one where I've ever felt the need to sit down and read through it.
I think the OSArch Steering Committee works best as a lightweight governance layer that only steps in when shared risk is involved—primarily around money, infrastructure ownership, legal responsibility, or protecting the OSArch identity. The core principle, as I see it, is that most technical direction should remain community-driven, but there are moments where discussion needs to end, and someone needs to be able to actually pull the trigger and move things forward rather than letting things linger indefinitely in consensus.
This becomes especially visible in the funding workflow via Open Collective, where community members propose work (for example Bonsai development, tooling, or infrastructure projects). In that context, the committee isn’t just advisory—it is effectively the execution gate: it approves funding, confirms scope completion, and releases funds when work is “done enough” to proceed. Without that function, funding pipelines tend to drift into ambiguity, where scope becomes elastic and delivery loses accountability. I think this decision-to-action role is what prevents stagnation when coordination alone is no longer sufficient.
The same issue shows up even more clearly in shared infrastructure: the Vanilla Forums for community discussion, MediaWiki for documentation, Matrix for real-time coordination, and the proposed Git hosting platform. I think the uncomfortable reality is that the current steering group—while historically important in getting OSArch off the ground—has become partially inactive in practice. Several members are no longer consistently engaged day-to-day, and as a result there is now a real decision vacuum: important infrastructure and coordination questions surface regularly, but there is not always a clearly active or accountable group able to make final calls. The effect is subtle but real—decisions don’t stop happening, they just become slower, more fragmented, or default to whoever happens to be most present at the time.
I think one response is to acknowledge that governance cannot remain static while participation changes. Perhaps a hybrid selection model (as shared above here) for steering committee membership may help address this. Rather than relying purely on nomination or purely on periodic election cycles that quickly become outdated, I think a mixed system could work better in practice: community reputation signals from the forum (actual contribution history, not just titles) and Git contributions, self-nomination for willingness to serve, and a lightweight ratification step from active contributors or a rotating cohort. The goal is not bureaucracy—it is to prevent governance drift, where legitimacy slowly detaches from actual participation.
This “ability to decide” becomes especially important in coordination spaces like proposed BBIM/OSArch property set standardization (for example OSA_Array or OSA_Aggregate). These initiatives already emerge organically across Bonsai, FreeCAD, and related tooling, but at some point someone has to say “this is now stable enough to adopt,” or “this naming is the baseline going forward,” ideally in alignment with broader ecosystems like buildingSMART International. Without that function, standards risk remaining permanently provisional—always discussed, never fully adopted.
So I think the steering committee should not be understood as symbolic governance or a discussion forum. It only has value if it is actively capable of resolving deadlock, re-anchoring fragmented momentum, and converting community consensus into coordinated action when timing matters. And if that capacity isn’t present, then I think it’s also valid to ask whether the structure is still real—or whether it has already quietly dissolved into something more informal, just without anyone explicitly acknowledging it.
I think it’s also important to acknowledge that there may simply not be enough sustained interest in a steering committee in general, or not enough shared belief that it is necessary or useful in its current form. It may also be the case that there are not enough actively engaged, trusted community members willing to step forward and consistently participate in this kind of responsibility at this point in time. I think that would be a valid outcome rather than a failure, and something we can simply revisit later if and when the community develops more sustained interest, capacity, or need for that kind of structure.
A polite request if the SC is revived: Anything that isn't by necessity private, is discussed in the open. For example either minutes/summary/transcript are published if it is an IRL or VC meeting, or a dedicated forum category that is read-only for the rest of us, and writable by SC members for longer discussions. This way everyone can still see the what/why of the SC, without it being derailed by the rest of us.
(Although I was somewhat unexpectedly given the keys to the kingdom as a github contributor, I would be the first to hold my hands up and say that I do not have the necessary qualifications/knowledge etc. to be on this SC.)
What is a steering committee for? I can think of two things:
in addition to what mentioned above, what comes to mind is a 'roadmap', and the steering committee, as the name implies, to navigate through it.
My personal view is that we need a rough set of steps with priorities to take Bonsai to the level we expect. It can't be accurate but at least it could guide current and future decisions.
I would like Bonsai to become a professional tool in the future, it would be something in 1 year's time or 5 years depending on resources.
But at least a rough idea of what to become is needed, if not into details at least what are the major features to invest on, what others to implement later, and so on.
Thanks
I totally agree with @steverugi . Having a clear roadmap would also help less non-power users like myself. Plus, my feeling is that while Bonsai has become a really powerful and versatile program, it’s still missing some features that would help attract a wider range of users. A roadmap would allow us to take all aspects into consideration. Anyway, great work so far!
Comments
@duncan good idea.
@yorik it appears they are global with memberships and privileges, etc.
https://gist.github.com/t3chguy/fdf541446d992d1fc96b8089b342fe7b
@theoryshaw Do I understand that discussion correctly that we can't set it up since we don't host our own instance? (But they're working on it). I can't find a guide anywhere and can't find any relevant buttons in the app.element.io interface
See the following video, I 'think' it might be because the OSArch tag is dedicated to a room...
https://www.dropbox.com/s/adg7ybn1ubzv4mp/2022-03-15_07-41-21_Element__OSArch_-_Open_Source_in_Architecture_Element.mp4?dl=0
Maybe try changing the room hash tag, and then maybe you can create the space?
@theoryshaw I can't find a way to release that handle. I've changed the description to "OSArch Chat - Open Source in Architecture"
So we could make a Space called "Open Source in Architecture" and have "OSArch Chat" & "OSArch organization" as rooms under the space (we should think about names before we jump into creating things. It seems like the handles are fixed. once created.)
@theoryshaw I can't find what date(s) we've agreed for future meetings.
@duncan your suggestion sounds good to me.
In the notes, it says
first Saturday 20:00 UTCI created an .ICS file here for everyone. Please let me know if this works for everyone's timezone. I created it via https://ical.marudot.com/
Whoops, updated the .ics file here. Was off by an hour.
@CadGiru @Moult @Jesusbill if I can collect your 'awesomes' I will make a Matrix Space as described above
Unfortunately, I can't make our April 2nd meeting.
Would everyone be open to rescheduling next wed, thurs, or friday at 20:00 UTC?
Sorry for the hassle.
I can do Wednesday, but not Thursday or Friday
I can't do Wednesday or Thursday. I don't know who he's mentioned it to but Dion wrote to me today that he will be out of the game for a little while, he's now a father (congrats @Moult) . I don't know if that means he's not coming to a meeting, but he's not commented on the forum since the 18th, so I don't expect to see him anytime soon.
So, is today's meeting at 20:00 UTC still on?
I think it is important to have @theoryshaw present.
I am open to reschedule for another day, perhaps for next Saturday?
Meeting adjourned as @moult and @theoryshaw were unavailable. Here's a framadate poll for choosing a rescheduled time for the April meeting.
@duncan said:
@CadGiru got your approval?
@brunopostle @Jesusbill do you have no dates at all which are a "maybe"? We're going to have trouble finding a date otherwise. There are already only three good dates.
@duncan I went back and marked some (✓), assuming this means 'maybe'
Answered poll. thanks.
@duncan did you end up setting up the steering committee's matrix room? I think we got the quorum on that. :)
Is a good medium for 'pinging' peeps.
invites have been sent
Done
It would be nice to reinvigorate the steering committee again.
Used AI to brainstorm on this one.
https://chatgpt.com/share/69dbcb5e-5688-8328-a7ee-97e73dbd009a
Perhaps AI can give us the confidence to hack together a 3rd party technical platform, around the tools we already use.
Thoughts? or any other AI brainstorms?
What is a steering committee for? I can think of two things:
@brunopostle
On formal CoC's. These are divisive, and seem to get weaponized.
They should be unnecessary, but the simple statement: "Be professional, be civil, or you can leave." is all that should really be needed, especially in a project like this where acting like a fool could be damaging to your business and/or professional reputation.
If the community enforces standards we all have a duty to maintain decorum when someone starts misbehaving. Once there's a CoC it becomes someone else's responsibility/problem to start policing it, i.e. it's another task to find a resource prepared to do the work.
Hands up if you have read every CoC for every project you have contributed to, or interacted with? I know I haven't. I can't actually think of one where I've ever felt the need to sit down and read through it.
I think the OSArch Steering Committee works best as a lightweight governance layer that only steps in when shared risk is involved—primarily around money, infrastructure ownership, legal responsibility, or protecting the OSArch identity. The core principle, as I see it, is that most technical direction should remain community-driven, but there are moments where discussion needs to end, and someone needs to be able to actually pull the trigger and move things forward rather than letting things linger indefinitely in consensus.
This becomes especially visible in the funding workflow via Open Collective, where community members propose work (for example Bonsai development, tooling, or infrastructure projects). In that context, the committee isn’t just advisory—it is effectively the execution gate: it approves funding, confirms scope completion, and releases funds when work is “done enough” to proceed. Without that function, funding pipelines tend to drift into ambiguity, where scope becomes elastic and delivery loses accountability. I think this decision-to-action role is what prevents stagnation when coordination alone is no longer sufficient.
The same issue shows up even more clearly in shared infrastructure: the Vanilla Forums for community discussion, MediaWiki for documentation, Matrix for real-time coordination, and the proposed Git hosting platform. I think the uncomfortable reality is that the current steering group—while historically important in getting OSArch off the ground—has become partially inactive in practice. Several members are no longer consistently engaged day-to-day, and as a result there is now a real decision vacuum: important infrastructure and coordination questions surface regularly, but there is not always a clearly active or accountable group able to make final calls. The effect is subtle but real—decisions don’t stop happening, they just become slower, more fragmented, or default to whoever happens to be most present at the time.
I think one response is to acknowledge that governance cannot remain static while participation changes. Perhaps a hybrid selection model (as shared above here) for steering committee membership may help address this. Rather than relying purely on nomination or purely on periodic election cycles that quickly become outdated, I think a mixed system could work better in practice: community reputation signals from the forum (actual contribution history, not just titles) and Git contributions, self-nomination for willingness to serve, and a lightweight ratification step from active contributors or a rotating cohort. The goal is not bureaucracy—it is to prevent governance drift, where legitimacy slowly detaches from actual participation.
This “ability to decide” becomes especially important in coordination spaces like proposed BBIM/OSArch property set standardization (for example OSA_Array or OSA_Aggregate). These initiatives already emerge organically across Bonsai, FreeCAD, and related tooling, but at some point someone has to say “this is now stable enough to adopt,” or “this naming is the baseline going forward,” ideally in alignment with broader ecosystems like buildingSMART International. Without that function, standards risk remaining permanently provisional—always discussed, never fully adopted.
So I think the steering committee should not be understood as symbolic governance or a discussion forum. It only has value if it is actively capable of resolving deadlock, re-anchoring fragmented momentum, and converting community consensus into coordinated action when timing matters. And if that capacity isn’t present, then I think it’s also valid to ask whether the structure is still real—or whether it has already quietly dissolved into something more informal, just without anyone explicitly acknowledging it.
I think it’s also important to acknowledge that there may simply not be enough sustained interest in a steering committee in general, or not enough shared belief that it is necessary or useful in its current form. It may also be the case that there are not enough actively engaged, trusted community members willing to step forward and consistently participate in this kind of responsibility at this point in time. I think that would be a valid outcome rather than a failure, and something we can simply revisit later if and when the community develops more sustained interest, capacity, or need for that kind of structure.
And yes, this was refined with AI. :)
A polite request if the SC is revived: Anything that isn't by necessity private, is discussed in the open. For example either minutes/summary/transcript are published if it is an IRL or VC meeting, or a dedicated forum category that is read-only for the rest of us, and writable by SC members for longer discussions. This way everyone can still see the what/why of the SC, without it being derailed by the rest of us.
(Although I was somewhat unexpectedly given the keys to the kingdom as a github contributor, I would be the first to hold my hands up and say that I do not have the necessary qualifications/knowledge etc. to be on this SC.)
@brunopostle
in addition to what mentioned above, what comes to mind is a 'roadmap', and the steering committee, as the name implies, to navigate through it.
My personal view is that we need a rough set of steps with priorities to take Bonsai to the level we expect. It can't be accurate but at least it could guide current and future decisions.
I would like Bonsai to become a professional tool in the future, it would be something in 1 year's time or 5 years depending on resources.
But at least a rough idea of what to become is needed, if not into details at least what are the major features to invest on, what others to implement later, and so on.
Thanks
I totally agree with @steverugi . Having a clear roadmap would also help less non-power users like myself. Plus, my feeling is that while Bonsai has become a really powerful and versatile program, it’s still missing some features that would help attract a wider range of users. A roadmap would allow us to take all aspects into consideration. Anyway, great work so far!
Interesting overview of gimp governance by Alexandre Prokoudine here: https://librearts.org/2026/04/gimp-at-lgm2026/
related discussion: https://community.osarch.org/discussion/3448/a-boost-for-osarch