This is to pick up the SPEC draft scientific-python/specs#242 and scientific-python/specs#321 with the understanding that we may need to split it up into two parts if it gets too long, one for changelog best practices and the other about release docs.
We need to be mindful that what we come up with will make sense for small tools and big libraries, too, and should avoid picking tools as holy grails and it should focus on the principles of what type of content the changelog should have for what audience (e.g. towncrier works really well for big libraries but it is really an overkill for tiny pytest plugins vs the maintainer writing up a changelog docs may works for the latter and no chance to be remotely sustainable for a multi person and somewhat active library).
This is to pick up the SPEC draft scientific-python/specs#242 and scientific-python/specs#321 with the understanding that we may need to split it up into two parts if it gets too long, one for changelog best practices and the other about release docs.
We need to be mindful that what we come up with will make sense for small tools and big libraries, too, and should avoid picking tools as holy grails and it should focus on the principles of what type of content the changelog should have for what audience (e.g. towncrier works really well for big libraries but it is really an overkill for tiny pytest plugins vs the maintainer writing up a changelog docs may works for the latter and no chance to be remotely sustainable for a multi person and somewhat active library).