Update developer guidelines based on suggestions in review

Author: eteq

messages/core_write_access.md

@@ -4,7 +4,7 @@ Hello {NAME},
 
 You can see the formal description of the subpackage maintainers role at http://www.astropy.org/team.html.  But there are some other guidelines to keep in mind, which I'm describing here.  In general you should only merge PRs that are in the domain of your subpackage(s).  This is a guideline rather than a firm rule: if you see something that's straightforward and obvious (e.g., a minor typo fix that's already been approved and the tests have passed but no one hit the merge button), you should feel free to help with that sort of thing even in other packages. Similarly, in areas where there's conflict/uncertainty, it's best to defer to a more senior maintainer (if there is one) or if absolutely necessary the Coordination Committee... but in cases where there's no obvious reason to question it (particularly if the lead is the PR author), it is also fine to merge things when it seems reasonable.
 
-Relatedly, if you haven't already, you should familiarize yourself with the maintainer guidelines: https://docs.astropy.org/en/latest/development/workflow/maintainer_workflow.html.  Please respond indicating you've seen these so we're sure you're aware of them.
+Relatedly, if you haven't already, you should familiarize yourself with the developer guidelines for Astropy: https://docs.astropy.org/en/latest/#developer-documentation, particularly the basic development workflow: https://docs.astropy.org/en/latest/development/workflow/development_workflow.html and the guidelines on when to squash or rebase: https://docs.astropy.org/en/latest/development/when_to_rebase.html. Please respond indicating you've seen these so we're sure you're aware of them.
 
 You should also feel free to help with labeling new PRs or issues as they come in - that's a task all of the subpackage maintainers share, since it's only people with write privileges can do.  So don't feel at all shy about labeling these, even outside your subpackage(s).