Process for Dealing with Issues

This is just a sketch of the process I go through when dealing with issues on GitHub.

This might be useful if I or others choose to automate the process using LLMs.

I will come back and update as I formalise.

1. Determine issue type – e.g. at basic “bug” or “new feature”.
2. Clarify what issue is – possibly different process for issue type.
   • Existing issue templates can be a starting point for this.
   • “Bug” = what is going wrong, when is the bug occurring etc.
   • “Feature” = what is requested, where and when and why.
3. Determine location of existing relevant code in repository.
   • Highlight functions and/or classes, together with file name and path and possibly line numbers.
   • Could we navigate a call graph generated automatically?
4. Determine if issue is to be broken down into separate subtasks that need to be performed.
5. For bugs:
   • Can you generate a test that replicates the bug?
   • Together with 3), identify the code that is causing the bug.
   • Identify a correction for the code.
   • Iterate until new test passes.
   • Check that existing tests pass; if, not evaluate failing tests and iterate.
   • Extend test suite for bug with similar edge cases.
   • Check that extended tests pass; if not, iterate until they do.
   • Check that existing tests pass; if, not evaluate failing tests and iterate.
   • Submit pull request that fixes the bug.
6. For features:
   • Determine what functionality needs to be added and where this slots in.
   • Write a failing test that provides the desired functionality.
   • Write the code to allow the test to pass.
   • Check that existing tests pass; if, not evaluate failing tests and iterate.
   • Extend test suite for feature with different examples and edge cases.
   • Check that extended tests pass; if not, iterate until they do.
   • Check that existing tests pass; if, not evaluate failing tests and iterate.
   • Submit pull request that supplies the feature.

Step 1) can be performed by an LLM that parses the initial issue message. Or by a user selecting a template when adding the issue.

Step 2) may be performed by the LLM refactoring the original issue text into a template form. Or by a user using a template on GitHub. There are lots of examples out there we can use and integrate.

Step 3) can be performed by a vector search on an indexed repository. Possibly using similar methods to IDE “Find Usages” functionality. Step 3) can report by adding additional text to the issue to be confirmed by a user.

Step 4) can be performed on all text in the issue thus far.

Steps 5) and 6) can be performed based on the classification in 1). There are certain overlaps so core logic can be shared between types. “Hard” bits can request user input.