Is it OK to move CHANGELOG.md into separate issues? about katas HOT 2 OPEN

hi @jizusun sorry for answering so late, I understand the "need" and usefulness of using issues on github or even a project, I just miss their integration into the workflow, that's why i started using the CHANGELOG (I described the process and whys here). I understand that this is different to how people are used to stuff working on GH. Maybe some kinda automatic issue creation would be cool :) ... I also work offline a lot, and there I can record progress in a CHANGELOG.
Sorry if that is not a satisfying answer :(.
And a lot of thanks for your love for this project.

from katas.

I'm not sure whether I'm supposed to pull this up again, but I decided to do it since the issue is Open.

I'm finding it difficult to understand the thinking behind those single-line changelog / to-do list items.

On the other hand, I understand the need to be able to work offline; so, here's my proposal - have a description for each todo item ( Definition of Done in 2 sentences or less ) in the changelog file itself. I like the idea of 'automated issue creation', but I don't think a single line would do any good if they were converted to issues either. So having a description would help in converting to GitHub issues as well. Not having a description / definition of done would raise the barrier to entry for new contributors.

I'm currently eyeing at the Todos, Ideas, etc list. I think they can be completed with minimal to no effort. I don't get why they're in the file even. Hence, I think there's more to them than what I think.

I'm going to describe how I understood it. If there's more, please clarify ( and that also would be the case to have a description of the task somewhere, if not in the changelog file )

1. Deploy <kataname>.spec.js files too (the passing tests).
   copy all of the files under the katas directory into a new spec directory, rename the files to have the spec.js filename extension, remove all the 'katafication' comment lines.
   additionally, change all the files in the katas to the katafied tests
2. Verify that all katafied tests fail (the katafication does really create failing tests).
   This is already complete in my humble opinion. I've run the whole suite ( from the gh-pages branch ) locally and have verified that they all fail. There were some SyntaxError fixes that are fixable ( probably task 5 - Test if katafication results in invalid JS code )
3. Remove lines which only have //// and nothing beyond (I have not seen a case where I would not remove that line).
   I don't understand this one. The katafication comment line means that the next line in the file should be removed. If that indicator wasn't there, then the katafied test would pass too because the next line ( the actual solution ) was not removed. And there are many tests which start with an empty line in which the user has to fill in the whole line. Of course, we could put up some dummy lines to make it not only //// and nothing beyond.
4. Fix vulnerabilities that GH shows.
   I think GitHub can do that automatically with Dependabot. It can at least open PRs and we just need to merge them. I guess having a good CI system in place could tackle this issue.
5. Test if katafication results in invalid JS code
   I already commented on this one. If it means that the tests don't result in SyntaxErrors, then I guess I've caught most of them in the one commit that I linked above.
6. Test if every test has the katafy part in it
   I think I can just put a PR marking this task as complete because I've verified it myself. Other than TODO tests ( or tests that simply pass because they have no code inside ), all the other tests now have the katafy part; but I need to be sure whether this is what was meant by the task at all.

from katas.