Issue Prioritisation

I always try my best to ensure that each issue is prioritised fairly, and implemented as soon as possible. I average implementing four new features per week, which are released every one to two weeks.

Issues (Feature Requests / Improvements / Bugs)

Due to the volume of issues raised for Git Graph (almost all are feature requests), the following guidelines are used to prioritise issues that are raised. This is a rough guide only, as requests that benefit a larger percentage of users are given higher priority than large features that benefit a small number of users.

Priority	Issue Type	Size	More Information
1 (Highest)	Bugs	Any	Once the issue has been reproduced, we typically have a beta release fixing it available within 1 - 2 days. Depending on its impact to users, we will either do a full release immediately or wait until the next scheduled release.
2	New Git Actions	Small / Medium	Git Actions that are commonly used by many people are preferred as they extend the core capability of the extension.
3	Feature Request / Improvement	Small	If a feature request or improvement is relatively easy and quick to implement, it will be included in one of the next releases. These are implemented so that each release has multiple enhancements that benefit each user, and have features ranging from large to small in size.
3	Feature Request / Improvement	Medium	One or two medium sized features are typically included in each release.
3	Feature Request / Improvement	Large	One large feature is typically included in every second release.
4 (Lowest)	Nice To Have	Large	These issues will only be implemented if time allows, and there aren't any higher priority items waiting to be implemented.

The feature sizes are outlined in the below table:

Size	Estimated Implementation Time
Small	Less than 2 hours
Medium	Between 2 and 8 hours
Large	More than 8 hours

Pull Requests

When a pull request is raised, I review it before I do any other work on this extension. If it all looks good, or requires minimal changes, it will be merged as soon as possible. However, if the pull request will likely require more than two hours of my own implementation work, it is prioritised similarly to the issue it relates to (I have to be fair to others who have requested higher priority features).

Note: If you have a feature that you'd like to implement yourself, please raise it as a feature request before you begin working on it. I always respond as soon as possible (within a few hours during the day & evening AEST). This is so that I can give you some helpful pointers of where to start, what to look out for, etc., which ultimately makes it faster, easier, and more seamless for people new to the codebase to implement the features they'd like.

Code Improvement

Along with the issues and pull requests described above, some time is also spent each release on code improvement. I find that this is necessary to ensure that new skills and learnings outside of working issue-to-issue are applied to the rest of the codebase to ensure that it is healthy and well maintained. In the long run this has significant benefits and time savings, and more than offsets the relatively small amount time spent each release.