changelog management

first off, thanks for all the effort you put into these and other tools that you maintain. even when there are some pain points, the value i get from your efforts earns a lot of latitude, but i also really appreciate your willingness to discuss opportunities for improvement.

based on [your comment from another thread](https://github.com/airbnb/enzyme/issues/2011#issuecomment-499179188), i'm willing to at least get the issue opened so it can be discussed. my feelings aren't too strong, but maybe my thoughts could be helpful.

> I hate monorepos, but it's what makes the most sense for this project.

i'm with you in the distaste for monorepos, at least from the perspective of a consumer. however, i can understand when there are efficiencies gained on the maintenance side. with the effort put in by a maintainer, an efficiency win seems fair even when there are some minor trade-offs that impact consumers.

i mostly spoke up in this case only because of the changelog case. i see that as one of two pain points that i run into consistently with monorepos. the other is the difficulty to file an issue that is for a specific package, which is sometimes outweighed by the simplified ability to file an issue that is not specific to a single package.

i think the pain point for the changelog is mostly noticable because it is approached so differently across various monorepos. if there was a more consistent convention, it may be far less of an issue.

**Describe the solution you'd like**

From a consistency standpoint, my vote goes toward advertising the details in github release notes. part of this lean is because i'm a heavy greenkeeper user and at least for non-monorepo packages, they are able to show the release notes directly in the PR. this is not handled as well for monorepos, but seems likely to improve.

if i don't find release notes in the greenkeeper PR, i follow the link to the project and check for a release first, in case notes were added that missed timing for inclusion in the PR notes. since this project does still tag the individual releases, would including the notes there be difficult to add?

**Describe alternatives you've considered**

the `CHANGELOG.md` is the next place i tend to look. if there is one in the root of the monorepo, i check there first. root changelogs can get pretty noisy for projects with lots of packages/releases though.

i've seen some projects include a separate `CHANGELOG.md` in the directory of each package, but i could see that being difficult to maintain and it's not always obvious to look for them.

after the changelog, i go back to the releases tab and use the [changelog enhancement added by refined github](https://user-images.githubusercontent.com/1402241/57081611-ad4a7180-6d27-11e9-9cb6-c54ec1ac18bb.png), which then means looking for the details through individual (filtered, at least) commits. it's only after this that i consider digging deeper into the details included in the individual commit bodies.

**Additional context**

i maintain all of my packages as individual repos, so i do not have experience with `lerna` or alternative monorepo tools and don't know much detail about the automation available from them.

also, thank you for versioning each package individually rather than syncing the versions across all of the packages :)