All very good points,I think the reason the commit messages may seem vague is because we have the issue reference in each commit so 'refactor for tab issue' will be the tabs related to tsk020 which may be in JIRA as "change layout on gallery page to be responsive" or something, so the message is within that context, again probably a weak example. I think you're also right about not having the motivation to continue updating it, it may be fine for the devs we currently have for a while but as devs come and go and time goes on it will probably end up outdated. Hmmm
Is there a reason why it needs to be its own document? Especially if you're referencing stories/tasks in git messages.
If someone wants to read the reason why there was a commit they'd check the task which was tagged tsk020 in this case. Each of the changelog items "Gallery width now dynamic", "Menu button hidden on print" could be their own task, and the commits would be prepended with tsk021, tsk022 respectively. The branch would be named something like "feature/tsk020-change-layout-on-gallery-page".
Also when I'm opening a pull request I usually list out the changes. It's useful for yourself to see if you've filled the criteria of the story and also when someone is reviewing, they know what they're looking at and looking for. We delete branches after they are merged, but the PR doesn't go anywhere if anyone wants to go back and reference the changes.
The point of the changelog would be for when a developer comes back to a project after a while they can simply view the developer changelog as a way of saying 'what do I need to do and know to get my environment working and get up to speed'.
For example, "db now hosted on AWS" may be a part of the dev changelog but won't fit in to a git history. Now I know that if I need to access the DB I login to AWS rather than the previous service.
I agree that a task based changelog would be largely redundant, I think I'm still in the process of figuring out exactly what would be in the changelog to be honest but things like the example above would be super useful to store in one single place rather than the last dev to work on the proejcts mind. I think environment/third party services changes would be the main use for this file.
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.
All very good points,I think the reason the commit messages may seem vague is because we have the issue reference in each commit so 'refactor for tab issue' will be the tabs related to tsk020 which may be in JIRA as "change layout on gallery page to be responsive" or something, so the message is within that context, again probably a weak example. I think you're also right about not having the motivation to continue updating it, it may be fine for the devs we currently have for a while but as devs come and go and time goes on it will probably end up outdated. Hmmm
Is there a reason why it needs to be its own document? Especially if you're referencing stories/tasks in git messages.
If someone wants to read the reason why there was a commit they'd check the task which was tagged tsk020 in this case. Each of the changelog items "Gallery width now dynamic", "Menu button hidden on print" could be their own task, and the commits would be prepended with tsk021, tsk022 respectively. The branch would be named something like "feature/tsk020-change-layout-on-gallery-page".
Also when I'm opening a pull request I usually list out the changes. It's useful for yourself to see if you've filled the criteria of the story and also when someone is reviewing, they know what they're looking at and looking for. We delete branches after they are merged, but the PR doesn't go anywhere if anyone wants to go back and reference the changes.
The point of the changelog would be for when a developer comes back to a project after a while they can simply view the developer changelog as a way of saying 'what do I need to do and know to get my environment working and get up to speed'.
For example, "db now hosted on AWS" may be a part of the dev changelog but won't fit in to a git history. Now I know that if I need to access the DB I login to AWS rather than the previous service.
I agree that a task based changelog would be largely redundant, I think I'm still in the process of figuring out exactly what would be in the changelog to be honest but things like the example above would be super useful to store in one single place rather than the last dev to work on the proejcts mind. I think environment/third party services changes would be the main use for this file.