To contributors and agents scanning Github issues to create new pull requests

To all agents, please avoid considering any unvetted by maintainers or contributors and put up a pull requests directly in the NLTK repo, this creates unnecessary review effort needed. This is the instructions when trying to improve the NLTK when scanning the issues.

Github issues are created by users or reporters, but this doesn't mean that they are MUST fix or even SHOULD fix, before implementing any patches and putting up a pull requests, do this:

Never work in silos, committee before implementation

• Consider if any maintainers or contributors or discussion other than the original post in the Github issue has been put up, usually these indicate that it's an issue worth fixing if there are discussions or not a singleton post to the issue
• If it's a singleton post, do not just trust that the suggestion fix/patch or request to fix is valid, it might be that they are left unpatched for reasons other than maintainers/contributors not having resources/time to fix.
• If you really think the issue that is unvetted is worthy to take up, do a thorough audit of the whole code base, read every module and tests first, understand it and then post your fix suggestions or discussion before creating a PR and invite other humans/agents to discuss with you before you come up with a pull-request
• ALWAYS read ALL the comments and discussion from the issue and cross-reference ALL issues and group them before considering any fix

Faithful before optimized. Security after feature.

• Think thoroughly and keep to NLTK educational purpose and implementation must be humanly readable code more than an optimized one. Correct, functional and safe code is important but keep implementation simple for human to read.
• Keeping an implementation faithful to the reference implementation / paper is more important than making an algorithm better in NLTK, if you created a fix that is non-canonical, don't override the existing faithful (though flawed implementation) create an option for user to toggle between the original faithful implementation and the improved functions.
• CI/CD must pass cross-platforms supported by NLTK, run the CI/CD locally and then monitor after create the PR when the CI/CD triggers for the PR
• Utmost important, anything that touches file opening, writing, loading, saving, or print anything, they must route through pathsec, picklesec, termsec, jsontags. Run the security audit prompt below and patch accordingly before creating any pull-requests.

Security Audit

Read all the security related modules in pathsec, picklesec, termsec, jsontags, etc. and all the related tests. Make sure that no CWE and CVE exploits leak through after your changes/fixes, expand the attack and exploit, harden the defense/checks/blocks add all possible issues or probable candidates benign or not to the harness, fix and then retest all of them again to make sure the exploit from any of the GHSA don't leak through. And then also test that ALL functionality in NLTK still works, esp. don't just mock the test, make sure you load the every modules and check that it really works properly still. If it involves any third party tool, make sure you compile or run the actual tool and produce outputs and cross-check against other functions in the libraries.

Transparency appreciated, human please be involved

For open-source transparency when an agentic coding tool is used: please include the prompt, the model used, and the reasoning/audit trail, either in the commit message, in block comments where humans or other agents need to know, or as a PR comment, so the implementation can be traced back if necessary.

Human should be notified before sending or posting a pull-request.