_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!
