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

SURVEY-17202 adding the ability to place a cell in editing mode #325

Merged
merged 1 commit into from
Jun 15, 2023

Conversation

fspringveldt
Copy link
Contributor

@fspringveldt fspringveldt commented Jun 14, 2023

As part of new functionality in SURVEY-17202, we need the ability to place individual cells into edit mode programmatically. This exposes this functionality on the GridContextProvider.

Author Checklist

  • appropriate description or links provided to provide context on the PR
  • self reviewed, seems easy to understand and follow
  • reasonable code test coverage
  • change is documented in Storybook and/or markdown files

Reviewer Checklist

  • Follows convention
  • Does what the author says it will do
  • Does not appear to cause side effects and breaking changes
    • if it does cause breaking changes, those are appropriately referenced

Post merge

  • Post about the change in #lui-cop

Conventional Commit Cheat Sheet:
build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
docs: Documentation only changes
feat: A new feature
fix: A bug fix
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
test: Adding missing tests or correcting existing tests

@fspringveldt fspringveldt force-pushed the feature/SURVEY-17202 branch 2 times, most recently from 7a4f5e9 to 227a629 Compare June 15, 2023 02:55
@pull-request-quantifier-deprecated

This PR has 47 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Small
Size       : +34 -13
Percentile : 18.8%

Total files changed: 3

Change summary by file extension:
.tsx : +34 -13

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@fspringveldt fspringveldt merged commit a1ee033 into master Jun 15, 2023
4 checks passed
@fspringveldt fspringveldt deleted the feature/SURVEY-17202 branch June 15, 2023 03:44
@fspringveldt fspringveldt restored the feature/SURVEY-17202 branch June 15, 2023 21:13
@github-actions
Copy link

🎉 This PR is included in version 14.4.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants