This repository hosts the list and description of all working groups (WGs) administered by the Polkadot Technical Fellowship.
Working groups are a social collaboration mechanism aiming to support the development and maintenance of the specific technologies defined in Section 2.3.1 of the Manifesto.
Working groups do not constitute a change to the Manifesto: they only seek to optimise productivity within the Technical Fellowship and improve communications with ecosystem developers and users.
Working groups are organised around two distinct roles: Leaders and Participants.
Leaders are responsible for:
- Proposing/creating ad hoc WGs
- Designing and planning internal tasks
- Decision-making and calls to action
- Reviewing targets and success metrics
- Collaboration with other WGs
- Supporting participants
Participants' duties include:
- Reviewing related RFCs
- Providing technical support
- Development & maintenance of related code
- Participation in technical discussions
Anyone can join/leave a WG as a participant at any time. Active Rank 3+ members are required to join at least one WG as a participant. Active Rank 5+ members are required to become the leader of at least one WG. A WG can have up to 3 leaders.
Each WG should have a public discussion channel so that external contributors can access related technical information, resources, and support.
The process for submitting WGs is open to Fellows (i.e Rank III to IX). Anyone may provide comments on submitted WGs.
To submit a WG, follow these steps:
- Fork the
working-groupsrepository. - Copy the
0000-wg-template.mdfile into thewgfolder and rename it to match the title of the WG. - Fill out the WG template and open a PR.
- Announce the WG to the Fellowship and wait at least 2 weeks.
- Put the WG to a vote.
The Fellowship will decide via off-chain voting when to approve and merge WGs. The Fellowship should not approve more than one WG with the same number.
The Initial leader(s) will need to open a poll in the relevant Fellowship channel to gather members' votes, with the voting period lasting no more than 7 days.
Should the Fellowship fail to approve a WG, the Initial leader(s) may chose to open a new poll at a later date or close the PR. PRs will also be closed after a period of 6 months without acceptance.
After an initial set of working groups (e.g. FRAME, XCM, Trustless bridges, etc.) has been defined, it should be possible to create ad hoc working groups (e.g. Plaza, Minimal Relay, etc.) to mirror the evolution of the Polkadot roadmap.
Initially, it is expected that working groups will prioritise reviewing existing RFCs and overseeing their implementation, which will be used as a measure of their effectiveness in the short-term.
The Fellowship is using Matrix for communication. Right now there exists two channels:
- Polkadot Technical Fellowship Channel: The channel for all Fellowship members to discuss. To get voice rights, you need to be part of the Fellowship. However, the channel is readable by anyone.
- Polkadot Technical Fellowship - Open Channel: Open channel for anyone. Should be used to reach out to the Fellowship e.g. to request review or help on a topic.