Skip to content

Pioneer: Create Lead Opening Proposal and generic working group proposal functionality #716

@Lezek123

Description

@Lezek123

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 at field (Current and Exact. Switching to Exact displays additional input where user can provide block number)
  • Max review period length field (number of blocks)
  • Simplified Application staking policy section, toggleable by a checkbox, with Stake mode and Stake value fields
  • Simplified Role staking policy section (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 schemaValidator from /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/admin tool 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:createOpening command 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.)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions