Manifesto amendments

[anaelleltd]

The Manifesto was last updated on 16 November 2022.
Many changes to Fellowship processes have ben made since then.
The Manifesto needs to be updated to reflect current practices.

[anaelleltd]

Amendments could cover the following topics:

ALL SECTIONS:

• Replacement: "Evidence(s)" with "Argument(s)"
• Replacement: "Grading(s)" with "Evaluation(s)"

SECTION 2.3 AUDIENCE, GOALS, AND NON-GOALS

• Technical implementation of WfCs: Can we mention if they are a goal or a non-goal for the Fellowship?

SECTION 2.3.1 Specifics

• New Polkadot protocol areas: Proof-of-Personhood, Native stablecoins, Multichain bridges, Statement store
• Upcoming Polkadot protocol area: JAM tooling
• Replacement: "user-interface code required to practically execute upgrades to the Polkadot (Main) Network;" with "user-interface code required to carry out the technical work (designing, programming, debugging) required to maintain Polkadot (Main) Network, including operational upgrades"

SECTION 4.2 (1) PROMOTION

• Fast promote: This feature is available for Ranks 1-3 and designed to be used to reward JAM Client implementers. Should it be used beyond the JAM Prize, for any new Polkadot protocol areas implementers?

SECTION 4.3 CONTINUATION

• Passive allowances: they can be used to avoid demotions. Should we set a time limit (in months) for each instance?

SECTION 4.5.4 Voting

• Agreement thresholds: they are barely used for evaluations. Should they be maintained as a retention criteria? Or are they better used exclusively as a promotion criteria?

SECTION 6 RANK SPECIFICATIONS

• Replacement: "Requirements" with "Requirements for [xyz Dan]"

SECTION 9 PRIZES

• Sub-treasury: Funding is used to incentivise development-focused initiatives and reward contributors for solving technical issues. Can we mention if funded RFCs and RFPs implementations funded can be considered honourable prizes?

[anaelleltd]

@kianenigma

[kianenigma]

Meta

Before going into too much detail, the first thing we need to discuss is what the the meta process on amending the manifesto? A voting made by which track can approve the change? or should be it be done via the root track of OpenGov?

Specific comments

Some preliminary opinions on the specific points:

Technical implementation of WfCs: Can we mention if they are a goal or a non-goal for the Fellowship?

This was discussed in the fellowship calls at least once, and the verdict around it was that:

• Fellowship's mandate is not to implement any W4C
• Fellowship, provided that someone has done a proper implementation of a W4C, should review it and not block it.

I believe the same can be said about an RFC, especially those that are opened by members who themselves cannot code and complete it. Although, while I don't know how to phrase it I think an RFC has more weight on the fellowship, and should be treated with more priority than W4C.

SECTION 2.3.1 Specifics

I generally agree with all the new suggestion. The broad term phrase I can suggest that encapsulates all existing and previous topics is:

"All core technologies needed to enable the existence of the Polkadot Network and its Native feature set". The "Native Feature set" can represent:

• New functionality present in AssetHub (contracts, DEXs, etc)
• Native stablecoin (!= stablecoin implemented by another parachain team)
• Native storage/messaging solutions (Bulletin-chain, Statement-store)
• New functionality in People chain (PoP)

What is important is also the term "existence of". So a mobile app allowing users to interact with any of the above is not included.

user-interface code required to practically execute upgrades to the Polkadot (Main) Network

I do think that we are getting ever more closer to PAPI being this tool, not PJS. I also think the maintainers of PAPI are very versed in core Polkadot technology.

Fast promote

I was faced with this question in a few times already, and by reading the existing manifesto carefully, my opinion converged to the following:

• Fast promotes should be acceptable for Ranks 1 to 3, because the time-requirement in the manifesto is not strict. It states:

It is generally expected that the participant will have been practicing Polkadot as their primary life-focus for at least one year, unbroken, after attaining the previous rank.

While for Rank 4 and above, this becomes:

The participant will have been practicing Polkadot as their primary life-focus for at least one year, unbroken, after attaining the previous rank.

This means that I am open to:

• If someone has equivalent of Rank 2 total-time + expertise in Polkadot, I would vote yes on their fast promote to rank 2.
• For rank 4 and above, a 1 year minimum unbroken (not passive) time in Rank 3 is required.

JAM Prize

Fast promote of 1 JAM member per team is a special case for the above, and is approved by OpenGov. It is also compatible with my opinion above.

Passive allowances: they can be used to avoid demotions. Should we set a time limit (in months) for each instance?

Yes, this is a good point. My opinion at the moment is:

• For any rank, regardless of passive or not, people should put their arguments for retention. For passive members, the argument could be as simple as: "I am not actively working on Polkadot [due to ...], and I am claiming only my passive allowance [proof]." Members might still decide to vote nay on this, but this is up to the social consensus of the members. I don't think not putting up any argument for any rank is acceptable, so I suggest keeping the demotion logic as-is.

Agreement thresholds: they are barely used for evaluations. Should they be maintained as a retention criteria? Or are they better used exclusively as a promotion criteria?

I think it is a good measure, and there is opensquare-network/subsquare#6789 for better visibility.

---

Other suggestions:

• clarify whether a fellow member already being compensated can apply for further funding from the fellowship treasury or not
• libp2p-based should probably be replaced with networking stack to accommodate for migration to newer technologies like lite-p2p.

[acatangiu]

Fast promote: This feature is available for Ranks 1-3 and designed to be used to reward JAM Client implementers.

I don’t see why this should be limited to JAM Client implementers. All contributions to any protocol covered in the manifesto should be allowed to be judged and voted on by Fellows and above in the context of a potential fast promotion.

Passive allowances: they can be used to avoid demotions. Should we set a time limit (in months) for each instance?

I am aligned with Kian, retention challenge should still be required, but with relaxed “passing grade”. Again, up to the Fellows and above to judge through vote.

Agreement thresholds: they are barely used for evaluations. Should they be maintained as a retention criteria? Or are they better used exclusively as a promotion criteria?

I am def in favor of keeping them. We’ve seen that they improve vote turnout. I expect we will use them more and more even in evaluations.

[anaelleltd]

The suggested amendments have been implemented here.

See highlights below:

@kianenigma @acatangiu Please review and let me know if edits/clarifications are needed.

[kianenigma]

@anaelleltd the changes so far enacted looks good to me. What about the other points above? I don't see all of them incorporated.

@acatangiu about

Fast promote: This feature is available for Ranks 1-3 and designed to be used to reward JAM Client implementers.

I don’t see why this should be limited to JAM Client implementers. All contributions to any protocol covered in the manifesto should be allowed to be judged and voted on by Fellows and above in the context of a potential fast promotion.

Then we should alter the existing wording of the manifesto that I named in the comment above e.g. for Rank 4 and above:

The participant will have been practicing Polkadot as their primary life-focus for at least one year, unbroken, after attaining the previous rank.

I am personally more in favor of the existing order; up to Rank 3 can be fast promoted, afterwards time becomes mandatory. But ofc if more fellows think otherwise, we can change it.

[anaelleltd]

@anaelleltd the changes so far enacted looks good to me. What about the other points above? I don't see all of them incorporated.

I left out:

• the specifics/examples re: Polkadot "Native feature set" as these could change in the medium term.
• any explicit reference to WfC and RFCs, as these are purely operational processes (i.e too granular for the more generic Manifesto).

Since there hasn't been much input/discussion re: salaried Fellows applying for extra compensation/funding through the sub-treasury, I didn't have any clear instructions on how to follow up. If you have a recommendation on this topic, please share and I will start my edits from there.

I don’t see why this should be limited to JAM Client implementers. All contributions to any protocol covered in the manifesto should be allowed to be judged and voted on by Fellows and above in the context of a potential fast promotion.

Then we should alter the existing wording of the manifesto that I named in the comment above e.g. for Rank 4 and above:

The participant will have been practicing Polkadot as their primary life-focus for at least one year, unbroken, after attaining the previous rank.

I am personally more in favor of the existing order; up to Rank 3 can be fast promoted, afterwards time becomes mandatory. But ofc if more fellows think otherwise, we can change it.

Regarding Fast promote, I left the original wording as the current promotion requirements for <Rank 3 apply most of the time. Instead, I added the following to indicate that these promotion requirements may/can be adapted for the odd candidate/member:

If this wording is not convenient, I will straight up edit each individual sections on Rank 1-3 requirements.