Make sure to check that an issue you're planning to resolve does not already have people working on it and that there
are no PRs associated with it
In the case of simple issues, a direct PR is okay. However, if you decide to work on an existing issue which doesn't
seem trivial, **please ask us first**. This way we can try to estimate if it is a good fit for you and provide the
correct direction on how to address it.
If you'd like to propose a subjective change to one of the UI/UX aspects of the bot, or there is a bigger task you'd
like to work on, but there is no corresponding issue yet for it, **please open an issue first** to avoid wasted effort.
Aside from the above, below is a brief checklist of things to watch out when you're preparing your code changes:
- Make sure you're comfortable with the principles of object-oriented programming, the syntax of C\# and your
development environment.
- Make sure you are familiar with [git](https://git-scm.com/)
and [the pull request workflow](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests).
- Please do not make code changes via the GitHub web interface.
- Please make sure your development environment respects the .editorconfig file present in the repository. Our code
style differs from most C\# projects and is closer to something you see in Java projects.
- Please test your changes. We expect most new features and bugfixes to be tested in an environment similar to
production.
After you're done with your changes and you wish to open the PR, please observe the following recommendations:
- Please submit the pull request from
a [topic branch](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#_topic_branch) (not `master`), and
keep the *Allow edits from maintainers* check box selected, so that we can push fixes to your PR if necessary.
- Please avoid pushing untested or incomplete code.
- Please do not force-push or rebase unless we ask you to.
- Please do not merge `master` continually if there are no conflicts to resolve. We will do this for you when the change
is ready for merge.
We are highly committed to quality when it comes to Boyfriend. This means that contributions from less experienced
community members can take multiple rounds of review to get to a mergeable state. We try our utmost best to never
conflate a person with the code they authored, and to keep the discussion focused on the code at all times. Please
consider our comments and requests a learning experience.
