diff --git "a/projects/projects_2024-25/Report-Micha\303\253l-Halleux-10692000.md" "b/projects/projects_2024-25/Report-Micha\303\253l-Halleux-10692000.md" new file mode 100644 index 0000000000000000000000000000000000000000..fa82c651027ddcce76c7bbdfa91a4d592d5d67fc --- /dev/null +++ "b/projects/projects_2024-25/Report-Micha\303\253l-Halleux-10692000.md" @@ -0,0 +1,94 @@ +# LINFO2401 project report - Contributing to an open source project + +| **Author** | Michaël Halleux | +|-------------------------|----------------------------------------------------------------------------------------------------| +| **Date** | 02/12/2024 | +| **NOMA** | 1069-2000 | +| **Academic Year** | 2024-2025 | +| **open source project** | [EuropeanFootballLeaguePredictor](https://github.com/nickpadd/EuropeanFootballLeaguePredictor.git) | +| **Pull request made** | [Setting up the project #84](https://github.com/nickpadd/EuropeanFootballLeaguePredictor/pull/84) | +| **License** | [MIT License](https://github.com/nickpadd/EuropeanFootballLeaguePredictor/blob/master/LICENSE.txt) | + +## Project: EuropeanFootballLeaguePredictor +_The following project description is a "copy and paste" of what was written by the original project maintainer._ + +EuropeanFootballLeaguePredictor is a predictor of europes top league games based on historic performances of teams, +taking into account only advanced league table statistics. It uses traditional machine learning techniques and +statistical modeling in order to deduct data driven predictions based on the team’s season performance and recent form. +The EuropeanFootballLeaguePredictor includes EnglishPremierLegue, La Liga, Ligue 1, Bundesliga, Serie A. + +The EuropeanFootballLeaguePredictor project and its associated predictions are provided for informational purposes. +The predictions generated by this project should not be considered as financial advice or recommendations to place bets +on any Premier League matches or other events. +Betting involves risks, and there is no guarantee that the predictions provided by this project will result in accurate +outcomes or profitable bets. The outcomes of sports events can be influenced by a wide range of variables that may not +be fully captured by the prediction model. + +## Choice of the project +To choose my project, I first asked myself what open source software I used on a daily basis. After listing them, I +realised that they were not suitable for me as my first contribution to an open source project because they were often +too large and complex. + +So I started to look for open source projects on the Internet to find one that was suitable for the work related to the +_LINFO2401_ course. I had four conditions that had to be met before choosing a project. +These four conditions, carefully prioritised, structured my search for a project. If the first condition wasn't met, I +didn't go any further and immediately moved on to exploring another project. This reasoning is similar to a decision +tree: ‘if condition 1 is satisfied, then examine condition 2; if not, give up and look for another project’: +1. A theme that I like and that I enjoy +2. Recent activity on the part of contributors +3. A project that's not too big (it's not very precise but my gut feeling is an excellent radar for that) +4. Possible interaction with the contributors + +So I saw this project, the main subject of which is sport, which is one of my passions in life. And the underlying theme +is machine learning, a branch that particularly interests me. I thought it would be a great opportunity to combine my +passion with my professional interests. + +## Contribution +I preferred to contact the project manager first to explain the context and get his agreement. Even though I wasn't +obliged to do this, I felt it was a mark of respect and it seemed to me to be part of the stages of contributing to a +project from what I had understood during _LINFO2401_. I therefore understood better who the author of this project was, +what he did for a living, why he wanted to do such a project and what his objective was with it. + +First of all, I had to set up and read the project for the first time. I realised that the project had a lot of +dependencies and this caught my attention. After talking to the author of the project about some of the ideas I had, but +especially about the feedback he'd had from users, I knew what I could suggest to try for improving part of the project. +In fact, according to him, users often had similar problems installing the project and running it locally. Often they +weren't familiar with the _poetry package_ and they had a lot of version problems when installing the dependencies. As +this seemed to be a recurring problem, I thought it would be a great way to contribute to the project and save the +maintainer time by not having to deal with the same issues over and over again. + +So I've developed two scripts to ensure maximum compatibility: a batch script (.bat) for Windows, designed to run via the +command prompt, and a bash script (.sh) for Linux and macOS. Although the languages are different, the two scripts have +exactly the same behaviour. These two scripts install all the project's dependencies with the correct version in a virtual +environment on the user's machine and explain the problem clearly to the user if they do not have the correct version of +python. + +With this in mind, I've decided to remove Poetry (and everything connected with it) in favour of centralised dependency management with the requirements.txt +file. This allows me to simplify the management of dependencies, avoid the reticence associated with Poetry and guarantee +a single, uniform method of installation, while limiting potential problems in the future. + +Advantages: +- The user has virtually nothing to do thanks to the script. +- The readme is easier to understand and more compact. +- If an error is reported, it's easier to understand what the problem is because all users will do exactly the same thing +(only running the script). So it's easier to understand where the problem is coming from. +- Dependencies are centralised in one place. +- The project is simplified in terms of number of files and number of lines (in fact, I removed 3950 lines from the +initial project and added only 139). + +Discussions with the maintainer also helped me understand how the contribution process worked on his project and how he +wanted us to suggest improvements. I asked him if I could make a pull request with my proposals without there necessarily +being an issue created for this beforehand. I thought it was important to try to respect and understand the contribution +process he was using in the project. + +## Conclusion +I know that I haven't carried out my pull requests in the way that good conventions would dictate. After making my first +pull request, the vast majority were accepted but some minor changes were requested. So I closed that pull request and +opened a new one that showed the changes that had been made. I know I should have changed this on my first pull request +to keep a clearer history of the changes. That's one more thing I've learnt thanks to this contribution! + +In conclusion, I think and hope that this contribution will solve some of the problems that users had. In any case, I +think it will help users who are less at ease with the domain. And I also hope that it will make maintenance work easier +afterwards for the developer. +I've been able to learn about lots of different areas thanks to my first contribution to the world of open source, +and it's made me want to make sure it won't be my last! \ No newline at end of file