What you are proposing I think is more a top-down approach.

Not necessarily both bottom-up and top-down are still possible with this, or a sensible combination of both. If I look at the HospEx page there's a whole lot of handholds and potential. But also it is potentially very broad so good MVP and roadmap planning are important.

I'd recommend at the start to just brainstorm a bit with people from all communities, not worrying too much about the MVP initially. Then when some central themes emerge, define a MVP from there. That is where the domain model comes into play. The brainstorm results are input to it.

A pure bottom-up approach carries a big risk. I explained it for FedeProxy today as: A naive approach would be to think "Code forges are walled gardens, so I create a federated proxy in between to connect them together i.e. named FedeProxy". Then bottom-up you might immediately start coding adapters based on individual Forge API's i.e. Github2Gitlab, Gitea2Gitlab, etc. If doing so, now you have a problem, because as you add forges the number of adapters will explode, and you little flexibility to add value-added features that were not obvious from looking at Forge API's. Adding them later will turn your codebase into a nightmare.

What you are proposing I think is more a top-down approach.

Not necessarily.. both bottom-up and top-down are still possible with this, or a sensible combination of both. If I look at the HospEx page there's a whole lot of handholds and potential. But also it is potentially very broad so good MVP and roadmap planning are important.

I'd recommend at the start to just brainstorm a bit with people from all communities, not worrying too much about the MVP initially. Then when some central themes emerge, define a MVP from there. That is where the domain model comes into play. The brainstorm results are input to it.

A pure bottom-up approach carries a big risk. I explained it for FedeProxy today as: A naive approach would be to think "Code forges are walled gardens, so I create a federated proxy in between to connect them together i.e. named FedeProxy". Then bottom-up you might immediately start coding adapters based on individual Forge API's i.e. Github2Gitlab, Gitea2Gitlab, etc. If doing so, now you have a problem, because as you add forges the number of adapters will explode, and you little flexibility to add value-added features that were not obvious from looking at Forge API's. Adding them later will turn your codebase into a nightmare.

What you are proposing I think is more a top-down approach.

Not necessarily.. both bottom-up and top-down are still possible with this, or a sensible combination of both. If I look at the HospEx page there's a whole lot of handholds and potential. But also it is potentially very broad so good MVP and roadmap planning are important.

I'd recommend at the start to just brainstorm a bit with people from all communities, not worrying too much about the MVP initially. Then when some central themes emerge, define a MVP from there. That is where the domain model comes into play. The brainstorm results are input to it.

A pure bottom-up approach carries a big risk. I explained it for FedeProxy today as: A naive approach would be to think "Code forges are walled gardens, so I create a federated proxy in between to connect them together i.e. named FedeProxy". Then bottom-up you might immediately start coding adapters based on individual Forge API's i.e. Github2Gitlab, Gitea2Gitlab, etc. If doing so, now you have a problem, because as you add forges the number of adapters will explode, and you have only very little flexibility to add value-added features that were not obvious from looking at Forge API's. Adding them later will turn your codebase into a nightmare.

What you are proposing I think is more a top-down approach.

Not necessarily.. both bottom-up and top-down are still possible with this, or a sensible combination of both. If I look at the HospEx page there's a whole lot of handholds and potential. But also it is potentially very broad so good MVP and roadmap planning are important.

I'd recommend at the start to just brainstorm a bit with people from all communities, not worrying too much about the MVP initially. Then when some central themes emerge, define a MVP from there. That is where the domain model comes into play. The brainstorm results are input to it.

A pure bottom-up approach carries a big risk. I explained it for FedeProxy today as: A naive approach would be to think "Code forges are walled gardens, so I create a federated proxy in between to connect them together i.e. named FedeProxy". Then bottom-up you might immediately start coding adapters based on individual Forge API's i.e. Github2Gitlab, Gitea2Gitlab, etc. If doing so, now you have a problem, because as you add forges the number of adapters will explode, and you have only very little flexibility to add value-added features that were not obvious from looking at Forge API's. Adding them later will turn your codebase into a Ball of Mud nightmare.

In reply to @mariha:matrix.org

For the user research, we could leverage:

1. answers to the survey Saemy and I did for WarmShowers, already almost 700 people answered, ActivityPub idea originates from Nick Sellen answer (https://warmshowers.bike/survey)
2. HospExSummit community which is directly interested in the topic and started similar initiative from the community-side (~30 people involved in organizing)
3. Trustroots volunteers and maybe members (~70K)
4. WelcomeToMyGarden team and maybe users
5. maybe BeWelcome community

I would appreciate a lightly facilitated call if somebody feels up for doing that, e.g. check-ins, check-outs, some rounds, making sure voices are heard, stuff like that... and some minutes.

What call cultures are you most comfortable with?

Agenda, maybe...

As for me:

• get to know each other and why everyone is here
• build common understanding of want to do, at a very high level
• maybe decide if we want to do anything about it before we push notification to WS users (like add something to the message or change something in the survey)

Agenda, maybe...

As for me:

• get to know each other and why everyone is here
• build common understanding of what we want to do, at a very high level
• maybe decide if we want to do anything about it before we push notification to WS users (like add something to the message or change something in the survey)