-
Notifications
You must be signed in to change notification settings - Fork 117
Description
Create Lead Opening Proposal
For Nicaea release we will need a new type of proposal that will allow creating a storage workng group "Lead Opening", similar to the typical worker opening created with add_worker_opening extrinsic.
Considering how many parameters (of varying types) are required for creating such opening and the fact that the human_readable_text parameter (of addWorkerOpening extrinsic) is actually expected by the Pioneer to be a valid JSON, compatible with the GenericJoyStreamRoleSchema from /types/src/hiring/schemas/role.schema.typings.ts (even though it is technically just one argument of the Bytes type), it could potentially get quite complex to implement a fully-featured form that will support creating such proposal.
Currently the working-groups/admin tool supports creating Content Working Group openings with the simplified form that only contains:
Activate atfield (CurrentandExact. Switching toExactdisplays additional input where user can provide block number)Max review period lengthfield (number of blocks)- Simplified
Application staking policysection, toggleable by a checkbox, withStake modeandStake valuefields - Simplified
Role staking policysection (same as above) - A textarea for
human_readable_text, where the entire json is just treated as "one value"
Creating such simplified form for the Create Lead Opening Proposal will probably not be too time-consuming, although such implementation will obviosly be lacking compared to the potential fully-featured implementation that will allow providing values for all the extrinsic parameters and a decent UI for human_readable_text json schema.
There are a few minor adjustments that could make human_readable_text as textarea (containing json) a good enough solution for now though:
- Validation and error handling using
schemaValidatorfrom/types/src/hiring/index.ts(already implemented in the CLI: Cli: Create working group commands related to openings and applications #707) - a very low-effort, high-return solution, as it allows us to get a very specific error messages with a negligible amount of coding required - A good default value/values (inside
/working-groups/admintool those are based on the selected "draft") that will allow the user to only slightly modify some parameters in case there's a need to do so - A command in the CLI that will allow generating a json in a similar manner as in
working-group:createOpeningcommand and just copy-pasting the result into the textarea.
I would also consider adding role_slashing_terms as part of the form, as this seem to be an important part of the policy and in contrast to the other "skipped fields", it's actually a required parameter in the extrinsic (working-groups/admin tool currently doesn't allow specifying any value other than Unslashable)
Reusable functionality
Since this is probably the first proposal I'm going to tackle and since we would like the working group proposal forms to be already implemented in such a way, that they could work with multiple different groups in the future, it may be a good idea to also go for creating a reusable generic component for WorkingGroupProposalForm while working on this issue. Such component will be very helpful later, when creating other working group proposals and can have some additional configuration to handle common cases among working group proposals, (ie. showCurrentLead, leadRequired etc.)