Define the responsibilities so we can evaluate salary payment requests

[xlc]

Related to #50

We need a way to define responsibilities for everyone so that when evaluate salary payment requests, everyone will have a clear understanding of what is acceptable or not.

e.g. we expect Rank 3 members to perform X amount of review work, Y amount of development, Z amount of support (to users or to other devs)

Eventually, the payout should be performance based for obvious reasons and that could replace the passive mode. For example, I personally am most likely going to be part-time working for fellowship that may not be qualified for full salary but should be more than the passive mode payout.

[pandres95]

While I consider this a good idea, I'm quite concerned about the relative hardship of completing a task (some developments imply more hours of work, others less, and the same with support and RFCs), and how that would be relevant to the performance-based evaluation. If we can find a baseline/common ground for this, I'd be happy to keep myself on the loop, giving feedback on this issue.

[bkchr]

IMO we should have at least one or better two cycles and be more open to accept what people present as defense to retain their rank. Based on these cycles we should then come up with some requirements per rank. I mean the manifesto already mentions some, but I think we can make them a little bit more "clear".

[xlc]

Yeah clarification is what I need. For example, does contribution to polkadot.js count? How about Chopsticks? ORML?

[pandres95]

IMO we should have at least one or better two cycles and be more open to accept what people present as defense to retain their rank. Based on these cycles we should then come up with some requirements per rank.

Fair enough.

I mean the manifesto already mentions some, but I think we can make them a little bit more "clear".

Yes! But still, the manifesto is quite vague (and I'd say overly ambitious) about what is expected at each rank (especially considering the Fellowship is aimed to scale, and the manifesto is more like an "academic wishlist", nice to see, but quite tricky to see in practice).

For example, I'm personally considering three non-trivial accepted PRs on polkadot-sdk the bare minimum to apply for membership or retain at Rank I, but I may be wrong, and RFCs, as well as contributions on runtimes might also apply as non-trivials. Also, is it really three?

What about peer-reviewed published articles? Is this peer-reviewed as in PRs, or peer-reviewed as in full-on academic publishing?

Yup, it's always a good idea to clarify those requirements to help people get a clearer view of their own path in the Fellowship.

[gavofyork]

Happy to set up a dialog for clarification but agree with Basti that practical experience should inform expectations. Letting it run for 2-3 months would be very helpful.

The academic nature of the manifesto is fitting since a) this stuff is impossible to get right on the first time and the more details you put in the more wrong it will be and b) it must be relevant long-term; practical details would make it short-sighted.

The Fellowship is not designed to be a general coders' payroll. It's more like an ongoing grant system to retain and develop protocol expertise. Since ORML is not directly relevant to the protocol then it would not be covered. I think the Manifesto is very clear on this point.