Add codespell support with configuration and fixes by yarikoptic · Pull Request #8761 · apache/devlake

yarikoptic · 2026-03-11T17:06:31Z

Add codespell configuration and fix existing typos.

I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.

CI workflow has permissions set only to read so should be safe.

Changes

Configuration & Infrastructure

Added .codespellrc with comprehensive skip patterns for caches (.cache, .npm, .yarn), test fixtures (*/e2e/raw_tables/*, */e2e/snapshot_tables/*), lock files, SVGs, CSS
Created GitHub Actions workflow to check spelling on push and PRs
camelCase/PascalCase ignore-regex to avoid flagging Go/TypeScript identifiers (HasTable, OrderIn, repoRes, etc.)

Domain-Specific Whitelist

Added legitimate terms that codespell flags as typos:

convertor/convertors - project's deliberate spelling convention for Go types and filenames (DataConvertor, *_convertor.go)
crypted - variable name in AES encrypt/decrypt functions
te - Tapd API field name
thur - Thursday abbreviation in Grafana dashboard SQL

Typo Fixes

Ambiguous typos fixed manually (11 distinct typos across 20 files):

convered -> converted (jenkins build model comments)
covert -> converted (issue_status_history log message)
Colume -> Column (migrationhelper error messages)
poping -> popping (api_client comment)
limt -> limit (6 connection model struct tag comments)
faile -> failed (pipeline error messages)
ths -> the (service.go comment)
reloades -> reloads (blueprint.go comment)
verifi -> verify (job_test.go comment)
Troughput -> Throughput (Grafana dashboard display text)
actived/activedColor -> activated/activatedColor (onboard styled components)

Non-ambiguous typos fixed via codespell -w (67 fixes across 47 files):
Common fixes include: doens't -> doesn't, faild -> failed, Internel -> Internal, mintue -> minute, mulitple/mutiple/muliple -> multiple, pipline/pipleline/pipepline -> pipeline, envioronment -> environment, Reveiw -> Review, serverity -> severity

Historical Context

This project has had 119 prior commits fixing typos manually, demonstrating the value of automated spell-checking.

Testing

Codespell passes with zero errors after all fixes.

Generated with Claude Code and love to typos free code

yarikoptic · 2026-03-11T17:07:14Z

      },
      "id": 101,
      "options": {
-        "content": "<div>\n  <img border=\"0\" src=\"/grafana/public/img/lake/logo.png\" style=\"padding-bottom:20px\" alt=\"Merico\" width=\"40\"></img>\n  <h2 style=\"display:inline-block;\">MARI Guide - Requirement Lead Time</h2>\n</div>\n\nSection | Description\n:----------------- | :-------------\nMetric Definition | Total duration of requirements from proposal to delivery. It can be divided by flow status in the practice domain or project management system to count the time share of each phase and help locate the links that drag out the requirement delivery cycle.\nMetric Value | The Requirement Lead Time reflects the rapid responsiveness of the R&D team. <br> In theory, the faster you can deliver value to customers, the better, but other aspects such as whether the delivered value meets customer expectations, requirement throughput, and delivery quality must be considered together. Fast delivery does not necessarily equate to good R&D practices.\n\n***\n#### *M (Measure)*\n1. Count the average or 80th percentile requiremnt lead time for different times.\n2. Counts the average or 80th percentile requiremnt lead time for different projects.<br>\n3. Count the length of time that requirements stay in different practice domains (requirements analysis, design, development, testing, release) or in different states.\n\n##### *A (Analyze)*\n1. Compare the requirement delivery speed of different projects to find the fastest and slowest delivering projects.\n2. Analyze the trend of the average requirement lead time within each cycle, make a vertical comparison, and locate the key points such as maximum value, minimum value, continuous up cycle, and continuous down cycle.\n3. Analyze the trend of the delivery cycle of 80% of the requirements within each cycle, make a longitudinal comparison, and locate the key points such as maximum value, minimum value, continuous up cycle, and continuous down cycle.<br><br><blockquote>\nWhy choose the 80% quantile instead of using the average?<br>\nThe point of statistics is to make predictions with real and valid data to support better decisions, while the mean and median cannot have the role of supporting predictions.<br>\nTypically, the mean and 80% quantile statistics will appear twice as far apart, and the 80% and 99% quantile tend to be approximately twice as related.<br>\nTherefore, the 80% quantile is a good balance point for prediction.\n</blockquote>\n4. Analysis compares the length of time requirement stays in different practice domains or different states to identify the most time-consuming links and find the key bottlenecks that affect overall delivery speed.\n5. Requirement lead time is correlated with requirement throughput to identify whether the requirement delivery trend is healthy or not.\n   - Healthy trend: requirement lead time is shortened and requirement throughput is increased.\n   - Unhealthy trend: longer requirement lead time and lower requirement throughput.\n\n\n##### *R (Review)*\nBased on the analysis results, focus on a few key points and use Ishikawa diagram (fishbone diagram) or Root Cause Analysis (RCA) to conduct root cause analysis, research and review. For example, if the requirement delivery cycle becomes longer in several consecutive statistical cycles, it is necessary to further investigate the length of stay of requirements in different phases and find the longest phase for root cause analysis.\n\n1. The requirements phase takes too long: unclear requirements, frequent changes, overly granular requirements, requirements priorities not clearly defined, insufficient resources or experience of requirements analysts or product managers?\n2. The design phase takes too long: unclear requirement documents, insufficient resources or experience of R&D leaders or architects?\n3. The development phase takes too long: unclear design documents, uneven task distribution, high stream load (parallel tasks), too much technical debt, too many bugs, insufficient resources or experience of developers?\n4. The testing phase takes too long: unclear requirements documentation, poor code quality, few automated tests, insufficient resources or experience of testers?\n5. The release phase takes too long: too long build or deployment time, insufficient resources or experience of operation and maintenance staff?\n\n##### *I (Improve)*\nBased on the review results, focus on the key root causes, and give targeted improvement measures in terms of norms, processes, tools and behaviors, etc., with clear improvement targets, improvement measures, verification cycles and responsible persons.\n\nThe following are the improvement ideas for reference:\n\n1. Communicate with customers or business parties to clarify requirements, reasonably disassemble requirements and define priorities, and invite business parties, R&D leaders and testing leaders to review requirements.\n2. Invite product managers, R&D personnel, and test leaders to conduct design reviews.\n3. Reduce requirement or task granularity, distribute tasks evenly, reduce flow load, increase unit testing, and solve technical debt and code problems in time to reduce the number of bugs and rework.\n4. Test left, develop self-test, code review, increase automated testing, and improve continuous integration capabilities.\n5. Automate deployment, shorten build time, and improve continuous delivery.\n6. Reasonable resource allocation and necessary training for each job holder.\n7. The improvement results should also be quantifiable to facilitate continuous metrics and tracking of improvement effects.",


here github fails to highlight requiremnt -> requirement

klesh

Good job. This is very nice!

klesh · 2026-03-12T12:49:42Z

Some checks failed—could you please fix them? I’d love to merge as soon as possible.

Add .codespellrc with skip patterns for generated files, camelCase/PascalCase ignore-regex, and project-specific word list (convertor, crypted, te, thur). Add GitHub Actions workflow to run codespell on push to main and PRs. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com>

Manual fixes for typos that needed human review to avoid breaking code: - Comment/string typos: occured->occurred, destory->destroy, writting->writing, retreive->retrieve, identifer->identifier, etc. - Struct field comments and documentation corrections - Migration script comment fixes (preserving Go identifiers like DataConvertor) Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com>

Automated fix via `codespell -w` for clear-cut typos across backend, config-ui, and grafana dashboards. Examples: sucess->success, occurence->occurrence, exeucte->execute, asynchornous->asynchronous, Grafana panel typos, etc. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com>

yarikoptic · 2026-03-12T16:39:23Z

done, please re-review/permit workflows run

klesh

LGTM.
Thanks for your contribution.

* ci(codespell): add codespell config and GitHub Actions workflow Add .codespellrc with skip patterns for generated files, camelCase/PascalCase ignore-regex, and project-specific word list (convertor, crypted, te, thur). Add GitHub Actions workflow to run codespell on push to main and PRs. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com> * fix(codespell): fix ambiguous typos requiring context review Manual fixes for typos that needed human review to avoid breaking code: - Comment/string typos: occured->occurred, destory->destroy, writting->writing, retreive->retrieve, identifer->identifier, etc. - Struct field comments and documentation corrections - Migration script comment fixes (preserving Go identifiers like DataConvertor) Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com> * fix(codespell): fix non-ambiguous typos with codespell -w Automated fix via `codespell -w` for clear-cut typos across backend, config-ui, and grafana dashboards. Examples: sucess->success, occurence->occurrence, exeucte->execute, asynchornous->asynchronous, Grafana panel typos, etc. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Yaroslav Halchenko <debian@onerussian.com> --------- Signed-off-by: Yaroslav Halchenko <debian@onerussian.com> Co-authored-by: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com>

dosubot Bot added size:L This PR changes 100-499 lines, ignoring generated files. pr-type/feature-development This PR is to develop a new feature priority/medium This issue is medium important labels Mar 11, 2026

yarikoptic commented Mar 11, 2026

View reviewed changes

klesh previously approved these changes Mar 12, 2026

View reviewed changes

yarikoptic and others added 3 commits March 12, 2026 12:38

yarikoptic dismissed klesh’s stale review via 91b560e March 12, 2026 16:38

yarikoptic force-pushed the enh-codespell branch from 398ebb2 to 91b560e Compare March 12, 2026 16:38

klesh approved these changes Mar 19, 2026

View reviewed changes

klesh merged commit b68c102 into apache:main Mar 19, 2026
11 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add codespell support with configuration and fixes#8761

Add codespell support with configuration and fixes#8761
klesh merged 3 commits into
apache:mainfrom
yarikoptic:enh-codespell

yarikoptic commented Mar 11, 2026

Uh oh!

yarikoptic Mar 11, 2026

Uh oh!

klesh left a comment

Uh oh!

klesh commented Mar 12, 2026

Uh oh!

yarikoptic commented Mar 12, 2026

Uh oh!

klesh left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

yarikoptic commented Mar 11, 2026

Changes

Configuration & Infrastructure

Domain-Specific Whitelist

Typo Fixes

Historical Context

Testing

Uh oh!

yarikoptic Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

klesh left a comment

Choose a reason for hiding this comment

Uh oh!

klesh commented Mar 12, 2026

Uh oh!

yarikoptic commented Mar 12, 2026

Uh oh!

klesh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants