Skip to content

adding saved replies to development guide, under triage #23109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions doc/devel/git_workflows.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@

.. _git_workflows:

Git workflows
=============

When reviewing contributions, we sometime refer to this page to offer more detailed git workflows.

.. _git_rebase:

Rebase
^^^^^^

If you want to rebase, the first thing to do is to squash all your commits into one, which will make the job easier.
Make sure you are in the PR branch, then to rebase do::

Comment on lines +14 to +16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you want to rebase, the first thing to do is to squash all your commits into one, which will make the job easier.
Make sure you are in the PR branch, then to rebase do::
If you want to rebase, the first thing to do is to make a backup branch::
$ git checkout my-working-branch
$ git checkout -b backup-my-working-branch
$ checkout my-working-branch
If you mess anything up, you can always get back to where you were pre-rebase by doing::
$ git checkout my-working-branch
$ git reset --hard backup-my-working-branch
Next, we suggest you squash all your commits into one, which will make the rebase easier.
Make sure you are in the PR branch, then to rebase do::

$ git rebase --interactive upstream/main


Git opens the last commits you made in our terminal editor (often it's vim) and you need to follow the instructions in
the file. Basically replace 'pick' by 'fixup' (or simply 'f') in all but the first commit (exit vim using `:wq` to
write/save and quite). Then update your main branch from upstream, change back to the PR branch and do::
Comment on lines +20 to +22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Git opens the last commits you made in our terminal editor (often it's vim) and you need to follow the instructions in
the file. Basically replace 'pick' by 'fixup' (or simply 'f') in all but the first commit (exit vim using `:wq` to
write/save and quite). Then update your main branch from upstream, change back to the PR branch and do::
Git opens the last commits you made in your editor (see `echo $EDITOR`) and you need to follow the instructions in the file. Basically replace 'pick' by 'fixup' in all but the first commit. When done, exit your editor.
Next, update your main branch from upstream::

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should be editor agnostic here, and rather refer to the environment variable that controls this behaviour in git.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought adding the exit vim clue would save a lot of people a lot of searching 😉 I saw something similar in the GitLab documentation for interactive rebase and I thought it was kind and helpful. I tried to keep it more concise and be clear it's just an example.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd hate for people to read our instructions and come away with the impression that they have to learn vi before they can master a rebase. If you want a generic vt100-compatible text editor pico/nano would be a lot more suitable for beginners who are just slavishly following our instructions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wholeheartedly agree. I don't think I implied that people need to master vim though?! At least on macs vim is the default editor, and I don't know how many beginners change it 🤷‍♀️ So likely the first time they run a rebase it would open in vim, and they might not know what to do. This means we need to add instruction for mac users to change the .bash_profile before they run rebase to nano to change their default, and/or a hint on how to exit vim. I am not sure what's the common default editor on windows and linux.


$ git rebase main

Comment on lines +24 to +25
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
$ git rebase main
$ git fetch upstream
$ git rebase upstream/main


and if there are problems, do ``$ git status`` to see which files need fixing, then edit the files to fix up any
conflicts (sections marked by "<<<") . When you are done with that::

$ git add <the fixed files>
$ git rebase --continue
$ git push --force-with-lease origin HEAD

If you have any problems, feel free to ask questions.

PS.
If at any point anything goes wrong, and you don't know what to do, just do::

$ git rebase --abort

and everything will go back to the way it was in the before ``$ git rebase`` times, and you can come back to your PR,
or to `gitter`_, and ask us for help, or that we do the rebase for you 😉.
Comment on lines +32 to +42
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
$ git push --force-with-lease origin HEAD
If you have any problems, feel free to ask questions.
PS.
If at any point anything goes wrong, and you don't know what to do, just do::
$ git rebase --abort
and everything will go back to the way it was in the before ``$ git rebase`` times, and you can come back to your PR,
or to `gitter`_, and ask us for help, or that we do the rebase for you 😉.
If at any point anything goes wrong, and you don't know what to do, just do::
$ git rebase --abort
and everything will go back to the way it was in the before ``$ git rebase``, and you can come back to your PR,
or to `gitter`_, and ask us for help, or that we do the rebase for you 😉.
If you finish the rebase, but it is _still_ wrong, you can still get back to your backup branch, as noted above.
When you think your PR has the right commits (look at `git log`) based on the latest upstream/main you can push to GitHub::
$ git push --force-with-lease origin my-working-branch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the addition of the backup! 🙇‍♀️ I used a backup tag so far to revert. Probably the branch strategy is less stressful and I should use that too 😃


.. _gitter: https://gitter.im/matplotlib/matplotlib
53 changes: 53 additions & 0 deletions doc/devel/saved_replies.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@

.. _saved_replies:

Saved replies
=============

To consistently maintain respectful and welcoming communication, reduce potential bias and errors, consistently provide
relevant information, and to avoid repitition, we decided to create a collection of saved replies for recurring project
needs. As a an active Matplotlib contributor, consider storing some of these responses in your GitHub account’s
`saved replies`_ as they might prove useful while reviewing issues and PRs, and otherwise supporting other community
members. Some of the suggested saved replies can be long and detailed. This is because we aim to offer support without
assuming the level of experience, or the intent the community member we are addressing might have. There is still room
to tweak and personalize your message if, for instance, some parts are redundant, require further information, or to
offer further support. Using these replies is optional.

.. _saved replies: https://github.com/settings/replies/

Issues
------

Coming soon 😉

Pull Requests
-------------

First Pull Request Merged
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking: Could we have a bot write that message or is that too impersonal? We already have an automated welcome message (as you can see in this PR 😄).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would rather do them myself while I can manage the load. I would need to set up getting notifications for new PRs being merged. But I will consider it if it becomes unmanageable ☺️. It's between UX and building relationships, and feasibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a slight preference for a human doing this. We do not have such a huge influx of new contributors and I think it does help build the inter-personal relationship.

^^^^^^^^^^^^^^^^^^^^^^^^^

.. code-block:: md

Hi-five ✋ on merging your first pull request to Matplotlib, @username! We hope you stick around and invite you to
continue to take an active part in Matplotlib! Your choices aren’t limited to programming 😉 – you can review pull
requests, help us stay on top of new and old issues, develop educational material, refresh our documentation, work
on our website, and so much more! For more info, check out: https://matplotlib.org/devdocs/devel/index

Did you know we have a monthly meeting 👥 for new contributors and a weekly meeting for the maintainers,
everyone is welcome to join both? You can find out more about our regular project meetings in this
[calendar page](https://scientific-python.org/calendars/).

Also, consider joining our [developer mailing list](https://mail.python.org/mailman/listinfo/matplotlib-devel) ✉️.
This is a great way to connect with other people in our community and be part of important conversations that
affect the development of Matplotlib.

Rebase
^^^^^^
.. code-block:: md

Hi, it looks your code needs to be rebased to include changes that have since occurred in the main repository. Would
you like to do this yourself, or would you like us to do this for you? I’m asking because a rebase can get a bit
fiddly and not everyone likes doing them 😉

We documented [the rebase process here](https://matplotlib.org/devdocs/devel/git_workflows#rebase.html) Have a look and
let me know how you'd like to proceed.
13 changes: 13 additions & 0 deletions doc/devel/triage.rst
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,19 @@ If you do not have enough GitHub permissions do something (e.g. add a
label, close an issue), please leave a comment tagging
``@matplotlib/triageteam`` with your recommendations!

Follow the saved replies guide for detailed instructions on how to
use and contribute to our communication repository. The git workflows has a few detailed workflows which we often link
to while reviewing code.
=======
use and contribute to our communication repository.

.. toctree::
:maxdepth: 2

saved_replies.rst
git_workflows.rst


Working on issues to improve them
---------------------------------

Expand Down