Feat/recruitment process

[dawidlinek]

Zgodnie z zadaniem operacyjnym w sekcji management przygotowałem opis procedur rekrutacji oraz wdrożenia członka.

Biorąc pod uwagę zbliżającą się rekrutację mamy idealny moment na dopracowanie tych procesów, więc zapraszam do dyskusji.

https://github.com/orgs/Solvro/projects/3/views/7?sliceBy%5Bvalue%5D=Management&pane=issue&itemId=95003140&issue=Solvro%7CSolvro%7C104

---

Important

Adds Rekrutacja.mdx detailing recruitment and onboarding processes for KN Solvro, including structured recruitment, headhunting, and member integration.

• New Document:
  • Adds Rekrutacja.mdx to src/content/docs/sections/Management/ detailing recruitment and onboarding processes.
• Recruitment Process:
  • Describes structured recruitment and headhunting methods.
  • Outlines steps from appointing a recruitment coordinator to retrospective analysis.
• Onboarding Process:
  • Details steps for integrating new members, including assigning mentors, communication channels, and project involvement.

^{This description was created by for 6cc4167. It will automatically update as commits are pushed.}

[czaja307]

wygląda fajnie 🔥
dorzuciłem parę uwag - zapraszam do dyskusji

[dawidlinek]

Do dodania: wdrożenie do sekcji

[dawidlinek]

Co myślicie o rozmowach rekrutacyjnych?

[MikeStork]

Co myślicie o rozmowach rekrutacyjnych?

Ja bardzo bym chciał. Dużo sie dowiaduje o osobie w rozmowie 1 : 1. Nie musimy robić czegoś wymagającego, ale takie proste poznanie osoby daje dużo zrozumienia w jakim kierunku chcą się rozwijać. Bardzo często zdarza się, że ktoś chce dołączyć do hardware'u ale robić tylko komunikacje z interfejsem użytkownika, nie wiedząc że to zadanie backendu

[Rejfi]

Co myślicie o rozmowach rekrutacyjnych?

Uważam, że jest to spoko opcja, napewno daje możliwość bardziej świadomej decyzji wybrania kandydata. Czasami taki kandydat, może okazać się dobry albo wartościwowy, a niekoniecznie w tym co nam wysłał. Pozwoli to trochę zrobić taki merge Rekrutacji/Headhunting - bo może się okazać, że osoba ma jakąś ciekawą/przydatną dla nas pasje/umiejętności i wyjdzie to na rozmowie, gdzie ma się trochę luźniejszy format i czas na pokazanie siebie.

[dawidlinek]

Co myślicie o rozmowach rekrutacyjnych?

Uważam, że jest to spoko opcja, napewno daje możliwość bardziej świadomej decyzji wybrania kandydata. Czasami taki kandydat, może okazać się dobry albo wartościwowy, a niekoniecznie w tym co nam wysłał. Pozwoli to trochę zrobić taki merge Rekrutacji/Headhunting - bo może się okazać, że osoba ma jakąś ciekawą/przydatną dla nas pasje/umiejętności i wyjdzie to na rozmowie, gdzie ma się trochę luźniejszy format i czas na pokazanie siebie.

@MikeStork odpowiadam jeśli chodzi o rozmowy rekrutacyjne. Ogólnie rozmowa z rodzicem, przewodniczącym sekcji/projektu jest planowana jako wdrożenie. To właśnie będzie moment na ustalenie ścieżki rozwoju itd.

Oczywiście można zrobić dwie rozmowy. Jedna rekrutacyjna jako 3 etap rekrutacji i potem jak ktoś już się dostał do koła to z rodzicem bardziej wdrożeniowa.

Pojawia się jeden problem. Kto te rozmowy będzie prowadził? W zeszłej rekrutacji mieliśmy ponad 120 zgłoszeń, a niestety o ile faktycznie zaangażowanie jest już większe to dalej nikt np. nie chce się zgłosić do koordynacji rekrutacji. W momencie, gdy nikt się nie zgłasza do takich rzeczy to automatycznie to spoczywa na Zarządzie, a ostatnie co Zarząd potrzebuje to jeszcze przeprowadzenie 120 rozmów w przeciągu tygodnia, no bo tez nie chcemy przeciągać rekrutacji przez kolejne tygodnie.

Jako kompromis na pewno widzę rozmowy do sekcji typu management, promocja itp. W sekcjach techniczna no z reguły jak kod jest dobry to nie wiem co by miała zmienić taka rozmowa.

[MikeStork]

Okej, valid point. Najwyżej later on sprawdzi się taką osobę

[simon-the-shark]

@ellipsis review this

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 0fc39df in 3 minutes and 35 seconds

More details

• Looked at 203 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. src/content/docs/sections/Management/Rekrutacja.mdx:73

• Draft comment:
  Remove extraneous {" "} artifact.
• Reason this comment was not posted:
  Marked as duplicate.

2. src/content/docs/sections/Management/Rekrutacja.mdx:134

• Draft comment:
  Typo: Replace 'liczna' with 'liczba' in the KPI list.
• Reason this comment was not posted:
  Marked as duplicate.

3. src/content/docs/sections/Management/Rekrutacja.mdx:189

• Draft comment:
  Consider using the standard spelling 'hackathon' instead of 'hackaton'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While 'hackathon' is indeed the more common English spelling, this is a Polish language document. In Polish, both 'hackaton' and 'hackathon' spellings are used. The meaning is clear either way. This seems like a minor stylistic preference rather than a clear error.
  The comment could be correct that 'hackathon' is the more standard spelling globally. The word originated in English and maintaining consistent technical terminology across languages can be valuable.
  However, this is a Polish document and 'hackaton' is an accepted spelling in Polish. The comment doesn't address a real issue that impacts understanding or functionality.
  The comment should be deleted as it suggests a purely stylistic change to an acceptable spelling variant in Polish, and doesn't address any real issues.

4. src/content/docs/sections/Management/Rekrutacja.mdx:197

• Draft comment:
  Typo: 'statusty' likely should be 'statusy'.
• Reason this comment was not posted:
  Marked as duplicate.

5. src/content/docs/sections/Management/Rekrutacja.mdx:116

• Draft comment:
  Typographical suggestion: In the heading 'III Etap rekrutacji - rozmowa rekrutacyjne', 'rozmowa rekrutacyjne' should be made singular ('rozmowa rekrutacyjna') to agree with the context.
• Reason this comment was not posted:
  Marked as duplicate.

6. src/content/docs/sections/Management/Rekrutacja.mdx:134

• Draft comment:
  Typographical error: 'liczna pozytywnie ocenionych zadań II etapu' should be corrected to 'liczba pozytywnie ocenionych zadań II etapu'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While this is a real typo, it's a very minor spelling error in documentation. The meaning is still clear. The rules say to avoid obvious or unimportant comments. Spelling fixes in docs are generally considered minor enough to just fix directly rather than comment on.
  The typo does affect readability slightly for Polish readers. The comment provides a concrete fix via suggestion.
  However, this is still a very minor documentation issue that doesn't affect functionality. The suggestion feature could be used to just fix it directly instead.
  While this is a valid typo fix, it's too minor to warrant a PR comment. The fix should be made directly instead.

7. src/content/docs/sections/Management/Rekrutacja.mdx:189

• Draft comment:
  Typographical error: 'hackaton' should be corrected to 'hackathon'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While this is technically a spelling error, it's a very minor one. The word is still understandable in context. The rules say not to make purely informative comments and to avoid obvious or unimportant issues. This seems to fall into that category - it's a minor spelling issue that doesn't affect functionality.
  The word 'hackathon' is indeed the correct English spelling, and maintaining professional documentation is important.
  However, this is a very minor issue that doesn't impact understanding, and the rules explicitly say to avoid purely informative comments and unimportant issues.
  This comment should be deleted as it's too minor and purely informative, violating the rules about avoiding unimportant comments.

8. src/content/docs/sections/Management/Rekrutacja.mdx:197

• Draft comment:
  Typographical error: 'statusty członków' should be corrected to 'statusy członków'.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_1sk0sc9UBhCMZqKt

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[dawidlinek]

omg, auto review is fire

[simon-the-shark]

@ellipsis review this

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 6cc4167 in 1 minute and 42 seconds

More details

• Looked at 203 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 11 drafted comments based on config settings.

1. src/content/docs/sections/Management/Rekrutacja.mdx:64

• Draft comment:
  Consider using mailto links for email addresses (e.g., anna.kozlowska@pwr.edu.pl) to improve usability and accessibility.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While mailto links can improve usability, this seems like a minor UI enhancement rather than a critical issue. The email addresses are already clearly readable and functional. The file is documentation in MDX format, and the current plain text format is perfectly acceptable for documentation purposes. This feels more like a nice-to-have suggestion rather than a necessary change.
  The suggestion could improve accessibility for some users. Email addresses are interactive elements and making them clickable is a common web practice.
  However, this is internal documentation, not a public-facing website. The current format is clear and functional, and the benefit of adding mailto links is minimal compared to the effort of implementing the change.
  The comment should be removed as it suggests a minor UI enhancement that isn't critical for documentation functionality.

2. src/content/docs/sections/Management/Rekrutacja.mdx:76

• Draft comment:
  Consider wrapping email addresses like 'michal.skalny@pwr.edu.pl' in mailto links for better interactivity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  This is a documentation file in MDX format. While mailto links can be helpful for clickable emails, this is a minor UI enhancement that doesn't affect functionality. The email addresses are clearly readable as-is. The comment is about UI/styling rather than logic. Per the rules, we should not comment on pure UI changes.
  The mailto links could make the documentation more interactive and user-friendly. Multiple email addresses appear in the file, so this could be a systematic improvement.
  While mailto links are nice-to-have, this is purely a UI enhancement. The rules explicitly state not to comment on UI/styling changes. The email addresses are perfectly functional as plain text.
  Delete this comment as it suggests a purely UI/styling change, which is against the review rules.

3. src/content/docs/sections/Management/Rekrutacja.mdx:80

• Draft comment:
  Consider wrapping email addresses (sks@sks.pwr.edu.pl, damian.zielezinski@pwr.edu.pl, lukasz.ptaszek@pwr.edu.pl) in mailto links for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This is a documentation file about internal processes. The email addresses are part of instructions for sending approval requests. Adding mailto links would be a minor UI enhancement that doesn't significantly impact usability - users can still copy-paste the emails. The comment is about a UI suggestion rather than a logic issue. Per the rules, we should not comment on pure UI changes unless absolutely necessary.
  The mailto links could make it slightly more convenient for users to click and send emails directly. The suggestion is technically valid.
  However, this is a minor UI enhancement that doesn't materially impact the functionality or correctness of the documentation. Per the rules, we should avoid making purely UI-focused comments.
  Delete this comment as it suggests an optional UI enhancement rather than addressing a significant issue.

4. src/content/docs/sections/Management/Rekrutacja.mdx:130

• Draft comment:
  Verify that the anchor '#wdrożenie' in the LinkCard matches an existing heading id for proper linking.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the author to verify something, which is against the rules. It doesn't provide a specific suggestion or point out a clear issue.

5. src/content/docs/sections/Management/Rekrutacja.mdx:6

• Draft comment:
  Consider consolidating imports from '@astrojs/starlight/components' into one statement.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

6. src/content/docs/sections/Management/Rekrutacja.mdx:64

• Draft comment:
  Consider formatting email addresses as clickable mailto links for better accessibility.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

7. src/content/docs/sections/Management/Rekrutacja.mdx:160

• Draft comment:
  Convert plain URLs into markdown links for improved readability and user experience.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

8. src/content/docs/sections/Management/Rekrutacja.mdx:164

• Draft comment:
  Consider rewording 'danie gwiazdki' to 'nadanie gwiazdki' for clarity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

9. src/content/docs/sections/Management/Rekrutacja.mdx:130

• Draft comment:
  Verify that the '#wdrożenie' anchor in the LinkCard matches an element ID in the document.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

10. src/content/docs/sections/Management/Rekrutacja.mdx:160

• Draft comment:
  In the sentence '... rodzic, github, sociale itd. ...', it appears that 'sociale' might be a typographical error. Consider using a more standard term (e.g., 'social') or clarifying the intended term.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  Since this is a Polish document, 'sociale' could actually be intentional Polish terminology. The document uses other English terms like 'github' mixed with Polish, so this could be a deliberate language choice. Without being fluent in Polish technical jargon, I can't be certain this is actually a typo.
  I might be missing some Polish technical terminology context. Also, even if it is a typo, is it important enough to warrant a comment?
  The comment is speculative without strong evidence that 'sociale' is incorrect, and even if it is a typo, it's a minor issue that doesn't affect functionality.
  Delete this comment as it makes assumptions about terminology in a primarily Polish document without strong evidence of an error.

11. src/content/docs/sections/Management/Rekrutacja.mdx:160

• Draft comment:
  When referring to brand names, please use proper capitalization. For example, 'github' should be 'GitHub' and 'google sheets' should be 'Google Sheets'.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative and does not provide any actionable feedback or suggestions for code improvement. It focuses on capitalization, which is not critical to the functionality or performance of the code.

Workflow ID: wflow_d6ocfKWNLvFIVs3H

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[wojciechkrzos]

Alleluja i do przodu, mergen machen, wszystko śmiga