[Payment due @mananjadhav] [No QA] Update HELPSITE_NAMING_CONVENTIONS.md

[stephanieelliott]

Explanation of Change

Changes:

• remove rules disallowing More menu, since it exists as a valid menu.
• Fix navigation tabs naming to standardize on "In the navigation tabs"

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/637657

Tests

N/A no tests, this is a documentation change only.

Offline tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

N/A no tests, this is a documentation change only.

Explanation of Change

Fixed Issues

$
PROPOSAL:

Tests

• Verify that no errors appear in the JS console

Offline tests

N/A

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

[melvin-bot]

@mananjadhav Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR modifies the governance document itself (HELPSITE_NAMING_CONVENTIONS.md) with two categories of changes: (1) removing the prohibition against calling the three dots menu "More" or "More menu," and (2) changing navigation instruction phrasing from action-oriented verbs to prepositional phrases. Both changes raise concerns about internal consistency and alignment with the broader authoring guidelines.

Scores Summary

• Readability: 5/10 - The navigation phrasing changes ("In the navigation tabs on the left") produce sentence fragments rather than complete, actionable instructions. The three dots menu section remains readable after changes.
• AI Readiness: 6/10 - Removing explicit prohibitions weakens the specificity of the governance rules, which could reduce consistency across articles and degrade AI retrieval precision over time.
• Style Compliance: 4/10 - The navigation phrasing change directly conflicts with HELP_AUTHORING_GUIDELINES.md Section 5, which requires step instructions to be "action-oriented." The phrase "In the navigation tabs" is a locative fragment, not an action.

Key Findings

Three Dots Menu -- Removing "More" Prohibitions

• The PR removes two explicit rules: "Do not call it 'More'" and "Do not write 'More menu'." It also removes the corresponding incorrect examples ("Click More", "Select ': More'", "Open the More menu").
• The PR description states the rationale is that "More" exists as a valid menu in the UI. If the UI genuinely labels this element "More," then the existing prohibition was incorrect and removing it is justified. However, this should be verified against the current product UI on all platforms.
• Removing these prohibitions without adding replacement guidance creates ambiguity. If "More" is now acceptable, the Correct examples section should show how to properly reference it (e.g., "Click More" with bold formatting per Button Naming Standards). Currently, neither the Correct nor Incorrect examples mention "More" at all after this change.
• The new incorrect example "Open the three dots menu" is a useful addition, as it clarifies that "three dots" should not be used without the visual symbol.

Navigation Phrasing -- "In the navigation tabs"

• Changing from "Use the navigation tabs on the left" and "Click the navigation tabs" to "In the navigation tabs on the left" introduces sentence fragments. These are not complete instructions -- they describe a location but do not tell the user what action to take.
• HELP_AUTHORING_GUIDELINES.md Section 5 explicitly requires step instructions to be "action-oriented." A prepositional phrase like "In the navigation tabs" does not satisfy this requirement.
• The TEMPLATE.md file at line 80 still contains the old phrasing: "Click the navigation tabs (on the left on web, on the bottom on mobile)." This PR does not update the template, creating an immediate inconsistency between the two governance documents.
• Examining existing articles reveals a mixed state: many already use "In the navigation tabs" phrasing, while others use "Click the navigation tabs" or "Use the navigation tabs." This PR would standardize on the fragment form, but does not address the existing articles that use action verbs.

Internal Consistency After Changes

• The Prohibited Language section (line 200-209) still lists "Click the three dots" as prohibited, which remains consistent with the three dots menu rule changes.
• The three dots Incorrect examples section now contains "Open the three dots menu" -- this is consistent with the rule requiring the visual symbol (vertical ellipsis) to always be included.

Recommendations

1. Clarify "More" menu guidance: If "More" is a valid UI label, add explicit guidance on how to reference it correctly (bold formatting, exact label match). Simply removing the prohibition without adding positive guidance leaves a gap.
2. Reconsider navigation phrasing: Either keep action-oriented verbs ("Use", "Click", "Select") to align with HELP_AUTHORING_GUIDELINES.md Section 5, or update Section 5 to acknowledge that navigation context-setting phrases are an exception. The current change creates a contradiction between governance documents.
3. Update TEMPLATE.md: If the navigation phrasing change is accepted, update docs/TEMPLATE.md line 80 to match. Currently it still reads "Click the navigation tabs."
4. Verify UI labels: Confirm whether the product UI actually labels the three dots menu as "More" on any platform. The review rationale depends on this being true.
5. Audit existing articles: A grep of the docs directory shows approximately 80+ articles using navigation tab phrasing. Many already use "In the navigation tabs" (suggesting the PR is aligning the governance to match existing practice), but others use "Click" or "Use." A follow-up pass to standardize existing articles would be needed regardless of which phrasing is chosen.

Files Reviewed

• docs/HELPSITE_NAMING_CONVENTIONS.md - Three changes: removed "More" menu prohibitions, changed navigation phrasing from action verbs to prepositional fragments, added "Open the three dots menu" as incorrect example. The "More" removal may be justified if the UI has changed, but needs replacement guidance. The navigation phrasing change conflicts with authoring guidelines.

Note: This PR modifies a governance document, so its impact extends to all future HelpDot articles authored under these rules.

[OSBotify]

A preview of your ExpensifyHelp changes have been deployed to https://181d692f.helpdot.pages.dev ⚡️

Updated articles:

• HELPSITE_NAMING_CONVENTIONS

[mananjadhav]

Approving as it's tagged No QA .

[melvin-bot]

@NicolasBonet Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

🎯 @mananjadhav, thanks for reviewing and testing this PR! 🎉

A payment issue will be created for your review once this PR is deployed to production.
E/E issue linked to the PR - https://www.github.com/Expensify/Expensify/issues/637657.

If payment is not needed (e.g., regression PR review fix etc), react with 👎 to this comment to prevent the payment issue from being created.

[github-actions]

Readability / structure violation: "In the navigation tabs on the left." is a prepositional phrase fragment, not a complete instruction. The previous phrasing ("Use the navigation tabs on the left.") was an imperative sentence, which aligns with HELP_AUTHORING_GUIDELINES.md Section 5 requiring step instructions to be "Action-oriented." Since this governance file sets the standard for all HelpDot articles, the example phrasing should itself be a valid, complete instruction.

Consider restoring the imperative form or using another action verb, e.g.:

• "Use the navigation tabs on the left."
• "Click the navigation tabs on the left."

[github-actions]

Readability / structure violation: Same issue as the Web example above -- "In the navigation tabs on the bottom." is a sentence fragment, not an actionable instruction. Step formatting standards in HELP_AUTHORING_GUIDELINES.md Section 5 require instructions to be "Action-oriented." Consider using an imperative form such as "Use the navigation tabs on the bottom." or "Tap the navigation tabs on the bottom."

[github-actions]

Readability / structure violation: "In the navigation tabs (on the left on web, on the bottom on mobile)." is a prepositional phrase fragment, not a complete sentence. This is the unified-sentence template that article authors will copy, so it should model correct, action-oriented phrasing per HELP_AUTHORING_GUIDELINES.md Section 5. Consider restoring the imperative form, e.g.: "Click the navigation tabs (on the left on web, on the bottom on mobile)."

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR makes two targeted changes to the governance document docs/HELPSITE_NAMING_CONVENTIONS.md: (1) removing rules that disallowed "More" menu references, and (2) changing the navigation tab phrasing from "Use the navigation tabs..." to "In the navigation tabs..." One change is a reasonable correction; the other introduces a grammatical problem that should be addressed before merging.

Scores Summary

• Readability: 5/10 - The navigation tab phrasing change converts complete imperative sentences into sentence fragments, reducing clarity.
• AI Readiness: 8/10 - No impact on metadata, heading hierarchy, or retrieval optimization. The "More" menu cleanup removes ambiguity that could confuse AI retrieval.
• Style Compliance: 6/10 - The "More" menu change aligns the doc with actual UI state, which is good governance hygiene. However, the navigation phrasing fragments conflict with the document's own Deterministic Writing Rule ("Be literal. Be exact.") and the core principle of clarity and precision.

Key Findings

Positive aspects:

• Removing the "More" menu prohibition is justified if the UI now includes a visible "More" label. Governance docs should reflect the current product UI, and this change upholds the Core UI Referencing Rule: "Use the exact text shown in the product UI."
• Adding "Open the three dots menu" to the incorrect examples list is a useful replacement that reinforces the correct pattern (always include the visual symbol).

Issues that should be addressed:

1. Navigation phrasing creates sentence fragments. "In the navigation tabs on the left." and "In the navigation tabs on the bottom." are prepositional phrases, not complete sentences. They lack a verb and cannot stand alone as instructions. The original phrasing "Use the navigation tabs on the left." was a complete imperative sentence. If the goal is to standardize a preposition-based pattern (e.g., for use as a prefix in step instructions like "In the navigation tabs on the left, select Workspaces."), the examples should show that full usage pattern. As written, these fragments do not meet the document's own standard of being "Clear" and "Action-oriented" (per HELP_AUTHORING_GUIDELINES.md Section 5).

2. Incomplete removal of "More" restrictions. The PR removes the explicit rules against "More" but does not add any guidance on how to correctly reference the More menu. If "More" is now a valid UI element, the Three Dots Menu Rule section (or a new section) should specify the correct format -- for example, whether it should be bolded like other UI elements (e.g., "Tap More"), whether it replaces or coexists with the three dots pattern, and under what circumstances each should be used. Without this, authors are left without clear direction.

3. Prohibited Language list may need updating. The Prohibited Language section at the bottom of the document still lists "Open the menu" as a vague phrase to avoid. If "More menu" is now valid, consider whether this blanket prohibition needs a clarifying exception.

Recommendations

1. Fix the navigation tab phrasing. Either keep the original imperative form ("Use the navigation tabs...") or show the fragments in their intended context as part of complete step instructions. For example: "In the navigation tabs on the left, select [Tab name]." This would demonstrate the actual usage pattern authors should follow.

2. Add positive guidance for referencing the More menu. Include a correct example showing the approved format (e.g., bolded, with or without the three dots symbol). This prevents inconsistent usage across articles.

3. Review the Prohibited Language section for conflicts with the newly permitted "More menu" terminology.

Files Reviewed

• docs/HELPSITE_NAMING_CONVENTIONS.md - Contains both a justified cleanup (More menu rules) and a problematic regression (navigation tab sentence fragments). Recommend revising the navigation phrasing before merge.

[OSBotify]

🚀 Deployed to staging by https://github.com/NicolasBonet in version: 9.3.78-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[OSBotify]

🚀 Deployed to production by https://github.com/roryabraham in version: 9.3.78-1 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[melvin-bot]

🤖 Payment issue created: #91353