Test/simple spec test types

[shane-moore]

Issue Addressed

Continuation of spec test PR's

Proposed Changes

Added SszSpecTest and CommitteeMemberTest

Additional Info

Blocked by #839 since this PR is built on top of it's commits

[github-actions]

Your PR title doesn't follow the Conventional Commit guidelines.

Example of valid titles:

• feat: add new user login
• fix: correct button size
• docs: update README

Usage:

• feat: Introduces a new feature
• fix: Patches a bug
• chore: General maintenance tasks or updates
• test: Adding new tests or modifying existing tests
• perf: Performance improvements
• refactor: Changes to improve code structure
• docs: Documentation updates
• ci: Changes to CI/CD configurations
• revert: Reverts a previously merged PR

Breaking Changes

Breaking changes are noted by using an exclamation mark. For example:

• feat!: changed the API
• chore(node)!: Removed unused public function

Help

For more information, follow the guidelines here: https://www.conventionalcommits.org/en/v1.0.0/

[diegomrsantos]

Can we avoid having many parallel draft PRs and instead focus only on one at a time? Also, please let's go back to small, focused, and easy-to-review PRs

[shane-moore]

Can we avoid having many parallel draft PRs and instead focus only on one at a time? Also, please let's go back to small, focused, and easy-to-review PRs

agree with having small PR's. each one of these spec test PR's builds commits on top of the previous PR, because the changes would clash if each PR's commits were each built off unstable. so this looks like 1800 line diff, but it's really just a few hundred lines. will be smaller once the upstream PR's are merged to unstable

I was thinking the strategy could be to leave the PR that's ready for review as open. and put the rest as draft. then, once PR is merged, I would take the next PR in the line out of draft. so you'd only have to review a small PR at a time instead of making one big one with all the changes. kinda figured it's fine for folks to ignore the ones that are in draft. alternatively could keep the draft branches local and just submit them to the repo once the PR before it is merged. I'm open to other suggestions to handle this

[diegomrsantos]

Can we avoid having many parallel draft PRs and instead focus only on one at a time? Also, please let's go back to small, focused, and easy-to-review PRs

agree with having small PR's. each one of these spec test PR's builds commits on top of the previous PR, because the changes would clash if each PR's commits were each built off unstable. so this looks like 1800 line diff, but it's really just a few hundred lines. will be smaller once the upstream PR's are merged to unstable

I was thinking the strategy could be to leave the PR that's ready for review as open. and put the rest as draft. then, once PR is merged, I would take the next PR in the line out of draft. so you'd only have to review a small PR at a time instead of making one big one with all the changes. kinda figured it's fine for folks to ignore the ones that are in draft. alternatively could keep the draft branches local and just submit them to the repo once the PR before it is merged. I'm open to other suggestions to handle this

The right way of doing this is using stacked PRs, but I believe the current way we work doesn't allow it. @dknopik

[diegomrsantos]

Can we avoid having many parallel draft PRs and instead focus only on one at a time? Also, please let's go back to small, focused, and easy-to-review PRs

agree with having small PR's. each one of these spec test PR's builds commits on top of the previous PR, because the changes would clash if each PR's commits were each built off unstable. so this looks like 1800 line diff, but it's really just a few hundred lines. will be smaller once the upstream PR's are merged to unstable
I was thinking the strategy could be to leave the PR that's ready for review as open. and put the rest as draft. then, once PR is merged, I would take the next PR in the line out of draft. so you'd only have to review a small PR at a time instead of making one big one with all the changes. kinda figured it's fine for folks to ignore the ones that are in draft. alternatively could keep the draft branches local and just submit them to the repo once the PR before it is merged. I'm open to other suggestions to handle this

The right way of doing this is using stacked PRs, but I believe the current way we work doesn't allow it. @dknopik

In the meantime, it'd be helpful to add a more elaborate description explaining the context in which the PR was created, as you did in the previous comment.

[shane-moore]

agreed that stacked PR's are the right approach for this type of thing. don't think it's easy or common to do for repo's where contributors work off of a fork. i think a middle ground is that for the rest of the spec test PR's, i'll make them as stacked PR's in my forked repo. and then, upstream each one to sigp/anchor once the previous PR has been merged to unstable

[shane-moore]

also updated the PR description to reference the PR that it's blocked by as you mentioned, great idea