Skip to content

Conversation

@YaelSchuster
Copy link
Contributor

After reviewing the document carefully, I tackled it layer by layer. First, I fixed the obvious stuff including typos such as, "Did you no" and "Tytorial." The formatting was all over the place, especially in the frontmatter, so I cleaned that up and made sure the date format matched Microsoft's standard. The biggest issue was really the flow. Lots of important information was buried too deep and some concepts were explained twice. I moved the example query upward, where it made more sense, and smoothed out the explanations so they build on each other naturally. There were also some technical hiccups, like missing links and inconsistent formatting for code blocks, that needed fixing. I kept all the original content but made it tighter and more professional, removing overly casual phrases like "Why don't you see" or "Related stuff." The whole thing reads much better now: cleaner, clearer, and properly technical without being stuffy. Now, it's polished up to meet Microsoft's documentation standards.

Thank you for contributing to Azure Data Explorer documentation

Fill out these items before submitting your pull request:

If you are working internally at Microsoft:

  • Provide a link to an Azure DevOps Boards work item that tracks this feature/update.

  • Who is your Docs team contact? @mention them individually tag them and let them review the PR before signing off.

For internal Microsoft contributors, check off these quality control items as you go

  • 1. Check the Acrolinx report: Make sure your Acrolinx Total score is above 80 minimum (higher is better) and with no spelling issues. Acrolinx ensures we are providing consistent terminology and using an appropriate voice and tone, and helps with localization.

  • 2. Successful build with no warnings or suggestions: Review the build status to make sure all files are green (Succeeded).

  • 3. Preview the pages:: Click each Preview URL link to view the rendered HTML pages on the review.learn.microsoft.com site to check the formatting and alignment of the page. Scan the page for overall formatting, and look at the parts you edited in detail.

  • 4. Check the Table of Contents: If you are adding a new markdown file, make sure it is linked from the table of contents.

  • 5. #sign-off to request PR review and merge: Once the pull request is finalized and ready to be merged, indicate so by typing #sign-off in a new comment in the Pull Request. If you need to cancel that sign-off, type #hold-off instead. Signing off means the document can be published at any time. Note, this is a formatting and standards review, not a technical review.

Merge and publish

  • After you #sign-off, there is a separate PR Review team that will review the PR and describe any necessary feedback before merging.
  • The review team will use the comments section in the PR to provide feedback if changes are needed. Address any blocking issues and sign off again to request another review.
  • Once all feedback is resolved, you can #sign-off again. The PR Review team reviews and merges the pull request into the specified branch (usually the *main( branch or a release-branch).
  • From the main branch, the change is merged into the live branch several times a day to publish it to the public learn.microsoft.com site.

After reviewing the document carefully, I tackled it layer by layer. First, I fixed the obvious stuff including typos such as, "Did you no" and "Tytorial." The formatting was all over the place, especially in the frontmatter, so I cleaned that up and made sure the date format matched Microsoft's standard. The biggest issue was really the flow. Lots of important information was buried too deep and some concepts were explained twice. I moved the example query upward, where it made more sense, and smoothed out the explanations so they build on each other naturally. There were also some technical hiccups, like missing links and inconsistent formatting for code blocks, that needed fixing. I kept all the original content but made it tighter and more professional, removing overly casual phrases like "Why don't you see" or "Related stuff." The whole thing reads much better now: cleaner, clearer, and properly technical without being stuffy. Now, it's polished up to meet Microsoft's documentation standards.
@prmerger-automator
Copy link
Contributor

@YaelSchuster : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@learn-build-service-prod
Copy link
Contributor

Learn Build status updates of commit 3a7043f:

⚠️ Validation status: warnings

File Status Preview URL Details
data-explorer/kusto/query/assessment.md ⚠️Warning Details

data-explorer/kusto/query/assessment.md

  • Line 0, Column 0: [Warning: h1-missing - See documentation] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
  • Line 6, Column 10: [Warning: ms-date-invalid - See documentation] Invalid date format for 'ms.date': '2024-12-05'. If specified, must be a date in format M/D/YYYY, no more than 30 days from today. If you don't specify ms.date, the date will be updated automatically.

For more details, please refer to the build report.

Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.

For any questions, please:

@ttorble
Copy link
Contributor

ttorble commented Dec 5, 2024

Hi @YaelSchuster - This pull request was opened in the public repo. Microsoft authors and contributors should work in the private repo, per the Microsoft Docs contributor guide. Would you make this content update in the private repo instead? Thank you! We'll close this PR.

@ttorble ttorble closed this Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants