Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define the responsibilities so we can evaluate salary payment requests #55

Open
xlc opened this issue Nov 28, 2023 · 5 comments
Open

Define the responsibilities so we can evaluate salary payment requests #55

xlc opened this issue Nov 28, 2023 · 5 comments

Comments

@xlc
Copy link
Contributor

xlc commented Nov 28, 2023

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.

@xlc xlc mentioned this issue Nov 28, 2023
@pandres95
Copy link

pandres95 commented Dec 1, 2023

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
Copy link
Contributor

bkchr commented Feb 27, 2024

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
Copy link
Contributor Author

xlc commented Feb 27, 2024

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

@pandres95
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants