Jake wants to narrow down the recruiting pool down a little to get the right people because we don’t have the space to accommodate people in our projects
Caleb summarized the recruiting process last year: no distinction for roles and go to respective project leads for what to do. The result was lots of people were very interested but then the attention from people got diminished
A lot of the people went were a lot of freshman that didn’t have a lot of experience (majority were engineers)
The org didn’t know what to do with newbies and how to give them a good experience participating in the club works
Shaurya: For API team, there were a lot of interests in the first few weeks but after several weeks later, people’s interests were diminished which is quite problematic because the retention problem can result in distraction from running the projects. One potential solution is to select a few peoples who are qualify and assigned them into a project.
Caleb: Didn’t know what to do with the newbies because they lack experience aside than letting them watch and observe. ACM also tried teaching newbies React for a month, it somewhat works but still resulted in dropoff after a few months
Jason: For me personally, I’m the type of person who wants to jump into work immediately and figure it out on my own but that’s not the case for many people. The questions boiled down to the fact that are we willing to bring in people and mentoring them for our projects
Kevin: We should probably accept people who have at least 1 year of experience.
Shaurya: Partnering with ACM to let people graduates from their projects to work with Nebula Labs
David: Nebula Labs are founded under the principles of open sourced project. Pipelines are good but we should make it easier for people to join
Caleb: Reflection from Freshman year where people getting rejection from ACM and it left a bad taste to people because it feels like a company environment instead of a student org to help students to grow. Been thinking a lot about keeping a transparent recruiting process and giving people resources to grow professionally.
David: Maybe we can try keeping our organization open where people can come to meetings and have the opportunities to get involved (like just general observations rather than mentoring people so people can jump in to try to help to help bridge the gap). We want people that are driven (willing to learn) not skilled.
Kevin: We can keep your meetings and projects open but we need to make it very clear that you can still join but you are not gonna get anything out of it if you didn’t put in the work.
Jason: not big on application, doesn’t align with hack culture
Ruben: But how do we differentiate between someone who is dedicated and willingness to learn and someone who is not dedicated and just curious
Kevin: Yeah but if we let them filtered them through, it’s a waste of time
David: We want an org that can retain our projects in the long term rather than burning through the projects quickly (in another word: don’t make them to efficient)
Caleb: I’m going to push back on this because I don’t think we will go through this quickly because there are still a lot to do from product to design
Kevin: Give example from PennLabs where there are a lot of projects but they are still existing and have a lot of work to do so it’s not a concern.
Caleb: There’s no solution to this but agree with David on the visibility test.
Jason: What if someone who is experienced and qualify can just apply to be a member quickly? Using a basic screening that demonstrates some kind of experience
William is here!!!! YAY~! ^^
Caleb: Maybe let people self selecting where people choose what they think it’s best for them, where we give them a list of projects and then ask people choose they want to go based on their experience.
Shaurya: Newbies dabble on different projects and never committed to the projects. Maybe assigned them into projects based on their skills and interests.
David: Like the idea
Caleb: If we do that, then maybe not ask people what projects they are interested in because it limits our flexibility
Jake: The reality is gonna be people will think that I see this project X is awesome, but I’m not qualify for this
Jason: Maybe be transparent and clear about the qualifications that are needed on this project.
Shaurya: That’s a good idea, we can express clearly that certain projects needed certain roles and so on
Ragini: Maybe we can do a rotational program
David: I like this idea, and maybe after they become a member, they can pick what projects they want to become apart of
Jake: But will people agree with that though?
Caleb: Yes but it also depends on how we market it. We can just focus on focusing on marketing NL as an org, and one of the perks being a member and u can pick a cool project you can be apart of
Kevin: but how is this different from filtering people and being selective of people
David: Throw newbies into bootcamps, and move them into projects into the second semester if the interest remains.
Jason: Not big on assigning projects to people because it takes away their agency
Kevin: Open source projects takes a lot of time and efforts and it’s hard to become one
Caleb: But assigning projects is important because it allows us to keep the project quality and have even distributions.
Caleb: Believe there are much rooms to grow in various projects and that’s why we have a product team so we have someone to assess what we need to build. So we don’t need to worry about running out of stuff to do.
David: It’s hard to keep a distinction between an open-source organization vs structuring as a company
David: Maybe implement paired programs where tickets are still being resolved but new people are not getting annexed . It’s hard to not cut the inexperienced people out because we need to keep some kind of filter to keep the projects going.
Caleb: From PM perspective, worst part was not having experience/resources to support new people and leaving them with a bad experience
Jake: Similar, I don’t really know how to help other than point people to other resources. “is it my goal to 1:1 mentor people?”
Hilary: I think this is only applicable for engineering?
David: Engineering will have the most number of people coming, so this is mostly targeted for engineering
Hilary: As design head I don’t have capacity to train people w/ 0 design exp.
Sharon: For product, maybe we can put experienced people with new people in some sort of ratio?
Caleb: will experienced people take on a mentorship role?
Sharon: yes; give opportunity to new folks to learn from more experienced team members
David: we need to be careful that we don’t call “new people” a “burden”
Hilary: yes; that’s why we want to have some sort of a filter
William: go to this club to learn, then come back to us
Hilary: partner with different clubs; send interested people to those clubs and get experienced people from those clubs.
David: need to make a clear distinction between new people who are motivated to learn but don’t have exp. vs ppl who don’t care + don’t want to learn
Caleb: observation period, get new people to see other projects, after 2 wks get ppl matched to other teams via interest form or reaching out to project lead directly
David: require people to attend 2 project meetings (diff or same project) and one division meeting before being able to contribute, use this as a natural filtering mechanism