Merge branch 'master' into 'master'

adding report - Michaël Halleux

See merge request ldricot/lingi2401!369

projects/projects_2024-25/Report-Michaël-Halleux-10692000.md

+# 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