Working Groups

[xlc]

I would like to discuss if we should introduce working groups to the fellowship process. Some ideas:

• Possible working groups: Frame, XCM + Bridge, JAM, Quality and Assurance, Release
• We could have ad hoc ones like one for the AH migration
• Two ranks in a WP: leader, and participant. A WP can have multiple leaders (just not too many)
• Anyone can join / leave a WP as participant at any time
• Active Rank 3+ members are required to be an active participant of at least one WP
• Active Rank 5+ members are required to be a leader of at least one WP
• Active participants are expected to:
  • Provide technical support
  • Development & maintenance of related code
  • Participate related technical discussion
  • Review related RFC
• Leaders are expected to
  • Design and plan related works
  • Make decisions
  • Collaborate with other WG
  • Support participants

Each WP should have a public discussion channel and people can use it to seek related technical support

[acatangiu]

Fully support this!

[xlc]

So the consensus is that we should do this as a social collaboration mechanism. No need to make any manifesto level changes (i.e. no change on retain/promote requirements). I think we can move it to the next step.

I created this for discussion: https://hackmd.io/@xlc/B1Rfx2JByx

[anaelleltd]

So the consensus is that we should do this as a social collaboration mechanism. No need to make any manifesto level changes (i.e. no change on retain/promote requirements).

Since this is mostly about centralising information in one place and there is no additional process for "joining" a working group, the new WorkingGroups repo could operate permissionlessly, just like the current RFCs repo. So, this new repo would just be used to host the list & description of all working groups, no?

Define the initial set of working groups
PR to add a page describe the working to be added
Onchain voting

I anticipate that these Working groups will closely match the specific technologies defined in bullet points in Section 2.3.1 of the Manifesto. Doesn't that make on-chain voting redundant from the get-go?

Create related channels, resource pages, project boards, etc
Onboard participants
[...]
Profit

With the details of each working group publicly available in the WorkingGroups repo, these tasks look more like active co-mentorship (e.g. directing a candidates and members to the relevant resources, sharing latest updates, answering questions, etc.).
Unless you meant "onboarding" as in recruiting people to join in? 👀

In terms of how each individual working group operates, I think we can let the leaders to decide.

The initial discussion in the Fellowship channel implied that working groups would focus on reviewing RFCs and oversee their implementation. Couldn't this be used as both a starting point and a measure of WG's effectiveness in the short-term?

[xlc]

So, this new repo would just be used to host the list & description of all working groups, no?

Yes

Doesn't that make on-chain voting redundant from the get-go?

I guess we don't need to have onchain voting. But we still need some discussions about which WG to have. Not every single bullet point needs to be a WG. Also we likely need to have some ad-hoc one.

With the details of each working group publicly available in the WorkingGroups repo, these tasks look more like active co-mentorship (e.g. directing a candidates and members to the relevant resources, sharing latest updates, answering questions, etc.).

Yes that's one of the goal, to improve collaborations and productivity as well as communications to ecosystem devs and users.

The initial discussion in the Fellowship channel implied that working groups would focus on reviewing RFCs and oversee their implementation. Couldn't this be used as both a starting point and a measure of WG's effectiveness in the short-term?

Sounds good to me

[anaelleltd]

I guess we don't need to have onchain voting. But we still need some discussions about which WG to have. Not every single bullet point needs to be a WG. Also we likely need to have some ad-hoc one.

Yes that's one of the goal, to improve collaborations and productivity as well as communications to ecosystem devs and users.

Thanks for the clarifications. I will start working on this new repo.