People always ask \"why this repo\" and never ask \"how is this repo\", so I created an app that finds how happy a repository is.\n\nTLDR; The app runs a sentiment analysis engine on your repo and finds how happy it is. Check repostatus\n\n## How?\n\nSo how exactly do you find the sentiment of a non living thing? Well, even I had that thought in my mind. Any repository is made up of people that contribute to that repo, people that interact in the repo's comments.\n\nSo, if we are able to run a sentiment analysis engine on the interactions of the people that are contributing to that repo, we might get somewhere?\n\nrepostatus extracts three important part of the repo (by using GitHub's API):\n\n- the commit messages\n- the comments on the issues\n- the comments on PR's\n\nOnce, we have these three things, we can combine them, filter out the unnecessary data and run our engine on it.\n\n## Tech\n\nThe backend is written in Python (FastAPI) and the frontend is written in Vue\n\nFirst things first, the sentiment analysis engine used by repostatus is the textblob library. It is very easy to use and works great.\n\nSo now that we have the engine at our ease, what's next.\n\n### Backend\n\nMy goto tech stack is Python so no wonder I went with that for the API.\n\nI used FastAPI for the backend. Off late, I have started liking FastAPI more and more and it was an obvious no brainer to go with it for the backend. It's ease of use with the efficiency is just awesome. If you haven't checked it out, do that, I'm sure you'll love it if you're a Python developer.\n\n#### Services\n\nServices that the API will offer are:\n\n1. Internal API for the webapp\n2. Public API\n3. Badge API (Yep, you can use repostatus badges on your README).\n\nI wanted to provide a Public API so that people would be able to use it for their own fun projects. The API is capable of working with both private and public repo's. The details for that can be found here\n\nThe badge is another thing that I thought would be a nice little addition. This badge works similar to how the travis build badges work or any badge. You can simply use the URL to embed it into your repositories README.\n\nMore details about the badge can be found here.\n\n\n\n### Frontend\n\nI love using VueJS. It was obvious that I would use that to build the frontend. Now for the frontend I wanted to make sure that it doesn't restrict the user too much.\n\nThus, repostatus works with both private and public repos. For private repos, GitHub's OAuth is used which gives us access to that particular repo and then we run the engine over the repo.\n\nOne issue that I faced while implementing the OAuth was that I wanted to make the process seamless. If you go the the app now and select on the OAuth option, you will see the process is pretty neat.\n\nHere's what it does:\n\n1. Opens a new window and asks the user to give access\n2. User gives access and GitHub redirects the user to my sites callback endpoint.\n3. Window closes and the app shows all the users repos.\n\nThe above steps makes it look real seamless. However, the hard part for me was to figure out how do I know when the OAuth is done and then show the window.\n\n#### Seamless OAuth\n\nSo in order to make it seamless, I implemented the following flow:\n\n1. User clicks on OAuth button, new window is opened and the app keeps waiting for it to close.\n2. In the new window, the user is redirected to the callback URL which returns a nice HTML page that shows the user that the window will close in 5 secs. After 5 seconds the window closes and the app knows that the OAuth is done.\n3. The app then tries to find the repo's of that user and accordingly shows the user all the repos.\n\nI know, it's not much. I have to say, though, I really liked implementing this one little feature and making it so seamless. I'm not even kidding, I just kept on doing OAuth on repeat after implementing it, for a while.\n\n## Badge\n\nAn example of the badge can be seen below.\n\n\n\nIsn't it cool?! It supports options like style of the badge where for-the-badge can be used. It changes the color of the badge based on the happiness status of the repo.\n\n## How is happiness exactly calculated\n\nAs I mentioned earlier, the happiness of any repo depends on certain parts of the repo. Thus, once the commit messages, issue comments and the PR's comments are extracted, they are run through a filter.\n\n### Filtering the data\n\nThis step makes sure that the data is cleared off of any unreadable content, like an image that the user might have posted in the comments. Or some code inside a code block that the user might have added in an issue report.\n\n### Running the engine\n\nOnce the data is cleared off all the unreadable content, it is passed to the textblob library that runs the engine on the data.\n\nNow, this library returns a float score. This score is between -1 and +1 where +1 indicates happy and -1 indicates sad.\n\nThus, when the engine is run on the comments, let's say we get a score of 0.8, this means, based on the comments, the repo is not that happy but it's more happier as compared to being sad. So repostatus considers that based on the comments the repo is happy.\n\nWe do the above process on other aspects of the repo too, the commit messages etc.\n\nOnce, all the individual scores are available, they are added up and an average is calculated. This average, mathematically, is also between -1 and +1. This is the overall happiness status of the repo.\n\nBased on this score, it is decided what color is to be assigned to the repo.\n\n### Caching\n\nSince the engine takes a pretty hefty amount of memory, the score of any repo is cached for 15 days.\n\nThe badges are cached for 24 hours and only after that they are updated.\n\nThis caching was necessary in order to make sure the performance of the API was not effected.\n\n### Try repostatus here\n\n### Source\n\nrepostatus is open source. Source for the backend and the frontend can be found below\n\n{% github trotsly/repostatus %}\n\n\n