Update portfolio-webpage-1.md

[Dignifiedmt]

improve the lesson and explain header head and heading properly

[naomiquinones]

A lot of the changes on this page are out of scope for the original issue. I can see value in some of them, such as the addition of the "Quick answer", "Why semantics matter", and "Landmarks and sections", as reminders of what has been learned up to this point. The "Accessibility best practices" might also be good to add. However, this is a project that should be done after the initial lessons, so the only change that was really needed was the change to line 49, changing "Headers" to "Headings (h1-h6)", and possibly also line 95. Those additional sections might be a better addition to the HTML lesson, if it doesn't already have them, but again, such changes are beyond what was requested in the issue.

In the future, if you use AI generated content, please be sure to omit the conversations and prompts, and include only the relevant changes.

[naomiquinones]

I'm curious why you changed the '-' to '*'. I noticed this in your other PR but you'd made content changes there. However, there are no content changes here.

[Dignifiedmt]

Thank you for pointing that out. The change from - to * was unintentional. It happened because I edited the file using a markdown editor that automatically reformatted list markers to *. There was no functional reason for the change, and I understand now that it created unnecessary noise in the diff.
I will revert those list marker changes so the formatting matches the original file exactly.

[daaimah123]

Thank you for the context, it is useful to know your process.

However, this has not been addressed in any commits and remains present in the current final markdown formatting, please do not mark any requests for changes as resolved if they have not been addressed. Similarly, please address each individual request for change stating how and where (the commit hash referenced) you made the change. For example:

I addressed changing the * to - in 12345

[naomiquinones]

The only line that really needed to be changed was 49. However, you've changed all the "-" to "*" and added a few line breaks. Could you clarify the reason for this change?

[Dignifiedmt]

Thanks for pointing that out. The change from - to * and the added line breaks were not intentional they were automatically applied by the editor I used. I’ll revert them so the PR only includes the required change on line 49.

[daaimah123]

Thank you for stating your why. However, this has not been addressed in any commits and remains present in the current final markdown formatting, please do not mark any requests for changes as resolved if they have not been addressed. Similarly, please address each individual request for change stating how and where (the commit hash referenced) you made the change. For example:

I addressed changing the * to - in 12345

Outstanding unaddressed task: removing formatting inconsistencies and line breaks (revert to original formatting and spacing) while exclusively addressing change to line 49.

[naomiquinones]

This item is the cut-off remnant of one of the lines deleted above.

[daaimah123]

This change is irrelevant to the issue you are solving for and in fact removes context that is critical to people learning to code for the first time.

Please revert back to original content and provide the hash number in which this has been done.

[naomiquinones]

It's not clear why these lines were deleted. Please restore them.

[Dignifiedmt]

Thank you for catching that. I’ll restore the full original line and the deleted checklist items so the section is returned to its original state.

[daaimah123]

See above comment.

[daaimah123]

@Dignifiedmt Thank you for your first pass at contributing to this project. Please ensure you read the contributor guidelines for the repo's best practices, I will address several things that I am observing with this PR:

1. Your PR description is missing, each pull request generated in this project is done so with a PR template:

For example, your description should likely look like this with the edits described:

📝 Description:

Adds my name to practice/participants.md as part of the PR review practice exercise. No functional code changes.

🔂 Changes Made:

Edited practice/participants.md to append my name to the list of participants.

⚙️ Related Issue

• Issue Number: # N/A

🍏 Type of Change:

Documentation update

🎁 Acceptance Criteria

• Criterion 1: My name appears at the end of practice/participants.md.
• Criterion 2: Markdown renders correctly as a bullet item.
• Criterion 3: No other files or lines are unintentionally changed.

🧪 How to test or what to evaluate

• Open practice/participants.md.
• Scroll to the bottom and confirm a new bullet: - Chinerey Ukwu.
• Verify that only one line was added (see “Files changed” tab).
• Confirm Markdown preview shows the bullet correctly (optional).

🚀 Repo Notes (if applicable)

• Will the table of contents need to be updated? NONE
• Which other repo areas will be impacted? NONE
• Are there any full time program curriculum considerations? (i.e. day docs, links, introduction of new concepts, etc) NONE

📸 Screenshots (if applicable):

N/A (text-only change)

✅ Checklist

• I have performed a self-review of my code.
• My code follows the style guidelines of this project.
• I have commented my code where necessary.
• I have tested my code locally and verified the website is working as expected.
• (if applicable) I have added documentation in the README.
• (if applicable) I have added tests that prove my fix is effective or that my feature works.
• (if applicable) New and existing unit tests pass locally with my changes.

2. Some of your requests for changes have not been addressed in any commits and remain present in the current final markdown formatting. When addressing requests for changes it is best practice to do so in a visible and tangible way. You can do this by:

• acknowledging each request for change (i.e. feedback was marked with an emoji reaction to show its accepted).
• Provide a written response to the request for changes in one of the following ways:
  • summary comment addressing each individual request for change stating how and where (the commit hash referenced) you made the change
  • reply to each comments generated via GitHub in your generated request for change
  • share an alternative thought with explanation of why you do not wish to implement the request for change or ask any clarifying questions
• Once actively stating how you've addressed a request for change alongside referencing the hash in which the change was made, mark the comment as "resolved".

3. If you are comfortable with sharing any concerns about contributor experience level differences or language differences in your PR code review, this helps your maintainer to understand how best to support you in a way that removes the need for relying on assisted AI/ML tools to do the iterative work for you. With employing such tools rather than doing the work yourselves early in your contributor journey, you do no learn proper code review or pull request hygiene creating lower quality contributions, friction with the existing style/format/conventions of the project, or otherwise. We would like to help all that add to this project in ensuring that best practices are exercised. I am happy to have a call with translated captions for explanation of changes needed, if that could be useful as well.

4. The incoming context you are attempting to add is overshadowing the actual solution. The task at hand was to make the clear distinction between the development concepts of heading. More specifically to ensure that the contrast of head and header are provided. Please revert your changes and exclusively address the task at hand.

   We should specify to the reader that they should use HTML elements for what they are, not how they look, giving examples where possible. For example, in the Misconceptions section, we could add something like, "I'll add an h1 here in the middle of the page because I want big bold text" and explain that it should be marked up as either a paragraph or lower level heading where appropriate for the structure of the page, and that we will use CSS to change how the elements look. Additional mention could be made of how using semantically correct structure helps for accessibility.