Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Merged by Bors] - Add "how to adopt pull requests" section #6895

Closed
wants to merge 14 commits into from
Closed

[Merged by Bors] - Add "how to adopt pull requests" section #6895

Changes from 5 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
48aab46
Add "how to adopt pull requests" section
oCaioOliveira Dec 9, 2022
a49850a
Add aditional description to section How to adopt pull requests
oCaioOliveira Dec 10, 2022
d6d0b9d
Add suggestion
oCaioOliveira Dec 12, 2022
21f55b7
Best rewrite of How to adopt pull requests
oCaioOliveira Dec 12, 2022
002c62e
Add aditional description to How to adopt pull requests
oCaioOliveira Dec 12, 2022
4dd3cb8
More context to example
oCaioOliveira Dec 15, 2022
1a07dd7
Add aditional description to section How to adopt pull requests
oCaioOliveira Dec 15, 2022
106a8c3
Fix ERRORS FOUND in MARKDOWN
oCaioOliveira Dec 15, 2022
cc9b59e
Fixes ERRORS FOUND in MARKDOWN
oCaioOliveira Dec 15, 2022
b4c9de6
Fixes typos
oCaioOliveira Dec 20, 2022
8b156ad
Aditional description How to adopt pull requests
oCaioOliveira Dec 20, 2022
a0ca180
Aditional description to reason label S-Adopt-Me
oCaioOliveira Dec 22, 2022
96e0ca0
Refactored phrase on section How To Adopt PR
oCaioOliveira Dec 22, 2022
b76a123
Add suggestions of fixe wording
oCaioOliveira Dec 22, 2022
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
8 changes: 8 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -275,6 +275,14 @@ By giving feedback on this work (and related supporting work), you can help us m
Finally, if nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to message @cart for a Bevy org role to help us keep things tidy.
As discussed in [*How we're organized*](#how-were-organized), this role only requires good faith and a basic understanding of our development process.

### How to adopt pull requests

oCaioOliveira marked this conversation as resolved.
Show resolved Hide resolved
Occasionally authors of pull requests get busy or become unresponsive. This is a natural part of any open source project. To avoid blocking these efforts, these pull requests may be *adopted*, where another contributor creates a new pull request with the same content. If there is an old Pull request without the label that is without updates, comment to the organization whether it is appropriate to add the *[S-Adopt-Me](https://github.com/bevyengine/bevy/labels/S-Adopt-Me)* label, to indicate that it can be *adopted*.
Copy link
Member

@MrGVSV MrGVSV Dec 13, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

I think there's two things a person can do:

  1. As you mentioned, they can ask an org member if a given PR could use the label (this generally happens on Discord from my observations but can also happen on the PR like you described)
  2. If they want to pick it up themselves, they should likely leave a comment on the PR asking the author if they plan on returning to the PR and if they can adopt it otherwise. If the author gives permission to adopt or simply doesn't respond after some time (maybe a few days?), they may then continue to adopt the PR.

You pretty much have 1 written down here, but 2 is another thing users can do to adopt a PR (and this may sometimes even skip the labeling since at that point the PR has been adopted).

Sidenote: I know this file doesn't necessarily follow this style, but I’d recommend splitting these longer paragraphs over multiple lines (with no empty lines between). This allows markdown to still treat it as a single paragraph, but makes it easier for reviewers to leave comments on particular sentences or phrases— both for this PR and all future ones that modify these lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The 2 was resolved as you asked, can you check please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We followed your suggestion of splitting these longer paragraphs over multiple lines, but the CI / markdownlint (pull_request) accused as errors. So we needed to maintain a paragraph.

Copy link
Member

Choose a reason for hiding this comment

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

Looks like the reason for the error was because of some spacing issues. It's telling you to remove trailing spaces on lines:

- Here is a sentence. 
+ Here is a sentence.
And here is another.

It also is suggested to add blank lines between lists and code blocks:

Here is some code:
+
```
fn foo() {}
```


With this label added, it's best practice to fork the original author's branch. This ensures that they still get credit for working on it and that the commit history is retained. When the new pull request is ready, it should reference the original PR in the description. Then notify org members to close the original.

* Example: `Adopted #number-original-pull-request`
oCaioOliveira marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Not super required, but sometimes people at-mention the original author in their PR description to further give back some credit to that author. Is this something we should add here? Or is it mainly a preference thing that users can decide for themselves (and so we can exclude it from this document)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We put this part with examples just because in the description of issue (#5539) it asked for "correct way to "adopt a PR" that also preserves credit of the original authors". Do you think this part may be deleted?


### Maintaining code

Maintainers can merge uncontroversial pull requests that have at least two approvals (or at least one for trivial changes).
Expand Down