fix typos and update post

Author: lauragift21

_posts/2024-05-13-april-rubygems-updates.md

@@ -15,7 +15,7 @@ Some other important accomplishments from the team this month include:
 
 - [Avoid Writing Credentials to Lockfiles](https://github.com/rubygems/rubygems/pull/7560): In an effort to enhance security and prevent users from accidentally sharing credentials publicly, we recommend that you do not embed credentials in lockfiles. This practice was already uncommon, except in instances where users included credentials directly in their Gemfile—a method we do not recommend. Instead, it's advisable to utilize settings. Despite some users opting to use an ENV variable, we consistently ensure that credentials are not stored in the lockfile but are sourced either from the configuration or directly from the Gemfile.
 
-- [Make `bundle updare specifix_gems` Smarter](https://github.com/rubygems/rubygems/pull/7558): For years, reports have indicated that `bundle update gem` does not consistently update the gem to its latest available version. Users find that if they delete their lockfile, specify the desired version in the Gemfile, or run `bundle install`, the gem updates as expected. Ideally, such steps shouldn't be necessary for updating a gem—`bundle update gem` should suffice. This is also why dependency bots like Dependabot sometimes fail to create PRs to address security alerts.  The challenge is that upgrading one gem may require upgrading others to prevent version conflicts. `bundle update gem` currently lacks the capability to handle this complexity. To address this, I implemented a fix where a full `bundle update` is first executed to determine the latest resolvable versions, followed by a targeted update that forces these versions, allowing the resolver to manage any conflicts by unlocking conflicting dependencies.
+- [Make `bundle update specific_gems` Smarter](https://github.com/rubygems/rubygems/pull/7558): For years, reports have indicated that `bundle update gem` does not consistently update the gem to its latest available version. Users find that if they delete their lockfile, specify the desired version in the Gemfile, or run `bundle install`, the gem updates as expected. Ideally, such steps shouldn't be necessary for updating a gem—`bundle update gem` should suffice. This is also why dependency bots like Dependabot sometimes fail to create PRs to address security alerts.  The challenge is that upgrading one gem may require upgrading others to prevent version conflicts. `bundle update gem` currently lacks the capability to handle this complexity. To address this, I implemented a fix where a full `bundle update` is first executed to determine the latest resolvable versions, followed by a targeted update that forces these versions, allowing the resolver to manage any conflicts by unlocking conflicting dependencies.
 
 - [Resolved Musl Platform Issues for RubyGems and Bundler](https://github.com/rubygems/rubygems/pull/7583): Since introducing support for the musl platform, there's been different issues and regressions with it, leading to hesitancy among gem authors about releasing musl variants. The maintainer of Nokogiri has been actively identifying these issues, including a critical problem he believes to be the last barrier to fully supporting musl precompiled gems. Addressing this issue seemed necessary. The non-transitivity of `Gem::Platform#===` with musl was causing missing platforms in the lockfile, leading to resolution errors. The issue has been resolved by specifically accommodating the unique aspects of musl when removing invalid platforms from the lockfile.
 
@@ -28,10 +28,10 @@ The updates made this month to RubyGems.org reflect a strong commitment to impro
 
 The following are highlights of what the team worked on this month:
 
-- [RubyGems Jank Limits](https://github.com/rubygems/rubygems.org/pull/4631):  To reduce the likelihood of disruption caused by a left-pad-like package removal, we've introduced limits on deleting old or highly downloaded gems. Gem deletions are now primarily for immediate fixes of newly released but broken gems, where reverting is the best solution. For other issues, the recommended approach is to release a new version. We've set a provisional limit on gems that can be yanked without a public review to avoid premature exposure. This policy affects gems with over 100,000 downloads or those older than 30 days, aligning more closely with other ecosystems that restrict deletions. We will adjust the policy based on feedback and continue to coordinate yank requests through RubyGems staff, balancing the needs of maintainers and the wider community.
-
 - [Re-introducting Avatars to RubyGems.org](https://github.com/rubygems/rubygems.org/pull/4599):  Originally, profile images were removed from RubyGems.org due to privacy concerns, as Gravatar's system exposing user emails, leading to complaints. This change, however, made the site appear anonymous, diminishing the perceived trustworthiness of gem info pages. To address this issue, [@segiddins](https://github.com/segiddins) has developed a solution that allows images to be safely displayed without compromising privacy. This new method proxies images through RubyGems.org, maintaining user privacy while enhancing the visual appeal and trust of the platform.
 
+- [RubyGems Yank Limits](https://github.com/rubygems/rubygems.org/pull/4631):  To reduce the likelihood of disruption caused by a left-pad-like package removal, we've introduced limits on deleting old or highly downloaded gems. Gem deletions are now primarily for immediate fixes of newly released but broken gems, where reverting is the best solution. For other issues, the recommended approach is to release a new version. We've set a provisional limit on gems that can be yanked without a public review to avoid premature exposure. This policy affects gems with over 100,000 downloads or those older than 30 days, aligning more closely with other ecosystems that restrict deletions. We will adjust the policy based on feedback and continue to coordinate yank requests through RubyGems staff, balancing the needs of maintainers and the wider community.
+
 - [Upgraded Search System from OpenSearch v1 to v2](https://github.com/rubygems/rubygems.org/pull/4613): The upgrade from OpenSearch v1 to v2 allows us to benefit from new updates, features, and enhancements. Additionally, the introduction of High Availability ensures that our search functionality will remain operational even if an AWS Availability Zone(Data Center) goes offline, providing a robust and resilient service.
 
 In April, RubyGems.org gained [82 new commits](https://github.com/rubygems/rubygems.org/compare/master@%7B2024-4-01%7D...master@%7B2024-4-31%7D) contributed by 10 authors. There were 1,111 additions and 761 deletions across 150 files.