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 a new NodeInfo type NodeInfoTypePrivateUnstaked #1214

Closed
vishalchangrani opened this issue Aug 27, 2021 · 1 comment
Closed

Define a new NodeInfo type NodeInfoTypePrivateUnstaked #1214

vishalchangrani opened this issue Aug 27, 2021 · 1 comment

Comments

@vishalchangrani
Copy link
Contributor

Problem Definition

What problem is this solving?

Currently, the NodeInfo can be one of three types:
A new type needs to be defined - NodeInfoTypePrivateUnstaked for the unstaked node. Care needs to be taken that this new type which allows for a nil staking key does not introduce any side effects.

Proposed Solution

What are the proposed solutions to this problem?

Definition of Done

What tests must pass for this issue to be considered solved?

Actions Needed Before Submitting

Update ticket status using the following (remove this section once ticket created)

  • What workstream does this ticket deal with? Find the appropriate 'S-' label and add that label.
  • Is it a specific 'type' of ticket (ex: bug, documentation)? If yes, add that label as well.
  • Is this ticket related to an overarching theme (ex: architecture, performance)? If yes, add that label as well.
  • Add any/all descriptive characteristic labels needed (ex: Needs Estimation, Needs Test Cases).
  • Now we should determine what release this ticket is associated with. If none, leave it blank. If it is associated with a specific release, please add it to the appropriate release.
  • If this ticket is associated with a release, we want to assign it a level of importance within that release. These labels follow the standard MoSCoW method rules. We want to look at releases and then the importance of tickets within those specific releases. So the MoSCoW label is ONLY valid when it is taken in conjunction with its release.
  • Assign this ticket a priority level (High, Medium, Low) via the appropriate label. These labels control the importance of the ticket within the sprint. For example, all P-High tickets should be worked on first, then P-Medium, then P-Low. This gives us an easy way to identify the order of priority for tickets within a specific sprint.
@vishalchangrani
Copy link
Contributor Author

observer node already boots up and is able to connect to a staked AN so this would have been implemented already one way or the other.

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

1 participant