For something I'm actively working on: a text file with a todo list inside it, usually added to .gitignore so that I can burn through a bunch of them quickly.
For something more long-term, ie I periodically work on it: Github issues, their primary role is to summarize the issue and include a code sample that either reproduces the bug or demonstrates what it would look like to use the feature. Their secondary role is to aggregate information, ie if I've done a bunch of research into a bug, they walk through everything I did and summarize what my conclusions were, that way I can re-read it instead of having to reinvest the effort to figure out the issue.
I also use tests for this, eg if I'm starting a project, I'll write out the names of all the tests I want it to pass, here is an example: github.com/JoshCheek/an-editor/blo... Sometimes I start by writing out all the tests, but usually 3-5 tests is enough, and then I can begin. The advantage of writing the test names is I left myself a description of the path I expect to go down. The advantage of writing the tests is that there is a series of existing tests that show me what I need to do to successfully go down that path. For me, writing the test names is often synonymous with figuring out what I'm doing, and if I still can't quite tell, then writing the tests takes that role. If I still can't tell what I'm doing, then I should either be testing at a higher level so that I can specify an outcome while knowing fewer details, or I should be prototyping, not testing, ie figuring out what I want.
Reading my last several commits is also a frequently useful way to get myself back into context.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For something I'm actively working on: a text file with a todo list inside it, usually added to .gitignore so that I can burn through a bunch of them quickly.
For something more long-term, ie I periodically work on it: Github issues, their primary role is to summarize the issue and include a code sample that either reproduces the bug or demonstrates what it would look like to use the feature. Their secondary role is to aggregate information, ie if I've done a bunch of research into a bug, they walk through everything I did and summarize what my conclusions were, that way I can re-read it instead of having to reinvest the effort to figure out the issue.
I also use tests for this, eg if I'm starting a project, I'll write out the names of all the tests I want it to pass, here is an example: github.com/JoshCheek/an-editor/blo... Sometimes I start by writing out all the tests, but usually 3-5 tests is enough, and then I can begin. The advantage of writing the test names is I left myself a description of the path I expect to go down. The advantage of writing the tests is that there is a series of existing tests that show me what I need to do to successfully go down that path. For me, writing the test names is often synonymous with figuring out what I'm doing, and if I still can't quite tell, then writing the tests takes that role. If I still can't tell what I'm doing, then I should either be testing at a higher level so that I can specify an outcome while knowing fewer details, or I should be prototyping, not testing, ie figuring out what I want.
Reading my last several commits is also a frequently useful way to get myself back into context.