polkadot-fellows / help-center Goto Github PK

Hi
I am reaching out as I am planning to launch soon a Security BugBounty with as a scope the bridge between Polkadot and Kusama. And in that context I am looking for curators.

SCOPE:
For that specific bounty, most of operational task will be perform by Parity Security team including:

• 1. reviewing the security bounty request from the Whitehat
• 2. after triage, giving it to the engineering team to have it fixed,
• 3. after remediation, checking if it fixes the root cause in partnership with engineering team involved, the whitehat and if required with external security audit firm
• 4. then to propose the reward level to the curators
• 5. eventually to communicate to the community about the bug and remediation

The key activities of the curators will be the following:

• oversight of the end to end process effectiveness including quality and speed to manage requests
• support the triage for edge cases based on expertise required
• decide the reward level based on the criticality and reward framework/banding within the referenda
• executing the payment onchain to the Whitehat when required

MEMBERS:
To ensure the successful implementation of this bounty, the curators will be at least 5, representing different members of the Polkadot ecosystem, bringing diverse forms of expertise:

• At least 2 curators with expertise on Bridges as this is the focused area of this bug bounty
• At least 2 curators with security expertise as this bounty is about security bug

to complete the members, having the Fellowship represented by someone on that bounty will be very beneficial from multiple perspectives

I am available if you need more details

I think we need one. Can be hosted on GitHub pages i assume.

I would like to have this repo (or some other repo) to be the main source of information for all fellowship members and candidates.

Here is an incomplete list of topics that should be included. We do have some of those information available somewhere, and we should have them gathered to a single place.

• How to become a candidate
• How to not get demoted. i.e. the responsibilities. (for rank 1, 2, 3, and so on)
• How to get promoted (to rank 1, 2, 3, and so on)
• How to setup identity and link to github handle
• How to use review bot and merge bot and rfc bot
• How to find a mentor
• The online and offline events (e.g. the OpenDev Monthly Call)
• Meeting notes

Following up on the approval of Proposal 103, the next immediate step is to create a secretary collective as per the initial discussion on Fellowship secretary.

I would like to get myself promoted to rank 5 within next 6 months and while the manifesto have the requirements, I would like to seek for clarifications to see if there is anything specific that I need to do to meet the requirements.

Here is the requirement from manifesto for V Dan so you don't need to look it up:

• Play a primary role in ideating, designing and formalising or prototyping a major component.
• Usefully assisted in devising (“creating”, “inventing”, “incepting”) three more major components.
• Usefully assisted (through advocation, research or rationalisation) in determining the long-term technical roadmap.
• At least one published long-form article about technology relevant to but not specifically concerning Polkadot.

Here are my questions and some answers I got

1. What is considered as a major component? Does Chopsticks count?

From Gav,

A "major component" would be something like the whole staking system or grandpa. The form in which it is formalised or implemented isn't especially important. There's no reason why it could not take the form of one or more pallets.
Regarding Chipsticks, I don't know to what level it is used to deliver and maintain the Core protocol (that would potentially be something to present when defending).
There may indeed be an argument to be made for it being considered a Core component.

Given Chopsticks is an essential tool to test the runtimes, it can be considered providing I can defend it.

2. How to participate in determining the long-term technical roadmap?
3. What will be considered for the long-form technology article? Are there any examples? Does it need to be a formal academic format?
4. How do I trigger the promotion process? I would image the onchain voting is only the last step. Presumably I need to prepare some material to prove my work and I need to publish it somewhere.

I want to exchange my member account in the fellowship as i have lost access to my previous account. I had to work on an extrinsic so as to allow for this. This is the linked issue created sometime ago #1

previous(current) account is: 15VsPr7y92ZFAN6zv7ELqC7eeWvJN5GT2kVozRfRuNoEZCsN
new account is: 12GyGD3QhT4i2JJpNzvMf96sxxBLWymz4RdGCxRH5Rj5agKW

This is the encoded call hash to fellowshipCollective::exchangeMember()
0x3c0600c6f57237cd4abfbeed99171495fc784e45a9d5d2814d435de40de00991a73c0600386a4f5a0311a2834e28c84daa299fe14414137807e201a1941e502c7a784467

We need to clarify the scope of the Core Fellowship so that new members can know in what area of work are considered in scope.

While we have manifesto as the source of truth, but it still leaves many rooms for interoperation and from recent discussions, it is clear the members do not have a consensus about this topic.

I am starting this issue in order trying to allow members to reach a consensus about this topic and then we will be able to produce a clear guideline for new members.

PS: I am not sure if this is the best place for such discussion, but at the same time this topic doesn't feel like in the scope of RFC. So I started this here for now and see if we can figure out the next step together.

Here is the quote from the manifesto for reference:

2.3.1. Specifics. Based on the above, we may conclude that expertise on the following technology and its strict descrip- tion(s) and/or implementation(s) would be considered a goal of the Fellowship:
• the internals of all functional Polkadot node implementations;
• cryptographic data-structures, algorithms, languages and apis required for the continued upkeep of the Polkadot
(Main) Network;
• consensus algorithms concerning the Relay-chain (babe & grandpa);
• trust-free bridges relying on said consensus algorithms (planned to be) utilised by system chains;
• parachain consensus;
• cross-chain message passing (xcmp, hrmp, dmp & ump);
• the Polkadot libp2p-based peer networking protocol;
• the Polkadot topology strategies;
• chain synchronisation strategies utilised by Polkadot;
• the Polkadot business-logic (aka the “runtime”);
• pallets utilised by the Polkadot (Main) Network and its system chains;
• the internals of the frame pallet framework;
• runtime and host apis;
• the xcm specification and realisation;
• standard rpcs;
• user-interface code required to practically execute upgrades to the Polkadot (Main) Network; and
• code or technology required by, and utilised primarily for, any code or technology already included.
In short, if expertise on a technology (or a specific implementation of it) is required and primarily used for the Polkadot (Main) Network to continue operating and improving, then it is covered. If it is not then it is not.
Notable examples of technologies/code which are not covered:
• Rust language (required by realisations of the Polkadot Network, but not primarily used for them); • libp2p (required by the Polkadot Network but not primarily used for it);
• ‘subxt‘ (useful tooling, but not required for Polkadot’s continued operation); and
• ‘ink!’ (useful tooling, but not required for Polkadot’s continued operation).

This is the list of repo I believe that are in scope and everyone will agree:

• https://github.com/polkadot-fellows/runtimes
• https://github.com/polkadot-fellows/RFCs
• Everything under https://github.com/paritytech/polkadot-sdk/ that is also included in the runtime Cargo.lock file
• https://github.com/paritytech/xcm-format

This is the list of repo that are currently considered in scope but may require additional discussion:

• Everything under https://github.com/polkadot-js

This is a list of repo that I would like to seek for clarification that if they are under scope of the Core Fellowship

• Everything else under https://github.com/paritytech/polkadot-sdk/ that's not included in the runtime Cargo.lock file
• Tests related to Polkadot runtime. e.g. Acala's XCM tests, polkadot-integration-tests
• Testing tools powers the tests. e.g. Chopsticks, xcm-emulator, xcm-simulator
• Fuzzer. e.g. substrate-runtime-fuzzer

I lost access to my former account id which is part of the technical committee fellow, my former account id is H5BuqCmucJhUUuvjAzPazeVwVCtUSXVQdc5Dnx2q5zD7rVn, This is my Polkadot account id I want to change to 12GyGD3QhT4i2JJpNzvMf96sxxBLWymz4RdGCxRH5Rj5agKW.

The Fellowship commits to the implementation of each merged RFC. Currently many of the RFCs are implemented by their creators, but this cannot be assumed in general. Especially not for external RFCs (eg #20).
I wonder if we should create an issue after each merged RFC to track its implementation. This could be done by the RFC merge bot.

You think this could be useful?

Over the time the fellowship exists now (not that long), I and others have seen that sometimes we would need to have more help in organizing stuff etc. So, the idea arose that it would be good to have some kind of Secretary for the fellowship. Here is a preliminary list of things this person could do:

• Organization of fellowship meetings
• Help with RFCs. Get more engagement. Do some cat herding and whatever that can help to improve the process
• Help documenting processes. Help people with basic stuff.
• Some project management stuff around releases.
• Maybe help with the fellowship/opendev call.

If you have more ideas, please comment.

We would also want to pay this person. The current idea is that we probably add some secretary collective as other collectives may at some point have the same need.