Contribution Guidelines #11127
yossigo
announced in
Announcements
Replies: 2 comments 2 replies
-
@oranagra @yossigo There was a proposal to include a section such as:
For all changes tagged with |
Beta Was this translation helpful? Give feedback.
1 reply
-
Another question I have is related to |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This page describes the process we apply for managing issues: bug reports, fixes, improvements, feature requests, and other ideas that may end up as part of the Redis project.
Redis is an open-source, community-oriented project, so it's open for community members to contribute and influence it. There are many ways an individual can contribute:
A @redis/core-team of five members drives the Redis project following the project governance structure. Running the project is a massive undertaking, and we rely on two things to succeed:
What do Redis-contributors do
There are many forms of contribution, including:
We want to emphasize that we welcome this kind of contribution from all community members, not strictly Redis contributors.
Nominated Redis contributors have additional triage permissions, so they can perform more operations such as labeling or closing issues and pull requests.
Guidelines for Redis contributors
These guidelines are provided here mainly for contributors but can also help other non-contributor members of the community better understand our process.
General
If you're unsure about the implications or history of something, feel free to consult other contributors or the core team via a mention in GitHub or Slack. Start by
@mentioning
one person, and include others only if it becomes necessary.Most of our work is around collaboration and gets done on GitHub using issues and pull requests. Below, you can learn more about how we use the platform.
Issue Assignment
We use issue assignment in two ways:
The rules are:
Assignments should be current and up to date and relate to the near future. Because of that, we don't assign most of the work in the backlog.
Labels
We label issues and pull requests to track them quickly and efficiently and indicate what needs to be done to progress.
Filter Labels
Because we work asynchronously, a big concern involves issues falling between the cracks. Many labels denote the current state of an issue so that we can effectively filter and find it later.
We usually don't clear labels when done working or closing an issue.
The following are the primary labels we use. Some older issues may also have other labels which are now obsolete.
state:to-be-closed
state:major-decision
state:help-wanted
approval-needed
release-notes
breaking-change
interface-change
State labels
These labels indicate the current state of the issue or pull request and what needs to be done to make progress.
state:needs-design
state:needs-coding
state:needs-test-code
state:needs-testing
state:needs-review
state:needs-code-doc
state:needs-doc-pr
redis-doc
repositorystate:needs-investigation
For closed issues or pull requests, the following labels provide information about why they were closed:
status:wontfix
status:invalid
status:unreproducible
status:duplicate
Pull request's commits, top comment, and merging
We aim for the PR top comment to represent a comprehensive list of changes, implications, side effects, design consideration, refactoring and other unrelated changes, as well as any other important information that can be useful instead of reading the actual changes.
For bug fixes, it is important to state the scenario which leads to the bug, and the implication on when it happens.
We usually aim to merge PRs with a squash merge, creating one commit in the target branch, and use the PR top comment as the commit comment for the squash commit.
Because of this squash merge strategy, it is often preferred to avoid amending commits and force-pushing, and instead keep adding incremental changes as separate commits, this makes it easier to review.
There are cases where we'd like to avoid using the squash merge:
On PRs that are marked with
release-notes
, specifically ones with a lot of details and a long top comment, we would also like a section in the to comment containing a short release note statement (or statements if there are several of them)Branching and Release Strategy
Work is generally committed to the
unstable
branch, which is the base for the major or minor releases.When work on a release is ready, we fork a release branch from
unstable
and use it to create release candidates. At this time, we focus work on the upcoming release, so all commits tounstable
naturally get merged to the release branch as well.We continue to do so until we release the general availability version. After we feel the version is stable, typically after several bugfix releases, we unfreeze
unstable
, which receives commits intended for the next major or minor release.Projects
We list issues and pull requests in GitHub projects as part of work and release planning, and in order to track bugfixes that need to be backported.
Triage
x.y
x.y Backport
Backlog
Issues and pull requests are associated with a project when we plan or consider including them in a release.
New requests or ideas go through a preliminary evaluation. Quick or minor improvements are placed in the Triage project for further analysis. Larger or more complex topics are placed in Backlog or a specific release.
The Backlog project has a lot of extra information for each item, including:
To preserve this information, backlog issues that get pulled into a specific release are also left in the backlog.
Milestones
We use milestones to quickly and easily classify the possible timeframe for an issue or pull request:
Next Minor backlog
Next Major backlog
These are obsolete and will be merged into the backlog project soon.
Process overview
Bug Flow
How to help
Helping with issue handling
Is the issue labeled correctly? If not, fix the labels.
Does the issue involve a question? If you can provide an answer, go ahead and reply. If the answer is trivial and it's not likely that it will turn into a discussion, you can also apply the "to-be-closed" label, or directly close it if you're sure about it.
Does the issue describe a problem/bug report? Even if you're not going to deep dive into it yourself (e.g., no time or experience with the specific issue), consider if the issue includes all the necessary details. If not, ask the original poster to provide it.
Helping with pull request handling
Does the pull request include complete information? Does it describe the context, the problem it aims to solve, what feature it provides and for what use case, etc.? If not, ask the author to provide this information.
Perform a code review. Your code review may be valuable even if you're unfamiliar with the specific area of the code in question. Code review is an iterative process, and different emphasis is required depending on what stage it is in:
In many cases, even a partial review that results with "Concept looks good to me, did not review the code itself" is helpful.
Consider the pull request completeness and quality:
doc-needed
label.Closing issues
We aim to have the bottom comment(s) of closed issues tell the story of why the issue is closed. If that's not the case, consider adding a final note indicating the reason for closing (duplicate of another issue, fixed by another issue, etc.).
If not sure about closing an issue, use the
to-be-closed
label to indicate it should be closed after further review.Closing Duplicate Issues
Since there's no way to link issues as related or duplicate in GitHub, only link Issues to PRs, and add a cross-reference in a comment.
There are many duplicate reports, and part of our work in maintaining the repository is to sort them out.
Sometimes closing duplicates is not enough, and people often add more comments to an already closed issue.
To prevent that, we will add a bottom comment saying "This issue is closed. Please continue the discussion in issue #1234".
Beta Was this translation helpful? Give feedback.
All reactions