Jeśli chcesz udzielić się w kodzie BookWyrm, to świetnie! Jeśli istnieje otwarty problem, który chcesz naprawić, możesz zamieścić komentarz do niego, tak aby niczego nie powielać. Staraj się, aby zakres próśb o scalenie był mały i skupiony na jednym temacie. Dzięki temu łatwiej będzie ją sprawdzić i sprawniej wprowadzić zmiany.
Jeśli nie masz pewności, jak coś naprawić lub nie możesz się za to zabrać, to nic nie szkodzi i wystarczy, że zamieścisz komentarz do prośby o scalenie i wspólnie znajdziemy rozwiązanie 💖.
Pull requests have to pass all the automated checks before they can be merged - this includes style checks, global linters, a security check, and unit tests.
There are several ./bw-dev commands you may find helpful for linting and testing prior to pushing your pull request. See Command Line Tool for all the options available.
We use EditorConfig to maintain consistent indenting and line endings.
BookWyrm uses ruff for both code linting (checking for errors) and formatting (ensuring code style is consistent). All new pull requests are checked with GitHub actions, and you can automatically fix code style problems by running ./bw-dev ruff. For linting errors, you can try ./bw-dev ruff-fix to automatically fix errors, though this may not always be possible.
Ruff linting warnings must be addressed before pull requests are merged, but it's a judgement call if the suggestion should be used, or the warning suppressed. See the Ruff projects's documentation on suppressing warnings using code comments.
The BookWyrm project previously used Black for formatting and Pylint for linting. You may notice artefacts such as pylint suppression comments in older code. We are still refining our linting rules so if something seems confusing or not quite right, don't hesitate to ask for advice.
We are gradually rolling out static type checking across the BookWyrm code base. This is a long term project. Whilst it is not compulsory to formally define types in new code, it is strongly recommended. This will help to avoid some more subtle bugs that may not be identified in tests.
We currently use mypy as our static type checker. Find out more about how to use mypy at the mypy project documentation.
Twoje prośby o scalenie zostaną również sprawdzone przez curlylint w poszukiwaniu szablonów Django.
Korzystamy z stylelint, do sprawdzania zasad CSS. Tak jak w przypadku Pylint możesz wyłączyć stylelint dla konkretnej zasady, ale należy mieć ku temu dobry powód.
ESLint sprawdza wszelkie wprowadzone zmiany w JavaScript. Jeśli ESLint nie będzie współpracował z Twoim kodem JavaScript, sprawdź wiadomości narzędzia po więcej informacji.
Celem BookWyrm jest jak największa otwartość i dostępność.
When contributing code, check the Inclusive Web Design Checklist before you file your pull request. For accessibility advice, A11Y-101 is also a useful source. For information on how to make your page templates multi-lingual, see the Translations section.
Niektórymi z aspektów, które współtwórcy BookWyrm uznali za przydatne do zapamiętania są:
input[type="checkbox"] lub input[type="radio"] w znaczniku <label><label>, wówczas należy go umieścić za elementem, do którego się odwołuje<button> dla czegokolwiek, co istnieje, aby wywołać instrukcję JavaScript (np. ukrywanie i pokazywanie fomrularza) lub wysyła żądanie POST (np. przesłanie formularza)<a> dla czegokolwiek, co wywołuje żądanie GET. Zazwyczaj element znacznika odnośnika (<a>) nie powinien być stylizowany jako przycisk (class="button"), ale istnieje kilka wyjątków, takich jak przyciski "Anuluj". W razie wątpliwości zapytaj o poradę w swojej prośbie o scalenieBookWyrm is an international project and aims to be inclusive of as many languages as possible. All user-facing messages and templates should follow the advice on translations and gendered language.