Skip to content
Open
Changes from all commits
Commits
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
9 changes: 9 additions & 0 deletions docs/Contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,15 @@ What can make any PR more controversial and requiring a higher level maintainer'
- Mixing contribution types
- Current level of maintainers not being sure about whether they can judge this PR

### 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.

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.

- Currently the Phobos channel on Discord is the best place to brainstorm things like that, as it's the most accessible place to reach out to maintainers and discuss your ideas (or if there's nobody around - try messaging experienced maintainers privately). GitHub issues, discussions and draft PRs (with not a lot of work done yet) are also a good place to discuss things, but they are not as fast as Discord and are better used for persistent storage of info.
- It's also a good thing to get opinions of multiple maintainers and not always consult specific one or a separate part of them. We should try to stay interconnected with each other, even if initially divided by language or habitually.
3. When we all have a clear idea of the plan you have in mind - all that is left to do is to finalize the design and implementation in the PR, and we'll review the minor things left and merge it.

### Project structure

Assuming you've successfully cloned and built the project before getting here, you should end up with the following project structure:
Expand Down
Loading