compose initial resolution for onboarding process #333

Open
oxaliq wants to merge 2 commits from oxaliq/docs.coopcloud.tech:resolution/onboarding into main
Owner

Includes "onboarding buddy" role and proposal for new resources

Includes "onboarding buddy" role and proposal for new resources
oxaliq added 1 commit 2026-09-28 14:38:01 +00:00
Owner

I really like it, great work! It seems like it mightn't be implementable in a consistent way however, based on my experiences of our fedi membership participation. Here are some ideas, adjust/take on/throw away as desired!

I think the majority of the resolution could be implemented as 1) a checklist for new members 2) a checklist for vouch/buddy member, aka "we need better checklists and docs that people can follow".

That doesn't eliminate the proposal for new people to have a clear place to ask their questions but it does allow for extremely infrequent capacity which characterises federation membership at this current juncture.

So, I think we'll have the intended improvement if the new people have a solid and clear checklist to read and know the handle of the person they can DM directly for support and questions. Then we're still building, people have direct support from their buddy and the process can continue async / when time allows (vs. scheduling in a meeting which might be it's own demoralising exercise as it sometimes is 🙃)

I really like it, great work! It seems like it mightn't be implementable in a consistent way however, based on my experiences of our fedi membership participation. Here are some ideas, adjust/take on/throw away as desired! I think the majority of the resolution could be implemented as 1) a checklist for new members 2) a checklist for vouch/buddy member, aka "we need better checklists and docs that people can follow". That doesn't eliminate the proposal for new people to have a clear place to ask their questions but it does allow for extremely infrequent capacity which characterises federation membership at this current juncture. So, I think we'll have the intended improvement if the new people have a solid and clear checklist to read and know the handle of the person they can DM directly for support and questions. Then we're still building, people have direct support from their buddy and the process can continue async / when time allows (vs. scheduling in a meeting which might be it's own demoralising exercise as it sometimes is 🙃)
Author
Owner

@decentral1se Thanks for the response!

I definitely agree that most of this could be distilled into checklists and I will change the "further proposes [...]" language to reflect that. One of the roles of the buddy would then be to keep new members in phase with the inevitable documentation drift.

I also understand the limited capacity that Federation members have. My personal hope for this role is that new members are quickly integrated in a way that allows us all to make better use of that limited capacity. Does an estimated upper bound on 1 hour of work per week for the buddy feel too excessive?

Yr definitely probably right about synchronous communication as well, especially as there is a current push for meetings and new members could always attend kite-flyings. I'll strike that.

@decentral1se Thanks for the response! I definitely agree that most of this could be distilled into checklists and I will change the "further proposes [...]" language to reflect that. One of the roles of the buddy would then be to keep new members in phase with the inevitable documentation drift. I also understand the limited capacity that Federation members have. My personal hope for this role is that new members are quickly integrated in a way that allows us all to make better use of that limited capacity. Does an estimated upper bound on 1 hour of work per week for the buddy feel too excessive? Yr definitely probably right about synchronous communication as well, especially as there is a current push for meetings and new members could always attend kite-flyings. I'll strike that.
Owner

Love this 😍
I See the concern from @decentral1se regarding the struggle of finding time for a meeting but I really like that this is part of the responsibility of the buddy role as this allows building real connections and allocating a budget for the role hopefully somewhat solves it. I also like @decentral1se emphasis on lists and async documentation. Maybe we can find a middle ground? Reduce the hours for the buddy role a little but expect at least one real time meeting?

Love this 😍 I See the concern from @decentral1se regarding the struggle of finding time for a meeting but I really like that this is part of the responsibility of the buddy role as this allows building real connections and allocating a budget for the role hopefully somewhat solves it. I also like @decentral1se emphasis on lists and async documentation. Maybe we can find a middle ground? Reduce the hours for the buddy role a little but expect at least one real time meeting?
oxaliq added 1 commit 2026-10-01 15:18:27 +00:00
also adds language that highlights social role of the buddy and need for
new member resources to be task lists
Author
Owner

@p4u1 @decentral1se i incorporated a compromise of only 1 expected meeting and added some language that i hope highlights the connection-building nature of the proposed role.

@p4u1 @decentral1se i incorporated a compromise of only 1 expected meeting and added some language that i hope highlights the connection-building nature of the proposed role.
Owner

Great stuff! I would adapt the "fedi member vouches for new member" template (do we have one?) so that there is a buddy: ... field and a link to this text so that people know what is going on and it will be implemeneted. Merge the shit 🥇

Great stuff! I would adapt the "fedi member vouches for new member" template (do we have one?) so that there is a `buddy: ...` field and a link to this text so that people know what is going on and it will be implemeneted. Merge the shit 🥇
Owner

heey thanks! danny just asked me something i didn't pay much attention before, but it has come up several times since i'm part of the federation and he's right to be confused. do we have an onboarding procedure for being added to repositories, teams, etc here on git.coopcloud.tech? for instance i couldn't even at-mention him in this conversation, and earlier this week i couldn't add maren as a reviewer (and can't at-mention here either).

i know there probably isn't one, since we've been adding folks on request in my experience, so maybe this resolution could be it?

this is the current membership list on toolshed, does it reflect federation membership?

image.png

members should have access to:

  • toolshed team
  • appropiate recipe maintainers team(s)
  • new website (at panel.sutty.nl)

ps: i guess someone will bring up fedi sso ;b

heey thanks! danny just asked me something i didn't pay much attention before, but it has come up several times since i'm part of the federation and he's right to be confused. do we have an onboarding procedure for being added to repositories, teams, etc here on git.coopcloud.tech? for instance i couldn't even at-mention him in this conversation, and earlier this week i couldn't add maren as a reviewer (and can't at-mention here either). i know there probably isn't one, since we've been adding folks on request in my experience, so maybe this resolution could be it? this is the current membership list on toolshed, does it reflect federation membership? <img width="300" alt="image.png" src="attachments/b740b4c8-fc8d-412b-932d-3fd12042bc96"> members should have access to: * toolshed team * appropiate recipe maintainers team(s) * new website (at panel.sutty.nl) ps: i guess someone will bring up fedi sso ;b
Owner

@fauno my 2c: that is a slighty different but important topic For maintainership, we wrote this: https://docs.coopcloud.tech/maintainers/maintain/. For general "getting added in different places", there was afair never a document written. This current proposal is about a good social integration. I welcome another proposal which is about permissions and entrypoints (which is a step further, when you are active, you did a thing (e.g. submitted a PR) and now the fedi or someone with permissions open the door for further integration).

edit: unsubscribing from this one now also! goood luckkkkkk

@fauno my 2c: that is a slighty different but important topic For maintainership, we wrote this: https://docs.coopcloud.tech/maintainers/maintain/. For general "getting added in different places", there was afair never a document written. This current proposal is about a good social integration. I welcome another proposal which is about permissions and entrypoints (which is a step further, when you are active, you did a thing (e.g. submitted a PR) and now the fedi or someone with permissions open the door for further integration). **edit**: unsubscribing from this one now also! goood luckkkkkk
Owner

I agree with @decentral1se, no we don't have a written process, yes we should have one, I would be happy to work with someone on either a PR to just document what I think is the current practice ("owners" = federation members, "co-operators" = anyone that contributes to a recipe) or a Resolution to set a formal policy.

I agree with @decentral1se, no we don't have a written process, yes we should have one, I would be happy to work with someone on either a PR to just document what I think is the current practice ("owners" = federation members, "co-operators" = anyone that contributes to a recipe) or a Resolution to set a formal policy.
This pull request has changes conflicting with the target branch.
  • docs/federation/resolutions/in-progress/046.md
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u https://git.coopcloud.tech/oxaliq/docs.coopcloud.tech resolution/onboarding:oxaliq-resolution/onboarding
git checkout oxaliq-resolution/onboarding
Sign in to join this conversation.