Update release documentation based on review comments from v0.4.0 #1346
Conversation
maxrjones
added
documentation
seisman
added
the
final review call
weiji14
left a comment
weiji14
left a comment
There was a problem hiding this comment.
Thanks Meghan for doing a post-release review of PyGMT's release processes! Just one broken link to fix and a suggestion on the forum post announcement part.
doc/maintenance.md
Outdated
| modules, gallery examples, API docs changes) and entries within each group | ||
| are alphabetical. | ||
| 6. Move a few important items from the main sections to the highlights section. | ||
| 5. Edit the list of people who contributed to the release, linking to their |
There was a problem hiding this comment.
See #1341 (comment):
How do I know whether any of the current order reflects a case-by-case basis or whether I should update based on
git shortlog -sne?See previous discussion at #1047 (comment). Will leave it up to you to take a first stab at the order :) Just to clarify, that line refers to the Zenodo citation order. The release note authors order should go strictly by
git shortlog(and remove the bots).OK, I guess I wasn't paying good attention for that release :) Thanks for the note.
Just on the author list, this is the order from
git shortlog -sneon the master branch (truncated to be for authors with >2 commits, and I've merged the counts for people using different emails). Note that the counts don't reflect co-authored commits properly, and should be taken as a rough guide:
Shall we also explicitly indicate that we should try to reflect co-authored commits?
There was a problem hiding this comment.
I am glad to add something about review efforts and team programming, but I would prefer to not base this off co-authored commits. The co-authored commits method seems flawed to me because a review comment that leads to a local commit by the PR author can be equally or more helpful that suggestions that are committed on the GitHub interface and this method does not value a thorough review that does not lead to any comments.
I learned recently that you can manually add co-authors to your local commits that are recognized by GitHub by putting Co-authored-by: Name <[email protected]> but since this is not in the contributing guide not everyone is probably aware of the option, plus it is time consuming and easy to forget.
There was a problem hiding this comment.
Please see if you are OK with the changes in ff27ac5
There was a problem hiding this comment.
Please see if you are OK with the changes in ff27ac5
I didn't mean the authorship on Zenodo archives, which is okay to me. I mean to reflect co-authors in the release note, i.e., changelog. For example, a team of four contributors contributes to a PR, but only one owns the commit. Does this case exist? If no, please forget this comment.
There was a problem hiding this comment.
I mean to reflect co-authors in the release note, i.e., changelog.
I don't think there is an easy way to automatically list "co-authors" in the changelog.
There was a problem hiding this comment.
I tried in #1341 (comment) using git log --format="%(trailers:key=Co-authored-by)" to get co-author names, but 1) the output is long and messy and 2) it doesn't give counts. Maybe we could find a better way?
There was a problem hiding this comment.
All the changes look good to me. We might find a better way to get co-authors' names later.
michaelgrund
left a comment
michaelgrund
left a comment
There was a problem hiding this comment.
After fixing the proposed changes, this PR looks good to me!
Co-authored-by: Wei Ji <[email protected]> Co-authored-by: Yao Jiayuan <[email protected]> Co-authored-by: Dongdong Tian <[email protected]>
|
@meghanrjones I think this PR is now ready for merge. |
seisman
removed
the
final review call
…nericMappingTools#1346) Update release_checklist.md, AUTHORSHIP.md, and maintenance.md Co-authored-by: Wei Ji <[email protected]> Co-authored-by: Yao Jiayuan <[email protected]> Co-authored-by: Dongdong Tian <[email protected]>
Description of proposed changes
Adds some information based on comments raised during the release process for v0.4.0.
Fixes #
Reminders
make formatandmake checkto make sure the code follows the style guide.doc/api/index.rst.Slash Commands
You can write slash commands (
/command) in the first line of a comment to performspecific operations. Supported slash commands are:
/format: automatically format and lint the code/test-gmt-dev: run full tests on the latest GMT development version