Skip to content

Conversation

Metadorius
Copy link
Member

No description provided.

@Metadorius Metadorius added ❓Project policy Minor Minor feature and/or fix, not a lot of changes or they are not significant labels Aug 21, 2025
Copy link

github-actions bot commented Aug 21, 2025

Nightly build for this pull request:

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

Co-authored-by: Kirill Andriiashin <[email protected]>
Copy link
Collaborator

@DeathFishAtEase DeathFishAtEase left a comment

Choose a reason for hiding this comment

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

Is this process description a 'requirement' or a 'guide'? I see that the content here, such as the repeated use of should seems more mandatory. If it is the latter, then splitting it more detailedly and explaining why each step is important would be more effective. Similarly, I think To ensure your contribution is smoothly accepted, please follow the following process: is more effective for new contributors than should try to stick to.


Generally, we should try to stick to the following process when contributing to the project:
1. Check whether there is an open pull request for whatever you want to contribute. If there is - comment on it and see if you can help with it instead of starting your own first. We hate to discard otherwise valid work just because it's a duplicate.
2. If all is clear - you should **get in touch with maintainers** of level high enough to review/merge your future PR and __talk with them about key design aspects before you even submit a contribution__. This is *especially* important for bigger and more fundamental improvements, when you're learning and when you're exploring "uncharted territories". Staying engaged in communication with the maintainers will help you to avoid unnecessary reworks later on and make sure that your contribution is aligned with how we do things. Not only that, but it also allows you to essentially get early reviews on important things and faster merges (which is especially important in light of our large amount of PRs) with higher level of confidence.
Copy link
Collaborator

Choose a reason for hiding this comment

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

  1. Here, your future PR seems ambiguous; perhaps it should be something like your upcoming PR?
  2. I see there is __bold__ writing here; why not use a consistent format?
  3. maintainers of level high enough needs a more accurate description, such as T? Maintainers or Leads.
  4. I think this paragraph is a bit too long, visually very dense and the key points are not concentrated. If it is split according to the content, it should be more helpful for reading, unless we have a detailed flowchart here.

### Contribution process

Generally, we should try to stick to the following process when contributing to the project:
1. Check whether there is an open pull request for whatever you want to contribute. If there is - comment on it and see if you can help with it instead of starting your own first. We hate to discard otherwise valid work just because it's a duplicate.
Copy link
Collaborator

Choose a reason for hiding this comment

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

For the first mention and non-abbreviated form, Pull Request might be more suitable to have the first letter capitalized.

@DeathFishAtEase DeathFishAtEase added the No Documentation Needed No documentation needed whatsoever label Sep 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Minor Minor feature and/or fix, not a lot of changes or they are not significant No Documentation Needed No documentation needed whatsoever ❓Project policy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants