kavignon / fsharp-mentorship-automatic-planner

F# automation with the purpose of pairing mentors to mentees for F# mentorship rounds. It reduces the matching periods lasting several hours to a few minutes + clicks.

Hi there 👋

My name is Kevin Avignon, and I am a senior software developer based in Montreal, Canada. I used to be a board member for the F# Software Foundation (FSSF). I led for 2 years the educative efforts for our international mentorship program and over that time, I had community members engaged with me as we built a platform to do match making between applicants (mentors/mentees).

You can find a list below of what I'm currently focused on:

• Exploring BEAM, Rails & Elm as I'm writing the online book Beware of Dragons

• I write posts on my technical blog from time to time.

  

fsharp-mentorship-automatic-planner's Issues

Documentation: We need some

Creating some documentation in the form of a README might be interesting at some point.

Re-engineer the automation for the mentorship planner

The project was built out of the need to make life easier for the person (me at the time and still as of today) leading the mentorship program for the F# software foundation. This tool was built very quickly, but that doesn't mean it's a bad implementation. The heart of the issue is that there isn't any tangible documentation for the usage of the application, which makes it harder to use (I forget the exact series of steps to follow, and I'm the maintainer). Furthermore, along the way, people contributed to this project (thank you for doing that - I truly appreciate taking time out of your busy schedule!), but that ultimately led to several problems, such as the main branch not being able to compile.

The current problems that I saw were:

• There isn't any form of testing to validate the current version of the implementation and confirm that the behavior is still correct.
• There isn't any form of CI process which validates that the contributions aren't breaking the current implementation
• There isn't any form of documentation that can showcase to a given user what they have to do to make pairings and then send the emails to the mentors/mentees.
• There isn't any tangible structure to the state of the code right now for such a small application. It's effortless to get yourself lost in the code while trying to find your way around (again, as the core maintainer, this is a huge problem)

The current implementation will be re-evaluated and simplified to ensure that the code can evolve without becoming overly complicated or hard to follow. To that end, here are the features that I am looking to get from this re-engineering:

• Parse the content of a CSV file containing the information of all the applicants
• Breakdown applicants to either mentors or mentees
• Evaluate the strength of a pairing between a mentor and a mentee. This is evaluated by ensuring that they have a match in their F# topic and that they have an overlap in their weekly schedule. More emphasis is given to rarer topics such as compiler work or machine learning with F#.
• Ensure that a mentor is paired with the best mentee they can get based on the strength of the pairing. To avoid redoing the computation from the past, it'd be an interesting feat to run benchmarks to compare finding a pairing for mentors like before vs keeping all the pairings of a mentor in a max-heap that is fit to K (K being the max number of students that they want) or even investigate leveraging quickselect.
• Have HTML content template for the emails to send to an approved mentor / approved mentee / rejected mentor / rejected mentee.
• Send emails automatically to all the applicants. We must ensure that there is some sort of secret pass around from somewhere to make the code secured OR pass on the password to the SMTP client every time we need to use the application.
• Allow mentors to have more than a single pairing if they wish for that
• Have a list of topics that can be used in the mentorship
• Allow a mentee to have multiple topics of interest for the mentorship
• Provide a CI pipeline that can confirm that the repository can build and run the test suite successfully
• A mentor with multiple mentees cannot have overlapping schedules with simultaneous mentees
• Add mentors to the private mentors channel if they're not already there (investigate the Slack API to see if that's a possible feature - not a hard requirement)
• The tool should support digesting timezones over utilizing UTC offsets. It'll lead to fewer bugs and will make sure that NodaTime can play with dates easily.

Improvement: Allow multiple topics of interest (for mentees)

I believe that currently mentors can specify multiple 'fields of expertise' but that mentees can only select one topic that they want to learn. We will open this up so that mentees can select multiple topics they might be interested in. The matcher should be reviewed if it can deal with this scenario and changed if necessary.

Improvement: Test the matcher on correct timezone/slot matching.

I've heard some feedback that people received a 'possible meeting' time slot at a time which they did not select (it is also possible that these people didn't fill out the form correctly). Either way, we should create better test cases for this.

Format code with Fantomas

As discussed on the F# Slack, we'll reformat the code here with Fantomas.

Improvement: Adapt the matcher so we only match people that are within a certain timezone margin

While the matcher currently matches on overlapping time slots successfully, it creates situations where the people who get matched are in completely different timezones. We've received some feedback that when the timezone difference is too big (e.g. 10 hours) this can be a difficult experience.

We should extend the matcher with functionality to restrict the possible overlap if we which to do so (e.g. only match when people have <10 hours timezone difference).