Expose add_member_to_rank extrinsic
#4778
Conversation
| pub fn add_member_to_rank( | ||
| origin: OriginFor<T>, | ||
| who: AccountIdLookupOf<T>, | ||
| rank: Rank, | ||
| ) -> DispatchResult { |
There was a problem hiding this comment.
Won't we need a similar call in core-fellowship? Or will this somehow bypass that configuration?
There was a problem hiding this comment.
Don't know. @ggwpez could you please take a look at PR and maybe help to answer this question. Thank you)
There was a problem hiding this comment.
I think we should have only one in the core-fellowship pallet. Similar to the induct function there.
There was a problem hiding this comment.
@ggwpez few questions:
- Does it make sense to make another call similar to
promote? - Maybe it's better to close Fellowship: Expose
add_member_to_rank#262 if the issue task is no longer valid?
There was a problem hiding this comment.
The task is definitely valid, it just does not prescribe a solution.
A promote_to function could also be useful for people already inducted but where it makes sense for some reason to promote them over several ranks.
There was a problem hiding this comment.
The task is definitely valid, it just does not prescribe a solution.
A
promote_tofunction could also be useful for people already inducted but where it makes sense for some reason to promote them over several ranks.
But this violate the rule of mainefest 4.2.3: "...associated rank is incremented by one". I suppose that it is not possible to increment rank more than 1 at a time. Or am i missing something?
There was a problem hiding this comment.
Two things:
One, the manifesto is from the Tech Fellowship. It is not the only collective (see, e.g., the Ambassador collective, which actually requires promoting members by 3 steps). If the Fellowship never wants someone promoted by more than one rank at a time they will need to configure things as such.
Two, we use origins to control access to privileged functions, and typically origins that correspond to public tracks will always outweigh any internal management origins.
What I mean is that rules like that are mainly arbitrary and can always be superseded by governance. You could also do a runtime upgrade or referendum to set_storage to get the same effect. The goal of this task is to provide a transparent, non-footgun way of accomplishing this effect.
Things like manifestos and white papers are guiding principles but they shouldn't trump pragmatism. The JAM prize, which the Fellowship also agreed to steward, has conditions like automatic promotion to X rank for certain accomplishments. Sure, the manifesto has that clause and it can be upheld by the members and enforced by origin configuration, but there are obvious pragmatic shortfalls of the code in some circumstances that led to the creation of this feature request.
mateo-moon
force-pushed
the
oleg-plakida/#262
branch
from
1d2a54c
to
b9d3700
Compare
mateo-moon
force-pushed
the
oleg-plakida/#262
branch
from
b9d3700
to
7113d01
Compare
mateo-moon
force-pushed
the
oleg-plakida/#262
branch
from
7113d01
to
4b497c1
Compare
|
The CI pipeline was cancelled due to failure one of the required jobs. |
mateo-moon
force-pushed
the
oleg-plakida/#262
branch
2 times, most recently
from
c7e5a0c
to
8c45ac3
Compare
mateo-moon
force-pushed
the
oleg-plakida/#262
branch
from
8c45ac3
to
41d39b1
Compare
|
Hey @oleg-plakida , are you going to keep working on this? |
|
Yes. At least i will try. On 19 Jun 2024, at 19:13, joe petrowski ***@***.***> wrote:
Hey @oleg-plakida , are you going to keep working on this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Add a `promote_fast` extrinsic to the `core-fellowship` pallet to allow promotions that ignore the promotion cooldown. It comes with a new `FastPromoteOrigin`. Supersedes #4778 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: command-bot <>
|
Sorry this became a high-prio after fellows being accidentally demoted. Superseded by: #4877 |
Sure thing. I understand. |
|
So we can close this? |
Add a `promote_fast` extrinsic to the `core-fellowship` pallet to allow promotions that ignore the promotion cooldown. It comes with a new `FastPromoteOrigin`. Supersedes paritytech#4778 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: command-bot <>
Add fast promotion tracks with 7 days (instead of 30 days) voting period. The tracks have a 50% turnout and 66% approval criteria. To be used in combination with paritytech/polkadot-sdk#4778. It could be that the 50% turnout is too much for tracks I and II, but for III there are not so many fellows so we can expect them to all vote IMHO. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Fixes #262
First PR.