Documentation: Cleanup: Update and streamline readme, contributing, and security#481
Documentation: Cleanup: Update and streamline readme, contributing, and security#481inkarkat wants to merge 13 commits into
Conversation
- Remove Stack Overflow; there are no questions tagged "todotxt" at all, and the platform is used much less for such things today - Nobody reaches out to Twitter for support; it's more an outlet for official announcements - GitHub Discussions and Issues are our two main venues for support; add descriptions to distinguish their purposes - Repeat Gitter link under community; there's still a surprising amount of subscribers and activity there, given the overall state of the project - Add Reddit link; found that on Gitter as somehow had revived it
…ing" As they are closely related.
…ort" The "add" example should be enough to be an idea of how this works. "replace" and "report" aren't very common nor interesting, and the contents are just duplicated from the usage page, anyway.
A link to the GitHub org doesn't provide any useful information here.
The Stack Overflow tag hasn't been used at all.
…core vs. add-ons There are no classes in Bash. However, the distinction between core functionality in the `todo.sh` script and extensions provided by add-ons is important. There have been many PRs that offered new commands that we had to decline and instruct to first implement those as add-ons.
Versioning is determined by the core team, no need to state such policy here. However, the PRs should be limited to single features, so mention that instead.
Just "help wanted". Linkify those for convenience.
We have the ISSUE_TEMPLATE.md for that.
Following GitHub's conventions for setting up a security policy (under the /Security and quality\). Add a very conservative statement about supported versions; with the very low rate of changes and active maintainers, it's unlikely that we'll be able to support multiple concurrent release streams, and users probably follow the latest release, anyway (or are totally ignorant and stay on the first installed version (OMG)).
…tact We should probably enable private vulnerability reporting: https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configure-for-a-repository; only an admin can do that. Any user is then able to add a security advisory that can only be seen by maintainers; cp. https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately
There was a problem hiding this comment.
Pull request overview
Documentation cleanup to better reflect current support/community channels, reduce duplicated guidance in contribution docs, and introduce a dedicated security policy document for vulnerability reporting.
Changes:
- Added
SECURITY.mdwith supported-version guidance and vulnerability reporting instructions. - Streamlined
README.mdsupport/community sections and removed inline command examples in favor of linking toUSAGE.md. - Updated
.github/CONTRIBUTING.mdto reference the security policy and modernize contribution/support guidance.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
SECURITY.md |
Introduces a security policy and vulnerability reporting guidance. |
README.md |
Updates support/community guidance and simplifies usage documentation references. |
.github/CONTRIBUTING.md |
Removes duplicated security guidance and modernizes contribution/support instructions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
@karbassi I'm glad that you're still reacting to PRs ;-) Someone has emailed Gina and me with a security vulnerability in todo.txt-cli, and I'm gauging whether it's possible to handle this the right way™. The last release was 1½ years ago, and except for my occasional attempts to revive this project, nothing is happening here :-( In my mind, the only chance to get this going again is by adding more maintainers; this had been suggested many years ago, but nothing has happened so far: todotxt/todo.txt#80 With my limited access rights, I need someone that quickly and consistently responds; apparently, you don't have that time (e.g. approval still missing on #447, no responses on any new issues or PRs from you for a very long time). It's hard for me to justify investing some of my time when I cannot be sure whether the thing can be quickly dealt with or it just languishes like so many other things and making the project look even more derelict :-( You've promised to be more responsive and active, but let's face it, it hasn't happened in the past years, it's not gonna happen. This isn't criticism, and please don't feel bad. It's just a fact. Please bump my write access to full admin rights for todo.txt-cli so I'm not blocked any longer, maybe add those maintainers that were suggested, too; I can remove them again if they don't respond / aren't interested (which would be totally reasonable). The spec seems to be actively continued at https://github.com/too-much-todotxt/spec; maybe that guy is interested to take over the todotxt/todo.txt project. (I had suggested that already). |
Stack Overflow isn't used at all, Twitter isn't for support, GitHub Discussions should be more emphasized.
The contribution guide had information that's better referenced rather than duplicated, and some boilerplate that doesn't match the project.
GitHub has some new conventions around vulnerability reporting, so factor out a separate document.
Before submitting a pull request, please make sure the following is done:
master.If you've added code that should be tested, add tests!Ensure the test suite passes.Lint your code with ShellCheck.Have afixes #XXreference to the issue that this pull request fixes.