Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recruitment System #1

Closed
tbeswick96 opened this issue Mar 14, 2017 · 3 comments
Closed

Recruitment System #1

tbeswick96 opened this issue Mar 14, 2017 · 3 comments

Comments

@tbeswick96
Copy link
Member

We need to have the recruitment system fully integrated into the website and the basic member functions of the website.
Currently we use google sheets to receive and track applications, as well as track the member base.

Basic recruitment flow:

  • New people should be able to read information about the unit, and then be taken to a form where they make an application.
  • The application will create them as a member pending review. The application should be visible to SR10 (not SR1)
  • SR10 should be able to view the full application and either accept or decline based on the information given (by the applicant).
  • If the application is declined, it should be marked as declined and archived (NOT deleted). The applicant could receive a notification or see a status on their application page (thoughts? some other units with similar systems don't do anything to notify a declined application).
  • If the application is accepted, it should be automatically assigned to an SR1, who will then be able to see the application. The applicant member should be made a candidate (automatically).
  • The SR1 will then do their normal duties, and update the application status as they go.
  • Once the applicant completes stage 3 (post-candidate-op), SR10 should be able to finalise the application, which will make the member a recruit. They should also have the option to decline it again. SR1 should not be able to do this.

Application form

  • First name (Varchar 35)
  • Last name (Varchar 35)
  • Date of birth (Date)
  • Steam64 (Varchar 17)
  • Email (Varchar 100?)
  • Unit preference (Int (enum))
  • Role preference (Int (enum))
  • Previous MilSim (Bool)
  • Military background (Bool)
  • Leadership preference (Bool)
  • Personal background (Varchar 1000)?
  • Skills (Varchar 500)?

Application form details

  • The name should automatically be formatted into LastName.FirstInitial for their member username. I dislike when people don't fill this in properly on the google sheet, so some automatic validation for requiring 2 names would be good.
  • For DOB currently we have a cut off at 16, but younger people still apply and lie about their age. They don't last long but it wastes our time. There are 2 approaches we could take here. 1) Explicitly state the minimum age requirement. The problem with this is people will lie as they currently do, which wastes our time further down the line (training etc). 2) Appear to allow all ages, but if DOB given is less than 16, the application is declined and archived. Problem with this is it's dishonest, but might make our life easier as people will be less inclined to lie if they don't know there is an age requirement.
  • The steam64 is another thing people don't fill in properly. Validating this could be complicated, but for our ease, this needs to be the "76561198102245997" number. I think the best approach might be to explicitly state that only this number is required, and to validate it so only exactly 16 numbers is allowed. (Check format of steam64). A full steam link should be formatted upon submission and set in the user details. This avoids people giving an incorrect link.
  • Unit preference should be 1 Para or JSFAW.
  • Role preference should be conditional based on unit preference (Only 1 para roles show when 1 para selected, and only JSFAW squadrons show when JSFAW selected).

Details

  • One large problem we have is retention at the recruit stage. Most recruits realise we are quite hardcore milsim which they weren't expecting. To help with this, applicants should be forced to read information on the unit before being taken to the application form. This won't solve the issue totally, but might help.
  • With the google sheet currently, applications are assigned based on which SR1 are active and how many applications they have at that time. The same should be applied here. SR1 should have the option to disable themselves in their member area so they stop getting applications (SR10 should be notified of this).
  • A member should have several states: Application Submitted, Application Accepted, Application Stage 1 Complete, Application Stage 2 Complete, Application Stage 3 Complete, Enlisted, Application Declined, Discharged. (These can be expanded based on other features and needs e.g LOA) SR10 should b able to edit all of these states. SR1 should only be able to assign the "Stage" states, and only if the application has been accepted, and not if the application has been declined or any other state assigned (declined, discharged etc)

Please add further features below

@arthos-blue
Copy link

Notifications are a good idea, maybe it could go
Application Pending
Application - Accepted / Denied

Now the application is sent off to the SR1's

Application Under Review
Application - Accepted ("an SR1 will be contacting you shortly" / Denied ("your application has been denied" include any reasons why it was)

@WordyK
Copy link

WordyK commented Mar 15, 2017

Application Under Review
Application - Accepted ("an SR1 will be contacting you shortly" / Denied ("your application has been denied" include any reasons why it was)

Yes this is something that should be there. No longer will people go around and ask "so what do I do now" or "when I will be contacted"

@Alwandy
Copy link

Alwandy commented Mar 23, 2017

wip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants