You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: CONTRIBUTING.md
+10-10
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
-
## Contributing to Flux
1
+
## Contributing to Branches
2
2
3
-
Thanks for your interest in improving Flux!
3
+
Thanks for your interest in improving Branches!
4
4
5
5
There are multiple opportunities to contribute at any level. It doesn't matter if you are just getting started with Rust or are the most weathered expert, we can use your help.
6
6
@@ -11,7 +11,7 @@ It should be considered as a guide to help you navigate the process.
11
11
12
12
### Code of Conduct
13
13
14
-
Flux adheres to the [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct) (even though it's not a Rust project). This code of conduct describes the _minimum_ behavior expected from all contributors.
14
+
Branches adheres to the [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct) (even though it's not a Rust project). This code of conduct describes the _minimum_ behavior expected from all contributors.
@@ -20,7 +20,7 @@ Instances of violations of the Code of Conduct can be reported by contacting the
20
20
There are fundamentally four ways an individual can contribute:
21
21
22
22
1.**By opening an issue:** For example, if you believe that you have uncovered a bug
23
-
in Flux, creating a new issue in the issue tracker is the way to report it.
23
+
in Branches, creating a new issue in the issue tracker is the way to report it.
24
24
2.**By adding context:** Providing additional context to existing issues,
25
25
such as screenshots, code snippets and helps resolve issues.
26
26
3.**By resolving issues:** Typically this is done in the form of either
@@ -55,7 +55,7 @@ If you have examples of other tools that have the feature you are requesting, pl
55
55
56
56
### Resolving an issue
57
57
58
-
Pull requests are the way concrete changes are made to the code and dependencies of Flux.
58
+
Pull requests are the way concrete changes are made to the code and dependencies of Branches.
59
59
60
60
Even tiny pull requests, like fixing wording, are greatly appreciated. Before making a large change, it is usually
61
61
a good idea to first open an issue describing the change to solicit feedback and guidance. This will increase
@@ -82,7 +82,7 @@ Keep an eye out for comments from code owners to provide guidance on conflicting
82
82
83
83
#### Reviewing pull requests
84
84
85
-
**Any Flux community member is welcome to review any pull request**.
85
+
**Any Branches community member is welcome to review any pull request**.
86
86
87
87
All contributors who choose to review and provide feedback on pull requests have a responsibility to both the project and individual making the contribution. Reviews and feedback must be helpful, insightful, and geared towards improving the contribution as opposed to simply blocking it. If there are reasons why you feel the PR should not be merged, explain what those are. Do not expect to be able to block a PR from advancing simply because you say "no" without giving an explanation. Be open to having your mind changed. Be open to working _with_ the contributor to make the pull request better.
88
88
@@ -98,8 +98,8 @@ It is tempting to micro-optimize and make everything about relative performance,
98
98
99
99
Focus first on the most significant aspects of the change:
100
100
101
-
1. Does this change make sense for Flux?
102
-
2. Does this change make Flux better, even if only incrementally?
101
+
1. Does this change make sense for Branches?
102
+
2. Does this change make Branches better, even if only incrementally?
103
103
3. Are there clear bugs or larger scale issues that need attending?
104
104
4. Are the commit messages readable and correct? If it contains a breaking change, is it clear enough?
105
105
@@ -109,15 +109,15 @@ When changes are necessary, _request_ them, do not _demand_ them, and **do not a
109
109
110
110
Specific performance optimization techniques, coding styles and conventions change over time. The first impression you give to a new contributor never does.
111
111
112
-
Nits (requests for small changes that are not essential) are fine, but try to avoid stalling the pull request. Most nits can typically be fixed by the Flux maintainers merging the pull request, but they can also be an opportunity for the contributor to learn a bit more about the project.
112
+
Nits (requests for small changes that are not essential) are fine, but try to avoid stalling the pull request. Most nits can typically be fixed by the Branches maintainers merging the pull request, but they can also be an opportunity for the contributor to learn a bit more about the project.
113
113
114
114
It is always good to clearly indicate nits when you comment, e.g.: `nit: change foo() to bar(). But this is not blocking`.
115
115
116
116
If your comments were addressed but were not folded after new commits, or if they proved to be mistaken, please, hide them with the appropriate reason to keep the conversation flow concise and relevant.
117
117
118
118
##### Be aware of the person behind the code
119
119
120
-
Be aware that _how_ you communicate requests and reviews in your feedback can have a significant impact on the success of the pull request. Yes, we may merge a particular change that makes Flux better, but the individual might just not want to have anything to do with Flux ever again. The goal is not just having good code.
120
+
Be aware that _how_ you communicate requests and reviews in your feedback can have a significant impact on the success of the pull request. Yes, we may merge a particular change that makes Branches better, but the individual might just not want to have anything to do with Branches ever again. The goal is not just having good code.
0 commit comments