Totally agree about issues in the issue tracker being lost over time. Once issues leave the kanban board I never see them again. Going back through the commit history is fine if you are looking for a specific commit or when a specific file changed but when you are just trying to catch up on anything that is actually critically relevant to how you approach a new feature it's not always clear what is actually useful and what is just noise.
I see it as not a comprehensive list of every single feature that has been completed on the project but more of a living readme.md. It's a place where a developer can go to see what technical points have changed that they may find useful. This may or may not be tied to an issue within your issue tracker.
Another few examples: - We switched to user token flow from app token flow so we get access to user endpoints, this includes adding user auth/login interface - Moved storage to AWS bucket so we don't use /storage anymore, see uploadController.php for example of how it's used - Started using Redis for session management due to load balancer being implemented
These are things which you could decipher from the commit history but this is a much more easily digestible format for only stuff that actually may require a developer to change their approach when adding features or refactoring code.
The more I think about it the more I don't think it's wise to enforce it for every feature as some features are trivial enough that they won't effect a developers approach. For instance adding a new route to a simple page may not really change a developers approach to any new features so not really necessary to go into the changelog.md
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.
Totally agree about issues in the issue tracker being lost over time. Once issues leave the kanban board I never see them again. Going back through the commit history is fine if you are looking for a specific commit or when a specific file changed but when you are just trying to catch up on anything that is actually critically relevant to how you approach a new feature it's not always clear what is actually useful and what is just noise.
I see it as not a comprehensive list of every single feature that has been completed on the project but more of a living readme.md. It's a place where a developer can go to see what technical points have changed that they may find useful. This may or may not be tied to an issue within your issue tracker.
Another few examples:
- We switched to user token flow from app token flow so we get access to user endpoints, this includes adding user auth/login interface- Moved storage to AWS bucket so we don't use /storage anymore, see uploadController.php for example of how it's used- Started using Redis for session management due to load balancer being implementedThese are things which you could decipher from the commit history but this is a much more easily digestible format for only stuff that actually may require a developer to change their approach when adding features or refactoring code.
The more I think about it the more I don't think it's wise to enforce it for every feature as some features are trivial enough that they won't effect a developers approach. For instance adding a new route to a simple page may not really change a developers approach to any new features so not really necessary to go into the changelog.md