Activity

1. stdlib-bot

   added

   Good First IssueA good first issue for new contributors!A good first issue for new contributors!

   on Jan 1, 2026
2. stdlib-bot

   added a parent issue on Jan 1, 2026

   • Tracking issue: Fix broken links in Markdown files #9112
3. stdlib-bot commented on Jan 1, 2026

   

   stdlib-bot

   on Jan 1, 2026

   ContributorAuthor

   More actions

   👋 Important: PLEASE READ 👋

   This issue has been labeled as a good first issue and is available for anyone to work on.

   If this is your first time contributing to an open source project, some aspects of the development process may seem unusual, arcane, or some combination of both.

   1. You cannot "claim" issues. People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
   2. We have a very high bar for contributions. We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.

   Before working on this issue and opening a pull request, please read the project's contributing guidelines. These guidelines and the associated development guide provide important information, including links to stdlib's Code of Conduct, license policy, and steps for setting up your local development environment.

   To reiterate, we strongly encourage you to refer to our contributing guides before beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.

   Setting up your local development environment is a critical first step, as doing so ensures that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. If you would prefer to avoid manual setup, we provide pre-configured development containers for use locally or in GitHub Codespaces.

   We place a high value on consistency throughout the stdlib codebase. We encourage you to closely examine other packages in stdlib and attempt to emulate the practices and conventions found therein.

   • If you are attempting to contribute a new package, sometimes the best approach is to simply copy the contents of an existing package and then modify the minimum amount necessary to implement the feature (e.g., changing descriptions, parameter names, and implementation).
   • If you are contributing tests, find a package implementing a similar feature and emulate the tests of that package.
   • If you are updating documentation, examine several similar packages and emulate the content, style, and prose of those packages.

   In short, the more effort you put in to ensure that your contribution looks and feels like stdlib—including variables names, bracket spacing, line breaks, etc—the more likely that your contribution will be reviewed and ultimately accepted. We encourage you to closely study the codebase before beginning work on this issue.

   ✨ Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions. ✨
4. Tejasvini595

   added a commit that references this issue on Jan 1, 2026

   docs: fix broken Markdown link

   ...

   This issue will close once commit 1bb4d14 is merged into the 'develop' branch.

   1bb4d14
5. SuYaSh-PaThAk04 commented on Jan 1, 2026

   

   SuYaSh-PaThAk04

   on Jan 1, 2026

   Contributor

   More actions

   I’ve opened a pull request that fixes this broken link by replacing the unreachable Harvard Library URL (returning HTTP 500) with a stable Wayback Machine archive.

   I verified that the original resource has been archived multiple times between 2019 and 2025 and selected an early snapshot to preserve the original reference while ensuring long-term accessibility.

   This approach maintains the intent of the documentation without introducing alternative or secondary sources, and resolves the link checker failure.
6. vaaibhavkaushik commented on Jan 1, 2026

   

   vaaibhavkaushik

   on Jan 1, 2026

   More actions

   Hi, I'd like to work on this issue!
   Please assign this issue to me. Let me know if there are any additional considerations. Thanks! 😊
7. batpigandme commented on Jan 1, 2026

   

   batpigandme

   on Jan 1, 2026

   Member

   More actions

   Hi @vaaibhavkaushik, we don’t assign issues, and it looks like @shubham220420 has an open PR fixing this one.
8. SuYaSh-PaThAk04 commented on Jan 1, 2026

   

   SuYaSh-PaThAk04

   on Jan 1, 2026

   Contributor

   More actions

   Hi @vaaibhavkaushik, we don’t assign issues, and it looks like @shubham220420 has an open PR fixing this one.

   Hey @batpigandme I think I have opened a PR before please check on #9477

   👍React with 👍1Reacted by Mara Averick
9. batpigandme commented on Jan 1, 2026

   

   batpigandme

   on Jan 1, 2026

   Member

   More actions

   @SuYaSh-PaThAk04, looks like you did! Athan or Philipp will do the review on this one. Buy summary point was just that @vaaibhavkaushik should probably work on something else! 🙂
10. batpigandme commented on Jan 1, 2026

    

    batpigandme

    on Jan 1, 2026

    Member

    More actions

    Oh, @SuYaSh-PaThAk04, see the comment on your PR #9477 (comment) and our Contributing docs. You do need to make a new branch on Git for the PR. We don’t commit directly to develop.
11. SuYaSh-PaThAk04 commented on Jan 2, 2026

    

    SuYaSh-PaThAk04

    on Jan 2, 2026

    Last edited by SuYaSh-PaThAk04

    Contributor

    More actions

    Oh, @SuYaSh-PaThAk04, see the comment on your PR #9477 (comment) and our Contributing docs. You do need to make a new branch on Git for the PR. We don’t commit directly to develop.

    Hey @batpigandme I have opened a separate PR #9493 this time from branch not from develop . Please see this and guide me for any further changes .
12. kgryte

    closed this as completedin #9493on Jan 3, 2026
13. kgryte

    added a commit that references this issue on Jan 3, 2026

    docs: fix broken Markdown link

    ...

    33ce408