Skip to content

[Exercise Approaches]: Audit/Cleanup of Track Approaches 2026 (part 2) #4197

Closed

Description

@Yrahcaz7

This is a tracking issue for existing approaches on the Python track.
(Part 1 of the audit/cleanup was issue #4055.)

In general, we are auditing/reviewing the following:

  • Spelling, grammar, and typos
  • Python syntax
  • Clarity of writing and explanation
  • Readability and maintainability
  • White space
  • Other Exercism markdown specifications as needed
  • Possible missing/additional approaches (noted as TODOs of future work)

See the lists for each category below. Exercises in "Merged Audits" have been reviewed, changed, and merged. Exercises in "Unaudited" have approaches that have not been audited yet.

Exercises in "Approaches In Progress" do not have finished/published approaches yet, while those in "Missing Approaches" do not have any known work on their approaches yet.

If you want to work on an exercise that is missing an approach, please check in with the maintainers to avoid conflicting with current track priorities or others who may be working on things.

Merged Audits
Unaudited
Approaches In Progress
Missing Approaches
  • Affine Cipher
  • Alphametics
  • Bank Account
  • Binary Search
  • Binary Search Tree
  • Bottle Song
  • Bowling
  • Change
  • Clock
  • Complex Numbers
  • Connect
  • Crypto Square
  • Diamond
  • Difference Of Squares
  • Diffie Hellman
  • Dominoes
  • Dot DSL
  • Flatten Array
  • Food Chain
  • Forth
  • Go Counting
  • Grade School
  • Grep
  • Hangman (to be replaced by Save the Cow)
  • High Scores
  • House
  • Kindergarten Garden
  • Knapsack
  • Largest Series Product
  • Ledger
  • Linked List
  • List Ops
  • Meetup
  • OCR Numbers
  • PaaS I/O
  • Phone Number
  • Poker
  • POV
  • Prime Factors
  • Proverb
  • Pythagorean Triplet
  • Queen Attack
  • Rail Fence Cipher
  • Rational Numbers
  • React
  • Rectangles
  • Resistor Color
  • Resistor Color Duo
  • Resistor Color Trio
  • Rest API
  • Run Length Encoding
  • Satellite
  • Scale Generator
  • Secret Handshake
  • Series
  • SGF Parsing
  • Simple Cipher
  • Simple Linked List
  • Spiral Matrix
  • Tournament
  • Tree Building
  • Twelve Days
  • Two Bucket
  • Two Fer
  • Variable Length Quantity
  • Word Search
  • Zebra Puzzle
  • Zipper

Activity

  1. Yrahcaz7 commented on Jun 9, 2026

    @Yrahcaz7
    ContributorAuthor

    Addressed in PR 4250:

    Collatz Conjecture Dig Deeper audit
    • introduction.md:

      • Line 4: "You can for example" should probably be "You can, for example,"
      • Line 10: "Under this process" should have a comma after it.
      • Line 35: "if/else" should be "if/else".
      • Line 36: "if/ else" should be "if/else".
      • Line 73: "created benchmarks" should probably be "created a benchmark" or "created a small benchmark application".
      • Some terms are missing backticks.
    • if-else/content.md:

      • Either line 21 should be merged with line 20, or "Meaning" should be replaced with "This means that". (Line 19 in ternary-operator/content.md)
      • Line 23: "Inside the loop" should probably have a comma after it. (Line 21 in ternary-operator/content.md)
      • Line 24 and 25: "then" is unnecessary here. (Line 27 in ternary-operator/content.md)
    • ternary-operator/content.md:

      • Line 21: The conditional-expression reflink is missing.
      • Line 22: "if/else" should be "if/else".
      • The last paragraph seems a bit awkward, especially the placement of line 25.
      • "ternary operator/conditional expression" is used a lot, making it harder to read. The first time it is mentioned, one should probably be in parentheses as a side note, and only the other name should be used later.
    • recursion/content.md:

      • Line 16: "Recursion isn't that common in Python, it is more common in" should either have a semicolon instead of a comma, or there should be a "but" before the "it".
      • Line 16: The colon is unnecessary.
      • Line 25: "number" should be "number".
      • Lines 24 to 28 have the same kind of awkwardness that is seen in ternary-operator/content.md.
      • Line 31: "recursion part" should be "recursive part".
      • Line 36: "or stack" should probably be surrounded with parentheses.
      • Line 36: "code adds 0" is confusing, maybe it should be "function returns 0"?
      • Maybe the terms "base case" and "recursive case" should be mentioned somewhere.
    • The performance article:

      • Line 3: "approach" should be "article".
      • Line 9: "the" is unnecessary here.
      • The usual disclaimer seems to be missing here. Is there a reason for that?
  2. Yrahcaz7 commented on Jun 17, 2026

    @Yrahcaz7
    ContributorAuthor

    Addressed in PR 4252:

    Leap Dig Deeper audit (part 1 of 2)
    • introduction.md:

      • Line 10: "you will use" is a strange wording, it should probably be "you can use", as there are other ways to determine if it is evenly divisible.
      • Lines 3 to 4 imply that all of the approaches are idiomatic, but line 37 contradicts that. One of these should be changed to match the correct one.
      • The last two approaches do not have the usual code blocks. Is this intentional?
      • The last approach is missing a link to its approach doc.
    • boolean-chain/content.md:

      • Line 9/59: This link is outdated, it should be replaced by the isleap source link from introduction.md, as that one has a fixed version number.
      • Line 11: "evenly divided" should probably be "evenly divisible".
      • Line 12: The "{" should be a "(" to match the closing ")".
      • Line 14: "the interpreter will stop the evaluation to return" would be very confusing to less knowledgeable students. It should probably be "the chain will short circuit and return" instead.
      • Line 15: There should be a "True" in between "be" and "if".
      • Line 40: The "Refactoring" header is a bit misleading. It seems to imply that the variation is somehow "better" than the original, even though they are about the same. It should probably be changed to "Variation 1" or similar.
      • Line 42/56 (line 13/33 in ternary-operator/content.md): The link should probably go to the header that is relevant.
      • Idea: It might be worth mentioning why != 0 is necessary. (And perhaps how it could be replaced with bool().)
    • ternary-operator/content.md:

      • Lines 15 and 16: "the expression is True/False, and" is not necessary here.
      • Lines 15 and 16: There should be a "True" in between "returns" and "if".
      • Line 26: "less efficient than another approach that would first test" should be "less efficient than the [boolean chain][insert-link-here] approach that first tests".
      • Line 27 should be in parentheses to make the long sentence (lines 25-27) more readable.

    Edit: I get a 404 error when I try to access the ternary operator approach, even though the entry is present in the config.json and the files are in the correctly named folder on GitHub.

    @BethanyG, do you know what's going on here?

  3. BethanyG commented on Jun 17, 2026

    @BethanyG
    Member

    Edit: I get a 404 error when I try to access the ternary operator approach, even though the entry is present in the config.json and the files are in the correctly named folder on GitHub.

    @BethanyG, do you know what's going on here?

    🤔 I just took a quick look. I don't know what is up. There doesn't appear to be a mis-match in folder name, name in config, or anything in the reflink. One thing I can think of that might be an issue is that the UUID for the article might not be unique, or there might be something poisonous in the formatting of the file. That author was fairly famous for cutting and pasting from other tracks and not changing the UUIDs ... so.

    Maybe we try re-creating that approach by re-doing the UUID for the article, and pulling out the text of the approach and re-saving it? I can do that after I finish reviewing your Eilud's Eggs approaches. 😄

  4. Yrahcaz7 commented on Jun 19, 2026

    @Yrahcaz7
    ContributorAuthor

    Addressed in PR 4252:

    Leap Dig Deeper audit (part 2 of 2)
    • datetime-addition/content.md:

      • Line 15: In "datetime object and a datetime.timedelta object", either "datetime object" should be "datetime.datetime object", or "datetime.timedelta object" should be "timedelta object". As it is now, it is a bit confusing and inconsistent.
      • Line 17: "exercises" should be "exercise's" here.
      • Line 20: The second comma isn't necessary here.
      • Lines 23 to 25: This bulleted list should be a paragraph instead of a list. It is also kind of confusing. Really, all of lines 20 to 25 should probably be merged into one unified explanation that is clearer.
      • Some terms are missing backticks.
    • calendar-isleap/content.md:

      • Line 3: The codeblock does not have syntax highlighting because the language is set to "pythoon" instead of "python".
      • Line 24/37 should probably use the link from introduction.md, as that one goes directly to the implementation instead of just the top of the file.
    • The performance article:

      • Lines 11 to 12: The list does not render properly because there is not a blank line in between the list and the previous paragraph.
      • Line 22: The chart's alt-text has the wrong dates: "1900, 200, 2019, and 202" should be "1900, 2000, 2019, and 2020".
      • Line 22: The mentioned heading "Timings for approaches by input year" should probably be surrounded by quotes instead of the whole alt-text.
      • Lines 38 to 45: These list items should probably say "approach", as in "The ternary operator approach" instead of just "The ternary operator".
      • Line 42: "but it is" should probably be "it is also".
      • Line 45: "then" doesn't seem necessary here.
  5. BethanyG commented on Jun 22, 2026

    @BethanyG
    Member

    @Yrahcaz7 - with any luck... the Leap PR will fix the missing approach. I replaced the UUID with a new one in config.json.

  6. Yrahcaz7 commented on Jun 23, 2026

    @Yrahcaz7
    ContributorAuthor

    with any luck... the Leap PR will fix the missing approach.

    It seems like it's fixed now!

  7. Fi6uDvGWucFv commented on Jun 25, 2026

    @Fi6uDvGWucFv

    Regarding the "Acronym" approach, instead of using "scrub the input," it might be clearer to say "clean the input" to align with standard terminology in data processing. Additionally, can we clarify what the expected format for the input string is in this approach to enhance clarity for users?

  8. BethanyG commented on Jun 25, 2026

    @BethanyG
    Member

    @Fi6uDvGWucFv - the changes to the Acronym exercise have already been PR-d.

  9. Yrahcaz7 commented on Jun 25, 2026

    @Yrahcaz7
    ContributorAuthor

    @BethanyG, actually, I think we never PRed those changes. I still see the old version on the website -- We probably both confused the new approach with the cleanup and never actually PRed it 😅.

    Should I draft up a PR? I'll probably have the time to do so tomorrow.

  10. BethanyG commented on Jun 26, 2026

    @BethanyG
    Member

    @BethanyG, actually, I think we never PRed those changes. I still see the old version on the website -- We probably both confused the new approach with the cleanup and never actually PRed it 😅.
    Should I draft up a PR? I'll probably have the time to do so tomorrow.

    Sure! Let's go ahead and do that. 😄 Thanks!

  11. Yrahcaz7 commented on Jul 13, 2026

    @Yrahcaz7
    ContributorAuthor
    Bob Dig Deeper audit
    • introduction.md:

      • Line 6 is confusing because it isn't clear that it is referring to a different approach. Making it a markdown list of the approaches would be one way of fixing this.
      • Line 10 should probably have a colon at the end.
      • Line 22 (line 25 in if-statements/content.md and if-statements-nested): "If an if statement can return" is confusing, as it makes it seem like the if statement only sometimes returns. It should probably be "If an if statement returns" instead.
      • The first two approaches don't have any explanation in introduction.md. Should this be added?
      • Line 71: The header "Other approach: answer list" should probably be "Approach: Answer list" because it is already under the "other approaches" header.
      • The last approach is missing a codeblock; was this intentional?
      • Line 83 is formatted as a list because of the "- " at the beginning.
      • Line 86: This link has the wrong highlight parameter. The parameter should either be removed or changed to endswith: https://docs.python.org/3/library/stdtypes.html?highlight=endswith#str.endswith
      • Overall: "if statements nested" is a bit awkward, "nested if statements" would be clearer.
    • if-statements/content.md and if-statements-nested/content.md:

      • Line 38 (line 43 in answer-list/content.md): " Z" should be "Z". Also, "when uppercase" should probably be "when uppercased" for grammar.
    • if-statements-nested/content.md:

      • Line 44: This is false because it is just an if statement, not an if/else.
      • Line 44: "returns if it is a shouted question or just a shout" is confusing, as Bob's response is what is returned, not the type of the input sentence. Replacing "returns" with "tests" would make it clearer.
    • answer-list/content.md:

      • Line 26: This link should be converted to a reflink. The linked python-tuples header also seems to have been renamed to creating-tuples-in-python.
      • Line 27 is rather confusing. "the performance between a tuple and a list here is equivalent" should probably be changed to "a tuple does not perform differently than a list here" or similar.
      • Lines 27-28: There is no transition between these two lines, which is a little jarring. Line 28 should probably start with "However," or similar.
      • Lines 34-36: There is no transition between these two lines. Line 36 should probably start with "Next," or similar.
      • Line 52 should have a colon at the end.
      • The snippet has # code snipped instead of the usual ...; which one of these is preferred?
    • The performance article:

  12. Bbk1AtJJF8 commented on Aug 3, 2026

    @Bbk1AtJJF8

    For the Affine Cipher exercise, consider including a function that explicitly demonstrates how the encoding and decoding are related mathematically, which would enhance clarity and educational value for new learners.

  13. BethanyG commented on Aug 17, 2026

    @BethanyG
    Member

    @gjbbcjj The changes to the Acronym exercise were already PR'd.

  14. BethanyG commented on Sep 10, 2026

    @BethanyG
    Member

    @kyliekamesha26 - I'm sorry, but this issue is closed to contributions from anyone but Yrahcaz7, who was originally assigned to it.

  15. Yrahcaz7 commented on Sep 14, 2026

    @Yrahcaz7
    ContributorAuthor
    Roman Numerals Dig Deeper audit
    • Overall:

      • "Loop over Romans" does not make sense, it should be changed to "Loop over Roman Numerals".
    • introduction.md:

      • Line 20: "concept" should probably be "process" or similar.
      • Lines 20-24: This paragraph should be made more generic; right now it seems to focus too much on the "With if conditions" approach.
      • Lines 24 and 95 should probably be separated from the last list item.
      • Line 91 is missing punctuation at the end.
      • Line 92 is a bit awkward.
      • Line 122: This is an odd place for the link, perhaps it should be moved to line 133.
      • Lines 135-147 should probably be reworded to use a link to the relevant lines instead of a codeblock.
      • Lines 175-180: This codeblock is formatted in a way that is very hard to read.
      • Line 179 uses double quotes.
      • The introduction is missing a section that links to the itertools.starmap() approach.
    • if-else/content.md, if-else/snippet.txt, and introduction.md:

      • This approach uses type hints, which are usually not included. It also has unnecessary assertions.
    • if-else/content.md:

      • Lines 17, 20, 22, 24, 26, and 35: There is an extra space after the +=.
      • Lines 28 and 37: There is an extra space after the second >.
      • The first codeblock has unnecessary > 0 and > 4 comparisons.
      • Line 49: This paragraph does not actually explain how the approach works.
      • Line 61 needs more explanation.
      • Line 64 is missing a serial comma in "hundreds, tens and units".
      • Line 69 does not make much sense where it is currently, so it should be moved to after the codeblock.
    • table-lookup/content.md, table-lookup/snippet.txt, and introduction.md:

      • This approach uses single letter variable names (that are not roman numerals). It also has an unnecessary assertion.
    • table-lookup/content.md:

      • Perhaps the comments could be merged into the rest of the explanation.
      • Line 17 (75 in introduction.md): "we need" should be "get" and "our" should be "the".
      • Line 34: This header should be "Variation 1" or similar.
    • loop-over-romans/snippet.txt:

      • This snippet uses single letter variable names (that are not roman numerals).
      • Line 2 (line 30 in loop-over-romans/content.md) has an unnecessary assertion.
      • Line 3 uses double quotes (quoting should be consistent per exercise, if I remember correctly).
    • loop-over-romans/content.md:

      • This approach uses type hints.
      • The exact workings of most of the variants are not explained.
      • There are no headers separating the variants.
      • Line 19: "Arabic (decimal)" should be "Arabic (decimal) numbers".
      • Lines 25-27, 70, and 89 use double quotes.
      • Lines 33-36 and 55-57 use single letter variable names (that are not roman numerals).
      • Line 40: "the" is unnecessary here.
      • Lines 44 and 45 have inconsistent spacing.
      • Lines 48 and 74 have docstrings.
      • Line 66: "1, 5, 10" should be "1, 5, and 10".
      • Line 69 is missing a serial comma in "10's, 5's and 1's".
      • Line 97: "is doing" should probably be "does".
      • Line 113 does not apply to the last variant. This should be clarified.
      • Line 113: There is a missing space after "while".
      • Line 117 is a bit awkward, changing "so need" to "so they need" should improve it.
      • Lines 121-124 should probably either be:
        • removed entirely, or
        • moved to a single variant (and preserve the type hints on only that variant) and also have links to resources about type hinting.
      • If it is kept, these should be fixed:
        • Line 122: There should be an "is" after the "and".
        • Line 124: "IDE's" should be "IDEs". Also, the subject of whether VSCode is an IDE should probably be avoided.
    • recurse-match/content.md, recurse-match/snippet.txt, and introduction.md:

      • This approach uses type hints.
      • The comma in [ROMAN_NUM[idx],] is unnecessary, as it is a single-element list, not a tuple.
      • The last case (case [num, idx, digits]:) can be changed to a default case (case _:).
    • recurse-match/content.md:

      • Lines 5, 38, 39, and 50 (line 155 in introduction.md) use double quotes.
      • Line 22: The first part of this sentence could be improved to: "A major limitation is the lack of tail-call optimization".
      • Line 26 has an extra space before the ending period.
      • Line 41 has an extra space after convert.
      • Lines 44-46: It is not clear what the ltr variable represents from its name. It should probably be renamed to roman_val or similar.
      • Line 57: This link is invalid as it uses loop-over-roman instead of loop-over-romans.
    • itertools-starmap/content.md and itertools-starmap/snippet.txt:

      • This approach uses type hints, single letter variable names, and double quotes.
    • itertools-starmap/content.md:

      • Line 50 is a bit awkward; perhaps it could be changed to: "Roman numerals for 5,000 and 10,000 are not defined, so spaces are used here instead."
      • Line 63: There should be a comma after "For example".
      • Line 71: "compute" should probably be "compute()".
    • config.json:

      • Line 23: "Numerals" should be lowercased here.
      • Line 53: Maybe "the recently-introduced" should be removed, as Python pattern matching has been around for almost 5 years now.

    @BethanyG, can I open a PR to fix these? (Or perhaps 2 separate ones due to the amount?)

  16. BethanyG commented on Sep 15, 2026

    @BethanyG
    Member

    Hi @Yrahcaz7 👋🏽

    @BethanyG, can I open a PR to fix these? (Or perhaps 2 separate ones due to the amount?)

    Apologies for the delay in replying. Go for it. Maybe two groups: The straight-up typos, whitespace, and punctuation-related stuff. And a second one for rephrases and other more substantial edits? Many thanks for working on this!

  17. jonahwhite115 commented on Sep 27, 2026

    @jonahwhite115

    I can take a look at auditing Circular Buffer next, specifically ensuring we cover the trade-offs between using a

  18. Yrahcaz7 commented on Oct 14, 2026

    @Yrahcaz7
    ContributorAuthor
    Raindrops Dig Deeper audit
    • Overall:

    • introduction.md:

      • Line 8: "many" is duplicated in "many many variations".
      • Line 16 is missing punctuation at the end.
      • Line 27 is missing a serial comma in "(3, 5 or 7)".
      • Line 28 is missing a space between 'Plong' and (7).
      • Line 38: "code" should be "the code" here.
      • Line 88: "f-string" should be "f-strings" here.
      • Line 91: A comma is unnecessary here.
      • Line 134: "tuple with join" should be "sequence with join".
      • Line 153: "factor -> sound mappings" would be clearer as "factor to sound mappings". It might also be helpful to provide the generator expression link again.
      • Line 154: "'results'" should be "results" here.
      • Line 205: This link should be to approach-itertools-compress, not itertools-compress.
      • Line 211 has unnecessary parentheses around number % factor.
      • Line 233: To clarify that this does not include the approach in the "Other Approaches" section, "All approaches" should be changed to "All 7 approaches".
      • Lines 235-239: This paragraph is rather large and would benefit from splitting.
      • Line 245: The comment has no space after the # and has an extra space before "Unless".
      • Line 262: n is usually used for big-O notation instead of m when there is only one factor.
    • if-statements/content.md:

      • Line 15: The "modulo" here should probably have the modulo link from introduction.md.
      • Line 16: "modulo == 0" and "sounds" should probably be surrounded with backticks.
      • Line 17: "Sounds" should be "sounds" here.
      • Line 20: The comma should either be removed or a matching comma after the "of course" should be added.
      • Line 26: A variation header would be apt here.
      • Line 28: The docs on conditional expressions could be linked here.
    • truthy-and-falsey-with-fstring/content.md:

      • Line 6: The comment is incorrect; modulo == 1 should be modulo > 0.
      • Line 12 (line 74 in introduction.md): The #OR# is indented here.
      • Line 23: The docs on f-strings should be linked here.
      • Line 23 (line 85 in introduction.md): The last comma is unnecessary.
      • Line 30 has mismatched quotes: 'Pling" should be 'Pling'.
      • Line 30: "not False" should be "is not False" here.
      • Line 31: The empty string here '' looks like a double quote when rendered on the website. Surrounding it in backticks could fix this.
    • loop-and-fstring/content.md:

      • Line 7 (line 97 in introduction.md, line 3 in loop-and-fstring/snippet.txt): Double quotes are used here, when single quotes are used in most other places.
      • Line 19 (line 108 in introduction.md): "sounds string" should be "the sounds string".
      • Line 20 (line 109 in introduction.md): "Sounds" should be "sounds".
      • Line 28: A variation header would be apt here.
    • sequence-with-join/content.md:

      • Lines 5 and 27 (line 119 in introduction.md) use double quotes.
      • Lines 9 and 30 (line 123 in introduction.md, line 6 in sequence-with-join/snippet.txt) have unnecessary parentheses around the if clause.
      • Line 16 (131 in introduction.md): "Sounds" should be "sounds".
      • Line 19: There should be a comma after "like most approaches described here".
      • Line 21: A variation header would be apt here.
      • Line 22 is phrased awkwardly; perhaps it could be changed to "The above solution might not be very readable for those not used to reading generator expressions inside calls to other functions, so if that is the case, it can be re-written as:".
    • dict-and-join/content.md:

      • Line 37: A variation header would be apt here.
      • Line 45 has unnecessary parentheses around the if clause.
      • Line 48, 49, and 52: All of these links now redirect here (with the appropriate heading).
    • itertools-compress/content.md:

      • Line 8 (line 4 in itertools-compress/snippet.txt) should either use parentheses or there should be explanation of implicit tuple creation.
      • Lines 9 and 34 (lines 166 and 173 in introduction.md, line 5 in itertools-compress/snippet.txt) have unnecessary parentheses around number % factor.
      • Line 14 should have the generator expression link.
      • Line 21 is a bit awkward, maybe it could be changed to: "The code is also harder to maintain should additional factors/sounds be needed."
      • Line 39 is a bit awkward, maybe it could be changed to: "In this variation, factors are keys and the sounds are values in a dictionary."
    • functools-reduce/content.md:

      • Lines 9 and 31 (line 166 in introduction.md, line 5 in functools-reduce/snippet.txt) have unnecessary parentheses around number % factor.
      • Line 9: The comment has no space after the #.
      • Line 23: "as the factor list expands" should be "if the factor list is expanded".
      • Line 32 has unnecessary parentheses around item[0] * item[1].
    • The performance article:

    • The performance article's snippet.md:

      • All columns past "14" can't be seen on the website (but they are still rendered in the HTML, so removing them may slightly decrease load time). Additionally, the website does not render any borders for the snippet's table, so it is hard to tell when one column ends and begins.
      • The data appears to be outdated (it seems like the article's data was changed in PR dict-and-join simplify for raindrops approaches #3620, but not in the snippet).

    @BethanyG, can I open a PR for these? (There's quite a few audit items, but only a couple of them need prose rewording.)

  19. BethanyG commented on Oct 14, 2026

    @BethanyG
    Member

    @BethanyG, can I open a PR for these? (There's quite a few audit items, but only a couple of them need prose rewording.)

    Go for it! 😄

  20. damianoecker26 commented on Oct 16, 2026

    @damianoecker26

    I am planning to audit the All Your Base approach documentation; should I prioritize updating the conversion logic explanation for multi-base edge cases before touching the formatting?

  21. BethanyG commented on Oct 16, 2026

    @BethanyG
    Member

    @damianoecker26, please see this comment.. Thanks.

  22. edinakama commented on Oct 17, 2026

    @edinakama

    I can tackle the All Your Base audit, but do we need to implement consistent error handling for invalid input bases or negative digits across the approach documentation before I begin?

  23. BethanyG commented on Oct 19, 2026

    @BethanyG
    Member

    @edinakama - did you not see the comment above? Please respect that. Thanks,

  24. brokendenim commented on Oct 20, 2026

    @brokendenim

    Regarding the Unaudited list, should I prioritize All Your Base to align with the existing style guide for functional decomposition, or is there a specific target for how to handle the base conversion logic in the approaches doc?

  25. BethanyG commented on Oct 20, 2026

    @BethanyG
    Member

    @brokendenim - As I said to @edinakama -- please read this comment. Thanks.

  26. locked and limited conversation to collaborators on Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

x:rep/massiveMassive amount of reputation

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions