This is an automated email from the ASF dual-hosted git repository.
fanningpj pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-pekko.git
The following commit(s) were added to refs/heads/main by this push:
new 6594ccd3d3 Fix link targets and minor wording (#113)
6594ccd3d3 is described below
commit 6594ccd3d344262795e0a2dfc5eaa5d365a32a43
Author: Keith Wansbrough <[email protected]>
AuthorDate: Tue Jan 17 22:09:16 2023 +0000
Fix link targets and minor wording (#113)
---
CONTRIBUTING.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 09cc9ad9d2..6f6ec623a5 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -63,13 +63,13 @@ The steps below describe how to get a patch into the main
development branch (`m
The steps are exactly the same for everyone involved in the project, including
the core team and first-time contributors.
1. To avoid duplicated effort, it might be good to check the [issue
tracker](https://github.com/apache/incubator-pekko/issues) and [existing pull
requests](https://github.com/apache/incubator-pekko/pulls) for existing work.
- - If there is no ticket yet, feel free to [create
one](https://github.com/apache/incubator-pekko/issues/new) to discuss the
problem and the approach you want to take to solve it.
-1. [Fork the
project](https://github.com/apache/incubator-pekko#fork-destination-box) on
GitHub. You'll need to create a feature-branch for your work on your fork, as
this way you'll be able to submit a pull request against the mainline Pekko.
+ - If there is no ticket yet, feel free to [create
one](https://github.com/apache/incubator-pekko/issues/new/choose) to discuss
the problem and the approach you want to take to solve it.
+1. [Fork the project](https://github.com/apache/incubator-pekko/fork) on
GitHub. You'll need to create a feature-branch for your work on your fork, as
this way you'll be able to submit a pull request against the mainline Pekko.
1. Create a branch on your fork and work on the feature. For example: `git
checkout -b custom-headers-akka-http`
- Please make sure to follow the general quality guidelines (specified
below) when developing your patch.
- Please write additional tests covering your feature and adjust existing
ones if needed before submitting your pull request. The `validatePullRequest`
sbt task ([explained below](#the-validatepullrequest-task)) may come in handy
to verify your changes are correct.
- Use the `verifyCodeStyle` sbt task to ensure your code is properly
formatted and includes the proper copyright headers.
-1. Once your feature is complete, prepare the commit following our [Creating
Commits And Writing Commit
Messages](#creating-commits-and-writing-commit-messages). For example, a good
commit message would be: `Adding compression support for Manifests #22222`
(note the reference to the ticket it aimed to resolve).
+1. Once your feature is complete, prepare the commit following our guide
[Creating Commits And Writing Commit
Messages](#creating-commits-and-writing-commit-messages). For example, a good
commit message would be: `Adding compression support for Manifests #22222`
(note the reference to the ticket it aimed to resolve).
1. If it's a new feature or a change of behavior, document it on the
[docs](https://github.com/apache/incubator-pekko/tree/main/docs). When the
feature touches Scala and Java DSL, document both the Scala and Java APIs.
1. Now it's finally time to [submit the pull
request](https://help.github.com/articles/using-pull-requests)!
- Please make sure to include a reference to the issue you're solving *in
the comment* for the Pull Request, as this will cause the PR to be linked
properly with the issue. Examples of good phrases for this are: "Resolves
#1234" or "Refs #1234".
@@ -81,7 +81,7 @@ The steps are exactly the same for everyone involved in the
project, including t
- In general, a PR is expected to get 2 approvals from the team before it
is merged. If the PR is trivial or under exceptional circumstances (such as
most of the core team being on vacation, a PR was very thoroughly
reviewed/tested and surely is correct), a single LGTM may be fine as well.
1. If the code change needs to be applied to other branches as well (for
example, a bugfix needing to be backported to a previous version), one of the
team members will either ask you to submit a PR with the same commits to the
old branch or will do this for you.
- Follow the [backporting steps](#backporting) below.
-1. Once everything is said and done, your pull request gets merged :tada: Your
feature will be available with the next "earliest" release milestone (i.e. if
backported so that it will be in release x.y.z, find the relevant milestone for
that release). Of course, you will be given credit for the fix in the release
stats during the release's announcement. You've made it!
+1. Once everything is said and done, your pull request gets merged :tada:!
Your feature will be available with the next "earliest" release milestone (i.e.
if backported so that it will be in release x.y.z, find the relevant milestone
for that release). Of course, you will be given credit for the fix in the
release stats during the release's announcement. You've made it!
The TL;DR; of the above very precise workflow version is:
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
